Enterprise API Management: Q&A with Book Author Luis Weir

APIs are a key enabler for digital transformation by enabling democratized access to information through light-weight services that can be linked together to drive a business solution. While APIs are often linked with technology projects, there is much more to establishing an API program than technology. Buy-in from the business is vital to a successful API program. If organizations cannot link an API program to achieving a business objective, it is bound to fail.

In the Enterprise API Management book, Luis Weir provides technology-agnostic strategies that organizations can implement to drive more predictable outcomes. The topics that Weir covers in this book include the Business Value of APIs, Business-Led API Strategy, API-Led Architectures, API-Architecture Styles, API Life Cycle and more.

InfoQ had an opportunity to catch-up with Luis Weir to chat more about his book, here is what he had to say.

InfoQ: Can you please introduce yourself and share your career background?

Luis Weir: I currently work as a Director of Engineering at Oracle Hospitality (a suite of SaaS applications for managing hotel properties), working on a next generation and API-led cloud distribution platform. Prior to Oracle, I was a consultant and also an Oracle Ground breaker Ambassador and Ace Director, which are 2 of the 3-developer advocate programs sponsored by Oracle. With these programs, I was supported to travel the world and present at events such as Code One (former JavaOne) in San Francisco, London, Beijing, and Sydney, Devoxx UK, Gartner AAD&I in London, Java2Days in Sofia, and several other user groups across Europe.

My previous role as a CTO was for the Cloud Solutions practice at Capgemini UK, where I was considered a global guru in the topic of APIs and Microservices. That’s the reason why I was leading high-profile API engagements with the likes of Cargill (US/Netherlands/Switzerland), Yara (Norway), IKEA (Sweden), Co-op (UK), EnterCard (Norway/Sweden), to name a few. Also, I was specifically focused to help them define and drive global API strategies, including their subsequent implementation, and define their operating models in the context of APIs and Microservices.

Before becoming an API/Microservices junky, my career was mainly focused on Service Oriented Architectures (SOA) and integration, which I guess is a natural transition and one that I’ve seen a lot in the industry. As a SOA consultant, I also had the opportunity to drive strategic SOA engagements with the likes of Cummins (US), McDonalds (US), Rogers Telecom (Canada), Reed Exhibitions (UK), and Network Rail (UK) while also supporting a variety of initiatives around the globe. So, I can say that during my 16-17 years of consulting, I gained a lot of global exposure and experience from both success deliveries and some failures.

Going back even further, I started my career when I was still at university (Electronics Engineering). I was doing evening classes and therefore was able to take on a full-time job as a software developer for one of the largest livestock companies in my country of origin, Venezuela. Moreover, I was working as a freelance web developer and also helped my university develop many of their internal websites in exchange for a much lower university fee. It was a great time!

In recent years, I had the opportunity to co-author 3 books on the topics of APIs and SOA focused on Oracle middleware technologies. In the past 7 years or so, my experience hasn’t been only with Oracle, but rather as a tech-agnostic consultant I have been helping organizations with their strategies and selecting their right tech stacks. So, I decided to write a 4th book, a completely tech agnostic one.

InfoQ: What was some of your motivations for writing this book and what are you hoping readers takeaway?

Weir: One of my main motivation was to simply share my experience in defining and driving global API strategies for large organizations, some of which are considered among the largest in the world in their respective industries.

Also, what I think my main motivation is the fact that I could never find a complete guide on how to define business-led API strategies and drive their subsequent implementation. Yes, there is lot of literature out there, but scattered all over the place. For example, some literature would focus entirely on business strategies for APIs (e.g. API monetization, API for digital strategy enablement, etc.) but wouldn’t then cover more details about the implementation, operating models and software development lifecycle. Other literature (I would say the majority in the world of APIs), would just focus on the REST architectural style, whereas for me it is an architectural choice. For me, the term REST isn’t a synonym of what an API is. Then, regarding implementation, there is good literature around Microservices; however, such literature rarely talks about business strategy let alone API management. And lastly, for the topic of organizational models, again, lots of content around DevOps and Microservices exist, but not necessarily in the context of API management.

So, to summarize, I wanted to fill a gap. I wanted to create a guide, based on real and honest experience, on delivering business-led API strategies end to end. I wanted to cover the business aspects of APIs, going into more detail about API-led architectures, the full lifecycle of APIs and related disciplines (e.g. microservices) and also about organizations around API products.

Enterprise API Management has something for everyone. From business analysts to architects and developers alike, this book has something to offer. And the positive feedback that I’ve received so far seems to indicate that I’ve filled the gap I was aiming to fill.

InfoQ: What are some of the common pitfalls that organizations run into when implementing an API program?

Weir: Throughout my time as an API strategist and practitioner, I’ve seen many mistakes and I’ve also made some myself. The important thing is to recognize them and learn from them. The top 3 mistakes that come to mind are:

• First, thinking that API management is just about implementing a product or tools without having business and customer value at the epicenter of the API strategy (sometimes there even isn’t an API strategy). This is perhaps the most common one, and one that happened a lot in the old SOA days. Unfortunately, it still occurs in the modern API-led era. Chapters 1, 3, 7, and 8 in the book can be used as a guideline on how to avoid making an API management initiative less about tools, but more about business/customer value, people, and processes.


• Second, thinking that all APIs are the same and therefore treating them all the same way. In some cases, this just happens accidentally. In other cases, it may happen to avoid ‘layering’ APIs because ‘microservices architectures and practitioners say so’. The matter of fact is, an API that is built specifically in support of a given mobile application will be less generic and less suited for its used outside of the ‘context’ on which it was built, than an API that was built without any specific consuming application in mind (and thus is not coupled to any application lifecycle). Chapters 1 and 4 touch upon this and provide a good guideline on how to avoid this common pitfall.


• Finally, adopting the wrong organizational model to provide enterprise-wide API capabilities; for example, one that centralizes all API efforts and capabilities, thus becoming a bottleneck and eventually becoming slow (aka traditional IT). Modern API initiatives should think about adopting platform models with self-service at the epicenter. Chapter 8 focuses exclusively on this and talks about how to adopt a platform model suitable for modern, flexible, and agile API organizations.

In addition to the above 3, there are many common pitfalls when it comes to API architecture and design. To explore these, I strongly recommend my "7 deadly sins of API design" article and video.

This presentation covers many of these pitfalls in great details, and also provides valuable recommendations on how to avoid them.

InfoQ: In the Enterprise API Management book, you talk a lot about business engagement as part of an API program. What are some ways that organizations can engage the business in these programs?

Weir: Any API initiative should start by identifying the business drivers for such endeavor, such as what are the benefits targeted and why, how will these targets be measured once delivered, and what return can be expected on the investment (ROI) (naturally leading to the question, what is the investment required in the first place!).

At this stage, it is less about the technicalities of APIs and more about the business itself. Therefore, it is empirical to elaborate an understanding of the business domain, its language, its key stakeholders, and how it operates. Doing so can help in identifying ways on how APIs can help, or in other words, the business drivers?

Once such business drivers are identified, then it’s a matter of presenting them in a comprehensive way to the right stakeholders. At this point, communication and presentation skills matter a lot, and so does the language used. A lot can go wrong at this point. If the presentation is too technical, business professionals will struggle to understand the value of what’s been offered. If incorrect language is used or the nature of the business itself is misunderstood, loopholes will be found during the presentation. As I said, at this stage, it’s not about APIs per se, but the business of APIs.

Therefore, the most important advice I can give for this stage is that the individual driving the strategy should be someone who possesses the skills to talk to business professionals and technical people alike. Someone who can understand the nature of the business and also articulate the benefits of APIs without getting lost in the woods. Particularly, someone that can inspire and sell a vision.

Luckily, however, it’s far easier these days to accomplish the above-mentioned, as majority of business professionals are already familiar at minimum with the term API.  

In the book, I cover this aspect extensively and give good and concrete tips on how to identify and present such business drivers.

InfoQ: When organizations develop a business case for developing an API program, what are some return on investment (ROI) considerations that should be factored?

Weir: To truly answer this question, I must refer to the API Value Chain section from Chapter 1 (The Business Value of APIs) of the book. APIs are like doors, they come in different materials, shapes, colors, and sizes. And this is for a reason.

APIs, like doors, provide access; however, it’s that "something" they provide access to that determines the value of the API itself. Think of it this way, what is the value of having a door that doesn’t provide access to something? Just like the door(s) to your house are quite important, and so is the door that provides access to a bank or even more to the vault of a bank. These doors provide access to something quite valuable, and therefore they are also valuable.

Of course, it’s not that simple, and throughout the book I get into more details. However, to answer the question, even before determining the ROI, one must first understand that different types of APIs deliver different levels of business benefits. In most cases, these benefits are indirect and not quite straight forward to measure.

For example, an API that enables an omnichannel strategy to an organization has the potential to not just open up new revenue streams, but it also ensures that a business remains relevant in an already digital world. But how can this be measured?

I think, there is a misconception in the industry at the moment that in order for APIs to deliver value they have to got to be monetized. Nevertheless, it is definitely true that APIs can be monetized on (meaning APIs as business products). As I described in the API Value Chain section in the book, there are huge business benefits that can also be gained indirectly; in some cases (and depending on the nature of a business), perhaps even more so than direct monetization on an API.

To summarize, one must first understand at what levels an API can deliver business value, and then, as already described in my previous answer, elaborate an understanding of the benefits that can be delivered through different APIs and how such benefits can be measured. Factor this information and understand the cost/effort that involves delivering not just the API strategy but subsequent implementation, and you can calculate a ROI. I recommend going through my book for details on how to accomplish this.

InfoQ: APIs provide the ability to democratize access to data. What are some considerations that organizations need to account for when governing the access to data through APIs?

Weir: APIs not just democratize access to data, but also to functionality. For example, there is an emerging type of API that offers access to AI/ML algorithms rather than data itself (in this case, data is the input for the API).

In any case, it’s not news that majority of organizations are adopting multi-cloud strategies, rather than putting all their eggs in a single’s cloud vendor basket. The consequence of this, though, is that data becomes federated as if it wasn't challenging enough to govern access to data in a single data center. Needless to say, governing access across multiple clouds (plus on-premise most likely) presents even a greater challenge.

Therefore, organizations really need to think about those API management capabilities that can spread across clouds while still having a single point of management (or single control-plane). In practice what this means is having the ability to manage access to APIs that could be in AWS, Azure, or Oracle Cloud, however, from a central place. This is what I refer to as 3rd generation API Platforms and describe this thoroughly in Chapter 2 – API Platform Evolutions.

Last and an important tip, cloud vendors are more and more looking for ways to lock customers in. In the context of APIs, it refers to vendors that offer API Gateways and management capabilities that only run in their clouds. However, for some specific type of APIs, using such single-cloud capabilities won’t present a problem (In Chapter 4, I refer to such APIs as single-purpose). In general terms, it is not just because of the "lock-in" factor, but also because it makes it a lot more difficult to consistently and holistically govern the APIs.  

InfoQ: SaaS applications often have an API-first strategy for interfacing with external systems. What are some tips for organizations who have legacy systems that can benefit from having an API tier?

Weir: Well, I would go beyond and say that a SaaS application that doesn’t offer an API is as useful as a computer not plugged to the internet. Yes, you can do stuff, but nothing goes in or out. Everything stays there. Locked!

Also, legacy systems are not different. In fact, several industries, specially banking and finance, still run on legacy systems (refer to my presentation "A microservice approach for legacy modernisation" for more details). And then, online banking is "the thing" these days, and a bank that doesn’t offer an online banking experience these days is as useful as the internet-less computer I mentioned earlier.

Therefore, it is not possible but a fact that even organizations that run on legacy are capable of implementing successful API strategies. And this can be accomplished by adopting techniques that allow the implementation of modern architectures that are capable to interface with legacy systems. This is perhaps a topic worth of a full book, but in my presentation that I shared earlier, I provide a concrete approach on how to accomplish this. This approach can be nicely completed with the architecture and patterns I describe in Chapters 4 (API-led architectures) and 5 (API-led architecture patterns) in my book.

InfoQ: How should organizations see API Management solutions vs Integration Platforms (ESBs, Message Oriented Middleware)? Do they complement each other, or do they compete?

Weir: In the broader definition of Service Oriented Architectures (SOA), all these tools and the capabilities they offered can be complementary. However, the devil is in the detail as it goes, so the answer to the question really is "it depends".

In my book, I have dedicated an entire chapter to explain how platforms have evolved from being monolithic magic boxes that could do everything in the name of SOA (system to system integrations using ESBs and messaging, business logic implemented with BPEL and rules engine, web services security, heavy SOA governance, etc.) to more light-weight capabilities that have clear separation of concerns in what they offer, and thus are better suited to be adopted in support of modern distributed architectures, especially those based on microservices and cloud-native.

For this reason, modern API management capabilities are less about integration (the wires connecting multiple systems including the capabilities involved in doing so, e.g. data transformation, orchestration, etc.) and more about managing and mediating the access to distributed (micro) services (or using the same analogy, the plugs wires connect to). So, in this sense, modern API management is complementary to integration and/or service implementation capabilities, and this becomes quite evident as I describe 3rd generation API Platforms in Chapter 2. Let me elaborate further.

Having said that, I don’t think that traditional SOA middleware (e.g. ESBs, BPEL engines, etc.) are obsolete. Quite the opposite. With hundreds if not thousands of organizations having already made heavy investments in these technologies (in many cases having become as business critical as the business systems they enable), even the thought of migrating and/or re-engineering these systems into a modern stack, will raise some eyebrows. Some would even argue (perhaps rightfully?) that the risk and cost of doing so outweighs the business benefits that could be gained. Either way, whether a transition occurs or not, the bottom line is that organizations will have to find ways to enable the co-existence between their traditional (monolithic) applications, and modern ones built on modern stacks.

I think traditional middleware have a crucial role to play in enabling such co-existence and transition as they can act as bridge from traditional to modern and vice-versa.

InfoQ: Once an organization has developed an API program, what are some tips to sustaining that program operationally? Do distributed support models work or should organization try to centralize that function?

Weir: As I describe in detail in Chapter 8, API products target an operating model, I think the best model top adopt is one that enables the organization rather than acting as a central bottle neck.

Through a platform-based model, organizations can decentralize the people capabilities required in order to deliver and support API products, whilst at the same time leverage, ideally (and desirably) via self-service tooling, a common set of technology capabilities thus avoiding re-inventing wheels and increasing costs.

I quote what I said in the chapter, as I think this explains the notion quite well:

"The core idea is that by offering an API platform as a set of self-service capabilities (e.g. those described in Chapter 4 – API-led Architectures) product teams don’t have to undergo heavy processes and/or have to spend lots of time liaising with a central organization in order to get access to the tools and capabilities required to deliver API products."

And then I continue to say:

"It is important to understand, though, that in order for this model to be successful, the platform must truly deliver to its expectations. This is absolutely crucial as failing to do so will most likely result in product teams being frustrated and being creative in finding ways to avoid utilizing the platform."

What I meant by this is that I’ve seen first-hand how a platform team instead of becoming a true platform just like Facebook or Twitter with rich set of self-service capabilities (think about it when was the last time you rang any IT support for any of these social platforms?). They look more like traditional IT whereby gaining access to any capability is process heavy (e.g. raising tickets, filling spreadsheets), with many manual steps (e.g. email exchanges) and thus time consuming.

InfoQ: With some organizations, like Netflix and ESPN choosing to shut down their public API presence, where do you see the API Economy heading? Is there still room for organizations to monetize their API programs?

Weir: The API economy is not just about API monetization or public APIs. There are many ways an organization can gain value out of APIs – as I believe I explained in some of my previous answers.

Netflix, for example, still offers a partner API (e.g. see this link), which is arguably also a public API, however, restricted to a known audience (Netflix partners). Furthermore, just Netflix internal video streaming APIs enable its 16-billion-dollar business, even if they’re not directly monetized. This is also part of the API economy.  

As ESPN themselves said in their developer blog (I found it here and here), their APIs running on their API platform although would not be directly monetized, and more business product would continue to be built on it.   

"As part of that evolution, we have made the difficult decision to discontinue our public APIs, which will enable us to better align engineering resources with the growing demand to develop core ESPN products on our API platform."

About the Book Author

Luis Augusto Weir is a Director of Software Development at Oracle and a former Chief Architect at Capgemini, Oracle Ace Director and Oracle Groundbreaker Ambassador. An API management and microservices evangelist, Luis has over 17 years of experience implementing complex distributed systems around the world. Co-author of 3 other books as well as numerous articles and white papers, Luis has been a frequent speaker frequent speaker at known events such as CodeOne, Devoxx, Gartner AAD&I, Oracle OpenWorld, Java2Days and many user groups and meetups. Luis holds an MS in Corporate Networks and Systems Integration from the Universitat Politecnica de Valencia (UPV) and a BS in Electronics Engineering from the Universidad Nueva Esparta.