The End of Rip ‘n’ Replace

When I talk about services and SOA in visits to customers and at conferences, I often hear about the need to achieve a better return on existing IT investments. In order for SOA to be successfully deployed, existing applications and systems need to be able to participate as equal citizens. They cannot consist only of just new code. In fact this looks to be a major consideration with respect to adoption.
Years ago we all expected the programs we were writing to be replaced. I know I wrote my share of non-Y2K compliant code. We never thought the applications we were writing back in the 70s and 80s would last for more than five years, never mind ten, twenty, or thirty. Things were changing so rapidly then – database management systems, transaction processing monitors, word processing systems were all coming out and it seemed like the code we were writing one day would be in a product the next.
As we know things didn’t turn out that way. Sure, some systems were replaced but the 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. The back end core functions, however, once well deployed, tended to stay in place.
With the advent of Web services, it seems that the software industry has finally reached a level of maturity at which existing investments are no longer questioned but rather accepted and embraced. You don’t hear things anymore like “Well, eventually you know you will have to recode everything in Java.” We don’t expect our IT environments to be replaced, we expect them to work better together.
This is in fact the essential role of the Enterprise Service Bus (ESB), to help preserve value in existing IT assets by service enabling them and allowing those services to easily communicate and share data. The ESB meets infrastructure requirements for business and government seeking to assemble meaningful architectures out of existing (and new) components.
In this context it is really strange to see the recent “markugment” (i.e. marketing agument – we’ve got marketecture, why not markument) between Sonic and Tibco, with Sonic offering to replace Tibco. And Tibco’s response seemed to have more or less taken the bait, claiming that they already have an “ESB plus plus” by another name.
But in either case I can’t really see the value to IT of proposing to take out an existing infrastructure and replace it with someting like Sonic’s JMS or Tibco’s Rendezvous, no matter what they add to it so they can call it an ESB. People have enough IT infrastructure – what they need is a good way to assemble what they already have into new applications. The industry needs a co-existence solution, not another rip ‘n’ replace approach.
Rip ‘n’ 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 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 you already have, be as nonintrusive as possible, and expose as much value (i.e. existing data and functionality) as possible. As a former IONA colleague was fond of saying, “there are no ugly babies” when it comes to the IT environment.
ESBs help you 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 we need a sensible, realistic product that you can adopt in incremental stages, pay for as you go, and enable these core functioning IT assets to be appropriately and profitably reused.


3 responses to “The End of Rip ‘n’ Replace

  1. The end of rip’n’replace can only come when all of an enterprise’s software assets are in suitable form to participate in an SOA. Otherwise, it’s just “big hat, no cattle”. But until very recently, most software was written as standalone (or at best client/server) monolithic applications. To break those up into SOA services would be a gigantic undertaking that no one is likely to want to pay for.

  2. Very timely blog, Eric. Let me play the devil’s advocate. The argument I believe is supporting economic realities never mind in the past we jumped and implemented the then vouge technology. Letting analysts and pundits off the hook so easily is not prudent. Two things must be pointed out-we can maintain the “past junk yard” and modernize our apps (ala services) and live with the inefficiencies or take a business look and and plan for a sunset for the legacy system and evolve towards the service paradigm. If the chasm between IT and business is to disappear we have to think as business person. Why settle for the eventual partial benefit when we can plan and evolve to continuous improvement.

  3. Yes, I agree, and perhaps there is more to the story than I wrote. The foundational technologies such as application servers and database management systems are becoming commodities. The plan for IT is not only to move toward services, but also to replace behind the services proprietary platform technologies with lower cost alternatives. However we are not talking about rip ‘n’ replace here in the context of a rewrite to another kind of technology, but rather the substitution of lower cost technology of the same kind. I agree this should also be a goal.