Change Impact Analysis or Impact Analysis (IA) is the process of identifying the potential consequences of a change, or estimating what needs to be modified to accomplish a change. In software engineering, there are two normal types of IA: “Traceability Impact Analysis” and “Dependency Impact Analysis”. The input of this process are the requirement or need that cause the change with the definition of that need or requirement and the current picture of architecture and its context. And the output of this process is the list of the impacts or potential impacts.

In the scope of software-intensive system architecture, we usually refer to Dependency Impact Analysis (DIA) as Impact Analysis which is the scope of this post because we will normally use Traceability Impact Analysis (TIA) as a starting point for the change in existing requirements, scenarios, functionalities, and features. And although there are also other types of impact analysis but it is not in the scope of this post.

Static structure,  dynamic structure, and quality-attributes views of the architecture will be used to identify the potential impacts by reviewing them against the scenario. And once we get the list of the impacts, we will then submit it to review with team and stakeholders.

At first (and most important) level, we will list only the impacts that happened on the whole IT system:

  1. system logics (both data and processing)
  2. information architecture
  3. software architecture
  4. hardware system architecture
  5. networks and infrastructure.

Then we will drill down into more details at detail level:

  1. Detail software design and implementation
  2. Detail OS and software framework or libraries specifications
  3. Detail hardware and driver specifications

After having the list of impacts on the IT system, we will then move to investigate the second level impacts on the processes or procedures of managing the IT system:

  1. Release and distribution process
  2. Installation, patching and uninstallation procedures
  3. Backup, restoration, and reconciliation procedures
  4. Environment/site failover procedure
  5. QoS and SLA
  6. Support and troubleshooting procedure
  7. Monitoring and instrumentation procedure
  8. Development and QA process/methods
  9. Etc.

Once we done with the second level impacts analysis, we can then submit the report to the chief architect and enterprise architect to review and consult with the business to evaluate and analyse the impacts at service and business level in order to review with the business side as necessary.