Adopting APIs and Microservices? Read this Post

If your organization is on the path toward an API-driven strategy, with microservices as the back-end implementation, you must read this article. Recent work with a commercial client has exposed the existence of a great deal of confusion and hype about the API approach that is unwarranted. While the microservices implementation is emerging as a very compelling application architecture approach for new applications and legacy modernizations, the API as the service interface is not new, nor is it as difficult as "classic" Service-Oriented Architecture (SOA) using Web services with WSDL (Web Services Description Language) service interfaces. If anything, the more contemporary API approach is much easier, as the ReST-ful API is a much simpler and eminently easier-to-consume approach to consuming services from a provider via the exposed API.

The API-based approach is not new, and it is not difficult. At the end of the day, there are a few key points about the API approach to worry about, and that’s it.  Here are some things to think about, but not to obsess about:

1.    Manage Expectations

2.    The API approach is SOA, and APIs are easier than “classic” SOA

3.    Do you need a Center of Excellent (CoE) or a “Center for (API) Enablement?”

4.    Get going and don’t overthink the API model.

Manage Business Expectations and Desired Outcomes

As with most technology trends, the API-led approach has received a ton of hype and buzz over the last few years. However, as we learned with “classic SOA,” over promising and under-delivering is a recipe for disaster. The API based approach has clear benefits and value, much as SOA did, but they are much easier to expose and consume. Nonetheless, you must manage business partner expectations about what an API-led approach will, and will not, do for the business and for Information Technology (IT). 

APIs are basically an easy-to-consume service interface to an underlying implementation. The functionality of the implementation is presented as the API. So, the API is only as good as the underlying exposed end points and the implementation of capabilities via microservices or via integration technologies, e.g. ESBs, or what have you.

APIs will not fix the IT organization. APIs will not in and of themselves fix IT delivery processes or improve time to market. APIs are easy compared to legacy SOA, but there are still organizational, technical and procedural fundamentals that must be addressed to “fix IT.”  In fact, a Mulesoft whitepaper suggests “breaking IT” first to exploit the benefits and value of APIs. However, not many businesses are ready for this approach, nor do they really want to be held accountable for IT delivery within their business unit boundaries. IT is hard work. APIs can help in some respects, but APIs don’t fix IT, and “breaking IT” will not help with the adoption of APIs. And believe me, the business really does not want the responsibility of IT delivery, because they know in their hearts that IT is hard work.

APIs are “Simpler SOA” but they are still SOA

There is a lot of content explaining the differences of these two closely-related paradigms. The technical approach and implementation is slightly different, but it is still closely related. However, the key aspect of APIs is that they share the basic fundamentals of the SOA operating model. There are providers of services, who expose capabilities via an API, and there are consumers of services, who consume the capabilities by accessing the API. The consumer-provider interaction model is foundational to APIs much as it was foundational to SOA. If there is not an organizational conceptualization of the roles and responsibilities of providers and consumers, and the governance that applies to these interactions, then the API-led model will be reduced to a technical integration approach.

The API approach is at its core a Service-Oriented Architecture (SOA) approach. With most organizations’ intentions to leverage APIs, Microservices, classic-SOA and integration services, as well as Cloud Services and Docker containers, the API approach is SOA with a capital “S.” 

It is important to emphasize that the SOA architectural paradigm is 15-20 years old. SOA is a known and mature model, and has evolved into today’s world of Representational State Transfer (ReST) APIs (as opposed to legacy SOA Web Services Description Language (WSDL) service interfaces) and Cloud computing services. The API architectural approach is about 10-15 years old, and as a result is a known and mature approach. 

Service-Oriented Architecture (SOA) is predicated on a Consumer-Provider interaction model, with a clear separation of concerns and roles between Service providers and the Service consumers. In the API-led world, this relationship is identical.

Service providers (API providers) enable, expose and provide “Services” to potential consumers, typically via a Service registry and/or a Service catalog. The Service provider in the the API operating model is often the IT team that "owns" the APIs and service implementations. They are operate the API enablement and runtime platform, which is the framework for building/exposing microservices and APIs, hosting them, and managing them as they are consumed in production.

Service consumers (API consumers) who have potential needs for Services, will access and browse the Service catalog, and if there are Services that have utility, they can access, subscribe to and consume them. Service Consumers in the API ecosystem are Business unit customers, supported by their respective Business IT organizations. 

Now, in the API approach, there is also a desire to engage 3rd party developers by establishing an API ecosystem that encourages broad consumption of APIs to potentially generate revenue from the APIs, as well as create customer and developer loyalty. Therefore, we can easily extended the core consumer-provider model to include partners and 3rd party developers.

 So, in summary, the API approach is SOA, and its foundational principles and governance requirements have already been defined in the classic SOA approach, with some minor extensions and differences in the implementation. If you mastered SOA, you will have no challenges with APIs. If you failed at SOA, APIs are easier, but there are still organizational, technical and cultural challenges to be addressed. APIs will not fix those.

Do You Need an API Center of Excellence or Not?  

When an organization is new to APIs, or any new technology for that matter, there is often an internal debate over whether to form a tiger team to support the API early adoption needs of the organization, and then formalize it by forming what is conventionally known as a “Center of Excellence” (CoE). Some API “pundits” advocate for a Center for Enablement in the world of APIs rather than a CoE. However, a “Center for Enablement” is merely a properly-formed CoE in this author’s view.

An API CoE has a number of key functions that it might perform, and they are all valuable. The question is one of scale. How many API architects or solution architects are necessary to support the initial API adoption by business projects or products, and then to sustain the potential enterprise demand from a full-blown API-led approach? The API CoE should plan for and provision resources to project/product teams to augment their assigned delivery resources, and help facilitate the API adoption process. The following functions might be considered in scope for a possible CoE:

·      Outreach and marketing of the API-led model and the organization’s API Platform

·      API concierge support— assist with navigating the CoE process

·      Perform Business Engagement and API consumption Project/Product team interface (with internal Business Consumers)

·      Provide API Resources: Support API consumption projects with API architects, API solution architects, API coaches/mentors and, as needed, Business Subject Matter Expertise.

·      Engage Enterprise Architecture (EA) and solution architecture (SA) support as needed

·      Perform/Facilitate API Governance (API qualification, portfolio ownership, API Certification, design time, runtime, versioning, etc.

·      Project knowledge artifacts, solution blueprints, and other useful guidance

·      A CoE API Developer portal will be available for external partners and 3rd parties to onboard into the CoE process

·      Provide an onramp to API Innovation

·      Provide Support for Partners and 3rd party developers, and onboard them into your API Ecosystem

Now, in reality, these functions can be provided with or without a CoE, and it all depends on the API strategy you are pursuing. The relative formality and structure of the Center of Excellence depends on how aggressively your API approach will be pursued and scaled. If you are planning a major API transformation, or API approach in support of a Digital Transformation, then you should formalize many or all of these CoE functions. Either way, you must provide some level of support for many or all of these CoE functions and processes.

Get Going, and Don’t Overthink APIs.

This is key: Do not overthink the API-led model and ascribe to it more complexity than needed. As suggested before, many of the API adoption challenges have already been solved via the classic SOA paradigm. Go back to first principles of SOA and you will have the basics for API success. Much of the hype and implied complexity of the API-led approach is by technology vendors who are selling products, e.g. API management tools, API/SOA infrastructure, et al. They clearly have an incentive to “scare” you into buying tools to hide the underlying complexity of API adoption. Don’t fall for it. Understand APIs, develop a formal strategy, develop a reference model and reference architecture, and begin the process of API adoption. Get going. But do not overthink APIs, or confuse API adoption with other initiatives that may support it, e.g. Agile methodology, capability-based planning and development, or even Bimodal IT, e.g. Gartner. These things are noise. Get going, build the team, get the planning and technology right, and engage with the Business.  In Afrikaans there is a saying, N boer maak ‘n plan,” which means the farmer makes a plan. It is often used as, “Let’s Maak ‘n plan,” or let’s get going (often by thinking on your feet and adapting your original plan.) With APIs, my advice is, Let’s Maak ‘n plan. Get going, don’t overthink it, and plan for desired business and IT outcomes you seek. If Agile methodology or capability-based planning aid your API efforts, fine. But they are not central to your API success.

Final Thoughts: AgilePath has developed a very mature API CoE Design Specification that may be useful for your organization. If you are interested in the Table of Contents (TOC) or the entire specification and organizational design, contact me at [email protected].