The Message Behind #NoESB
We have always advised creating and managing efficient, effective integrations between applications in an effort to get the most value from your data. The currency of a digital business lies in the data it processes and delivers, so ensuring access to relevant data repositories is critical to success in the digital economy. For a long time, an enterprise service bus (ESB) was the defining tool to integrate and connect applications. However, as businesses have become more digital in their focus, and as enterprise infrastructure landscape has both evolved and matured, an ESB is no longer a reasonable option. In order to help our customers and stakeholders thrive, we have taken it as our mission to drive this message home. "No ESB" is the mantra from the Akana offices, and here's why.
Why No ESB?
When applications performed rudimentary communication between and among them, standard services integration required a tool that could provide the necessary connecting points.
When ESBs first became prominent, it was because they had connection capabilities that were tied to specific applications. When only two apps needed to talk to one another, that was fine, but built into that paradigm was a proprietary mindset. To enable actual data transactions required dedicated, complex layers of code to enable access, gateway, messaging, integration and ongoing management. Creating the connection between apps via an ESB was similar to product management. Requirements needed to be built and managed, and usually an entire development team was deployed to ensure a seamless application experience (although very little attention was paid to what the end-user experience was).
Today, a 1:1 relationship between and among apps is extremely limiting and simply wouldn't work in an environment where apps communicate and transact with multiple other apps. The end result is vast amounts of data that come from different sources, and are used on mobile devices, in the cloud and through the Internet of Things. Speed, flexibility and openness rule the world of applications nowadays, and an ESB would bring all of that to a grinding, limiting halt. The purpose now is not to join apps, but to build new business opportunities through digital channels.
Does that seem way too declarative? Well, development of apps will not slow down, and every day an organization looks to apply ESB principles to app management is another day they will be limited in what they can create and deliver to customers. App development and delivery cycles require weeks, not months, and because every app seems to have at least some mobile component, versions will be updated rapidly. The drive among app developers is to get the idea to market quickly, and adapt as required. The ESB model focused primarily on authentication and LDAP-based accessibility. Here again, doing that is cumbersome and prevents quick action when needing to bring an application to market, or enable it to interact with mobile and IoT devices.
One of the many advantages of an API is that connectivity among apps gives way to more emphasis on authentication and threat protection. These are things that can be done through the API; they aren't separate tasks with specific requirements, which is what an ESB would have required. With an API, security is more rigorously enforced, but it's done in a more flexible environment. The developer has little to do because authentication and integration are baked into API functionality.
What is now required is an application gateway that can easily integrate and connect apps that are already delivered with hooks and other typically inherent API-unique features that prepare them to be connected with other apps. Full disclosure, yes, we make an app gateway, so we're fully committed to promoting that. But we also get no benefit from keeping customers operating in an outdated, inefficient system that will prevent them from reaching their business goals.
Hence, our message of "No ESB". Cloud, mobile, IoT - this is the state of the evolved application development, and without question, an ESB will not allow you to achieve any degree of success in those areas. Most applications now come with standard REST APIs which enable flexible and rapid creation and deployment of robust apps, all powered with data from multiple repositories. The architecture for integration now resides within these APIs. A connecting "bus" is not just irrelevant, it's damaging.
Our version of success includes all enterprises sharing data securely in an effort to deliver better and more productive applications. We prosper when our customers prosper, and they can only do that when they operate with the right tools and vision. We will continue to crusade against the use of ESBs and direct app developers and digital businesses to operate in a way that is conducive and complementary to achieving success.