There is a common perception amongst small to midsized corporations that an Enterprise Service Bus (ESB) is cost prohibitive.
Let’s explore the ESB advantage and help your business:
Click on any advantage to read about it.
Overcome the Barriers to Entry
When looking at the barriers to entry for any middleware solution, we are talking about two things: infrastructure (hardware and software) and resources. While many corporations think you have to invest in expensive software and highly specialized (i.e. expensive) people to make middleware work, ESB is cost effective. If we look a little deeper, we can see that you’re already paying for most of the cost. The portion you’re not paying can be scaled to your situation. Let’s look at both individually.
Infrastructure
While there are costs associated with standing up an ESB, those costs can be tailored to your specific scenario. Most ESBs can run on multiple platforms and be virtualized or (increasingly) hosted on the cloud.
From a software perspective, many ESB products offer tiered pricing where you can choose the features that suit your requirements. There is no need to purchase a product with features you neither need nor want.
Resources
You will need an admin. You will need a developer. Do a comparative cost between ESB knowledge (learning the product ) and protocol knowledge (needed regardless). The critical question to ask is whether the cost you save by using an ESB is greater than the cost of learning the ESB itself.
Take a close look at your current integration portfolio. You’re probably already doing some flavor of EDI, File Transfer, Web-Service (SOAP & REST), and cloud integration (and that doesn’t even include the different security protocols). With every one of those integrations, you had to pay for someone to learn each of those formats. Contrast that with an ESB, where most use drag and drop widgets that simplify all of that for you. Some products provide built in development patterns based on specific integration scenarios: grab, configure, and deploy. When using these built in widgets and patterns you can switch the ESB value proposition by using the product’s offerings to future proof your application.
Infrastructure Suited for Agility
The changing world of information requires a system to react quickly, incorporating a large range of API’s and protocols without stopping the business-driving functionality. At its core, this modern economy is about service oriented architecture, exposing your business to the world in the form of re-usable services. In order for any of that to work, your services must be stable, with consistent interfaces; otherwise, a significant portion of your IT spend will be on regression testing. At the same time, your systems must be flexible enough to adapt to changes to your partner services. An ESB is the foundation of a service oriented architecture providing a barrier between your services and the consumers.
The ability to quickly switch or onboard providers without bringing your systems to a halt is a very real advantage of having an ESB. Here is a real world example: two similarly sized companies, one with an ESB (company A) and one without (company B), replaced providers for a shared enterprise service. Both providers shared their services in a similar matter, but company B spent 15 times more than company A. Company A cut over the integration for $20,000; company B’s cost over $300,000 – and that is only IT spend. It took company B several months to complete the cutover, and company A completed it in 4 weeks. This stark contrast can be explained for two simple reasons:
One.
Company A’s ESB allowed for a once only change, and they didn’t have to consider all consumers of the service. The ESB allowed the inputs to stay the same; nothing changed from the perspective of the business services.
Two.
Company B had to find and change every instance of the service call within every application. Regression testing had to occur across the entire enterprise. This resulted in a much larger team, slower time to market, and higher risk and costs.
Create Consistency Across Your Enterprise
If you have a strong architect or technical go-to person, they will undoubtedly say their system supports many of the same features of an ESB. If you have multiple systems, each architect or go-to technical person will tell you their system can support much of what an ESB does. The end result of following the advice of these business-system experts is a muddled architecture with multiple ways to accomplish the same task. Why not consider using native functionality of your business systems and offloading the customization to a system tailor-made for it? In the end, you are not only reusing services, but also maximizing the out of the box functionality of your systems. With less customization and more consistency, companies assume less risk while increasing time to spend on revenue-driven initiatives.
Get The Most Out of Your ESB: Beyond Routing and Transformation
Most companies don’t switch providers every day, and some do not have a whole ecosystem of applications to maintain. Maybe your organization is largely self-contained with a few smaller integrations built in. What is the value of an ESB when your systems aren’t so complex?
In simplified scenarios where you aren’t doing a lot of service orchestration, here are a few ancillary offerings of most ESBs that are worth considering.
Audit
Security
Workflow Management
Pause Transactions Mid-flight
Need more? Reach out to us to learn what we can do for your business.
You may also be interested in Resolve UX & Server Performance Hiccups Faster, With Dynatrace for IBM Commerce, courtesy of Ravi Sama, BlueSky Solution Architect.
