About Us | Login | Follow CITO Research:

The Lessons of Google Play for API Designers and Enterprise Architects

In a fascinating article about the architecture of Android (“Balky carriers and slow OEMs step aside: Google is defragging Android”) Ron Amadeo, reviews editor of Ars Technica, explains in a masterful way how Google is systematically freeing itself from the grip of the device vendors.

While this story is interesting enough from an engineering point of view, its biggest impact for me was the lessons that API designers and enterprise architects should take away. Through disciplined adherence to backward compatibility, precise separation of concerns across layers, and introduction of a new intelligent API controller, Google has shown how it is possible to manage a complex API surface in an orderly way. The principles at work in this architecture can be put to use for individual APIs, collections of APIs, and in vast enterprise architectures. Anyone who is a fellow traveller along the path of Digital Transformation should take these lessons to heart.

Mobile Apps - A Fast-Moving World

Google’s architecture is motivated by the challenge it faces as the publisher of a platform that must run on the hardware of many different manufacturers. In order to update the software that runs on a device, Google is beholden to how fast the vendor can test a new version and deploy it either to new devices or over the air to existing devices. In the fast-moving world of mobile apps, this makes for a slow process of evolution, not something that anyone wants.

Google Play Services - Moves Fast

Remember, few apps rely on core operating system functions. Most apps instead use APIs that repackage and present lower level OS functions and incorporate other code and external services. What Google has done is introduce Google Play Services as the controlling layer for the API surface. Instead of having to wait months or longer for device manufacturers, Google Play Services can update the API layer as soon as new APIs are ready. The entire installed based of Android can be changed over to new APIs in a couple of weeks.

To pull this off, Google Play Services has become essentially a superuser of your phone that can do almost anything to it, even grant itself more permissions. When Google Play is installed, it asks to be granted a huge amount of power. If you don’t grant that power, your phone won’t work so well.

One of the reasons that this is possible is that the APIs on Android, at least the ones controlled by Google, have super strict backward compatibility. That means that as much as possible when APIs change, all the applications out there still work.

Remember that Google, as smart as they are, introduced this architecture gradually after encountering the problem of the mismatch in the pace of change of the operating system and the APIs that support mobile apps.

Learn from Google’s Experience

Both API designers and enterprise architects can learn from Google’s experience. The lessons are simple but extremely hard to stick with.

First, be slavish about backward compatibility for APIs. Usually this mean introducing a version number and doing the hard work of making sure that the old stuff continues to be tested and stays in working order.

Second, control the cycle of updating APIs and separate it from the underlying systems that provision the API. This will be especially difficult for enterprise architects who may prefer just to expose a vendor’s API to internal teams of developers. Remember: once you do that, you have ceded control of the update cycle.

Third, automate everything. Google’s updates are configured and then they happen. There is no black art, no key person who has to be there to tweak things.

Fourth, abandon big bang versions. Google preserves versions on all the APIs, but because of that, it no longer has to worry about the big bang versions like Jelly Bean and so forth. The platform can move forward at whatever speed makes sense, incrementally or fast, as each API is improved.

As I said, these lessons are much easier to talk about than they are to apply. But by living according to these principles, the technology you build will have the maximum power possible, and so will you.