Akana Platform Free Trial

Get Started Today »

Roberto Medrano

noesb2We 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 SOA Software offices, and here’s why.

NOesb

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.

noesb2

Share Button

5 Comments

  1. REST Architecture complements the NoESB concept and that looks like the future.

  2. Interesting, but ESB’s are not targeting 1:1 integration, they are actually built for reuse, any integration point is created to benefit multiple consumers/apps.
    And what is so drastically different in API gateway, is not that same concept of offloading common functionality (authentication, trnasformation, composition) to a specific layer? Just an ESB that supports API/ RESTful interfaces…

  3. I totally agree that ESB’s are not required in the enterprise. They are too expensive and adds a major dependency to most projects (a “middle-man”). Even worse, I have examples where the integration estimates are higher than the projects requiring the integration. Totally unworkable, and most enterprises are smart enough to realise there are better ways to do things, and API’s and Gateways meet that requirement. I also note that BPM software is also is being positioned properly when you remove the ESB from the architecture.
    What I am interested in, is one of the main features of ESBs has been the notion of removing point-to-point connections which has been positioned as creating “spaghetti” of integrations within the enterprise which make software hard to manage and maintain (etc, etc) rather than a nice bus (or hub-and-spoke) style architecture.
    APIs don’t get around this problem, so is the general position that this (point-to-point) has been oversold and is not the problem that it is made out to be? (My opinion is yes, it has been and is not a problem -> the only problem is for architecture diagrams which look too “messy”). I guess we could talk about other features such as auditing, logging, and security but I also believe that these were nice to have features rather than necessities (and we have other ways to address this rather than a heavy weight ESB).

  4. […] simplify application management, API gateways are starting to be used more as the answer to “no-ESBs” to quickly integrate applications. This is a logical evolution; API gateways already adhere […]

Add a comment