Organizations regularly make changes to their applications, IT infrastructure, and business processes. Before implementing any change, one critical question needs to be answered: What will this change affect?
The answer is rarely straightforward. A server or application change can disrupt business processes and ultimately affect customers. Similarly, changing a business process can leave behind applications or technology that are no longer used but continue to generate costs.
Effective impact analysis must work in both directions: tracing how technology changes affect business operations and how process changes affect the supporting technology. In practice, organizations often examine only one side, leaving dependencies, risks, and potential costs overlooked.
How Impact Analysis Has Worked in the Past, and How It Works Today
Early in my career at a large financial services company, every IT change had to go through a Change Advisory Board (CAB). The board brought together representatives from departments that were expected to be affected by the proposed change. Each representative consulted their team, assessed the potential impact on their operations, and returned with a recommendation on whether the change should proceed.
This review process could take weeks or even months, depending on how frequently the board met. Despite these efforts, affected departments could still be overlooked, leading to additional questions, repeated discussions, and delays in change approval.
Today, a similar challenge persists. Whether a change originates in IT or the business, organizations often rely on the knowledge and experience of individual stakeholders to assess its potential impact. Part of this involves identifying the relevant RACI roles: Responsible, Accountable, Consulted, and Informed.
In practice, organizations typically have a clearer understanding of who is responsible for a process or technology and who is accountable for its outcomes. The challenge is identifying everyone who needs to be consulted or informed before a change takes place. Without a clear understanding of the relationships between business processes, applications, and the people who use them, important stakeholders can be missed.
I experienced this firsthand when I submitted a software request through an internal web form, only to discover that the form had been replaced without notice. The team responsible for the process change had not identified everyone who still relied on the original form. As a result, the change affected more users than anticipated.
This experience illustrates a common limitation of change impact analysis: when organizations depend primarily on individual knowledge rather than documented process and technology relationships, they risk overlooking stakeholders who depend on the systems or processes being changed.
Impact Analysis Runs in Two Directions
One of the main challenges in impact analysis is the lack of visibility between business processes and the technology that supports them. In many organizations, business teams document and manage processes using Business Process Management (BPM) tools, while IT teams maintain applications, infrastructure, and their dependencies in separate Enterprise Architecture (EA) tools.
This separation creates gaps in change impact analysis. Business teams can assess how a change affects their processes, while IT teams can evaluate its impact on applications and infrastructure. However, without connections between these two environments, neither side has a complete view of how changes to business processes affect technology, or how technology changes affect business operations.
See how GlobeArc connects BPM and EA in one repository: take a product tour.
From Technology to the Business
From an Enterprise Architecture standpoint, you might know everything affected by a change to a server or an application on the IT side. What you might not know is who uses that application in their process, or whether the application running on that server supports a process that is customer-facing.
You could plan for months to change an application or a server and never realize where it’s used within processes. You could get all the way through the change without knowing you were affecting a customer directly.
The same challenge applies to incident management. When an application experiences an outage, IT teams need to determine which business processes are affected and whether the disruption impacts customers. Without documented relationships between applications and business processes, assessing the business impact of an IT incident becomes more difficult, potentially delaying incident prioritization and response.
From the Business to Technology
Business process impact analysis is equally important when changes originate on the business side. During process redesign, organizations may discover unexpected technology dependencies, including multiple applications supporting the same task across different organizational units, locations, or business functions.
Process improvements can also eliminate tasks that previously required specific applications or technologies. When those tasks are removed, the supporting technology may no longer be needed. However, without documented relationships between business process tasks and their supporting applications, IT teams may remain unaware that the technology is no longer being used.
As a result, organizations can continue paying for unused applications, licenses, or infrastructure even after the associated business processes have changed. Connecting business processes with Enterprise Architecture enables teams to identify these dependencies, assess opportunities for application rationalization, and determine whether the technology can be retired or consolidated.
This helps organizations translate process improvements into measurable cost savings, provided the technology has no remaining dependencies or business requirements.
People Are Part of the Impact Too
I’ve also seen organizations make significant workforce reductions without fully assessing how employees are connected to critical business processes and supporting technology. In some cases, they let go of entire teams without recognizing that those teams held essential knowledge about how and where specific applications were used.
Only afterward did these organizations discover that the affected applications still supported customer-facing processes and required ongoing maintenance and updates. As a result, some had to rehire employees they had previously let go to restore the expertise needed to support those systems.
These situations demonstrate why change impact analysis must account for people, not just processes and technology. Understanding employee responsibilities, application dependencies, and critical knowledge before making workforce changes helps organizations identify operational risks and avoid losing expertise essential to business continuity.
How to Perform Impact Analysis in Both Directions
Doing impact analysis well starts long before a specific change is proposed. It depends on having the business process and Enterprise Architecture information documented and linked.
1. Connect Process Tasks to the Technology That Supports Them
Link each task in your business processes to the applications, servers, or other architecture objects it relies on. That connection is what lets you trace a change from one side to the other.
2. Capture Ownership and RACI for Both Sides
For each process and each supporting architecture object, document the owner and the RACI information. Go beyond responsible and accountable. The consulted and informed parties are the ones most often missed, and they are the ones who most need to hear about a change.
3. Document the Current State
Capture how the process and its supporting architecture look today.
4. Document the Target State
Capture how the process and its supporting architecture will look after the change.
5. Compare Current and Target to See What Changes
Look at the overlap and the differences, from the process all the way down through the technology and the architecture. What is being removed? What is changing? What is affected as a result?
6. Reach Out to Everyone Affected
With the differences identified and the RACI information connected, you know which individuals and teams to contact about anything that is, or could be, affected, including the owners on the IT side.
7. Make the Decision With the Full Picture
Once you understand the impact, the remaining question is when and how to move forward, based on the impact, the strategy, and the risk. That’s when you decide how to run the initiative or projects that make the change.
What Changes When You Get It Right
While the exact financial benefits of effective impact analysis vary by organization, connecting business processes with Enterprise Architecture provides several practical advantages:
- Reduced operational risk. Documented relationships between business processes, applications, and infrastructure help teams identify dependencies and assess potential risks before implementing changes. This improves visibility into how a proposed change could affect business operations and customers.
- Faster impact assessments. Instead of spending weeks gathering information from different departments, teams can trace documented dependencies and identify affected processes, systems, and stakeholders more efficiently. When this information is accurate and up to date, the initial impact assessment can take significantly less time, although formal approvals may still be required.
- Greater cost visibility. Understanding how applications and infrastructure support business processes makes it easier to identify the financial implications of proposed changes. This can reveal opportunities to eliminate unused technology, reduce unnecessary expenses, and improve resource allocation.
- More informed decision-making. With a clearer view of business and technology dependencies, leaders can evaluate potential impacts, compare options, and make decisions based on documented information rather than assumptions.
However, change impact analysis does not always lead to lower costs. An organization may deliberately increase technology spending to accelerate time to market or support a strategic business objective. The value lies in understanding those financial and operational implications before committing to the change, rather than discovering unexpected costs afterward. In other words, a cost increase is a decision you are making. It’s not a surprise or a risk.
A few years ago, I saw the importance of this firsthand while working with a senior technology executive at a global automotive manufacturer. During our discussions, the executive emphasized how understanding the interconnected relationships between business processes and technology helped leaders make more confident decisions.
By seeing how a proposed change could affect both business operations and the underlying Enterprise Architecture, decision-makers could better evaluate its consequences before moving forward.
Where to Start if Your Process and Architecture Tools Are Separate
Effective assessment requires visibility into the relationships between business processes and the technology that supports them. Ideally, Business Process Management (BPM) and Enterprise Architecture (EA) information should be connected, allowing teams to assess dependencies without duplicating documentation across systems.
When organizations use separate BPM and EA tools, establishing consistent references between them is an important starting point.
At a minimum, organizations should:
- Reference applications and systems in business processes. Document which applications or technology components support each process task, making it easier to identify technology dependencies when assessing business process changes.
- Reference business processes in Enterprise Architecture records. Identify which business processes rely on each application or system, helping IT teams understand the potential business impact of technology changes.
However, simply adding application and process names to both systems is not enough. Different departments may use different names for the same application, making it difficult to trace dependencies accurately.
Establishing consistent naming conventions across BPM and EA tools helps teams identify relationships between business processes and supporting technology. While this provides a practical foundation for change impact analysis, maintaining accurate, traceable connections between the two systems is essential for assessing impacts reliably.
The Biggest Mistake: Not Having the Information in Either System
One of the most significant mistakes is failing to document the relationships between business processes and their supporting technology.
When Enterprise Architecture information is not connected to business processes, organizations lack visibility into how changes to applications or infrastructure could affect business operations and customers. The same problem exists in reverse: without business process information linked to architecture records, IT teams cannot reliably assess how process changes affect the underlying technology.
The Takeaway
Good impact analysis means you know what you don’t know. When your business processes are connected all the way through to the technology and architecture behind them, every change can be understood from both sides, and every cost is a decision rather than a surprise.
How GlobeArc Helps
GlobeArc Software connects business processes with the Enterprise Architecture (EA) components that support them, enabling organizations to perform change impact analysis across both business operations and IT infrastructure.
As teams document business processes in GlobeArc, they can link individual process tasks directly to supporting applications, systems, and other architecture objects. Each task's properties can be reviewed to understand its dependencies and assess how a proposed change could affect related processes and technology.
The Relationship Explorer provides visibility into the connections between architecture objects, business processes, and other related elements. Process overlays also allow teams to compare the current state with proposed changes, helping them identify what will change and which dependencies may be affected.
GlobeArc also supports AI-assisted impact analysis through its built-in Ask feature or external AI tools, such as Claude, connected through the Model Context Protocol (MCP). Using the relationships documented in GlobeArc, these tools can help teams trace potential change impacts across business processes and supporting technology, including customer-facing activities.
Combined with documented RACI information, these capabilities help organizations identify affected stakeholders, understand dependencies, and make more informed decisions before implementing changes. The accuracy of these assessments depends on the completeness and quality of the information maintained in GlobeArc.
Schedule a GlobeArc demo to explore how connected business process and Enterprise Architecture information can support more effective impact analysis.
Frequently Asked Questions
What is impact analysis?
Impact analysis is the work of understanding what a proposed change will affect before you make it, including processes, applications, infrastructure, people, and customers.
Why does impact analysis need to work in both directions?
A technology change can affect business processes and customers that IT can’t see. A process change can leave behind technology the business no longer uses but the organization still pays for. Looking from only one side misses half the impact.
What does RACI have to do with impact analysis?
RACI identifies who is responsible, accountable, consulted, and informed. Most organizations know who is responsible and accountable, but not who should be consulted or informed. Those are the people a change is most likely to surprise.
How do you start if process and architecture information are in different tools?
Use consistent naming in both tools. Put architecture names in your processes and process names in your architecture records, so the two can be traced to each other.
Can impact analysis reduce costs?
In most cases, yes, because it makes it easier to see the cost effect of removing or changing something. When a change does increase cost, impact analysis makes that a deliberate decision rather than a surprise.
