Build Business Capabilities, not APIs

As CIO, you should adopt a “composable enterprise” strategy to establish a platform for innovations consisting of composable digital building blocks. Your core business capabilities are the building blocks. Composing them into new differentiating capabilities will give your business the necessary agility to rapidly execute on its strategies. Digital innovations focused on customer experience, operational excellence, and partner and provider engagements are the face of this agility.

RESTful web APIs have proliferated because of the ease with which modern developer frameworks allow them to be exposed and consumed. They are now the preferred technical artifacts through which modern microservice architectures are realized. However, herein lies a danger! Architects may make the naive presumption that they contribute simply because they expose data from systems of record through APIs. With this limited mindset they will miss out on building the capabilities that will actually bring value.

In this article I explore how we can shape those building blocks that will contribute to the realization of your company's strategies. I refer to your core business capabilities - functions that encapsulate the routine fundamental tasks of your business, the more complex ones around core business processes, and the differentiating capabilities that exploit these. You should expose all these through APIs.

Empower the Enterprise Architecture Team to automate your Core

Those processes which are core to the operations of the business and considered routine and essential to keep the lights on ought to be digitized and automated. This will free up management to focus on those processes which will allow your company to implement new differentiating initiatives for customer and partner engagements.

Your Enterprise Architecture team is responsible for the identification of the core business processes that need to be automated, the part that systems of record have to play in these, and ensuring that IT projects benefit from and contribute to long-term IT strategies in consideration of the business operating model.

It is their responsibility to decompose the IT landscape (ERP systems, CRM systems, custom systems built in-house, databases, etc.) into building blocks that can be rapidly recomposed for innovations that differentiate your business from its competitors. In the world of retail, you will find the core disciplines of order fulfillment, picking, packing, delivery, and returns management. Amazon’s Prime initiative is an example of differentiating business processes that exploit the underlying automated core.

You should encourage your EAs to act as partners and enablers of domain teams. They should promote pragmatic approaches to digitization that give autonomy to the domain teams. But they should still evangelize best-practice and clearly publish the impact of those well-defined APIs that adhere to the best architectural standards.

They must ensure that projects are realized with your strategic vision in mind. Mobile initiatives which need new APIs should result in the design of business capabilities agnostic to the very mobile channel which demanded them. Indeed, agnostic to every channel! Once designed and built as agnostic capabilities, they should be adapted to suit the custom technical requirements of the mobile channel and the business requirements of the app users on that channel. Subsequently, the demand for the same capabilities in other channels, or in other mobile initiatives, should be met with more adaptations of the same capabilities.

Integrate Data with a Strategic Mindset

It is imperative to consider the information needs that every data integration is motivated by. These sets of actionable information are prime candidate microservices that can impact the business process automations and digital channel experiences. The focus should be on building system-of-record-agnostic and channel-agnostic capabilities that encapsulate discrete responsibilities around core sets of business information, like Order and Invoice and Item and Customer and Sale and Pricing.

APIs which define business capabilities are much more than mere data carriers. In line with the principles of domain driven design, they are fully responsible for the business actions that drive the data movement. 

Thus we avoid the temptation to see the value of APIs merely in terms of unlocking data from the backend systems. Well-defined microservices with business oriented APIs hide all details about systems of record so as to decouple the latter from the API consumers. Your architecture ought to outlive your systems of record, and be driven by and cater to the timely, accurate, contextual and compelling information exchange with your customers, employees, partners and suppliers.

Implement a Microservices Architecture with Discipline

The principles of design that shape a Microservices Architecture focus on the guidelines that govern the quality of technical artifacts that are built in order to automate core business processes and form building blocks for innovations. Adhering to them is a sure recipe for the delivery of powerful and simple business capabilities.

The Microservices Architecture has evolved and emerged from these core foundations:

• Service Oriented Architecture
• Domain Driven Design
• Continuous Delivery

Together these approaches to digital solutions form the guiding principles through which IT can match business agility with its own agile responsiveness to new initiatives. The human discipline which forms a necessary part of ensuring quality deliverables through all of their principles is the sure protection against building distributed monoliths. These have all of the pains of a microservice architecture and few of the gains.

Service Oriented Architecture

Microservices represent a more pragmatic approach to service design by focusing more on the needs of individual business units. This is in contrast with the first overly-ambitious aim of SOA to deliver services reusable across the enterprise, and its consequential emphasis on enterprise-wide canonical models.

All of the principles that guided the design of services in SOA are truly alive in the Microservices world in that they are:

• loosely coupled so as to hide implementation details from the API consumers and decouple definitions in the API from any backend systems that may partake in the invocation. This affords you the luxury of switching out implementations and backend systems with no downstream impact on the consumers.
• abstracted around business capabilities making them truly business products which can have impact in multiple contexts like business processes and digital channels.
• reusable across business processes and business channels because they are agnostic to both. While reuse is no longer an exhausting prerogative it is still sought after with the reduced scope that falls within the realm of a particular business unit.
• autonomous so as to maximize reliability and guarantee to a reasonable degree the quality of service expected by the API consumers.
• stateless to allow them to scale with demand.
• discoverable so that developers of consuming software have a clear understanding of everything they must know to write software which consumes them correctly.
• composable so as to form part of composite business capabilities which are digitized through the collaboration of independent simple buiness capabilities.

Domain Driven Design

Business capabilities are best designed when their design is the result of tight collaboration between the development team and business experts. Domain driven design recognizes the business domain as prime customer of the microservice.

The capability expresses its functionality in the language of the domain and makes no effort to attend to the broader needs of the business as a whole. This is because each domain team will likely have different perceptions of apparently similar business entities.

The microservices built in this way are bounded within the context of the semantic understanding of the business held by the teams in a particular domain. They are protected from outside influences in their design to such a degree that for every consumption at the level of business channels for mobile, web and partner engagements, as well as by other domains, they are deliberately adapted through targeted experience APIs. These experience APIs are the only point of access to the business capabilities, both composite and simple for digital channels. For those scenarios where cross-domain business processes are automated with building blocks provided by each domain, business domain events should also be used.

Continuous Delivery

There will be no end to the demand for new digital solutions coming from the business. There is no future date that is close enough to satisfy the stakeholders. The evolution of the discipline around continuous integration which automates the build pipeline now includes the automation of deployment into production.

Microservices are ideal deliverables in this model given their limited scope of responsibility and impact on the overall workings of the system as a whole. If any bugs are introduced into production as a result, the very same continuous delivery model will ensure the rapid release of fixes. Without continuous delivery, a microservices architecture would only increase the pains of the IT teams due to the multiplication of deployment tasks.

Design for Customer Experience

Most of us have purchased goods on Amazon. It is quite an amazing thing to consider that behind that simple click to checkout your basket, there lies such a complex business capability exposed through an API that has to compose a number of other APIs as part of the order fulfillment process. All this complexity is totally hidden from us. We click and we receive a confirmation, a promise that the goods will be delivered. We care nothing (in this exact moment) about when our credit card transaction goes through and have no other expectations beyond that confirmation. Our correct assumption is that eventually our bank account will be debited and the goods will arrive on our doorstep. 

“The customer experience is the next competitive battleground”

Even if the business capabilities that collaborate for the order fulfillment were down in this moment of time we should not know about it. We care only for the confirmation, the promise that our request will be catered to.

This ought to be the standard for all complex business capabilities exposed to customers through whatever channel. Compositions of capabilities should minimize their dependency on API calls and maximize the use of business events. The order fulfillment capability should publish an order created domain event to a broker after it has invoked the API of the microservice responsible for the information around the order itself, and it has received a confirmation number (if any is needed) to send back to the customer. The other microservices that collaborate in the composition should subscribe to this event and be driven by it. This adds to the overall reliability of the composite capability and protects the customer experience from the fallout of any down-time on a failed microservice. Eventually, when the failed microservice comes back online again, it will receive the event, execute its capability and the order will be fulfilled.

Your microservices should be invoked through their RESTful web APIs only when necessary and be driven by events when no information they can provide is needed by the customer for this transaction.

Count Business Capabilities as Digital Assets

We measure value in the digital solutions that business capabilities represent by the impact that they have in the multiple contexts set by business processes and the various digital touchpoints to which they are exposed. They are not defined by either of these and so can be adapted and reused in other contexts.

As valuable assets, and to facilitate the adaptation that the typical custom requirements of a technical and business nature require of them, we manage them through the industry-wide discipline of API Management. API Management facilitates the publication of your microservices so that their intent is clearly understood by business and technical stakeholders and developers of consuming software have everything they need to consume them. It also addresses the adaptability requirements through its injection of policies that cover areas of logic like security, rate limiting, auditing, data filtering, and indeed any relevant and pervasive logic.

As fundamental building blocks of compositions that correspond to interactions with customers, partners and suppliers, the analysis of the usage of the microservices is of great value. The mining of key business information relevant to their consumption can contribute towards making strategic business decisions and driving new innovations. Don't underestimate the potential benefits of such analysis. An Uber driver recently explained the reason why I only had to wait 4 minutes for her to pick me up at San Francisco airport compared to my usual 10 to 15. She said it was because Uber have started to tell them to head to the airport minutes before Uber customers begin to arrive!

Sell your Business Capabilities

The composable enterprise has two facets, one internal to the enterprise and the other external.

The internal aspect effectively establishes a platform for innovation within the enterprise. By automating the core business capabilities that define the routine, mundane tasks that the business does by way of necessity, it can now leverage these automations with compositions that are responses to the newest initiatives. The multiple domain teams responsible for the building of microservices that encapsulate the capabilities ought to be encouraged to publish these through API Management facilities. They should also receive promotion of the same from the Enterprise Architecture team who should act as a center for enablement of every other team. A healthy degree of competitivity between the teams can grow if assets are seen to gain adoption and have impact in the digital initiatives. Chargeback mechanisms can be put in place so that the usage of these capabilities from other cost-centres can be the channel through which the projects which gave birth to them are funded.

The other aspect to the composable enterprise is external. You should consider the differentiating composite business capabilities built on top of your core as potential sources of new revenue channels by exposing them to the outside world. In the words of Jeff Bezos:

“It’s hard to find things that won’t sell online.” 

Exposed through APIs to third party developers but formally expressed as the core capabilities of your business, these business capabilities are what establish your very business as a platform for innovation and set you ahead of your competition as beneficiaries of the API economy.