Legacy Evolution to SOA – Case Study: Automotive Company
Introduction
This case study provides a historical view of a journey that an enterprise has taken to evolve legacy applications to SOA. The objectives of the case study are to:
- Provide a sample of how enterprises are evolving their legacy application to SOA
- Identify gaps and learn from their journey to establish guidelines and best practices
- Describe the viewpoint on the current state for the evolution
- Provide recommendations to improve the journey by adapting the approach and best practices outlined above
Case Description
For such an initiative we cannot talk about a “project”. In fact, it is a transformation program.
The Transformation Program
This program was divided into the following phases:
- Assess current state, including an application assessment (including what can be phased out, etc.): An assessment was done on around 50 legacy supply chain applications. This determined that: 30 applications could be replaced by common systems/Commercial Off-the-Shelf (COTS) systems; 15 applications could be retained; four (4) applications could be retired; and two (2) applications could be retired because other systems could take over the functionality. Retiring can show as a quick-win with an immediate cost saving. This was important input for the future state architecture.
- Define the future state architecture: The future state architecture divides the IT landscape into a presentation layer (able to web-enable mainframe screens, replace thick clients, introducing a portal), process layer (able to orchestrate processes), integration layer (Enterprise Service Bus (ESB) functionality, to replace the point-to-point coupling and to enable provisioning of web services), and the application layer (existing and new application functionality). This future state architecture enables automotive supply chain process support, in a way that is not possible in the current state.
- Transformation planning: This transformation is not only about replacing applications, but also about introducing a new future architectural landscape design. Careful planning is necessary to maintain control and keep the IT support ongoing for the business while transforming the IT landscape. This also includes more detailed business case planning to support the right priorities.
- Execution: Execution follows a tight program and project management approach, with an architectural framework and processes in place.
Challenges to Evolve Legacy Applications to SOA
- Providing realistic return-on-investment data
- Lack of documentation
- Poor architectural design
- Lack of resources able to work on the outline
- Poor programming structure (lack of structured programming)
- Hardware where application is used (e.g., mainframe)
Business Concerns
High update costs:
- Applications are tightly-coupled (integration is “hard-coded”).
- Old technology requires constant upgrading.
- Application source is mainly Programming Language 1 (PL/I), originating from the 1960s.
- The number of experts on this language is declining.
- Costs for maintaining the code are escalating.
Functional concerns:
- Applications are custom to a specific local country situation, while there is a drive to globally standardize business/manufacturing processes.
- Data is not easily shared.
- Data is not stored in a database but in (SAM) files.
- Poor usability.
Poor Business Process Management (BPM) support:
- Applications are not optimized to support best-in-class business processes.
About the Legacy to SOA Initiative
The ultimate vision of the Automotive Company is to reach the following situation:
- An adaptive and agile environment which can absorb changes.
- COTS and/or globally selected common systems deployed.
- Local customization minimized, only where local business differentiates significantly.
- Applications are driven by the processes, and not the other way around.
- Open architecture, which allows for re-use and timely sharing of data.
- Lower costs and reduced amount of maintenance.
Architectural Overview
The following diagrams show a high-level overview of the evolution from legacy systems point-to-point integrated, towards SOA.
Case Study A – Supply Chain As-Is (Legacy)
Case Study A – Retire Some Systems
Case Study A – Integration Focus
Case Study A – Business Process Focus
Lessons Learned
- L2SOA is a transformation program and has to be approached and managed as such.
- Quick-wins and cost reduction can help gain support.
- An application (portfolio) assessment should always be part of an L2SOA project/program.
- Transformation strategies and technology choices need to be made during transformation planning using a holistic approach to consideration of options.
- Use of a reference architecture.
Recommendations to Improve the Journey, based upon this Guide
- Governance strategy and processes were not taken into account, but need to be.
- There was a lack of resources which could work on the future architecture outline and transformation program, which poses a serious acceptance risk. This should be noted as a Critical Success Factor (CSF), and regarded as a showstopper.
- While there was a recognized challenge on providing realistic return-on-investment data, there were no base-lined metrics available. Those are necessary for the return-on-investment discussion and for initiating (approved) further transformation projects.
- The SOA focus in this case study seemed to focus on technical enablement of applications as Solution Building Blocks (SBB), and not on business capabilities and processes using a top-down approach. This is not necessarily a wrong approach, but a top-down approach focusing on business process optimization to support business drivers typically provides greater motivation for change. Many organizations use a combination of both approaches.
- These large transformations should be supported by a change program which manages changes towards operations, departments, and people.