Google's Android - The Promise

So Google's Android mobile platform is finally here.

I'm not going to add to the cacophony of voices discussing the technology itself. There are far more competent people doing that already.

Stepping back from the technobabble for a moment, I have a sense of déjà vu. I feel this is a moment rather like the one back in 1981 when IBM launched the PC.

The personal computer era can be neatly classified into a BC-AD kind of history with the launch of the IBM PC corresponding to the birth of Christ. Before, it was all about proprietary hardware and proprietary software. After, it was all about open hardware and, uh, proprietary software.

Even with its partial openness, the IBM PC proved to be a neutron bomb that eliminated all its rivals in short order. Only Apple survived (although it suffered a near-death experience in the mid-nineties).

The echoes of the IBM PC's debut are still reverberating through the IT industry today, its megatonnage a direct result of its comparative openness. [Of course, the fact that the IBM PC was from IBM didn't hurt, but I wager it wouldn't have done anywhere near as well if it hadn't been for its openness. After all, the IBM PS/2 (which was meant to be the PC's successor) bombed badly because of its proprietary MCA (Micro Channel Architecture) bus, which lost out to the open ISA (Industry Standard Architecture) bus. The PC moved on, leaving IBM behind, proving that it was openness rather than pedigree that was responsible for its success.]

With Android, Google is out-IBMing IBM. It's an open platform all the way. Android itself is released under an Apache license, like its underlying Java Virtual Machine (more correctly, the Dalvik Virtual Machine based on Apache Harmony). The Linux kernel underlying both of them is covered by the GNU GPL. Unlike Apple, Google will not attempt to control the application ecosystem on top of the platform either. This is true openness.

Where will this lead us? Let me make a prediction. This obviously sounds audacious in late 2008, but I'm betting it will appear obvious in hindsight by 2010. I'm predicting Blackberry/iPhone capabilities in devices costing $10. That's right, ten dollars. The hardware's made in China, the platform's Open Source, the applications are downloadable free of charge. How much does a cheap plastic LCD wristwatch cost? That's how much a mobile device will cost within 2 years, thanks to openness.

Update 30/09/2008: The first comment on this entry was a very well-informed one warning of the very different economics and market constraints in the mobile market compared to the PC market. But you know what? These are mobile devices we're talking about, not just mobile phones. They're basically wireless-capable PCs in a smaller form factor. If the existing mobile players are exploiting their natural monopoly to essentially charge rents, I think they're about to have an unpleasant deflationary surprise when for example, Google moves the action away from the telco-dominated mobile phone network onto the wireless Internet. Google has a habit of introducing game-changing features into their products. Think Suggest for Google Search, Street View for Google Maps (itself a game-changing product), and Google Documents, the online office suite. Google also has an interesting way of slipping products rather unobtrusively into the market with ultimately unpleasant consequences for their competitors. 

How could Google fight the established players in the mobile phone market? Let's think. The bulk of mobile subscribers are in cities. The 80-20 rule means that investing in relatively few Internet Wireless Access Points in major cities will cover the bulk of subscribers, and the rest can be switched through the regular mobile network. ISPs, not telcos, could be the main carrier partners of the device manufacturers who go with Android. Google can use its huge additional advertising revenue to provide cross-subsidies and hide any differences in economics by having to use different networks. And the subsidy required will keep decreasing as WAP coverage increases. This is something that just occurred to me as a casual afterthought, so I'm sure the Googleheads have even better ideas.

The bottomline to the consumer is that massive reductions in cost-per-MIPS began to occur with PCs as soon as an open platform appeared. Can this happen again with mobile devices? I think it can.

But even if Google breaks the telco oligopoly and creates an Internet-based mobile device ecosystem, it still faces a formidable challenge because it can't stop other players from exploiting this more open network.

This time, Apple is far stronger as an incumbent than it was in 1981. The challenger (Google) is just as new to the battleground market segment as IBM was in 1981 but just as deep-pocketed and determined as IBM was.

Will Android's openness be sufficient to overcome Apple's brand, technical sophistication, polish and level of entrenchment in the market?

That's not the only challenge before Android. There is an open competitor as well. Will LiMo queer the pitch for Android?

Well, I'm both pro-openness and pro-competition, so the more the merrier :-). And I'll save my money till the price of a mobile device drops to about $10. That's me not putting my money where my mouth is!

Go, Android!

A Tool for Generating Data Flow Diagrams

Many months ago, I posted an entry called Context Diagrams as a Tool for SOA. Today I learnt that Douglas Barry has created a tool to help software designers visualise data flows. Just specify your inputs and outputs and "wire" them up, then the tool generates visual representations of the relationships. You can get what Barry calls "Business Process Diagrams", "Data Flow Diagrams for Services" and "Data Flow Diagrams". [I couldn't tell the difference between the plain DFDs and the DFDs for Services. They seemed to be identical in this version.]

Anyway, it's quite an interesting application, and I had lots of fun playing with it.

My suggestions to further develop the tool:

1. Allow flow chaining, i.e., allow the outputs of one step to become inputs to the next. [Or perhaps the tool is already doing this and I haven't understood the notation yet.]
2. Provide support for localised and progressive decomposition of modules, i.e., allow the designer to explode a node within its own context without having to go back to the top-level listing of all inputs and outputs, because beyond a point, this tends to become confusing. [Barry explains that this is already catered for, but perhaps my initial examples were too simple and didn't support a second level of decomposition that would have tested this feature.]
3. Refine the "DFDs for Services" view to be truly service-oriented, by allowing for a different paradigm of construction below level 1. Then the tool can help to implement the Viewpoint Flip that I've argued is the deciding characteristic of SOA. [Perhaps we need to support UML class or object diagrams once we explode Services into their components. I'll have to think about this some more.]
4. Aesthetics - create some conventions to lay out the diagram in a more predictable manner, so that it is aesthetically appealing and more intuitive at first glance. I had to drag the components and arrows around a fair bit to see the flows more clearly, once the diagram got beyond a certain size (i.e., more than 2 inputs and 2 outputs). (I know this is just quibbling, but the tool has a lot of potential, and some smarts around the generation of graphics would make it very powerful.)

It's a free site (for now, at least) and you're not asked to register with your personal details either, so I'd recommend that you give the tool a try. If you missed the link earlier, you can find it here.

Google Chrome - The Promise

I'm excited about Google Chrome, the newest browser on the block, even though I haven't used it yet.

How come? Well, I use Linux at home, and Google hasn't seen fit to release a Linux version of Chrome yet...

Still, I am excited.

But do we really need yet another browser? Well yes, I think Chrome is important for at least a couple of reasons.

1. It's high time Netscape's original vision of the browser as an application platform was realised. Our current generation of browsers is architecturally hobbled. Chrome implements the behind-the-scenes improvements required for a browser that has ambitions of being a true application platform. See this tech-friendly explanation of what these improvements are.

2. It's high time Microsoft's browser market share received another blow. For those who think Microsoft has begun to play nice in the web standards space, think again. They're up to their old dirty tricks once more. Anyone whose employer has deployed Sharepoint will know what I mean. There are heaps of Sharepoint features that don't work in Firefox. You're forced to use IE if you have Sharepoint. We learn once again that it's dangerous to give Microsoft control of both ends of the Web. Apache is slipping. And Firefox isn't enough. I hope Chrome provides enough buzz to draw users away from IE.

For all the coolness of Chrome, there are still important features missing. The obvious one for me is E4X support. How can an application platform not have native support for XML manipulation? We live in a SOA world, don't we? We have to deal with business logic in the form of services, right? So what's with the lack of XML support? I certainly hope this is a temporary issue, because I believe the application platform of the future must support SOFEA, and without XML support, it's just not going to cut it.

Of course, these are early days, so the glass is really half-full. Good on ya, Google!