APIs – Managing Challenges with a Portfolio Management Approach
Jan 22, 2019
Application Programming Interfaces (APIs) have emerged in recent years as a key enabler of digital transformation and enterprise agility.
By defining and deploying APIs, senior IT leadership can increase the responsiveness and adaptability of IT systems – both legacy and modern – by linking applications and data faster and more effectively. This enables a de-coupling between Agile ways of working for systems of engagement – the “front end” applications used by end users, where user experience and responsiveness are vital – and the more highly governed working practices for “back end” systems of record that often still underpin core capabilities of the enterprise.
However, many IT leaders have struggled to deliver the benefits promised by the “API economy”. Instead, they encountered limited visibility and transparency of APIs across the organization, redundancy and duplication, increasing maintenance overhead and ultimately more costs, with the same barriers to rapid transformation that existed before. One of the primary causes for this is often a narrow/siloed, IT-focused approach to API programs.
We have found that taking a portfolio management approach can help address these challenges and enable the benefits of APIs to be delivered effectively. The key principles are analogous to the well-established portfolio management practices for projects (“PPM”) and applications (“APM”).
First, start with the business context, based on the business’s strategy and goals. This typically involves understanding which business capabilities are priorities for investment/improvement, and which customer journeys are the focus of transformation efforts.
Customer journeys provide a structured, customer-centric approach to designing and analyzing customer experience, which is necessarily a high priority for digital transformation. They also provide a means of identifying which business processes, IT services and applications are needed to support a superior end-to-end customer experience. This in turn informs which APIs are required to link together the supporting systems and data required for the customer journey (together with the associated advanced analytics) and provides real, tangible business value associated with those APIs.
By creating metrics that take these factors into account, the business value of (potential) APIs can be assessed in a transparent and objective way.
Second, APIs are not necessarily just about supporting the customer experience. In many cases, they are “technical enablers”, acting as a wrapper around legacy systems and enabling data services for business applications that contain business logic. The applications may then, in turn, provide higher level APIs and data services for systems of engagement.
From this perspective, technical value represents a more relevant metric. This measure can quantify the benefits of avoiding legacy technologies – where skills and resources are scarcer and more expensive, and where changes can be more complex and risky – and providing modern APIs (e.g. RESTful microservices) that are easier to consume by business applications and more adaptable to changing demand. Technical value may also include other quality aspects of APIs, such as capacity and other performance metrics.
Third, make sure that the portfolio of APIs is leading to a simpler, more adaptable IT landscape. One of the dangers of having autonomous teams building APIs and microservices is a complex proliferation of dependencies across a large network of connected APIs. Taking an architecture-guided approach to control this complexity, which allows light touch coordination across teams, avoids the pitfall of “API spaghetti” without requiring classical, monolithic, waterfall ways of working.
Perhaps the most important point to keep in mind, though, is that APIs are about data – providing data to applications in a reliable and performant way. So it’s critical to have a data architecture modeled, as part of the overall enterprise architecture, that enables data objects to be mapped to the APIs, applications and services that provide and consume them. This gives visibility into duplication of data services and APIs, enabling rationalization and optimization of the portfolio.
Modeling the data, API and application architecture not only supports business agility through faster transformation, but also supports governance, risk and compliance management by enabling these teams to quickly visualize the “footprint” of data in the enterprise landscape (e.g. for GDPR compliance reporting) and assess risks and impacts (e.g. for information security). Furthermore, this also underpins a full line of sight from the customer experience and business strategy, through processes and applications, to the data required to support them, enabling impact and dependency analysis for improved planning and execution.
In summary, the rise in APIs represents a significant opportunity for enterprises to accelerate their digital transformation efforts. However, it can be risky and costly if this is done in a siloed way, without business context and a clear understanding of technical benefits. By taking a portfolio approach, in which APIs are treated as first class citizens of the enterprise architecture, organizations can ensure they make the right planning decisions towards realizing the benefits of the API economy.
