API Program: Initial Speed to Value

This is the 8th entry in a blog series about enterprise digital transformation, with an emphasis on API programs.

In this post we discuss some tips for initially setting up an API program, keeping in mind the elements of the minimally viable mandate discussed in the entry "Three Ground Rules, Two Patterns, One Mandate." We believe these are essential for enterprises to get started quickly, yet retain the flexibility to adjust course as complexities emerge.

In many enterprises we find that API programs have already been operationalized as a distinct and permanent software development capability, sometimes called an “API Factory.” This pattern is not in itself risky - we know of several that are working well, and are helping set up others. As noted in “Three, Two, One”, in fact this has turned out to be great way to begin the journey, even for the most complex of enterprises. Where this is healthy, the individuals involved are usually excited for the opportunity to up their game. Where we encounter significant resistance, the reason is often an anti-pattern described in “The API Project Trap,” and a concerted turn-around effort is needed.

As a new practice to foster a nascent API program, enterprises should begin by holding quarterly reviews of the active portfolio of IT projects, to detect and list those that include digital experiences for customers, partners, and/or employees. This is because the existing IT governance models (often based on ITIL, COBIT, or ISO) should assure that every project in the portfolio has three healthy drivers that can be leveraged by the API program:

• it is coupled to the enterprise KPIs;
• the use cases and desired experiences are well understood; and
• they are tied to funded initiatives.

Over time, the elements of these reviews we describe here become integral to how every project is conceptualized, and every project innately includes the structure and information that leads to fruitful API design and utilization. For the first such review, a selective approach is called for, prioritizing cooperative business units to improve overall outcomes. Occasionally we do see enterprises with significant external urgency to transform, and executive sponsorship ready to fund and execute on the transformation. In these cases, a comprehensive, fast-track approach can be justified, and often catalyzes a new culture more quickly.

Now for the specifics of this new practice.

As discussed in depth in previous blog entries, digital experiences are created by systems-of-engagement, which are apps, websites, external partner API integration points, devices, etc. This is true for all projects that reach beyond the internal secure LAN environments containing only the enterprise backends. Note that this definition of “internal” is different from a description of who designs or constructs the applications for the project; most internally constructed applications actually communicate on external networks, and match this description.

As a new practice, going forward all program managers should factor each of their projects into two buckets: activity to create and maintain digital system-of-engagement “front-end” digital experiences, and separate activity covering “backend" system-of-record changes to core systems. From this perspective, many projects do not actually require backend system changes, they just need access to them; in our new practice, this integration segment of each project also falls into the system-of-record bucket. As an important design principle, while systems-of-engagement often handle transactions as part of their job, they should not store them, and should not become systems-of-record for any transactions or other data.

To track the functional dependencies between backend and front-end buckets of activities, project analysts create and maintain a shared map of links between the systems-of-engagement and the systems-of-record. This can be done in a spreadsheet, or in a data modeling tool, whatever works. It is critical that this map only describes the functions needed, without specifying the actual backend systems themselves. This map leads to an abstracted list of backend functions needed by all the systems-of-engagement in the portfolio. We will talk more about these abstracted “business capabilities” models later. Initially some projects may have difficulty drawing this line - they may need to be redesigned, or a vendor replaced, in order to achieve this goal.

Typically the abstracted business capabilities can be fulfilled with existing backend functionality. This fulfillment usually requires an expert in the backend systems themselves, who identify the minimum integration and adaptation needed from the backend system to be able to provide each function. Occasionally this includes tasks that requires changes directly in the backend.

Sometimes we see some enterprises that decide to make a strategic investment and tackle specific backends more comprehensively, to create interoperable interfaces across all functionality of that system. This approach is especially valuable when the backends are expensive to “open up,” such as financial systems, or telecom networks. For such monolithic systems, the costs are often significantly lower to “open the patient once” and perform comprehensive surgery once, rather than causing repeated disruption with incomplete integrations.

However, most of the time, this fulfillment can be framed as an integration task that does not require any backend change at all. Finally, as more and more APIs become available, this fulfillment disappears completely, as the new systems-of-engagement simply call the growing library of APIs for fulfillment of their functionality. Distinguishing among different system-of-record scenarios supports the rough estimation of effort needed to complete each project in the IT portfolio, and helps drive the prioritization to create business value sooner.

The two key elements are now in place to drive a continuous project workflow:

1. A set of scoped system-of-engagement projects, with clear dependencies on business capabilities; and
2. A set of scoped system-of-record projects, fulfilling the requirements of business capabilities.

This practice leads to initial backlogs of separate front-end and back-end tasks, which should be groomed regularly. At the beginning a lightweight quarterly review process is usually enough to drive the re-prioritization needed to retain relevance to changing business needs. However, is important not to completely decouple the scheduling of back-end work from the front-end work, because they need to fit together to deliver business value to users. The API Product Manager (see other post for description of the API Team) has to carefully balance these dependencies to express priorities to the implementation teams. It also helps if the work is done by agile squads that deliver value end-to-end, where each squad includes front-end, APIs, back-end integration, and QA skills, as well as big data specialists where appropriate. Good scrum masters also typically take a holistic approach and partner well with both the API Product Manager and the business owners of the IT project, with an eye on delivering real business value while simultaneously creating reusable business capabilities in the form of APIs.

By the way, rather than obsess over where organizationally this practice should be permanently located, and what rules the rest of the enterprise should play by, the focus should stay turned to outcomes and performance, enabled with agility and participation of every team. See post on The Holy Playbook Trap for thoughts on avoiding renewed calcification of processes.

Is this similar to the experiences you are having with your API program?  How does this align with the agile software development processes at your enterprise?