Legacy Evolution to SOA – Approach to Enable L2SOA
Legacy systems come in all varieties, be it different languages, technologies, exotic vendors, etc. Therefore, not all transformation or enablement projects are the same. But when we look at these projects, we can identify some recurring high-level steps that are naturally present even when the actual content or activities within them are different.
The TOGAF Architecture Development Method (ADM) provides a process to facilitate and manage architectural development and transformation projects – see The TOGAF ADM. Combined with the TOGAF SOA Guide , it provides the foundational process for L2SOA transformation engagements. This can be done as part of an enterprise architectural engagement, or as a separate architecture cycle which specifically focuses on L2SOA.
Using the ADM phases and the TOGAF SOA Guide, the important aspects to consider from an L2SOA point of view are outlined in this chapter. These aspects can be used together with the more extensive guidance in the TOGAF SOA Guide as a process for L2SOA architecture cycles.
Successful SOA depends in part on the readiness of the enterprise to become service-oriented. Peruse any existing SOA maturity assessment report to arrive at the SOA readiness of the organization and in particular for the legacy application(s) under consideration. One of the results would be an assessment of the “fit-for-SOA” state of the current legacy architecture, with gaps described from a maturity perspective. If there is no existing SOA maturity assessment the advice is to conduct one; for example, by using The Open Group Service Integration Maturity Model (OSIMM) , an Open Group Standard.
It is also important to note in this phase that the architecture governance and support strategy need to be confirmed. This will need to include the importance of legacy governance in transition stages from legacy to SOA.
With regards to the Architecture Repository and Architecture Building Blocks (ABBs), we suggest looking at The Open Group SOA Reference Architecture (SOA RA)  to initially populate the Architecture Repository. Note that the Operational Systems Layer in the SOA RA hosts the legacy systems, and the SOA RA describes “access services” which use service enablers and adapters to enable legacy functionality to be accessed as services.
When establishing the architecture team, make sure to include representatives from the legacy environments for collaboration on the transformation.
The TOGAF SOA Guide suggests establishing a Center of Excellence for SOA. This would be a good suggestion to examine in order to concentrate L2SOA expertise, foster re-use, and potentially eliminate both application and infrastructure redundancy.
A new architecture lifecycle starts with the Architecture Vision which is concerned with establishing the architecture project and obtaining approval to proceed.
One of the major drivers of an L2SOA initiative is cost reduction, so a return-on-investment analysis is important. A business case is a mechanism to support rationalization of the investment process and stakeholder buy-in. This is an essential step in order to obtain approval. Business planning and portfolio management efforts are to be performed by the business responsible for managing the business capabilities when transformation of their legacy business-critical systems is being performed. This needs to be addressed in the Architecture Vision.
In Phase A, a business-oriented decision (or principle) needs to be made to extend the life of legacy systems, or to focus on replacement. This is important for the Target Architectures and the Opportunities and Solutions phase (Phase E). The high-level description of the final architecture in the Architecture Vision will need to take this into account.
This phase also needs to lay the groundwork for non-functional requirements such as: creation/use of legacy modernization guidelines, identification and selection of legacy integration patterns and selected tools, maintainability, supportability, performance and security, extensibility requirements, data and information protection, and information assurance; for example, refer to work by The Open Group Security Forum, The Open Group RTES Forum, and The Open Group Trusted Technology Forum (OTTF), all Forums of The Open Group.
In these phases, the as-is (current state) and to-be (target state) Business, Information Systems, and Technology Architectures are developed.
Current State Architecture
For L2SOA, the current state assessment of the application landscape needs to be done in sufficient detail to be able to identify the legacy systems and functionality decomposition and the integration to/with other application systems. The usage relation from legacy functionality to current state business services and business processes needs to be identified, to know which business will be impacted in a transformation.
The to-be migrated or modernized (e.g., SOA-enabled) legacy applications and their functionality need to be identified in more detail (logical application components, information system services), to prepare for gap analysis with the Target Architecture. Also, an analysis of the information elements managed within the legacy systems is important.
With regards to legacy systems, a first analysis can be done if systems can be retired, consolidated, re-factored (SOA enablement), or replaced. This will need to be detailed and finalized in the Opportunities and Solutions phase (Phase E).
Target State Architecture
Potential (groups of) services need to be identified which fulfill the required functional needs and flexibility. This starts from the Business Architecture, in which business services are identified. Information system services have to be identified to support the business services, using the approach, SOA principles, and views as described in the TOGAF SOA Guide . This enables the identification of gaps between functionality provided by current legacy systems and what is needed from a Target Architecture perspective.
L2SOA needs to align with business and IT strategies, and therefore needs to consider a portfolio rationalization assessment as input for the target state architecture, as well as application portfolio management. The portfolio rationalization assessment provides input on systems that can be retired, consolidated, re-factored, or replaced. Application portfolio management provides input on tactical increments that are in-flight and planned.
Depending on principles like protecting return-on-investment and others, the Technology Architecture needs to contain technology for both the SOA infrastructure components, as well as legacy integration technology (e.g., providing specific adapters, emulators, source convertors, etc.). The Open Group SOA Reference Architecture (SOA RA)  is a starting point for that. Also evaluate the need for and type of tooling to support/enable legacy migration/modernization.
The Target Architecture will be divided into several Transition Architectures to gradually transform from legacy under architectural governance control. This phase consolidates the gap analysis from Phases B to D, identifies the Solution Building Blocks (SBBs) and the projects that will deliver them. It is here that the final decisions are made about which specific legacy systems will be transformed towards SOA style and in which priority (e.g., first quick-win with screen scraping, but further work on implementing a service bus on which the legacy systems will be connected).
To assess the impact of the SOA migration and to communicate the various aspects to and with stakeholders, it is advised to create an additional SOA migration planning view on the defined Transition Architectures (as preparation for the next phase). The view describes enterprise-wide impact for options considered (Transition Architectures with options/impact). The view critically examines options considered for migration paths and throws light into enterprise-wise impact, pros, cons, and work packages for each option with stakeholders weighing in on the best possible migration path given the opportunity and situation. The final target state options, as planned in the next phase, will contain strawman views of all the baseline applications carried forward, baseline applications burned down, and target applications introduced and carried during increments.
Specific vendors need to be chosen to provide tools for legacy integration, SOA infrastructure components, and to replace legacy systems (with, for example, a Software as a Service (SaaS) solution, if relevant). The TOGAF SOA Guide  details the various SOA-specific deliverables for this phase.
With L2SOA, the transformation is at least two-fold:
- The design and build of an SOA infrastructure
- The modernization of the legacy applications itself
The latter will not be able to succeed if the former does not have a minimum level of implementation; this is important for planning.
The planning can take into account various stages of SOA maturity and a phased approach to modernize the legacy systems. For example, first retire systems (quick cost reduction), then integrate legacy user interface in an existing portal, consolidate systems, then open up some transactions as web services, etc. Note that for the integration of legacy systems in an SOA infrastructure a proof-of-concept is advisable to get familiar with the integration technology.
Also, the governance model needs to be reviewed again, especially now that it is clear which legacy systems are affected, and therefore also the relevant business domains.
It is very important to keep working with the relevant legacy system specialists, and have them participate in the architecture team.
Especially when the transformation is at the program level, it should be supported by a change program. Current operations and departments will be affected and need to be managed and guided for this change. Organization and Process describes further organizational impacts and suggestions.
Governance discusses additional governance-related considerations and challenges, along with recommendations for overcoming the issues.
In this phase, changes from various inputs are taken into consideration regarding the effect on the architecture. Depending on the assessed type of change, a decision can be made to start a new architectural cycle for a (set of) legacy application(s) to transform towards an SOA (e.g., changes in the business environment, new technologies). It can also be decided to implement a change request without a cycle if the change is small and with no or minimal impact. A new cycle will take the existing defined architectural views and artifacts as input, together with the new requirements.
At a certain time it is advisable to again conduct an SOA maturity assessment, using The Open Group Service Integration Maturity Model (OSIMM) , an Open Group Standard. This manages and justifies the transformation process, for L2SOA evolution.
There are different starting points possible to identify which legacy applications to transform towards an SOA. For example:
- From a functional perspective, select the business services and processes and information system services (or define new services) which need more flexibility, re-usability, etc. and then relate the legacy systems that need to transform to their respective services.
- From a technology perspective, select the applications to modernize based on the age of the technology, availability of new technologies to service enable them, etc.
From experience with legacy modernizations, testing is a very important activity and sufficient time needs to be planned for it. Some systems have been rebuilt in a new language based upon newly written documentation by using and observing the legacy system. Some systems run as emulators on new hardware, etc. All types of testing are important on applications, infrastructure applications (e.g., emulators), and hardware. This includes performance testing.
It is advisable to conduct a proof-of-concept to verify the viability of the overall approach, including the types of test.
Legacy systems and technology platforms are building blocks in the TOGAF Content Metamodel, just like all other applications and technology platforms. Functionality of existing legacy applications (physical application components) need to be modeled in logical application components and decomposed in information system services. This enables, on a logical level, a gap analysis with the Target Architecture. However, this needs to be done only to the level of detail/granularity that allows the architect to perform an effective gap analysis.
Architects may consider extending the TOGAF Metamodel with the SOA-specific concepts proposed in the TOGAF SOA Guide .
The Carnegie Mellon Software Engineering Institute (SEI) has developed a Service Migration and Re-use Technique (SMART) which helps to make initial decisions about the feasibility of re-using legacy components as services within an SOA environment . This technique can be of good value during the architecture cycle.
Legacy modernization has a major impact on operation. Some new capabilities introduced in rebuilt applications may require adjustments in monitoring, network planning, and security. Service-Level Agreements (SLAs) should also be reviewed. Cross-domain applications may cause interesting conflicts among decentralized operations teams.