<<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 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"?>> You can read this in its entirety at: http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch/index.html?ca=drs- Thanks to Sanjiva's blog (http://www.bloglines.com/blog/sanjiva?id=237) for pointing this out. Gervas
