With the growing acceptance of service-oriented architecture (SOA), CIOs are more than ever likely to be tasked with achieving a better return on the existing investments that already comprise IT infrastructures. To accomplish this task successfully, existing applications and systems need to be able to participate as equal citizens in the new architecture. This is a very different way of thinking from the way CIOs and developers perceived the systems built in the not so very distant past.
Not that long ago, it was simply expected that the programs we wrote would be replaced. Back then we all wrote our share of non-Y2K compliant code and never imagined it would ever be a problem. Surely all these "temporary" or short term development efforts would soon be replaced by better and newer code. Technology was changing so rapidly then - database management systems, transaction processing monitors, application servers and the like were all coming out and it seemed like what was code one day would be in a product the next. And each new general-purpose language being proposed – whether it was COBOL, C, C++, VB or Java – might finally be the one language that everyone would use, and all the old stuff would get recoded into the winning language and finally fixed.
As it ended up, things didn't turn out that way. Certainly, some systems were replaced, but the more successful ones never were. Once a given area of business was successfully automated, whatever the solution, it was on to the next. More functions might be needed, or improvements made to performance, scalability, security, or GUIs or Web browsers added, but the back-end core functions, however, once well deployed, tended to stay in place.
With the advent and mainstream acceptance of Web services, the software industry has finally reached a level of maturity whereby existing investments are no longer questioned but rather accepted and embraced. Companies don't expect IT environmen
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
ts to be replaced; they expect, and even demand, that they work better together. The new mantra, from the boardroom to the developer, is "achieve a better return on existing IT investments." Scrapping existing applications and systems and filling the void with new code cannot accomplish this.
Getting existing systems to work together to accomplish new and better things is in fact the essential role of the enterprise service bus (ESB). The very nature of ESB technology helps preserve value in existing IT assets by Web service enabling these assets and allowing the resulting services to more easily communicate and share data, independent of the technology choices in the underlying systems. The ESB meets infrastructure requirements for business and government seeking to assemble meaningful architectures out of existing (and new) components by creating, deploying, managing and connecting services across disparate IT environments.
It is therefore strange to see some vendors of integration software still advocating a rip and replace approach to new IT infrastructure. Little or no new value accrues to IT departments that merely take out an existing infrastructure and replace it with another, since the value to the business is not increased. IT departments are under more pressure than ever to ensure that every investment adds to the business's bottom line.
In fact, it can be argued that many of today's companies have enough IT infrastructure – what is really needed is a good way to assemble what companies already have into new applications. An SOA provides a perfect blueprint or style of design for reusing and more widely sharing existing assets. The industry needs a co-existence solution, not another rip and replace approach. Rip and replace solutions are just too expensive, both in software and (especially) labor costs, and also implicitly assign less value to existing investments than they really have. The last thing IT departments need is another big investment in a bloated software system from the last century that doesn't work well with all their existing infrastructure, networking and language deployments.
ESBs are really all about adding just the right amount of incremental value (and therefore incremental code) to existing systems so that they work well together. ESBs are not about ripping out existing middleware, networking, messaging, languages or applications in order to install new products. To be effective, ESBs must play well with the software that is already in place, be as nonintrusive as possible and expose as much value (i.e. existing data and functionality) as possible. That's the only realistic way an SOA is going to meet today's demanding requirements on IT departments. As enabling infrastructure for an SOA based on Web services, the ESB needs to provide incremental value to existing investments – it cannot require an additional, equivalent investment to what's already in place.
ESBs help create new applications out of existing applications. They are not systems in and of themselves. The IT environment has passed the stage at which a large investment makes sense. Now a sensible, realistic product is need to adopt in incremental stages and enable these core functioning IT assets to be appropriately and profitably reused.
About the Author:
Eric Newcomer is Chief Technology Officer at IONA, where he leads the company's participation in industry standardization activities. Eric was a founding member of the XML Protocols Working Group at W3C, which produced SOAP 1.2. He is a former editor of the Web Services Architecture specification and is also co-author and editor of the Web Services Composite Application Framework (WS-CAF) set of specifications and co-chair of the WS-CAF technical committee at OASIS.
