API-Led Architecture is the New API Strategy
Blog: The Tibco Blog
I’ve observed an interesting trend in the API space over the past few years. The producers of popular public APIs — Facebook, Twitter, Netflix, ESPN, etc. — either clamped down on the levels of data and functionality they exposed, or they pulled their APIs from the public completely. There are still plenty of public APIs out there for the average developer to integrate with their applications, but the hype seems to have completely died.
This may seem like the death of APIs as a business model. It turns out the truth is quite the opposite — many of these APIs are more powerful and more useful than ever, only the strategy of how they are used has changed. RESTful APIs were originally heralded as a way to open development on a platform to the community of independent developers who were the vanguard in mobile, web applications, IoT, VR, and similar technologies that dwell for a while at the edge of most corporate priorities before they become mainstream.
The fact is, it worked. The success of many social network sites like Facebook and Twitter is due in no small part to their efforts in aggressively promoting development on their platform. Those annoying cow-clicking requests you got from friends drove engagement and encouraged greater adoption of their service. It helped them ramp up to early growth.
But the pattern now seems that, once a level of growth is achieved, those APIs get locked down. This is not because they didn’t work — to the contrary, they fueled that early growth — but because the ROI on a public API is not as strong as the ROI for taking these services internal and allowing their own developers to take advantage of easy to integrate, fully functional web services.
The value in adopting APIs has always been in opening an organization’s data in a secure, consistent way that is both programming language and environmentally agnostic. Web service APIs don’t care if your application code is written in C# served on a Microsoft Windows machine or Python in a Kubernetes cluster. They don’t require special libraries beyond the HTTP libraries that come standard in most languages. With proper management and authentication attached, they can be easily secured and controlled from a central location. And, when designed so each service can stand independent of the other services on offer and decoupled from any specific use case, they can be easily re-used for multiple applications, significantly reducing development time and costs.
This was originally accomplished by placing an API layer over the underlying system — not unlike how one might create a website to access an underlying database in a more user-friendly way. The original pioneers of API adoption quickly realized that the value they were providing to outside developers had even more value to the developers on their own staff. Mentioning the famous Jeff Bezos mandate from 2003 exhorting all of Amazon’s developers to expose their data and functionality through services or risk termination is cliche at this point, but that’s for good reason. Amazon was, at first, a bookseller, then an online mall. They are now also the dominant force in cloud hosting and computing because every service they built to manage their own massive infrastructure was designed to be accessed through APIs. This not only allowed them to better scale as their business grew to massive proportions, it opened a whole new line of business through their Amazon Web Services offerings.
API-led architecture is the final realization of years of figuring out how best to manage large infrastructures that must rapidly adapt to changing market conditions. Where the enterprise service bus obviated the need for flaky point to point connections made through proprietary protocols, web service APIs served natively from hosted applications have opened up new levels of access and efficiency without adding much overhead. Whether they live in the cloud or within your own datacenter, hosted applications that serve their own APIs — especially those modeled on popular designs like REST — make it easier for your internal developers to quickly integrate them into existing workflows and applications. Microservices have risen as a major development paradigm because they so closely hew to the same design principles that make these APIs valuable. The modern integration stack is built on these APIs and will be for the foreseeable future.
The reality is that most enterprise-level companies do not currently have what may be considered a true API-first approach. Years of legacy development on systems that required doing integration “the hard way” can not be so easily undone. In most cases, it would mean completely scrapping these legacy systems — systems that still drive value for the organization and work well for their purposes. I’ve seen some companies attempt to do just this, but it has always cost a tremendous amount of time and effort, taking focus from doing the things that made the business a success in the first place. In most cases, it’s just not worth it.
But that doesn’t mean you can’t adopt an API-first approach in all of your new development. Tools like BusinessWorks and TIBCO Cloud Integration can help you integrate with your legacy systems — even those still operating on mainframes — while transforming the data and functionality they support into modern API styles with very little loss in performance. Adopting an API strategy doesn’t mean you must expose these services to the public; it means creating an experience for your own developers that makes them more efficient, better able to adapt to changing market conditions, and happier as they are able to use the latest and greatest technology they see out there every day to improve the work they do for your organization.
We’re in the third phase of the API revolution. The promise of service-oriented architectures has finally arrived, and they’re more efficient and easier thanks to the widespread adoption of web-based service best practices. If you’re looking at your creaky old infrastructure and wondering how you’ll ever bring it to modern standards, TIBCO’s team of experts is here to help. We’re your best partner as you adopt the modern integration stack and make the move to an API-led architecture.
Leave a Comment
You must be logged in to post a comment.
