Application Platform Strategies Blog

Why Microsoft Loves Google's Android

Blogger: Richard Monson-Haefel

Note: due to inconsistent use of terminology this blog post can be confusing. It's been replaced with a new entry "Why Microsoft Love Google Android, Take 2".  It's recommended that you read that post rather than this one.

You won't hear Microsoft say this out loud, but secretly they are celebrating Google's contribution of the Android mobile phone platform to the Open Handset Alliance - at least they aught to be. Android is perhaps the best thing to happen to Microsoft since they won the browser wars in the 1990’s.  And given Verizon’s announcement yesterday that they will be opening up their network to any device and operating system that meets a "minimum technical standard" it seems that Android may have legs even if Google doesn't secure the 700 MHz spectrum.

Microsoft's biggest competitor in the software development industry has been, for the past 12 years, Sun Microsystems' Java Platform.  Starting in the mid to late 1990's Java began to gain mind share among developers in every area in which Microsoft has an interest. Today, with over 6 million developers (according to Sun) Java clearly dominates the software development industry.  Point in fact, Microsoft had to completely revamp their software development platform in 2000 to mimic the Java platform in order to complete; enter Microsoft .NET.  While Microsoft .NET has been extremely successful at winning back a portion of the developer community from the Java platform, Java has remained the darling of the enterprise and perhaps the most successful software development platform in the history of computing. Microsoft really doesn't like the Java platform very much. Java is Microsoft's biggest competitor in software development and is arguably the platform to beat. 

The Java platform and its standardization process are not perfect. A series of missteps by Sun Microsystems and the Java Community Processes (JCP) have contributed to the growing success of Microsoft .NET. The JCP which defines the Java standards has allowed the enterprise platform, Java EE, to become unbearably complex and has created an ecosystem for its mobile platform, Java ME, which is terribly fragmented despite its overwhelming penetration (8 out of 10 phones ship with Java). The foundational platform, Java SE, however has remained a strong competitor and has given up very little ground to Microsoft, but all that is about to change with the introduction of Google's Android mobile platform.

To put it bluntly: Android as it is currently defined is a fork of the Java ME platform. Android is similar to the Java ME, but it's a non-conformant implementation.  Android is not compliant with Java ME nor is it compliant with Java SE. In fact, it’s not really Java. Although it uses the Java programming language, the core APIs and the virtual machine are not consistent with the Java ME or SE platform - it’s a fork. This was first pointed out by Stefano Mazzocchi in his November 12th blog entry entitled "Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME". Stefano missed the fact that Android does not properly implement the CDC or CLDC Java ME APIs (a minimum requirement for Java ME conformance) - but kudos to him for being the first to report on the fork. The fork has since been picked up in the blogsphere by others here, here and elsewhere.

The forking of Java is good news for Microsoft for a couple of reasons. First, from a marketing perspective the Java platform's greatest strength is standardization and multi-vendor (e.g. IBM, Oracle, SAP, etc.) support. In comparison, Microsoft .NET is a portrayed as a proprietary platform that locks-in organizations to the Microsoft platform. That's the marketing message which has been used by Java proponents for a decade and it has been extremely successful. But now, with the introduction of Android, the solidarity around the Java platform could crumble.  If Android, as it’s currently defined, is successful then Java will no longer be consistently implemented at a fundamental level.

Microsoft offers an excellent mobile platform of its own, Windows Mobile and Microsoft .NET Compact Framework. It's proprietary, that's true, but it’s consistently implemented and extremely powerful platform for developing Rich Mobile Applications (RMAs).  In comparison, Java ME is a standard that has a wealth of functionality and is supported by dozens of vendors, but its implemented inconsistently across mobile devices making it extremely difficult to develop applications that will "write once, run anywhere". If Android succeeds (time will tell) then Java on mobile devices will loose its hold on the market. Android may win, but Java ME will loose.  If I was in the Windows Mobile and .NET CF marketing department I would be popping the cork on a huge bottle of champagne the day Android is released. It's the best thing that could have happened to Microsoft's mobile platform.

OK, so if the Java mobile platform will falter because of the introduction Android, how does that impact Java SE? After all, Java SE is used for desktop and server-side development. How is that threatened by a mobile platform? Good question. Here's why: Sun has been moving toward unifying the Java ME and Java SE platforms for a while now.  This was pointed out in an excellent analysis by Caroline Gabriel of Rethink Research. As part of the evidence for her argument Caroline references a quote from James Gosling the "father of Java” in a CNET interview just last month.

"We're trying to converge everything to the Java SE specification. Cell phones and TV set-top boxes are growing up," Gosling said at a Java media event here Wednesday. "That convergence is going to take years."      

But don't take James Gosling's word for just take a look at JavaFX Mobile, which Sun Microsystems announced earlier this year. It's based on the full Java SE platform, not Java ME. In a nutshell Sun Microsystems isn't betting on Java ME for the long-haul, they are betting on Java SE.  After all, Java ME was developed for "constrained devices" with limited memory and processing power. However, as technology advances that label no longer applies to mobile phones in general. Smartphones are becoming powerful, if smaller, computers with complete operating systems, lots of processing power and plenty of memory. The era when mobile phones are simple appliances is coming to an end - mobile phones are becoming a complete computing platform.

The reason a phase out of Java ME and the expansion of Java SE to mobile devices is so important to Sun Microsystems, is that it meets Sun’s original goal for Java. It establishes a single platform for all computing devices. It makes excellent sense and improves the argument that Java is a standard consistently implemented across computing platforms. Sadly, however, by the time that happens Android may have already Balkanized the mobile Java community into Java ME and Android camps.  The “one platform to bind them all” party may be over before it gets started.

Assuming the demise of Java ME as a standard platform for mobile development is nearing and that Java SE will take its place, the question of a consistent platform across all computing devices becomes even more important.  How do you sell people on Java?  You tell them that it’s a standard used across mobile, desktop, and server applications.  You tell people that the skills your enterprise developers gain writing desktop and server-side applications will translate directly to the mobile platform. 

Unfortunately Android undoes all that. It tells the industry that Java is not consistent across computing platforms and that using the Java language, but not the APIs or virtual machine is just fine as long as the end result is a workable solution.  That leads us to the assumption that if it works for the mobile industry then why not the desktop or the server-side? Why can't other vendors introduce platforms that use the Java programming language and some of the Java APIs, but is otherwise inconsistent with the Java platform? What's the harm of IBM or Oracle having their own version of Java as long as it works?  You'll find the answer to that question in historical records when Sun Microsystems successfully stopped Microsoft from adding proprietary extensions to the Java platform in the 1990's.  As pointed out by Maureen O'Gara there is some irony here. 

“The sweet irony is that this greatest threat to Java since Microsoft should come from Google CEO Eric Schmidt, the guy who originally led Java development at Sun and signed the contract with Microsoft, leading to the Java wars.”

Java's greatest strength today is uniformity and ubiquity. Take away uniformity and you end up with many different kinds of Java and so there is no real ubiquity. Take away ubiquity and there is very little incentive to choose the Java platform over other options like Microsoft .NET. In fact, Microsoft .NET starts looking a lot more attractive because it is consistently implemented; not Balkanized. If .NET is just as powerful as Java, why choose a solution such as Java that is inconsistently implemented across vendors? The strongest marketing asset that Java has today, "write once, run anywhere" standardization, is effectively lost.

Verizon opens up its network. Wow!

Blogger: Richard Monson-Haefel

Verizon announced yesterday that they will be opening up their network to any device or operating system that meets a "minimum technical standard" starting in the second half of next year.  This is fantastic news provided it comes true - its also a huge boost to the potential of the Android platform because Google will not need to acquire the 700 MHz spectrum to make it succeed (although they still have an API fragmentation problem not to mention the forking of Java). Like many I'm cautiously optimistic. A great analysis as to why we should be cautiously optimistic is provided by Om Malik in his blog entry "Why Verizon Went Open and What it Means".

SOA and Economic Theory

Blogger: Anne Thomas Manes

Here's a great article on SOA and economic theory (supply and demand/trust and incentive) by Jake Sorofman on searchsoa.techtarget.com.

When bottom-up success calls for top-down perspective

Blogger: Joe Niski

A recent request for perspective and advice really got me thinking.

Company X has a very successful software testing team. Their success is easy to measure: development projects aren't required to use the testing team, and are billed for testers' time - and the testing organization is fully utilized because they provide real value to development. Congratulations - customers are beating a path to your door! Many organizations I speak with (and many I've worked for) would consider this a great achievement - and in the often-contentious realm of enterprise software development, it is.

Of course, things aren't 100% ideal - accurate performance and load testing is a challenge, as it is within most large companies, and testing isn't part of an overall quality-assurance initiative or organization. But the software testing group is regarded as an essential feature of the development landscape.

In many ways the structure of Company X's testing organization is fairly typical. Test staff are matrix-managed, reporting to project managers and the testing manager. Testers are engaged with projects throughout the development lifecycle, and serve as a bridge between development and operations. Although project-level testers are charged to projects, testing tools (expensive, enterprise level tools) are centrally funded out of the IT operations budget. The testing organization does not report to executives in charge of development, which reduces conflicts of interest between quality and features/schedule/budget.

However, it's their location on the org chart that's raising questions. Due to historical reasons, testing reports into the head of IT operations, at the same level as a peer of the helpdesk and desktop support teams. Company X is examining it's overall IT organizational model, so the question about the proper "home" for testing has come up. It makes sense to keep the chain of command apart from development, but in the absence of a broad quality assurance organization, where should testing reside? Stay in operations, perhaps with additional matrixing into server and network teams (in the hope of facilitating performance & load-testing improvements)? Or does an opportunity exist for becoming the seed of a full-fledged QA group, as a peer to development & ops?

My risk-avoiding gut says not to mess with success and leave things as they are. But my head (still smarting from the lumps incurred by failing to pay attention to the potential effects of reorganization during my own career) says to identify your allies and sponsors (both inside and outside your direct chain of command). Get to know who knows about your good work, and to seek their advice. If your success is at the grass-roots level, you can't always assume executive-level support - and that level of support may be needed to avoid getting lost in the re-org shuffle. More importantly, the internal high-level contact can provide valuable perspective and may reveal interesting opportunities.

Android will be as fragmented as Java ME unless ...

Blogger: Richard Monson-Haefel

I've been researching Android, Google and friends answer to the mobile phone market, and it looks great until, that is, you read the fine print.  Google says that the members of the Open Handset Alliance (OHA) have all signed an agreement not to fragment the platform, but what does that mean?  It's hard to say without seeing the wording of the actual agreement, but if the API documentation is any indication it doesn't mean much.

According the the documentation the really interesting APIs such as those used for Location (e.g. GPS), 3D, Bluetooth, accelorometer, Wi-Fi, etc. are ... wait for it .... "Optional APIs". In other words, any given implementation of Android can pick and choose to implement whichever optional APIs they want.  This means that there is no guarantee that, for example, an application that uses GPS and BlueTooth is going to work on your mother's  Android compliant mobile phone.  In fact, I'll bet that consistency among handsets with regard to supporting these optional APIs will be poor. 

This should come as no big surprise to folks who do Java ME development because Java ME has exactly the same problem. Different mobile phones may implement the same basic Java ME configuration and profiles (at least CLDC 1.0 and MIDP 1.0) but they can also implement any combination of about two dozen optional Java ME APIs.  This is why Java ME is "fragmented" and its a problem that will occur with the Android platform as well.

The way to avoid fragmentation is to establish different stacks that specify a minimum baseline for Android phones that support optional APIs.  For example, the Android "Complete" stack would support all of the optional APIs.  Android "Advanced" stack would support some subset of the optional APIs. The Android "Basic" stack would support none of them. Once you establish standardized stacks you can minimize the fragmentation somewhat but it's still an issue. Java ME has these types of stacks starting with what is unofficially called GEN-1 (CLDC 1.0 and MIDP 1.0), the JTWI, and most resently the MSA.  With each new stack, or umbrella specification, Java ME gets tighter but vendors are under no obligation to implement these profiles.

If Android is to succeed it should offer only one stack. Otherwise what's the point of using Android over Java ME? Very little as far as I can see - they will both be fragmented and therefor impractical for mass consumer applications.

Of course, Google promises a much more open network but as I argued in a previous post that isn't going to happen unless Google secures the 700 MHz spectrum.  One advantage to Android: There will only be one implementation of the virtual machine and operating system - at least that seems to be the case. However as the Linux kernel on which Android runs is ported to different devices those ports may have small differences in exactly how phones carry out tasks close to the metal. Ports could diverge and inconsistencies may arise from one handset to the next. Another advantage of Android is the capability to change the look & feel (L&F) of the interface itself and to replace any application - even the basic dialer - with a third party application, but that will depend on the network operator. For example, T-Mobile, a member of the OHA, indicated that it will have some type of certification process for android applications running on their networks - you can bet that they are not going to give up L&F branding to third-party developers.

There are a lot of pieces that need to fall together to make Android more successful than Java ME.  Java ME  is shipped on 8 out 10 mobile phones today, but mass consumer applications of any value (beyond simple games) are just not practical.  If Android suffers from the same framentation problem and is far less pervasive than Java ME, then it doesn't offer a very compelling product.

I actually like the Android architecture and have high hopes for the platform, but the reality of mobile application development today in the mass consumer market is pretty discouraging - its hard not to be a skeptic.

UPDATE 11/28: ARCchart has published an article arguing that Android could eliminate fragmentation in the Mobile Linux world. It's a great article and while Android may resolve fragmentation in Mobile Linux it still suffers from fragmentation at the Java API level.

Annotations: Are they a step forward or backward?

Blogger: Anne Thomas Manes

Paul Fremantle wrote recently about the new JSR181 annotation support added to the Apache Axis2 project. JSR181 allows you to add annotations to a Java class or interface, such as "@WebService" and "@WebMethod" to automatically convert the class into a web service and a method into a web service interface (portType). You can use these annotations in place of writing a services.xml configuration file or running utilities like java2wsdl and wsdl2java to generate the WSDL and services.xml configuration files.

For people that prefer the code-first development approach, annotations look like a wonderful feature. Just write your code, add a couple of annotations, compile, and presto -- you have a web service. What more could you ask for? Dennis Sosnoski wrote an excellent article explaining some of the advantages of the code-first approach. When used with build tools, such as Ant and Maven, the code-first approach also enables a lot of highly productive automation.

At some point I'm going to write a full-length rebuttal to Dennis's article explaining why I think code-first development is such a bad thing. His approach of adding a layer of abstraction by using a separate data binding framework (JiBX, in this case) to generate the WSDL and schema is a step in the right direction, but I still have a fundamental problem with generating schemas from code because it results in a proliferation of incompatible schema types -- increasing redundancy and complexity. Schema types should be the first-order sharable entities within a SOA initiative.

Annotation-driven development assumes code-driven development, and given my opinions about generating schemas from code, you can imagine that I'm not going to be a fan of annotations.   But I have more fundamental concerns about annotation-driven development. For one thing, in order to compile a class containing annotations, you have to include a proprietary JAR in your classpath that is responsible for compiling the annotations. Paul touches on this point in his blog post:

[I could write a whole blog post about whether Java with annotations are really POJOs! After all, to compile a normal Axis2 POJO service I don't need anything Axis2-related in my classpath - I fix all that up later with XML descriptors. In this case, although the annotations are standard, I still need to have WebService specific JARs in my classpath to compile these "POJOs".]

Paul also goes on to explain about all the cool stuff you can configure using annotations. Basically, anything that you could configure in the services.xml file could also be configured using parameters in an annotation. But, of course, that means your annotations are no longer simple. And, they rapidly become proprietary -- because every framework supports a unique set of annotation parameters. Once you add annotations to a class, it's no longer a POJO.

I'm also really concerned about embedding infrastructure-related functionality into the application's source code.  I'd much rather keep all that infrastructure-related stuff in a configuration file that can be edited without going back to the source code. Today you may want to expose the service using SOAP and WSDL -- but at some point down the road, wouldn't you also like to expose it using a RESTful HTTP interface or whatever the next latest and greatest middleware technology might be? Do you really want to go back to the source code to update an annotation?

Keeping infrastructure-related information in a configuration file is a good thing. Admittedly, configuration files have become a lot more complicated than the average developer would like. And no one really prefers to write in XML. But I don't think this move to annotations is any better. All we're doing is shifting the complexity, and in the process, we're reducing the flexibility of our code. I really think annotations are a step backward.

Enduring truth or fad - Titles, Patterns and Metrics

Blogger: Chris Haddad

When titles such as 'VP of SOA' get bandied about, sentiment points to either an irrationally exuberant bubble about to burst or an enduring discipline being enshrined in organizational culture. A technology executive focus on the convergence between technical architectures and the architecture of the business (e.g. strategy, organization, business models, processes, market differentiation, channel communication) can overcome cultural inertia preventing improvement in IT service delivery and break the legacy logjam hindering alignment of IT systems with strategic business initiatives.   However, I think putting SOA in the executive title is a transitory fad rather than an enduring position. Remember how companies quickly dropped a '.com' suffix from their name?  I disagree with Zapthink's statement that a 'VP of SOA position is a fundamentally new role'.    Every IT executive position today, including CIO, VPs of Enterprise Architecture, and VPs of LOB IT, should be focused on the intersection between business strategy, business process, IT architecture, and measured business benefit.

I'm 'all in' on a long term bet to make service orientation a core focus. To be successful, the focus has to be grounded in best practice patterns and metrics. Technology executives who understand and communicate the value proposition of service-oriented patterns will reduce complexity in the IT environment and increase agility. Service-oriented patterns include the following:

1] Share and re-use what you have.

2] Consolidate what exists.

3] Conform projects to common standards

SOA champions who successfully marshal IT initiatives anddemonstrate quantifiable (i.e. metric driven) improvement in the IT environment will enable a more agile IT environment, reduce time to market, decrease cost of IT per transaction (in aggregate), and better support business initiatives.   

It doesn't take 'SOA' in a job title to be effective and follow best practices.......   A main factor holding back IT organizations today is a lack of executive-level sponsorship and focus on the basic discipline of running IT as a business, by the metrics. Running IT as a business is every executive's job, not just those with SOA in their title. Please let me know your equivalient of a financial ballance sheet, income statement, and cash flow analysis...

Comparing Web Frameworks

Blogger: Richard Monson-Haefel

Link: Raible Designs | Comparing Web Frameworks: Time for a Change?.

Matt Raible is considering updating his evaluation of Java web frameworks - personally I can't wait to read the results of his research.  I wish he was including Spring MVC if only because its so popular, but I understand the need to limit the number of frameworks evaluated.  Matt does excellent analysis and I've depended on his expertise in the past. Keep an eye out for his update because it will be well worth the read.

The APS team has frequently spoken about doing a more comprehensive web framework evaluation our selves - perhaps one that utilizes the new "subthread" format.  A subthread document is actually composed of several documents including a Technologies and Standards, a Market Landscape, and at least three Product Profiles. They take an enormous amount of effort to write but the resulting coverage is very deep and the format is very flexible.  For example, next quarter I'll complete a subthread on Rich Mobile Application development for the enterprise. That document includes a 27 page technology and standards document, five product profiles (Java ME, Flash Lite, Mobile Ajax, Microsoft .NET CF, and BlackBerry MDS) ranging from 10 - 25 pages each, and a market landscape which will probably be another 20 - 30 pages long. I've spent almost the entire year working on it.

The amount of time and research required to write a subthread makes us careful about taking them on - I could do a whole subthread on web frameworks but that would put me out of action of at least a couple of quarters. I could also so a subthread on Rich Internet Applications or build on the Rich Mobile Application subthread I'm just now completing.  In the end we have to let the needs of our customer drive our research so the decision is ultimately up to them. What would you prefer?

Google’s Android: A non-starter without ….

Blogger: Richard Monson-Haefel

If you missed the Google Android announcement than you are either not interested in mobile application development or you are living under a rock. In any case, there has been an enormous amount of speculation on the subject so I thought I would weigh in.

The Google Android platform requires a very different business model for network operators, which is why it’s a non-starter unless Google gets its hands on that 700 MHz spectrum they’ve been after. Here’s why:

Mobile network operators from China Mobile (the largest) to the Verizon (the close-ist) make their money from subscribers through contracts and, increasingly, value-added services. The thing to remember is that the mobile providers want, and usually have, complete control over the mobile network. They like it that way. Mobile providers decide what you see and what applications and content you can access. They are, in effect, in control of the entire channel. This is their business model and one that has proven enormously profitable despite its destructive impact on innovation in the mobile space.

Google’s Android business model proposes taking that control away from providers and giving them a new revenue model, one based on advertising and to a lesser degree data transmission fees. It’s a cool business model, no doubt about it, if you are Google.

Can you think of a better way to advertise your product than to put it on people’s mobile phone? Its right in their face and with personalization – don’t get me started on the privacy issues – marketers will be able to tailor adds directly to very specific consumers. Do a search for automobiles on your Android phone and you can expect to see an advertisement from a major automobile manufacture on your home screen next time you go to make a call. It’s a brilliant venue for advertising – perhaps the best ever devised. It’s like putting a personalized build board in front of every consumers face.

As I said it’s a great advertising model, but network operators are not in that business today. What Google wants is for the mobile network operators to do an about-face on a business model that has proven successful and very profitable to one that has potential but is unproven. Do you really think mobile network operators are just going to give up control? Although Google has buy-in from a couple network operators – think of it as insurance on their part – and mobile device manufactures, this means very little at this point. Google intends to share advertising revenue with carriers, but why should carriers share anything when they can control the whole market?

The only thing that will make the Android platform successful, as far as I can see, is if Google managed to win the 700 MHz spectrum that the FCC plans to put up for auction. If it does that, then you can expect the entire mobile economy to change very quickly and established mobile operators – in the US to start with – will have to change their business models or they’ll end up like CompuServe did after the introduction of the World Wide Web.  If Google can secure the 700 MHz spectrum, than Android will be a game changer – if they can’t then Android is a non starter.

MVC Matrix and the RedPill

Blogger: Chris Haddad

In the near past, Java Servlets, ASP-Classic, and Perl scripts were the truth for web application development. Developers were beholden to HTTP name/value pairs and generated HTML pages via page templates. In 1996, I had a meeting in Redmond with a Microsoft lead Program Manager for ASP Classic. I mentioned that ASP Classic did not enforce a correct separation of concerns between page layout, actions, and business logic. I was thrown out the door and exiled from Redmond for ten years. During my exile, I built intranets with various technologies including ASP Classic and COM, ASP.NET and C#, Apache Struts and Java Server Pages (JSP), in-house developed widget libraries, and DHTML and JavaScript. During my journey out in the cold, I found a sense of elegance missing from all solutions.

 

Over the years, best practices morphed from tightly coupled page templating to use of a Model-View-Controller pattern. But MVC-oriented web applications have glaring limitations. The frameworks subvert the Web model (for example, Universal Resource Locators [URLs] are no longer valid) and convoluted ‘switch’ statements are often used to route client requests to back end transactions.  Additionally, the browser container hailed in the late nineties as the ultimate application host has enslaved application development and balkanized the runtime landscape. A disconnect between client and server capabilities existing in the frameworks, supported languages, and domain models. Client tier development has remained on a starvation diet for the last eleven years, and the backlash against the gaunt, thin clients is on the rise.

 

While presentation frameworks have experimented with event models and added buzzwords to their ‘features list’ (AJAX, Web 2.0, Service Oriented Architecture [SOA], and Rich Internet Applications [RIA]), a Redpill is needed to break out of the MVC Matrix and enable creation of ‘fit clients’. Vendors such as Adobe, Appcelerator, and Lazlo Systems  enforce loose coupling between client pages and server-side application logic by injecting a service layer. A message-oriented interaction instead of a page-oriented interaction will enable developers to experience a new perspective on application interactivity, decouple client-side technologies from server-side technologies, and break down traditional application silo boundaries.