Incorporating Existing Systems into SOA

You have dedicated significant resources to creating a services oriented architecture (SOA), investing heavily in hardware, software and personnel. You have trained people, hired experts, engaged vendors and deployed small scale services under an SOA framework. You have moved beyond the crawling stage and are ready to advance to the next stage of SOA deployment. But there is an elephant in the room no one wants to mention – your existing systems.

Executives I have spoken to sense that something may be missing from their SOA strategy. One question invariably comes up. What about my portfolio of existing systems? These systems are comprised of millions of lines of software, have been battle-tested over the decades and manage vast amounts of business data on a daily basis.

“No problem” an architect replies. We will simply “wrap” existing systems using middleware technology where each middleware interface becomes a service. But your gut tells you that this may not be the answer. And you are correct.

Why Existing Systems Must be Incorporated into SOA Strategy

Existing software assets are essential to your business. Application systems contain a reservoir of business rules vital to operational continuity, yet remain undocumented outside the source code. These software assets and accompanying business data are difficult to decipher and almost impossible to replicate using “green-field” approaches. While these systems represent a reservoir of business knowledge that your SOA strategy can hardly ignore, they are locked into aging, often convoluted and highly segregated architectures.

Aging application architectures are typically segregated into functional silos that contain redundant, fragmented and inconsistently defined functionality. A recent IBM white paper stated that “as much as 60 to 80 percent of the functionality in silos may be redundant or duplicated in other parts of the business. ” Despite these flaws, these systems embody and enable automated processes across the enterprise.

Another SOA hurdle involves critical business data that can only be accessed by existing systems. Accessing or manipulating indexed files, hierarchical or network databases, and even large relational databases is only possible by executing systems custom built to understand that data. Not surprisingly, data architectures mirror the redundancies, inconsistencies and fragmentation found in application architectures. Yet this data must continue to play a key role in your business and emerging SOA.

SOA Must Go Beyond Simplistic Wrapping Options

SOA teams have not ignored existing systems as evidenced by the predominant tactic of wrapping existing systems using middleware technologies. Leveraging existing systems functionality within an SOA, however, must extend well beyond simplistic wrapping options. Treating existing systems as a “black box” does not address the previously discussed architectural limitations of these systems.

The previously cited paper from the IBM Systems Journal examined the results of wrapping systems at major financial institutions. It stated that “recent advances in integration middleware technology have provided some relief by making it possible for financial institutions to move customer information across channels. But in many cases the technology has been laid over flawed legacy architecture and has merely created more duplication.”

In the long-term, merely wrapping existing systems to achieve SOA objectives will serve to further convolute existing application architectures while doing nothing to address underlying weaknesses within these systems. This should not come as a surprise. Redundancy and inconsistency are the antithesis of what most architects consider to be a valid “service”. In other words, black box wrapping tactics do not lead to a successful SOA deployment.

Using Systems Modernization to Integrate Existing Systems into SOA

If wrapping existing systems is not an option and recreating entrenched functionality using a green-field approach is not option, then what options remain? Systems modernization is an alternative worth exploring. Modernization tools and disciplines allow organizations to analyze, refactor and transform existing systems while SOA provides a formal architectural target for modernization initiatives.

Organizations can use modernization to capture and incorporate existing systems functionality into SOA. Analysts can examine systems from a variety of perspectives and then rationalize, consolidate, componentize, otherwise refactor and ultimately transform existing application and data architectures as dictated by your SOA strategy.

While an SOA-driven modernization scenario depends on a robust target SOA and certain other variables, organizations should minimally be aware of modernization options. Consider the following modernization activities that can be used to incorporate existing systems into SOA.

1. Examine cross-functional application and data architectures to determine how they can be leveraged within the SOA. Functional mapping of existing systems, with a focus on functional redundancies, provides a map for subsequent modernization activities.
2. Determine where functions can be reused, how to address related redundancies and inconsistencies of those functions, and outline a phased plan to deliver rapid ROI to end-users.
3. Determine end-state data architecture, with a particular focus on rationalizing and consolidating redundancies and inconsistencies within relevant data structures and subsequent normalization activities.
4. Rationalize data definitions across systems of interest as a prerequisite to creating modular services and subsequent data redesign efforts.
5. Selectively modularize targeted systems and programs to:
   1. Isolate and consolidate common I/O logic, user access logic and business logic
   2. Create reusable services that can continue to function in the existing systems environment and be defined as a service under SOA
6. Create middleware-based interfaces to modularized routines to incorporate existing application functionality into SOA. Note that this option couples the use of middleware with systems modularization.
7. Proceed, if applicable, with data architecture redesign and phased redeployment and required systems refactoring.
8. Migrate modularized functions into either a new target language or model-driven architecture.
9. Continue with phased migration selectively migrating, integrating and incorporating existing systems functionality into the SOA.

It is clear that for SOA to be truly successful, the evolving role of existing systems must be incorporated into an SOA strategy, or that SOA strategy will suffer from an inability to effectively access and leverage critical business functionality and data.

1- “Aligning Technology and Business: Applying Patterns for Legacy Transformation”, Howard Hess, IBM Systems Journal, Volume 44 Number 1, 2005.