Legacy is just beautiful

Through the TechWatch news service comes this reference to a Computerworld article on the “beauty” of legacy systems.
Beauty as in the eye of the beholder, of course. Or as one of the founders of this company liked to say, “There are no ugly babies.”
It’s interesting in this article that the definition of legacy is pretty much something that works. In fact some people would say that “legacy” is a name any code earns immediately after it goes into production.
A few years ago we were discussing how to handle “legacy” systems in a standards meeting. The IBM representative said they preferred the word “heritage” (and even got a few people to go along with the idea that this is more polite somehow).
I thought why not take the next step? Call them “heirloom” systems…
But the serious point of the article highlights what is probably the most significant impact of Web services on the IT industry: the ability to recognize the value in existing systems and easily enable it for reuse. We are not talking about replacing COBOL with Java anymore; we are talking about adding a layer of XML to what’s already there and getting more out of existing investments, which is a very good thing.
We are not talking any more about replacing stuff that works just because a new technology came along. Legacy is definitely beautiful when it’s dressed up in XML and exposed using Web services.


3 responses to “Legacy is just beautiful

  1. Eric, the problem in some cases with exposing legacy apps as a service is that these apps were not designed for this purpose, and in some scenarios there is the risk of performance and availability (or more general QoS) problems.
    I agree that reuse of existing systems is one of the beauties of SOA / Web Services, but it is a beauty which should be handeled with care, I think the French would call it “femme fatale” (fatal beauty) ;-).

  2. Loek,
    I should thank you for that comment 😉
    You are exactly right that how it’s done is very important. That’s why we focus so hard on legacy enablement, including mainframe. We know that these systems were not necessarily designed to be services (in fact most likely they were not) so we support “contract first” development with code generation in Java, C++, COBOL, and PL/I.
    That means you can design the service first, and generate code that helps you link it into the legacy application. Or you can run the code in a standalone gateway, on the requester side, the provider side, or both (depending on what you’re doing).
    And finally, we know from years of experience with mission critical, large scale SOA (Credit Suisse for example running 1000 services from mainframe to desktop with an estimated load of 1B transactions/year) that customers need to preserve the qualities of service in these trusted systems. So we developed plug-ins for legacy formats and protocols, and for other aspects such as high availability, logging, transactions, and security that you add by configuring your WSDL.
    You are also right that design is very important. I did not say anything about how it should be done. Most of the discussion on this topic of the best approach revolves around the importance of “contract first.” That is, deciding first how you want to expose the service to the requester, and then how to map the service to the execution environment.
    I agree that simply generating a service description from an existing application is not necessarily a good thing, and often it is the wrong solution.
    But I do not think this detracts from the “beauty” of legacy reuse. It just means you have to be careful how you do it, and use the right tools.

  3. Eric, “contract first” is definately the way to go, whether you develop new services or whether you expose existing systems. The good thing is that more and more people are aware of this.