Four questions to ask before putting SOA 'lipstick' on that legacy 'pig'

Four questions to ask before putting SOA 'lipstick' on that legacy 'pig'

Summary: Four questions to ponder before attempting to service-enable a legacy applications


SOA is a great strategy for surfacing legacy functionality into newer environments, but it has its limits. There are, quite frankly, many legacy applications that are beyond help.

Mike Oara, CTO and co-founder of Relativity Technologies, had some interesting thoughts on my recent post on the efficacy of service-enabling legacy systems. As Relativity's business is putting Web services functionality in front of legacy stacks, Mike's thoughts carry particular weight.

Mike notes that every developer has an innate desire to create something completely original.  However, it takes some teeth-gritting to actually reuse code:

"There is a maxim in the software development world: Good programmers write good code, great programmers reuse other people's code. Any good programmer enjoys creating software according to his own style and his own concepts about good or bad code. Writing something new is always fun. Reusing existing software is painful as the developer must enter somebody else's mind, understand what the other one meant, and live with the existing limitations."

However, he observes, when it comes to service-enabling large legacy applications, reuse becomes a very important part of the process. "The desire to create something new often collides with the reality of large-scale applications," he points out. "They incorporate a huge effort, measured in hundreds of person-months and tens of millions of dollars. The decision to recreate all these software assets cannot be taken lightly and cannot depend on a simple developer’s preferences."

This is particularly true in the case of exposing Web services from a legacy application, Mike adds:

"One may deal with a huge and complex application interacting with very large databases. Porting this to a new environment or rewriting large amounts of code may not be a viable option. In most cases reuse is a better alternative."

However, in some cases, Mike agrees with Jeremy Miller that some legacy code may be so bad that reuse is impossible. In a recent post, I quoted Jeremy's observations that attempting to service-enable a moribund application will just lead to a service-enabled moribund application, and nothing more.

Mike posted the following questions that need to be asked in determining if it's worth putting lipstick on that pig:

  • Is the legacy application well layered? A well-layered application, in which the user interface, business logic and data access are clearly separated is well suited for creation of web services. On the other case, if user interface logic and data access are mixed in the same programs, creation of Web services may be impossible without an initial re-architecting effort.
  • Does the legacy application have the concept of reusable services? If the original developer designated certain programs to be reusable services, these may be easily turned into web services.
  • Are program interfaces designed to pass minimum required data? If communication areas are unnecessarily large, this will result in low performance and ugly messages for service operations.
  • Are service programs robust? If they depend on user interfaces to validate the data, they may fail when invoked from another environment. If they validate the data themselves, they are more suitable to be encapsulated.

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Hammer salesman sees nails everywhere

    [b]As Reactivity's business is putting Web services functionality in front of legacy stacks, Mike's thoughts carry particular weight.[/b]

    I see nails everywhere. He also starts off with a fallacy:

    [b]Mike notes that every developer has an innate desire to create something completely original.[/b]

    Not exactly accurate. Every developer has the innate desire to get paid. If they can get paid just as much reusing someone else's code, then the copy/paste functions on their workstation will melt down from all the use.

    By stating that as an assumption it subtly announces to any management types reading this column that your internal programmers really just want to sling new code for maximum billing, can't be trusted to give an honest evaluation of the cost/benefit of code reuse in a particular instance and if they want the real inside scoop on code reuse call this guy. It's more about how consulting services are sold than how SOA is implemented.

    SOA is just one tool in the box. Sometimes it's the right one, sometimes not. There are more than four things that go into that determination. Anyone can hit a home run layering SOA in front of a well-built application. There are also a dozen different way to solve the same set of problems.

    Beware of buying your solutions from a hammer salesman.
  • One more question

    In my opinion, there is another important question. Does the legacy 'pig' have perform a valuable business function and what is the cost of attempting to reproduce the business function with new technology?

    Kent Landholm
    Planet Group