To reflect contemporary business practice organisations need to update their legacy computer systems. A major concern is how to gain a detailed understanding of the business information supported by each system. Harder still is the task of defining an information architecture that transforms stand-alone systems into an integrated set of functions that fully support the current and future needs of the business. This case study describes how one company used TOGAF and a reference model-based approach for this task.
The Problem:
Because of the size, complexity and age of legacy systems it can be difficult to gain a clear picture of how an individual legacy system stores, processes or manages business information.
In this case, each legacy system was developed independently, so data items and information structures did not conform to consistent Enterprise Architecture standards, naming conventions or principles.
Things had become even more difficult because there of the need to transfer information between systems. To meet new business demands there were many fixes, bridges and changes both within and between legacy systems. These changes complicate the original systems and add to their complexity.
A major task in an architectural approach to reengineering legacy systems is to gain a thorough understanding of each individual system and the relationships between them. The following table summarises some of these problems, with examples and possible impacts. This is not a complete summary of information related problems – a full list would cover many more types of problem!
From an architectural perspective it was very difficult to compare one system against another. The IT team realized that to resolve these inconsistencies and problems require considerable effort and resources, and that developing a coherent information architecture would be a costly, time consuming and high risk endeavour. However, the CIO also knew that reengineering legacy systems or developing new systems without a clear data or information architecture would be like creating a city without a city plan, architectural designs and building standards.
IT therefore created a Request for Architecture Work, asking the EA team to provide a clear roadmap to resolve these issues in legacy systems over a five year period.
The Solution:
The EA team followed the Architecture Development Approach – taking the Request for Architecture Work (Preliminary Phase), and developing an Architecture Vision (Phase B), but then they jumped directly to the Data Architecture in Phase C. They proposed an information architecture to encompass the information structures and content of both legacy and future systems. Initially they decided to create an information framework that could be populated with information models to analyse data and process needs from a business and IT systems perspective. They proposed purchasing a licence for a generic data model that would form a basis to analyse past, present and future architectural structures. This reference model would form be a Foundation Architecture, in the sense of the TOGAF Architecture Continuum.
The EA team felt it was important that the information architecture was independent from the application and technology architectures. In other words, it was an information architecture, not an information technology architecture. This made it easier to analyse information that was processed and stored outside the enterprise boundary and away from the organisations’ internal systems.
Once they had acquired the reference model from the vendor, the EA team began the task of mapping the highest priority legacy systems to the model. When necessary they extended or adapted the reference model, but they made sure that these changes were minimal in order to keep the beneficial structures provided by the model.
Benefits of a Distinct Information Aarchitecture and Reference Model-Based Approach:
The EA team summarized the following as the key benefits they achieved by using a Foundation Reference Model:
- Providing consistency: It provided a systematic approach to ensure that all components conform to standard principles, rules and representations.
- Managing complexity: Large organisations are too complex for anyone to manage without recourse to simplified models and abstraction.
- Storing know-how: The reference model included a greater number of concepts and ideas than the team felt they could come up with independently.
- Tracing development: The reference model provided a trace from well-structured architectural concepts through to the wide number of variations found in the implemented systems.
- Improving utility: Being professionally prepared, a good reference model is clear and accessible.
- Co-ordinating effort: A reference model supports a co-operative style of working and helps build a cultural ethos with shared meanings and values, a key success factor for effective enterprise architecture.
- Providing structure: A reference model provides an ‘info-structure’ that can be steadily adapted over time to capture details of implementations and information usage.
- Tracking change: A reference model allows for flexibility and latitude. Each model can be adapted easily for changes that are unplanned or not anticipated.
- Capturing learning: The model provided an effective structure for gathering the results of organizational learning.
- Structuring ideas: Reference models are a natural tool to support the way that we think or structure our ideas, in a similar way to the way that we make sense through mental models.
The EA team felt that the initial iteration of the ADM – from Preliminary and Architecture Vision directly to Data Architecture, supported by the purchase of a foundation data reference model – was an effective way to quickly provide the right architectural basis for improving their legacy systems and data structures. They were then able to initiate further iterations of the ADM to deal with specific concerns.
