Sunset Legacy Applications Gracefully
Sunsetting a legacy application or a system within an enterprise is a challenging task that requires careful consideration of risks and impacts. Furthermore, you need to plan proper action items to transition the architecture into the to-be (future) state.
Let us follow the mentioned process step by step, with an example to make it maximally clear and practical. We took the data shown below from an actual organization where we assisted with architecture efforts. We have changed the object names slightly to avoid exposing the company's identity needlessly. Such a reflection of reality should ensure that the analysis we demonstrate is doable in real life, too.
Capture EA Assets about Application Landscape
Before we start the analysis necessary for sunsetting an application, we need the apparent prerequisite - Enterprise Architecture assets that describe the current landscape. We will use Archipeg's Object Catalog Designer for this task, but you can use any tool that allows capturing information about applications, integrations between them, and the features they deliver.
Precisely, please capture the following objects and elements:
- Applications: list IT applications and systems that you are sunsetting, as well as those that need to stay in the to-be architecture state.
- Integrations between applications: associate upstream and downstream systems according to the current state of your architecture landscape.
- Features: i.e., the lowest level capabilities that the applications perform or deliver for their consumers.
In our example, we are sunsetting an application called "PipeBridge." Let us open this object from the catalog designer and reveal its data. In the below image, we have omitted the empty fields for simplicity. You can examine the upstream and downstream systems, as well as the features offered by PipeBridge to its users.
Analyze EA Assets Related to Legacy Applications
It is time to analyze the assets and decide on the action plan to sunset the PipeBridge app. Before we start this exercise, let us clarify a couple of things:
- Your concrete case may require capturing and analysis of more data than what we have shown here. For example, besides the indicated fields above, Archipeg can hold attributes describing components (application's deployable modules or units), data, end-users, and responsible teams.
- For the example's sake, we will assume that your assets are similar to ours, so we won't be going into the details on how to analyze other types of data.
For convenience, let us analyze the assets visually. For this task, we will use Archige's Object Graph Explorer. Alternatively, you can use a tool that can traverse the knowledge graph to make conclusions similar to what we do below.
Let us drag the PipeBridge object onto the diagram surface and expand the associations. After a bit of rearrangement for readability, here is what we get.
All right, that's a lot of arrows, but at least we know we have a sufficient amount of data to make decisions. Next, let us try to make sense of this visual graph. We can quickly adjust the annotations within the graph explorer, which is a good starting point for our research.
This view is much better. We are starting to make sense of the assets around PipeBridge. Two of them are applications (upstream and downstream), and the rest are features. The next step is to attempt planning action items based on what we know about the landscape.
Plan Action Items to Transition into To-Be (Target State) Architecture
Let's start with the applications. InCenter, most likely, sends data into the PipeBridge. And CSP, in turn, receives data from the PipeBridge. In both cases, we can schedule meetings with the respective SMEs and stakeholders to decide on the fate of these integrations. Perhaps, a more critical question is the downstream rippling effect of sunsetting the PipeBridge. To follow this path, we can further expand the associations of CSP. However, we will postpone that step until we know the immediate implications related to the CSP. After all, CSP may be sending an entirely different kind of data downstream, and PipeBridge might not have to be concerned about it.
With the above conclusion, let us narrow our view around the features. We will assume that we should retain the features but sunset the application, even though we know that your situation might present different constraints.
We can see that the PipeBridge has five capabilities that we will need to maintain. Perhaps, the most straightforward path is to find other candidate systems that would support those features without much change. Since we have the visual analyzer at hand, we can quickly find applications linked to each capability. Below is the figure with the narrowed-down view.
As you can see, for three features (account transparency, handmade analysis, and books controller), we have found singular candidate applications that would take over the feature to support. Confirming our hypothesis with the SMEs of those apps is a good idea.
For the accounting processes, we have two possible candidates. Maybe we are even dealing with duplicate implementation among the newly discovered systems, which presents the opportunity for application portfolio rationalization. Either way, we will need a more thorough analysis to identify the capability-owning application for the future state.
Finally, the books predictor feature yielded no further applications after expansion. We may have found a critical gap to address before sunsetting the PipeBridge; otherwise, the mentioned capability support will disappear from the landscape.
With this step, we have completed the preliminary analysis of our EA assets and decided on a plan as we advance.
Key Takeaways
What a day! We have learned a lot by examining our EA assets. Let us summarize the findings and conclusions.
- Having a sufficiently large EA asset repository is a critical prerequisite for analysis. We would not be able to conduct the above exercise and make conclusions without the data at our disposal.
- Conflicts of interest, impacts, or implementation gaps can be hidden deep in the knowledge graph. Indeed, we discovered that one of the features had no potential support if we tried to sunset the legacy application in a rush.
- Findings lead to other action items and informed decisions. With some of the outcomes from the above exercise, we can conduct appropriate meetings with the SMEs. In other cases, we can plan the individual action items or gain an insight into the level of effort based on the impact size.
The above use case was conducted using Archipeg - Cloud-Based Digital Enterprise Architecture Software. You can start your free 30-day trial with transparent prices at any time. We are here to help if you need us.
See Also