The direction of company-as-application-provider is clear: You want to serve the end-user with customized, individualized functionality that constantly evolves as new services roll out and remains robust in the face of service failure. As businesses become more accustomed to operating as digital entities, expect the pace of application changes to accelerate. This means IT has to be prepared to modify applications on an ongoing process, not an occasional "big bang."
Secret to Operating as Component Provider? Stable APIs
Providing a component, paradoxically, requires a very different approach. A component encapsulates functionality and exposes it via a RESTful API. In effect, the API represents a contract between the component provider and the user and requires a commitment on the part of the provider that the interface will change infrequently and protect the user from code changes or functionality extensions.
Supporting an API-faced service is admittedly challenging. It requires planning, technical expertise and a commitment to impose as little change as possible to API users. Certainly I've seen horrible API practices over the past few years. APIs changed overnight. Different behavior from the same provider API call when served from different data centers. APIs throttled at laughably low levels of traffic.
It's vital to understand that, as an API provider, you're responsible to users — many of whom you may not even be aware of — to provide a scalable, robust, reliable service. It's also vital to understand that, if you fail to provide an API with those characteristics, you may alienate or lose users — some of whom may be anonymous but in fact represent very large companies.
Keep these critical things in mind when providing a service component:
Users depend on the stability of your API and its functionality. While you may follow Etsy-like best practices, they may not — which means their application may stop working if your service fails. If someone's application stops working, that's probably not the best time to tell them about application composition best practices.
It's critical that your API change infrequently, with plenty of notice, and provide some period of backward compatibility. If you change the way you implement functionality, such as modifying or improving the code), the behavior of your API must not change. Moreover, as you add new functionality, expose it via additional APIs or via functionality that's exposed inside the existing API while leaving previous API functionality undisturbed.
You may not, and in fact probably will not, know the users of your API. This is particularly true if someone encapsulates your service within their service. Their user, in effect, becomes your user. The spread of mobile apps exacerbates this user anonymity and makes API stability even more important, because user populations can be so much larger.
Sign up for CIO Asia eNewsletters.