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

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.