In order to meet ever-increasing customer demands and compete on a global scale, many organizations need to be able to fold new systems and/or new features into existing systems quickly and cheaply. These organizations — and perhaps yours — have portfolios of existing systems and infrastructures that were implemented literally decades ago.
These “legacy” systems, while well-architected for the demands and market conditions of the past, have often become increasingly complex through the years and more costly to maintain. What’s more, these systems are based on technologies that simply don’t provide the flexibility and disciplined agility that modern programming languages and frameworks can.
[pullquote]Many times the knowledge about a system’s structure and operation is compartmentalized to the point that the information only resides in the heads of the team members maintaining the systems.[/pullquote]Organizations that wish to undertake efforts to modernize their aging systems portfolio may face the additional challenge of not having a documented, published and complete representation of how these systems operate and interact that is accessible to the entire organization. Many times the knowledge about the system’s structure and operation is compartmentalized to the point that the information only resides in the heads of the team members maintaining the systems. No current, accurate documentation exists.
We have found that the old adage of a “picture is worth a thousand words” applies strongly in these situations and developing a systems context model can be a straightforward — yet powerful — way for organizations to start their journey down a path of legacy systems modernization. System context models provide a visual inventory and roadmap of an organization’s systems portfolio, and are an effective communication tool for the organization to use in discussions about what systems to modernize and what approaches to take for modernization.
The primary advantage of investing in building a System Context Model instead of (or in addition to) just creating a list of systems and interfaces in a spreadsheet or document is the that the models can provide a visual business context for understanding the systems interaction that “lists” simply cannot provide. Also the models can be built using simple office applications, like Microsoft Visio, that companies already own.
What’s a Context Model?
A system context model is typically a “system of systems” model comprised of one or more diagrams, where each diagram may depict one or more systems and their interactions with other systems either internal to the organization or external to the organization. The model can be organized to create views of the systems and their interactions for one or more core business functions that the systems support, or they may be organized by business entity (e.g. department) that owns the maintenance of the systems. We have found that organizing the model through views of system interactions by the core business functions they support is the most useful approach for legacy systems modernization in order to fully understand the dependencies between systems.
For example, a context model for some of the types of systems a consulting services firm like AIS might use may look something like this:
The “boxes” in the diagram represent individual applications/systems that may be either purchased commercial off the shelf (COTS) products or custom in-house applications. The boxes can also represent external systems outside the organization. The lines show the types of key interactions between the systems and data flow. The purpose of the diagram is to provide a “big picture” view of the systems in the organization’s portfolio and how they interact with each other at a high level.
In a legacy systems modernization project, this type of information is critical to understand and communicate the system dependencies in order to assess the full impact or ripple effects of re-architecting one or more of the systems onto a more modern technology stack and infrastructure. It also provides a means of bounding the problem space and helping to set what the overall scope of the modernization effort will be.
In addition to depicting systems and their interactions, the model can be used to collect important information about what technology stacks/platforms the systems are currently deployed on, and what organizational entities own what system. In some cases it may also be useful to represent specific data persistence stores (files, databases, etc.) for completeness.
How to Build a Systems Context Model
In general, a system-of-systems model (as shown above) is constructed by both interviewing system owners and the team members who are involved in the maintenance of the systems and reviewing any existing systems requirements specifications, architecture/design documents or test plans. In many cases, available system documentation is either non-existent or is significantly out of date, so the interview process is absolutely essential to the successful construction of the model. It may also be necessary to either manually or through the use of any available code analysis tools review the legacy systems code directly to fully understand all of the touch points a system has to other systems.
The scope of the interviews, documentation reviews and code reviews is dependent on the vision and scope of the modernization project as defined by the sponsors within the organization. We have found that taking a top-down approach to start with (and then verifying from bottom up) is often the most practical approach to getting the information needed to construct the model efficiently and accurately.
The first set of interviews we do is typically with the managers of the teams that are maintaining the legacy systems. These interviews usually provide a broad view of the systems and are a good starting point for subsequent interviews with the team members, where we can focus more in-depth on the specific system(s) they work with. Where we start in the management chain is usually determined by the customer sponsor of the modernization effort, and will vary by organization and by scope of the project.
[pullquote]During the management level interviews, we focus on drafting models of the systems of system view and seek to understand who the experts are in each of the systems — these are the people we will interview next.[/pullquote]During the management level interviews, we focus on drafting models of the systems of system view and seek to understand who the experts are in each of the systems — these are the people we will interview next. We take the draft models from the management interviews into the team interviews and use them as a starting point for a detailed discussion for each system. The end result of the interview process is a set of draft diagrams defined at both the system-of-systems and individual systems level of detail that we can then, like sections of a quilt, “stitch” together the raw information from the draft models into a coherent set of system-of-systems views by core business function.
The number of diagrams that result from this effort will vary by the goals and scope, along with the number of business units involved and the number of core business processes examined. In general, we strive to create an enterprise-wide view of the systems as the primary model view for each core business process. We find these views give the best set of information that enables the all-important discussions of:
- What systems to modernize,
- In what order to perform the modernization,
- Using what approach (re-write, port, retire, etc.)
The information in the system context models can be used as a starting point for defining a modernization roadmap and phased implementation plan.
System Context Model Notations and Tools
Context models can be created using various notations and it really boils down to what works best as a means of communication within the organization. A simple “box and lines” style notation like the one used in the example above was created using Microsoft Visio‘s basic flowchart stencil. Given the potential size and scale of the models for organizations (that may have literally dozens to hundreds of systems involved in the legacy modernization effort), less is more when it comes to notation. Clean and simple should be the mantra for the team developing the models.
Other types of notation that may be used include the Unified Modeling Language (UML). A system-of-systems context model can be constructed using a UML Class diagram with packages to represent the individual systems and dependency associations to represent the system interactions. Alternatively, a UML Use Case diagram can be used to where subsystems represent the systems and actors represent external entities or users.
Ideally, it is best to use a modeling tool that enables you to store elements of the model in a central repository and capture custom attributes for the model elements that can be used to manage the modernization effort. Also having the capability to create different filtered views of the models and generate reports of the systems inventory that the models represent is extremely helpful. One tool that we have found useful is OpenText’s (formerly Metastorm) ProVision modeling tool.
System Context Models in a Nutshell
System context models provide a useful means of defining the scope and managing the complexity of legacy modernization projects. They enable the organization to get a clear and fact based understanding of the systems they have and how those systems are dependent on each other. The models provide a basis for making informed decisions about how to plan the modern effort and for creating future state visions of the systems implementation.
