Our recent webinar featuring Forrester Research took a deep dive into three big mistakes when it comes to APIs and microservices. Ian Goldsmith, VP of product management for Akana, and guest speaker Randy Heffner, VP & Principal Analyst at Forrester Research, helped attendees better prepare themselves to drive the right solutions for their organizations. We received a lot of great audience questions during the webinar – far more than what we could tackle in the Q&A. In this post, Randy Heffner answers three of your questions on APIs and microservices.
There are two major approaches. First, very few executives appreciate the business value of platform investments in APIs and microservices, so rarely does it succeed to sell on the abstract value of the architecture. However, most can understand business investment strategies that build on one another. In this case, get above the level of an individual project to identify a portfolio of known business change initiatives and known industry pressures that are likely to drive business change. Estimate and compare the cost and time-to-value of responding to these streams of change with and without APIs and microservices. In other words, raise the conversation to the project portfolio level, because that’s where API and microservices synergies have their greatest impact, and cast the conversation in business change investment terms, not architecture value terms.
Second, some business initiatives have API value built-in, and these can be sold on their own. For example, if a firm aims to improve its order fulfillment process across multiple channels (e.g., mobile, web, kiosk, direct partner integration), APIs are the best technical approach to enable consistent customer experience and business process results no matter which channel an order originates through. In this case, APIs should be the default architecture proposed, with no discussion of non-API approaches.
One must be careful about jumping too quickly to the strategy of converting legacy apps. To make this clear, it helps to distinguish clearly between APIs and microservices. With APIs, one can use a variety of available legacy modernization and API integration tools to quickly build business APIs that provide access to the business transactions and data buried in a legacy app. This avoids the expense of converting the monolith and meets the needs of digital transformation by enabling dramatic improvements to customer and employee experiences, not to mention API-based business process optimization and B2B integration.
This approach is great when legacy business rules and data largely align with the future of the business, but when business dynamics drive rapid change to the inside of a legacy app, it’s time to start carving off chunks of the app and converting them to microservice architecture. Each chunk would serve a cohesive set of business functionality (i.e., a single business capability) and provide the business APIs related to that capability. Gradually the legacy code behind each chunk would be replaced with modular, separately deployable microservice components.
Business capabilities provide a major organizing structure for teams that deliver APIs and microservices. The answer to the previous question described how a legacy application would be divided into business capability “chunks.” Each business capability (e.g., order fulfillment, billing, inventory, and so on) becomes a software product delivered by a team (an individual team may own one or more business capabilities). The team is responsible for the business APIs that embody the services provided by business capability, and they are responsible for the implementation of those APIs as microservices. The beauty of it, though, is that other teams that use the APIs do not need to know (in fact, should not care) whether the business APIs are backed by microservices, legacy integration, or any other implementation method — all this is the private business of the team responsible for the business capability.
In addition to these business capability teams, an organization may have a center of excellence for APIs and microservices (or more broadly, for cloud-native solution architecture) to establish collaborative design and governance models that foster evolution of coherent portfolios of business APIs. Lastly, an organization may have teams whose API focus is on technical capabilities and other types of APIs, such as integration or infrastructure APIs.
If you haven’t already, be sure to watch the on-demand version of this webinar. Randy weighs in on several other interesting questions concerning APIs and microservices.