This site will be of interest to you if you are concerned with the modernization and integration of large modern software systems, where some, if not all, of the components are existing legacy systems. Our approach begins with an attempt to clarify and unify the attributes of certain popular software acronyms; SOA, ADM, MDSD, MDA, and MDT. These definitions are followed by a brief look at two currently available solutions for incorporating legacy modernization with a modular architecture.

Service Oriented Architecture (SOA) ... is just designing your architecture to best work in a Web service environment, based on the consumer-provider model. The key to a true SOA approach is separating the services layer of the architecture completely from the other layers of the architecture (Jim Minatel, 2005). More generally SOA is concerned with interoperability and connectivity of services and components. Number one in the list of SOA requirements is… First and foremost, leverage existing assets. Existing systems can rarely be thrown away, and often contain within them great value to the enterprise. Strategically, the objective is to build a new architecture that will yield all the value hoped for, but tactically, the existing systems must be integrated such that, over time, they can be componentized or replaced in manageable, incremental projects (Channabasavaiah, Holley, & Tuggle, 2003)

Architecture-Driven Modernization (ADM) is a road map currently under development by the Object Management Group's (OMG) ADM Task Force. Current work involves building a Knowledge Discovery Meta-model (KDM) to facilitate the exchange of existing systems meta-data for various modernization tools. Subsequent standards will address analysis, visualization, re-factoring and transformation related standards(OMG, 2004).

Model Driven Software Development (MDSD) can be described as…a new software development paradigm for distributed project teams involving 20+ people, with roots in software product line engineering, which is the discipline of designing and building families of applications for a specific purpose or market segment. MDSD aims at developing software from domain-specific models. Domain analysis, meta modeling, model-driven generation, template languages, domain-driven framework design, and the principles for agile software development form the backbone of this approach (Jorn Bettin, 2004). MDAD is distinguished form the field by its emphasis on 'domains-specific models' and 'domain analysis' which is the task or service each component will provide within the resulting software portfolio. Like SOA, one goal is to ensure modularity and agility. MDSD is primarily concerned with new software development and does not directly relate to modernizing existing systems, except…to create adapters to or wrappers for legacy systems (Markus Volter, 2004).

Model Driven Architecture (MDA) was adopted by the Object Management Group (OMG) in 2001. The three primary goals of MDA are portability, interoperability and reusability through architectural separation of concerns. And, It is model driven because it provides a means for using models to direct the course of understanding, design, construction, deployment, operation, maintenance and modification (Miller & Mukerji, 2003). This definition seems to imply that MDA, like MDSD, is primarily concerned with high-level models and new product development. However these same authors expand the scope of MDA by suggesting that an MDA tool…might transform a [Platform Independent Model] PIM directly to deployable code without producing a [Platform Specific Model] PSM. Such a tool might also produce a PSM, for use in understanding or debugging that code.

Model Driven Transformation (MDT) definitions vary. Some vendors and authors use the phrase in reference to transformations that restructure or enhance an existing modern system. In this sense, MDT is not referring to legacy transformation in the typical 3GL sense. Others use the phrase when referring to the transformation of models within MDA. For example one paper notes, We have currently developed top-down and bottom-up model-driven transformations between particular PIM and PSM (Koehler, Hauser, Kapoor, Wu, Kumaran, 2003). This suggests the possibility for developing a low-level (fine grained) model of a legacy system, lifting this model into a high-level business model and then modernizing the functionality and/or architecture with SOA, MDA, ADM and/or MDSD.

The University of Alabama Birmingham, Department of Computer & Information Sciences - Composition and Modeling Laboratory is conducting research into Model-Driven Program Transformation (MDPT). This laboratory has defined MDPT to specifically address legacy transformation issues. However their transformations are used to ‘add features’ to the legacy system using MDPT, not to convert the legacy code to modern object oriented language. In their online report, they refer to the, ...several hundred billion lines of legacy code in production use. To apply model-based techniques to such systems, it is beneficial to have an approach that is also transformational (i.e.., one that actually modifies the source code representation) in order to add features to an existing code base (SOFTCOM, 2004) . A case study is offered in the report where features were added to an existing legacy C++ system. We are left to wonder how this relates to a legacy system written in COBOL, Fortran, Ada, VAX-Basic, etc. Perhaps they are reluctant to directly address 3GL's because of the challenges presented. Developing Industrial-scale parsers to support all languages, and integrating them within the modeling tool, is really time-consuming (if not unfeasible). (Zhang & Gray, 2004)

The tools mentioned by Zhang & Gray involve the modeling of application services, typically with a focus on business domain analysis. However, industrial strength parsers are currently in use, creating abstract syntax tree models and facilitating the automated transformation of models. One company utilizes such a process to provide full modernization of 3GL legacy systems, including their conversion to modern object oriented languages and N-tier architectures. More than 26 case studies provide testimony to 7 different legacy source code parsers with more under development (TSRI, 2005).

SOA, ADM, MDSD, MDA, and MDT all advocate a well-integrated modular architecture as...the best platform for carrying existing assets into the future, as well as enabling the rapid and correct development of future applications. But how can we best achieve a well designed and integrated system when one or more of the components are derived from 'existing legacy assets'? We will examine two currently available solutions for legacy modernization, with an eye on how well each solution fits into the advocated integrated modular system.

Re-host and/or Wrap the Existing System
This solution has the advantage of being minimally invasive to the existing legacy code. And wrappers are available, for some 3GL languages, through 3rd party vendors. These vendors contract to facilitate the move from mainframe dependency and allow integration with modern system components. There is some conflict, however, with the goals of MDA and SOA. Creating a heterogeneous system of old and new hinders agility by trading mainframe dependency for vendor dependency. Interoperability is also limited by available vendor middleware.

The idea of a Service Bus to facilitate modular interface is introduced in Part-2 of the SOA article by Channabasavaiah, Holley, & Tuggle. The article includes a diagram where backend (legacy) processes are unable to attach directly to the Service Bus. This indeed could be the case for a wrapped or re-hosted legacy application. Figure-1 borrows from their diagram to illustrate resulting interactions and modular relationships resulting from a wrapping solution.

Convert Existing Legacy Code to a Modern Language
Converting a legacy application into a modern object oriented language is currently accomplished using automated transformation tools or with a manual rewrite. Manual re-writes, generally performed off-shore, can be the best alternative for systems involving only a few thousand lines of code with no security concerns. However, costs, project timelines and the risk of failure apparently grow with N^2 behavior for manual rewrites, and are not be the best solution for larger systems.

Conversely, as the size of the application increases, automated conversions decrease cost, risk, and timeline on a line-of-code basis. The amount of decrease depends upon the level of automation. One company boasts levels of automation exceeding 99.9% (Newcomb, Doblar, & Smith, 2004).

How does fully automated code transformation work? One example of automated modernization involves lifting the legacy code into an intermediate object model (IOM). The objects within this intermediate model represent legacy processes and control flow, setting the stage for the code conversion into a modern object-oriented language, (e.g. C++, Java, C#, or Visual Basic).

Parsers generate an abstract syntax tree (AST) from the legacy source, (e.g. COBOL, Fortran, Ada, C, Jovial, Vax-Basic, and Assembler ). The legacy AST is transformed via Enhanced Backus-Naur Form (EBNF) rules into a generic platform independent AST. The AST model and the associated EBNF rules allowing model-to-model transformations comprise the IOM.

Figure-2 illustrates a fully automated legacy modernization project integrated with MDA considerations for modularity and SOA considerations for interoperability and web services. In a two stage process, first the IOM automatically generates the target code for testing before any changes are made. This is done to insure full functional equivalency to the original legacy application. Following testing and validation, improvements to the target code (e.g. re-factoring for an N-tier architecture) are made within the IOM and target code is re-generated.

Figure-2

Conclusion
There are proponents for leaving legacy code running on a legacy mainframe. There are proponents for re-hosting onto a modern platform with little change to the legacy code. There are proponents for code conversion via a manual re-write, (though not many). And finally there are proponents of using automated tools to perform code conversion and architectural enhancements. If you are considering modernizing a business system, then you probably are considering modernizing the legacy code, architecture, hardware and database. You may be surprised at the reasonable price, low risk, and speed with which such a modernization project can be done with today's automated solutions.