Digital transformation seems to be focused on creating new digital capabilities, such as being able to accommodate social, mobile, analytics and cloud, but digital transformation isn’t just about creating the new, but also about utilizing the old. A large number of organizations undergoing digital transformation have been in business for many years and have dozens of legacy applications. These applications have an unprecedented amount of data locked inside them. This data has huge value to accelerate digital transformation, if only it could be easily used in new contexts.
Therefore, the ability to properly do digital transformation is measured on how effectively you can unlock data from legacy systems as well as how well you can bridge the new digital world with your old legacy one.
This is a tough job. How to unlock and make access to data to a broader audience within your organization, while keeping control and governance?
The answer that many IT leaders found was to use APIs as a means to facilitate data consumption. That was a good start, but that is also when many fell into a trap; they thought that API strategy to unlock data is solely accomplished by buying API management technology. This appealing simplicity has made several early adopters get into trouble. Buying an additional technical capability will not equate to having wide API adoption throughout your organization, nor will it make your partners, LoB IT and IT willing to consume your APIs. Sadly, many people were waiting for the data to be massively consumed, but it never really happened. Yet API Management became the scope of how IT organizations tried to tackle the challenge of API adoption.
To give one example, I recently met a large pan-European government institution which fully adopted a large scale, organization-wide, API management solution. Although there were good business and technical benefits, 5 years later they now find themselves with a mess of point-to-point connections with back-end systems to provide connectivity to the APIs. They have been spending a tremendous amount of money with the vendor’s professional service team to build, change and maintain those connections. This unforeseen cost eventually deteriorated the TCO of the initiative. It’s sad, but it happens quite often.
After the initial hype of APIs fades away, we see many API management pure-play vendors being acquired by larger software organizations. It seems that this pure technological capability by itself is not enough. API management by itself is not the silver bullet for digital transformation and not even a standalone software category. API management must and should be part of a larger and more comprehensive connectivity strategy which companies doing digital transformation need to adopt. If you want proof, just look at the latest acquisitions: Oracle buys Apiary, Google buys Apigee, Tibco buys Mashery…
What is the right way out of the API management trap?
In my opinion API management does provide some great things, and that’s important to recognize. However, the early adopters of API management solutions started exposing existing endpoints as APIs. People liked it, so as APIs became more widely used, more complex requirements came to the table. Soon organizations discovered that change happens: they needed to evolve their APIs, they needed to compose APIs together, and they needed to build new APIs for new situations. And this inevitable change led to new challenges; it inevitably led to governance challenges, but it also led to integration, design and development challenges. This started to reveal the importance of the full API lifecycle, not just the API management aspect. It also highlighted that only buying software is not enough to truly affect digital transformation. There was a need to have a proper architectural approach and an operating model for it.
Based on these observations, MuleSoft has developed a point of view on how to solve this problem. This point of view, which we have a whole product strategy to support, is centered around developing a different Operating Model. In my time with MuleSoft, I have seen this operating model work with several customers, including flyDubai, APG, Unilever, McDonald’s and Coca-Cola. This operating model is powerful because it uses technology in a way that is aligned with key business outcomes. It provides quick value while supporting long-term aspects such a self-service and reusable service.
If you are more interested in the complete point of view and how you can avoid the trap of pure API management, take a look at the e-book, First Break IT. The book will give you some insights about the MuleSoft hybrid integration platform which includes API Management but also other important complementary capabilities for full API lifecycle management. It will also highlight a prescriptive architectural approach called API-led connectivity. Finally, it will give you a glance of the right multifunctional team (C4E) that supports this operating model, enables a broader set of the organization to perform IT-like work, and evangelizes API benefits to the broader organization.
