Simplicity through APIs

I've previously written here on the causes of complexity and also of my frustration with the Banking industry's obsession with, IMHO, outdated assumptions on consumer requirements. Collectively issues like these create an over-bearing technical debt that frustrates the abilities of all large companies, but in particular banks, to respond to their markets.

This is why the mobile app world is so populated with smaller companies and startup-types. Larger enterprises have a tendency to be a little slow to respond to big shifts like mobile. The high degree of complexity they have to deal with and the slow evolution of ingrained attitudes contribute to this lack of IT agility. However, I see real demand in business areas for a more responsive approach to IT. Ask any "Head Of" in a banking business if they want to do mobile faster and I guarantee the answer is "Yes, of course!"

So if businesses want more agility, what can IT do about this? I am old enough to have been in the industry long enough to have experienced a number of evolving attempts to break enterprise IT systems up and make them more agile and responsive. The goal has always been to allow large companies to possibly inherit some of the agility that smaller ones are lucky enough to acquire.

Evolution of enterprise agility

• In the early days the IT industry identified the need for an enterprise data model. The theory was that the if you could have data across systems stored in a consistent manner it should help to ease development efforts.
• Soon, enterprise data models began to be replaced by the more in-vogue object model. Object models extended the concepts of modelling from purely data to include the function (i.e. the application program code).
• However, both enterprise data models and object models suffered a similar draw-back - as the models themselves grew in richness they also grew in complexity. Soon those models were of such complexity that they themselves became a barrier to agility. They were large, with many, many inter-related items that made the effort of assessing the impact of, even small, changes great. Large changes tended to be avoided completely. Developers required lots of familiarisation to use the models and bugs crept into systems because those unfamiliar with the models misused them. I've seen this first hand on a number of initiatives and have come to develop a deep suspicion of complex data/object models because of it.
• Responding to these problems the industry shifted towards Service Oriented Architecture (SOA). SOA claimed that by breaking these models up into discrete and courser-grained components, some of the benefits of models could be achieved without the drawbacks. A smaller number of courser-grained components without so much inter-dependency promised more simplicity. Newer, simpler, technical underpinnings like SOAP and XML, that heavily leaned on the internet world, attempted to further simplify things. Finally, perhaps, the industry had found a way of simplifying enterprise architectures and introducing much-needed agility.
• However, even with SOA, some (many?) enterprises seemed to have struggled with actually achieving the promised agility. It seems to me that, whilst SOA was a step in the right direction, it is still one step away from delivering on the promise of simplicity.

Introducing APIs

More recently, and outside of the enterprise IT world, we have seen the emergence of the concept of enterprise Application Programming Interfaces (APIs). Big internet companies like Facebook and Twitter identified that they could increase their value by allowing others to build apps that interact with their underlying platform. Payments provider Stripe goes one step further by making its entire reason-detre to be used through its API - without its API it has no reason to exist. I've written before on the concept of public APIs and their applicability to enterprise IT. APIs, I believe, have the potential to finally deliver enterprise agility.

Why do I think this might be the case?

• The use of a standard technology set and design patterns - primarily REST (design pattern), HTTP (access protocol), JSON (data structuring) and OAuth (security) that are well understood by large groups of developers, supported by all popular programming environments and proven at scale.
• Systems that use an API are 100% unaware of each other. They are built independently by individuals and companies that have no relationship or knowledge of each other's internals, so independence is guaranteed. Small companies can build apps that use a large enterprise API, but maintain their smallness and independence. No meetings, no discussions, no consultations - independent teams developing independent systems that interact through a public API. I like to refer to this as a "fire break" in the architecture. Enterprises may need to be complex, or cannot avoid it, but by hiding that complexity behind an API we can put a hard limit on the spread of that complexity. Whatever is the other side of the API should and must remain 100% separated from the complexity that lies the other side.
• APIs have demonstrated the ability to allow third parties to interact with a platform in a 100% self-service manner - public APIs supporting 1000's+ of client apps.

Finally, we have a design pattern and technology set that is proven to introduce a level of simplicity and separation between systems. Its important that this has been proven at scale - this isn't a promise or a dream, its happening now. Facebook, Twitter, Stripe and their compatriots are proving the model at a scale unimaginable to most traditional enterprises.

What differentiates such APIs from SOA?

I would like to suggest a three step qualification for APIs. I've seen disturbing desires to relabel and 'spin' previous generations of interfaces, services, etc as APIs and its important to have a qualification test that avoids this happening. If an API doesn't fits these tests then its unlikely to lead to the simplicity we seek, so should not be considered an API. The following are characteristics that are common amongst the APIs we see in the web world - facebook, twitter, stripe et al. They are what's made that universe successful and so its worth borrowing those characteristics for the enterprise.

1. An API should be capable of being used by a new client through a self-registration process. No meetings, no workshops, no discussions, just fill in a web form and submit your request.
2. An API should use the commonly accepted technologies and protocols on which the wider industry has rapidly standardised upon. This is important because it means the learning curve is much reduced through the use of common technology and designs. Primarily this means:
• Adopting the design patterns associated with the REST protocol - objects exposed via explicit URIs accessed via standard HTTP calls in a stateless manner.
• Data structured using JSON. JSON is important because its an order of magnitude easier to work with than older technologies - just 1 or 2 lines of code are all that's needed in most programming languages to transform a JSON string into a native object, so there's a very low skill barrier to its use. XML, by contrast, has its own complex processing model that's notoriously tricky and yet another technology to learn.
• OAuth for security. OAuth is important because for the first time we begin to get a standardised security architecture for APIs. Only with security can we have a usable API.
3. An API should be provided with a set of documentation that makes its use 100% self-sufficient, including:
• Clear online documentation that means the API can be used without any training, meetings or discussions that might slow down or complicate things.
• An online "Test API Explorer" that allows users of the API to fill-in test fields and explore how the API responds. This is important because it allows developers to explore the API without requiring and code development. A developer who clearly understands the API's behaviour is much less likely to abuse it or to introduce errors into their application.
• Example implementations in common languages (e.g. HTML/Javascript, Android, iOS) that show, in code, how the API should be used.
• Support forums where developers can ask questions, help each other and most importantly, record for posterity and future re-use the answers to each others questions.

If an alleged API doesn't look and smell like that of Facebook or Stripe then it's not an API. It needs all of the above to qualify. If your API isn't self-service, doesn't use REST/JSON/OAuth, etc, then it doesn't qualify.

APIs in Banking

All this talk of public APIs might seem a bit radical in the conservative and security-conscious Financial Services world. But its happening already in banks and payments providers. I've already mentioned Stripe and its payments API and PayPal has recently renovated its own solution to provide a very similar API. Credit Agricole presented their App Store, backed by an API, at Finovate. AXA Bank are offering at EUR50,000 prize at the launch of their API. And the Open Bank Project are offering their own take of a standardised bank API across banks. Its happening already. An influential group of solid financial providers are building the future, and soon others will feel the pressure to respond.

Agility

Just as an example of the agility an API delivers, a few weeks ago I was able to prototype a mobile payments service based on Stripe in a single day. I was feeling under the weather and lazing on the sofa - but still had my iOS app up and running using the Stripe API the same day. I didn't need to speak to anyone, there were no meetings, everything was self-service using technologies that were simple for me to use and with out-of-the-box iOS implementation libraries I could use to simplify the whole task. Most enterprises would spend much, much longer discussing the costs of doing such a PoC and debating its value. The availability of a public API meant I could just build my PoC the same day. This is a dramatic change from how things work within most large enterprises.

Creativity

There's one other benefit of a public APIs and it has to do with creativity. Most people in enterprise IT operate within a relatively closed community - a community of like-minded people who think in similar ways. There tend to be a lot of middle-class young-to-middle aged males, but not so many women, academics or those from deprived communities, for example. Enterprises often reach out to different groups as part of their innovation programmes - vendors, universities, customers, etc - they do this to solicit different perspectives, to break out of the straight-jacket of conventional thinking within their own organisations. But they tend not to do so for 'mainstream' initiatives - which means the perspectives and thinking can tend to be quite narrow. Maybe this is why so many mobile banking apps disappoint.

APIs allow enterprises to solicit development from anywhere. Well-documented self-service APIs using standard industry design patterns and technologies allow an enterprise to run a hackathon, a university challenge or even to support their own App store for independent third parties. Such initiatives have the potential to tap into very different perspectives and to arrive at solutions they might never have identified themselves. We call this innovation, and APIs have the capability to make it happen.

Multi-Channel Architectures?

In my last post I somewhat cheekily challenged the concept of a multi-channel architecture, asking why banks weren't investing all their efforts into the only channel that will really matter in my personal vision of the future. What really offends me is not so much the multiple channels, as the suggestion that somehow we should attempt a common technology and architecture across all channels - that is the real sin that I believe would result in organisational gridlock. A common solution where any change impacts everything means everyone needs to agree such a change.

My alternate vision of the future has the different channels acting with autonomy and at an agile pace - precisely because they are freed from the necessity to co-ordinate and agree every change with each other.

My vision would have the bank consider its core operations as a platform, like Facebook, with an API to which independent channel apps are coded (just like any Facbook app that uses its Graph API).
Channel apps can be independent of each other - one technology/architecture/generation in the branch, another in mobile - and each able to move at their own pace of change. Of course its still possible to have common technology across the channels, but its very much incidental (and not preferable if that requires co-ordination of change between the channels). No enforced dependencies, no need to co-ordinate new releases across channels has to be the target if new channels, like mobile (and maybe smart watches and glasses to come soon), are to reach their potential.

In effect, I'm suggesting that banks break themselves into two - a series of independent channels, linked via a common API to the "back end bank". We are seeing this separation beginning to be referred to as "Systems of record" and "Sytems of engagement". I like this definition because it explicitly acknowledges the different characteristics of Systems of Record (resilience, reliability, stability, security of data, etc) versus Systems of Record (agility, integration with social, mobile, etc). The separation, via clear APIs which act as an architectural "fire break", are implied by the definitions.

Back-end as a service

Back-End As A Service (BAAS) is a new trend to abstract and aggregate all of the server-side components needed for app development, from data storage to user management, location services, social media integration, etc. All of these services are packaged in a way that makes their use "native" to a mobile developer and avoids them having to understand the underlying technologies necessary on the server. They are typified today by smaller mobile-focussed companies like Parse, StackMob and Kinvey, amongst others, who all present their BAAS services through standardised APIs.
The BAAS model could just as easily be applied in an enterprise context by banks - with the bank packaging their legacy "Systems of Record" as a BAAS model, presented to the channel teams through a standard API.

Summary

Keep an eye on APIs, Facebook et al could well be helping to unconsciously define the future of enterprise IT. But it's not just trendy webby companies, even IBM is getting in on the act with its API Management platform that includes Cast Iron API platform, OAuth support in traditional enterprise security products like Tivoli Federated Identity Manager and REST/JSON support into most of its middleware portfolio.

So, we have APIs, Systems of Record, Systems of Engagement, Mobile and Back-end as a service - all contributing to a future banking architecture. Have I included enough trendy phrases for you?!

Posted with Blogsy