From the Blogosphere
Avoid Getting Lost on the (Enterprise Service) Bus
The risks of ESB-first SOA projects and how to mitigate them
By: Jason Bloomberg
Jul. 30, 2009 06:30 PM
So, you've been following ZapThink long enough to know that beginning a Service-Oriented Architecture (SOA) project by purchasing an Enterprise Service Bus (ESB) is starting at the wrong end of the initiative. Purchasing any technology, especially an ESB, at the beginning of an architecture project is a recipe for failure, you've been telling anyone who'll listen. But for whatever reason, your organization didn't pay attention to you, and now they've dropped a bundle on an ESB. Maybe your boss golfs with the vendor sales rep, or maybe the powers-that-be are listening to the wrong analyst firm, who knows. But in any case, you're stuck with that decision, and you're now expected to implement SOA with it.
Fortunately, while purchasing an ESB too early in a SOA project does substantially increase your risk of failure, all is not lost. After all, you're not alone; this mistake is one of the most prevalent SOA snafus in IT shops around the world today, and not all of those projects end up as failures. Many of today's ESBs are now mature products, and can be an important part of a fully functional SOA implementation. Understanding the risks that buying an ESB too early in a SOA initiative presents, and dealing with those risks proactively, can turn a bad situation around and get your SOA initiative back on the right track.
Understanding the Risks
In fact, the pitfalls that the ESB-first approach introduce fall into three broad categories:
ESB-First SOA Best Practices
In particular, it is essential to take a process-driven approach to your infrastructure, instead of an integration-centric approach. Remember that building Service compositions that implement processes typically compose capabilities across multiple execution environments. Furthermore, those compositions are both dynamic and unpredictable -- the business process specialist in charge of the compositions may change them around long after you've deployed the Services. Governance becomes the key to managing that unpredictability, rather than pre-defined integrations.
As a result, you shouldn't rely upon any one execution environment for your Service implementations, or any one process management environment either, for that matter. ESBs can offer an effective, managed execution environment for some of your Service interfaces, but you rarely if ever want to rely upon any one runtime environment for all of your Services. In other words, you should balance the advantages of running your Services "on the bus" with the fact that SOA allows you to leverage heterogeneity both on and off the bus.
One essential point here is that SOA leverages interoperability more so than portability. In a virtual machine-based "write once, run anywhere" environment, whether Java or Microsoft Common Language Runtime (CLR)-based, distributed computing relies upon the portability of code. SOA, however, leverages the interoperability of the Service interfaces so that you don't need to move the underlying Service implementations around. As a result, running all your Services on the ESB can actually impede your SOA implementation, rather than support it.
So, if you shouldn't think of your ESB as either integration middleware or as a universal Service execution environment, then what role should your ESB play? The answer is a Service intermediary. Transformations and content-based routing are the essential capabilities a Service intermediary should deliver, in conjunction with robust security and management. Building the Business Service abstraction depends upon transformations and content-based routing, and fortunately, most ESBs offer these capabilities. So, only use the traditional messaging middleware capabilities of your ESB if you really need them, and only leverage the Service runtime your ESB provides when convenient, but configure your ESB as an intermediary to get full value out of it as part of your SOA infrastructure.
Not only does using an ESB as an intermediary enable you to architect the Business Service abstraction, it also resolves the "middleware for your middleware" problem, because intermediaries can intermediate between disparate integration technologies just as well as they can intermediate between Service providers and consumers. If you feel you need to use your ESB's message queuing technology, for example, just because it's there, however, then you won't get this benefit.
The ZapThink Take
The bottom line is to always remember that the business drives the architecture, and the architecture drives the technology. Don't let the technology drive the architecture! SOA is particularly adept at abstracting existing technology, which can include recently purchased products in addition to your legacy environment. But knowing which of your existing capabilities to leverage -- and which to forego -- can make or break your SOA initiative.
Learn more at one of our upcoming Licensed ZapThink Architect Bootcamps or SOA & Cloud Governance courses.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week