When not to salvage the legacy application

March 12, 2008

When not to salvage the legacy application

One of the hardest things for organizations to do is to retire old applications. Unlike hardware that tends to be replaced on a regular cycle, old software sticks around way too long. It definitely over stays its welcome. I remember when I worked at John Hancock decades ago and watching as departments struggled to replace aging systems. While they were ready and willing to make the change, they often didn’t know precisely how these old systems worked. The developers never documented what they wrote and those people had retired years earlier.

Now you would think that the problem had gone away. In reality, the problem got worse with the advent of client/server computing where there was less structure applied to the development process. I came across a very old article I wrote back in 1996 that talked about a lot of those issues (please ignore the picture). Just when you thought it couldn’t get any worse, web based development came along. Instead of having a few hundred developers, the web brought the advent of thousands of developers all provide changes and updates to applications. We are now at a cross roads that is quite unique.

While we still have many aging applications that cannot be easily updated, we also have the need to move to Web 2.0 to create Rich Internet applications (RIA). Web 2.0 offers a way to dramatically transform the user experience. Organizations are looking to this approach to development to make access to knowledge and information much more immediate and intuitive than ever before. But the transition isn’t easy.

I got thinking a lot about the transition from client/server applications and old web based applications when I met with Nexaweb a few weeks ago. The company has been around since 2000 and specializes in the Web 2.0 space. While there has been a lot of hype around Web 2.0 it actually is a very pragmatic technology infrastructure. While I think that a lot of customers assume that you can just approach Web 2.0 as though it were a simple web application. The reality is quite different. In fact, good Web 2.0 applications have to be well architected. What I liked about what Nexaweb is doing is their approach to application modernization with a Web 2.0 spin. In essence, Nexaweb is focused on modernization of aging client/server applications by providing tooling that documents the existing code. It is designed to identify bad code and provides a tool to generate a model driven architecture. Like any good consulting organization, Nexaweb has leveraged best practices used to help its consulting clients move old applications to Web 2.0. Nexaweb is selling a set of productivity tools that can generate a model driven architecture. It is intended to generate code as part of this process. The company claims that it can reduce the cost of transforming old code by as much as 70 percent.

The new product called Nexaweb’s Enterprise Web Suite including a UML modeling tool, a reporting tool that identifies repetitive processes, and code that is no longer used. Clearly, Nexaweb isn’t the only company taking advantage of modeling tools and an architectural approach. But the fact that the company is focused on helping companies transform their aging client/server applications into modular, service oriented approach is a step forward. It is one of the set of companies focused on not just updating applications by transforming into Web 2.0. What stands out is the fact that Nexaweb seems to be combining application transformation into business services (can you say Service Oriented Architectures). However, I must add that IBM has been on this track for quite a few years. Through its industry models, IBM has been helping companies transform its aging areapplications into industry specific business services. In addition, Microsoft’s Silverlight and Adobe’s Air are adding a new level of sophistication to the momentum. WaveMaker, that I discussed in an earlier entry is making a contribution as well.

The trend is clear and it is good for customers. We are finally seeing software companies providing a path to moving code into the new world that is based on reusable, modular services that are architected. The next stage in the movement towards a service oriented architecture is applying this approach to the new generation of Web 2.0. Let me add a disclaimer — this isn’t magic. There is hard work here. None of these approaches or tools are automatic. They give customers a head start but there is hard work to be done. The alternative is to hold your breath and hope that things don’t break too quickly. There are so many promises of easy solutions to hard problems. There are solutions and tools that take the drudgery out of leaving legacy applications behind. But there is worthwhile hard work that really has to be done.

About Judith Hurwitz

Judith Hurwitz is an author, speaker and business technology consultant with decades of experience.

  1. […] that are important to investigate as early in the project planning and scoping process as possible. Legacy applications may span a wide variety of user interaction paradigms that do not map neatly to the […]

  2. Lots of opinions exist on the correct way to migrate but I think the industry is still missing the clearsight.
    Incidently, I have also opined on the subject

    Any comments are welcome.


  3. Great position on this – I have faced many a potential customer who want me to retool/reuse/revamp a legacy web application.

  4. […] Hurwitz’s post on When not to salvage the legacy application should be mandatory reading for anyone getting ready to retool/revamp/reuse their current software […]

  5. Mary Loomis used to have a “meteoric theory of data”: data never moves, it just lands and sticks! Much the same could be said of applications. We have run across many many companies who moan about all the “legacy” apps they have deployed. But when you ask them what they are going to do about it, they just shrug. I think wrap and extend is a better model for legacy migration than rip and replace. I also think skills migration for development talent is more important for the enterprise than app migration.

Leave a Reply

Your email address will not be published.