While I have been travelling recently, giving some talks on modeling and metadata management, I have had a lot of people ask me the same question, “What is impact analysis?”. As I’ve been giving the answer a few different ways depending on who is asking, I’ve come to the conclusion that there are a lot of different ways to think about it.
Or, more precisely, there are four main viewpoints to take into account: business, architecture, design and implementation. Each discipline will have its own perspective. So, the answer to “What is impact analysis?” depends on who you are. When you’re evaluating a modeling tool to provide impact analysis, it’s important to consider all four viewpoints.
From a business perspective, impact essentially means cost and risk, as well as what options exist to minimize both. Impact is measured by how much a thing costs and what the downstream damage may be if things go wrong.
Architects tasked with estimating risk and cost for the business need to know where change is going to occur, what dependencies relate to the change, and what the complexities are. If they can identify those things, they can get a pretty good sense of risk and cost. But they also need to factor in the implementation workload to get a true estimate. For that, they go to the designers.
Designers require a much more granular level of detail. They need a list of the servers, systems, applications and databases involved. They need to know how much and what kind of code is required, and if any software and hardware updates are necessary. In order to answer these questions, they tap the implementers (or developers).
Ultimately, the implementers (or developers) need to understand all the new pieces of code that would be required, where they’d need to be added and how to check in and roll out the changes. They are also interested in what resources are required, and what are the agreed upon, or required, delivery dates.
So, in order to ensure that we know about the cost and risk of a proposed change, we need to know the costs and risks of making the change, which servers, systems, application and databases will be involved, and when we get right down to it, how every bit and byte will be implemented by whom.
In short, effective impact analysis requires that we know everything at the business, architecture, design and development levels. It requires that we capture each viewpoint, and make it available to the people who need it. Additionally, it requires that we are able to sync those viewpoints, so that when there’s a change at one level, it gets implemented at all levels.
How do you manage all of this? With the right tool. The right tool can both capture knowledge at all levels and present the impact analysis for each one. The right tool can give the right person the right viewpoint at the right time. The right tool can sync all viewpoints so that everyone can see his or her own information, as well as the different levels that all roll up to management.
So you can see that impact analysis isn’t just one thing, but rather a federation of a lot of things working together.