Table Of ContentESB-oriented architecture: The wrong approach to adopting SOA http://www.ibm.com/developerworks/webservices/library/ws-soa-esbar...
ESB-oriented architecture: The wrong approach to
adopting SOA
Level: Introductory
Bobby Woolf ([email protected]), WebSphere SOA and J2EE Consultant, IBM
17 Aug 2007
This article examines projects organized around building an enterprise service bus (ESB). It
describes why a project with no SOA goals is a bad idea, and it explains what to do instead to
properly adopt SOA.
Introduction
An increasingly common request from clients is to complete a project that does not use service-oriented
architecture (SOA) as a whole, but instead implements only an enterprise service bus (ESB) architecture. Such an
ESB-oriented architecture is easy to envision, but its success is difficult to measure. What clients requesting such
projects do not understand is this: An ESB-oriented architecture does not produce business value. A project based
on ESB-oriented architecture needs to be made into one based on SOA-oriented architecture to help ensure that it
successfully delivers business value.
Using only an ESB architecture
SOA is based on business requirements. It aligns IT and business so that IT systems work the way the business
does, helping to ensure that IT produces business value. See the IBM whitepaper IBM SOA Foundation: An
architectural introduction and overview (see Resources) for more details.
The primary goal of SOA is to align the business world with the IT world in a way that makes both more
effective.
IT departments that use IBM products and services to build IT systems might have limited understanding of their
businesses’ requirements. For an engineer accustomed to precisely planning how a system will work, the way the
business works can seem unplanned and random. Explanations appear inconsistent and unworkable, and the needs
of business users sound unrealistic and ever-changing. Business requirements become an urban myth, rumored to
exist within the organization, but somehow melting away under the light of scrutiny.
From this perspective, aligning IT and business sounds impractical. It seems the business does not know what it
wants. Its processes (such as they are) defy automation. Efforts to automate processes become frustrating and
pointless.
What engineers understand is technology. Technology does not require fanciful wish lists of requirements; it just
requires code. Code does not complain about being difficult to use, and the compiler does not change its mind
day-to-day about what it really wants. Code either runs or it doesn’t. And if it runs today, it will run tomorrow.
Technology is easier for engineers to grasp, and it is more satisfying. It also happens to be the main thing most
enterprise software companies sell. ESBs are technology, and they connect other technologies.
By contrast, SOA is complex, while ESBs are easy to understand. ESBs do not need any of those annoying
business requirements; only technology requirements. ESBs are precise. They are based on standards: data
formats, wire protocols, XML, IP, HTTP, SOAP, JMS, JAX-RPC, JAX-WS, and so on. SOA could get stuck in
analysis paralysis forever, but an effort to build an ESB could actually get some real work done.
This is often referred to as a connect everything to everything project. The client has many parts—applications,
computer systems, data centers, departments, subsidiaries, outposts, partners, and customers—and the parts do not
1 de 5 3/9/2007 21:24
ESB-oriented architecture: The wrong approach to adopting SOA http://www.ibm.com/developerworks/webservices/library/ws-soa-esbar...
talk to each other. The left part has no knowledge of what the right part is doing. One part has data that another
part needs, and these two parts need to work together. If only all the parts were connected together, they could all
work together. And unlike the futility of trying to understand what the business’ requirements are, connecting
everything to everything is a problem that can be solved, because the solution is technology. If the IT department
is a hammer, then an ESB is the nail of SOA.
The mindset is often: “We don’t know what else we need, so for now we will just build an ESB.” But is this really
any different than the approach of “You start coding, I’ll go find out what they want”?
Introducing an ESB field of dreams
Readers often summarize this desire to connect everything to everything with a single phrase: enterprise service
bus. So what do they mean when they say they want an ESB? What do they mean by ESB? Do they necessarily
call it an ESB?
Often clients like to rename that first word in ESB. Instead of enterprise, they describe another organizational
unit, such as corporate, department, or government. Sometimes they describe what it will be used for, such as
procurement or payroll. Or they describe what it will transmit, such as product or order. Even if what clients want
is a corporate product procurement service bus, do not be fooled by the words preceding service bus. Those
clients want an ESB. They sometimes even describe it as “An ESB but ….”
The client’s focus is really on the last part: the bus. In a technical topology that includes a bus, everything
connects to the bus, and therefore to everything else using the bus. The bus is the main avenue of communication
between the parts. Communication between applications, and even between computers on a network, is usually
accomplished using messaging: a series of discrete packets of information. One resource that gives a great
overview of this is the book, Enterprise Integration Patterns , which calls such connectivity a message bus.
Clients often do not think too much about the service part of ESB. An xSB, enterprise or otherwise, is for invoking
services; otherwise, it is simply a message bus. Service invocation means one application telling another
application what to do, and the other application doing it and usually sending back a response to report the result.
So, if what the client wants to build is an xSB, what are the services? “The services can be whatever it turns out
they need to be,” the IT staff might say. This is the most definite indication yet that the project is purely a
technology one. Implying that the services are irrelevant says that the applications using the bus are irrelevant,
how the applications use the bus is irrelevant, and the application integration requirements (much less business
requirements) are irrelevant. The xSB will work for anything. An ESB being architected for an SOA can initially
ignore many of these service requirements, because they will become apparent as the SOA is fleshed out. But an
ESB without an SOA has no services, and therefore it is just a bus.
A project to build just a bus can be considered an IT field of dreams project. Like Kevin Costner’s character in
that baseball movie, the IT department is taking the attitude that "if you build it, they will come." If you build the
bus, people will build SOA applications around the bus. The problem with the field of dreams approach is that,
unlike in Hollywood, in the business world there is no guarantee they will come. If and when people do build SOA
applications, they might not like what you built, so you might have to rebuild a lot of it anyway before they can
use it. Even if they do eventually use it and love it, that is a lot of delayed gratification, which the IT department
might find difficult to endure while waiting for the big payoff at the end of the movie.
Understanding ESB-oriented architecture's limitations
What is wrong with an ESB field of dreams? Remember the part in the middle of the movie where Annie wants to
divorce Ray? (If not, it takes up the whole second act, where everyone thinks Ray is a fool.) Your project will go
through a period like that too, and the project sponsor probably does not want his employer to divorce him!
The problem is this: An ESB by itself produces no business value. An ESB is a means to an end, not the end itself.
2 de 5 3/9/2007 21:24
ESB-oriented architecture: The wrong approach to adopting SOA http://www.ibm.com/developerworks/webservices/library/ws-soa-esbar...
An ESB is like the electrical wiring or plumbing of an SOA. Plumbing does not produce value; sinks with water
coming out of their faucets do. Wiring does not produce value; lights, especially lights connected to switches, are
valuable. A road is not valuable except that it enables you to get from one point to another. An ESB without an
SOA is like a road from someplace nobody is located going to other places nobody wants to be. People might
eventually want to go to those places, but in the meantime, the road is all cost and no benefit.
ESB-oriented architecture is inherently flawed in that it builds connectivity no one might ever want to use. The
business does not derive additional value until systems connect to each other and are working together. Until then,
the ESB is just cost with no benefit. It might make the IT department feel good because they have built something,
but it will not make the business feel any better, because the business is not accomplishing anything it couldn’t
have already accomplished without the ESB. The ESB becomes the equivalent of a human appendix for the IT
department, a vestigial organ within the topology of deployed applications.
Rather than the IT field of dream’s slogan of “if you build it, they will come,” a more appropriate slogan comes
from Extreme Programming (XP): “You aren’t gonna need it.” This slogan is shorthand for a very practical
principle:
Always implement things when you actually need them, never when you just foresee that you need them.
This principle—don’t build it until you need it—is the opposite of the IT field of dreams. Rather than building it
because you hope that someone will want it, do not build it until you know someone wants it. Then you can make
sure to build what they want, not what you think they might eventually want. And you will not incur the costs of
building it until you are also ready to reap the benefits of having built it. This principle is just a good business
philosophy, and it applies to the IT department as much as any other parts of the business.
Using SOA-oriented architecture
To review, some good principles for any software development are:
Do not build it until you need it.
Build what creates business value.
Align IT and the business.
Instead of following an ESB-oriented architecture, follow an SOA-oriented architecture, and build the ESB as part
of the SOA. In other words, do SOA—just as described in IBM SOA Foundation for creating and integrating
applications that embody the SOA foundation architecture.
With this approach, you develop an ESB as part of developing the SOA. You will discover services based on
business needs. Each service requires not only providers and consumers, but also a channel in the ESB to connect
the two. That channel implements the service interface just like a provider (but acting as a proxy), including
message formats for service requests and responses that enable remote invocation (such as interprocess
communication) of the service. Differences in the consumers’ and providers’ service interfaces, message formats,
scope, and qualities of service can be bridged and facilitated by mediations. All of this is the core of ESB design,
and none of this can be done without knowing the services the ESB invokes. And knowing those services requires
knowing the services in the SOA that will use the ESB.
In this light, connecting the applications is the easy part. Connecting their business functionality is the much
greater challenge. That cannot be achieved by building only an ESB.
Conclusion
Clients often want to build only an ESB because that involves a technology challenge without the need for messy
business requirements. Building just an ESB becomes an IT field of dreams, where IT builds an ESB and then
3 de 5 3/9/2007 21:24
ESB-oriented architecture: The wrong approach to adopting SOA http://www.ibm.com/developerworks/webservices/library/ws-soa-esbar...
hopes some SOA will come along and use it. Such an ESB-oriented architecture loses the benefits of SOA. It does
not create business value. In fact, it incurs cost without reaping immediate benefit. And it does not align IT and
the business. The better alternative to ESB-oriented architecture is SOA-oriented architecture. Do not build an
ESB by itself; build it as part of an SOA, preferably one that fits the SOA Foundation architecture that IBM
recommends.
Share this...
Resources Digg this story
Learn Post to del.icio.us
Refer to “IBM SOA Foundation: An architectural introduction and overview” Slashdot it!
(developerWorks, Dec 2005): A whitepaper about the IBM SOA foundation
architecture.
Check out “A quick intro to WebSphere® Business Process Management” (developerWorks, Feb 2006):
An overview of the IBM SOA product strategy, from enterprise architect to developer.
Read more in "Should IT departments really build systems the way Kevin Costner builds baseball fields?"
for more information about the IT field of dreams concept.
Learn more about the Enterprise Service Bus on the IBM ESB root page.
Read more about “Exploring the Enterprise Service Bus”: Greg Flurry refines the IBM SOA message on
what an ESB is.
Refer to “Simplify integration architectures with an Enterprise Service Bus” and “Why do developers need
an Enterprise Service Bus?” where James Snell and Bobby Woolf explain the practical benefits of using an
ESB.
Consult Enterprise Integration Patterns for the best way to learn about how to integrate applications.
Find more details at “You Aren't Gonna Need It” from the Extreme Programming Roadmap wiki.
The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and
introductory, intermediate, and advanced tutorials on how to develop Web services applications.
The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
Stay current with developerWorks technical events and webcasts. Check out the following SOA and Web
services tech briefings in particular:
Get started on SOA with WebSphere's proven, flexible entry points
Building SOA solutions and managing the service lifecycle
SCA/SDO: To drive the next generation of SOA
SOA reuse and connectivity
Browse for books on these and other technical topics at the Safari bookstore.
Get products and technologies
Innovate your next development project with IBM trial software, available for download or on DVD.
Discuss
Participate in the discussion forum.
Get involved in the developerWorks community by participating in developerWorks blogs.
4 de 5 3/9/2007 21:24
ESB-oriented architecture: The wrong approach to adopting SOA http://www.ibm.com/developerworks/webservices/library/ws-soa-esbar...
About the author
Bobby Woolf is a WebSphere J2EE Consultant for IBM Software Services for WebSphere (ISSW).
Bobby assists clients in developing applications for WebSphere Application Server using WebSphere
Studio Application Developer. He is a co-author of Enterprise Integration Patterns and The Design
Patterns Smalltalk Companion. He also has a blog on the IBM developerWorks Web site called
WebSphere SOA and J2EE in Practice. Bobby is a frequent conference speaker.
IBM and WebSphere are trademarks of IBM Corporation in the United States, other countries, or both. Other
company, product, or service names may be trademarks or service marks of others. Other company, product, or
service names may be trademarks or service marks of others.
5 de 5 3/9/2007 21:24
