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.
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:
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.
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:
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.
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.
What a day! We have learned a lot by examining our EA assets. Let us summarize the findings and conclusions.
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.