Executive summary

Enterprise architecture is often documented through application inventories, capability maps, data-flow diagrams, and integration diagrams. These artifacts are useful, but they frequently leave leaders with a critical unanswered question:

If we change one application, data platform, interface, or infrastructure component, what else could be affected?

The answer is rarely visible in a conventional enterprise-architecture diagram.

Enterprise systems are connected through direct dependencies such as integrations, shared databases, and hosting relationships, but also through indirect dependency chains. An application may have only a few visible connections while still sitting within a network where a change can propagate across dozens or hundreds of components.

Research using a biopharmaceutical company’s enterprise architecture found that nearly one-quarter of the architecture could potentially be affected by a change to a randomly selected component. It also revealed that 32% of the components formed a tightly interconnected architectural core and that 67% of the architecture either belonged to, depended on, or was depended upon by that core.

For leaders planning modernization, cloud migration, application rationalization, integration changes, security remediation, or AI-enabled transformation, that kind of architectural visibility is essential. It changes the conversation from “What systems do we have?” to “Where is change most likely to create enterprise-wide risk, cost, and delay?”

That research was conducted by a team that included Carliss Baldwin and Alan MacCormack of Harvard Business School, two of Silverthread’s co-founders. 

Key takeaways

• Traditional enterprise-architecture diagrams document systems, but they often do not show how a change will propagate across the enterprise.
• Dependency analysis can reveal a hidden architectural core: the applications and infrastructure components most likely to create broad change impact.
• In one biopharmaceutical enterprise analyzed in the research, a change to a randomly selected component could affect nearly one-quarter of the architecture through direct and indirect dependencies.
• This visibility helps leaders plan modernization, migration, integration, and risk-reduction work based on structural evidence, not intuition or the loudest stakeholder.
• The same dependency mathematics applies at two scales: across an enterprise portfolio, and inside an individual codebase. Silverthread’s CodeMRI® Suite applies it at the code level.

What is enterprise architecture analysis?

Enterprise architecture analysis is the process of examining the relationships among an organization’s business capabilities, applications, data, integrations, and infrastructure to support better technology and business decisions.

At its most basic level, enterprise architecture answers questions such as:

• What applications support a business process?
• Which systems share data?
• What infrastructure supports a critical application?
• Where are integrations and dependencies concentrated?
• What must change when the business introduces a new capability, retires a platform, or adopts a new technology?

Traditional enterprise architecture often focuses on documentation. It creates a useful inventory of the enterprise and shows how major systems relate to one another.

But documentation alone is not analysis.

A diagram may show that a customer-facing application connects to a data platform, a set of integrations, and several downstream applications. It does not necessarily reveal the full chain of direct and indirect dependencies, or identify which component creates the greatest potential blast radius when changed.

That is where dependency-based enterprise architecture analysis becomes valuable.

Why application inventories and diagrams are not enough

Most enterprises can produce a diagram filled with boxes and arrows. The problem is that, as the number of applications and integrations grows, the diagram becomes difficult to interpret.

The result is often a familiar “spaghetti diagram”: technically accurate, visually dense, and operationally unhelpful.

It may tell an architect that two systems are connected. It may not tell a CIO, CTO, transformation leader, or program owner:

• Whether a planned change is locally contained or enterprise-wide
• Which applications are tightly interconnected
• Which infrastructure components are shared dependencies for many systems
• Which business capabilities rely on a fragile or highly coupled application cluster
• How a change may propagate through indirect relationships
• Where modernization work will require the most coordination, testing, and risk management

Those are decision questions, not documentation questions.

A more useful approach analyzes the enterprise as a network of dependencies. It measures not only what connects directly, but also what connects indirectly through the broader architecture.

What is propagation cost?

Propagation cost is a measure of how much of an architecture may be affected when a change is made to a randomly selected component.

It includes both direct and indirect dependencies.

For example, imagine that Application A relies on Application B, which relies on a shared data platform, which is used by several other applications. A traditional view may show only Application A’s direct dependency on Application B. A dependency analysis captures the broader chain and identifies the potential for change to spread beyond the immediately visible connection.

A higher propagation cost suggests that changes are more likely to have broad consequences across the enterprise. This can mean more analysis, coordination, testing, project risk, and unplanned work.

Propagation cost is not a stand-alone verdict on architecture quality. Enterprises need shared services, common infrastructure, integrations, and common data. But it is a powerful measure of structural exposure: it helps leaders understand how much of the enterprise could be implicated when a component changes.

Research evidence: uncovering the hidden structure of enterprise architecture

A Harvard Business School working paper examined the enterprise architecture of a U.S. biopharmaceutical company. The analysis included:

• 407 architecture components
• 1,157 dependencies
• Business groups
• Software applications
• Data schemas
• Application servers
• Database instances
• Database hosts

The paper’s authors were Robert Lagerström, Carliss Baldwin and Alan MacCormack (Harvard Business School), and David Dreyfus. Baldwin and MacCormack co-founded Silverthread in 2013 with Dan Sturtevant to commercialize this body of MIT and Harvard research on architectural measurement.

The researchers analyzed both direct and indirect dependencies among these components. Rather than viewing the enterprise architecture solely as a collection of layers—business, application, data, and infrastructure—they identified each component’s position in the larger dependency network.

The analysis found a core-periphery architecture.

A core-periphery architecture contains a large, tightly interconnected group of components—the core—surrounded by components with different dependency roles.

In the BioPharma case:

• The architecture had a 23% propagation cost, meaning a change to a randomly selected component could potentially affect nearly one-quarter of the architecture.
• The tightly interconnected core contained 132 components, or 32% of the architecture.
• The core, the components that depended on it, and the shared components it depended upon represented 67% of the total architecture.

The component classification also produced an intuitively useful result:

• Business groups primarily functioned as control elements: they depended on the applications and technology that supported the business.
• Infrastructure components primarily functioned as shared elements: many applications relied on them.
• Software applications constituted the tightly interconnected core.

This is not a universal benchmark. The study examined one organization, and enterprises differ substantially in their architecture, operating model, technology estate, and business requirements.

Its value is in demonstrating that enterprise architecture can be analyzed objectively. Leaders do not need to rely solely on a visual inventory, institutional knowledge, or a list of applications when evaluating change risk.

It is also worth noting when the study was conducted. The working paper was published in 2013, before microservice decomposition became a default pattern and before AI-assisted code generation began adding to enterprise codebases at speed. Each of these trends adds components and dependencies. None of them removes the need to understand how change propagates.

The four roles that matter in a dependency analysis

A dependency analysis can categorize components based on their role in the architecture.

Core components

Core components are part of a tightly interconnected group. They directly or indirectly depend on one another, which means a change in one can create consequences across the rest of the group.

Core components often deserve special attention during modernization because they may require broader coordination, regression testing, and phased execution.

Shared components

Shared components are used by many other parts of the architecture but do not themselves rely on as many components.

Common examples may include data platforms, identity services, shared APIs, application servers, schemas, and infrastructure services. A change to a shared component can affect many consumers.

Control components

Control components depend on other parts of the architecture but are not broadly depended upon by others.

In an enterprise setting, business capabilities, business groups, or front-end business processes can often play this role. They consume applications and services rather than serving as a common technical dependency.

Peripheral components

Peripheral components have relatively few dependencies. They may be easier to change, replace, retire, or modernize because changes are less likely to spread broadly through the enterprise.

Peripheral does not mean unimportant. A peripheral application may support a mission-critical process. It simply means its structural change impact is more contained.

Why indirect dependencies matter

Direct dependencies alone can be misleading.

An application may appear low risk because it has only a handful of direct connections. But if those connections lead into a tightly coupled cluster, its actual change impact may be much broader.

The BioPharma research illustrated this clearly. Some components had low direct dependency counts but high indirect dependency visibility. In other words, they did not look especially risky in a simple diagram—but were connected to many other components through chains of dependency.

This matters in real-world decisions:

• A cloud migration can affect more systems than the original project scope suggests.
• An application retirement can uncover hidden downstream dependencies.
• A shared data-model change can alter reporting, integrations, compliance workflows, and customer-facing applications.
• A security patch or infrastructure upgrade can require unexpectedly broad testing.
• A new AI capability may depend on systems, data flows, and access patterns that were not visible in the initial use case.

When indirect dependencies are not understood, programs often discover their true complexity late: during testing, cutover planning, production incidents, or post-launch remediation.

How enterprise architecture analysis improves modernization decisions

Enterprise architecture analysis does not replace engineering expertise, portfolio management, or business judgment. It gives those functions better evidence.

It can improve decisions in several high-value areas.

Application rationalization

An application inventory can identify redundant, aging, or low-value systems. Dependency analysis helps determine whether an application can actually be retired without creating disproportionate disruption elsewhere.

Cloud migration and platform modernization

Migration plans should account for more than application ownership and infrastructure readiness. Leaders need to understand shared dependencies, tightly connected application clusters, and the likely testing and coordination requirements of each migration wave.

Mergers, acquisitions, and technology integration

After an acquisition, organizations need to understand not only which applications overlap but how each environment is structurally organized. Dependency analysis can help identify integration risk, shared-service dependencies, and areas where consolidation will be more difficult than an inventory suggests.

Cybersecurity and resilience

Architecture visibility helps teams identify shared infrastructure and highly connected components where a failure, vulnerability, or outage could create broad impact. It also helps leaders plan resilience investments according to systemic exposure.

AI and data transformation

AI initiatives depend on applications, data, interfaces, identity systems, infrastructure, and governance. A dependency-based view of enterprise architecture helps reveal where new AI capabilities will encounter structural constraints and where changes could introduce enterprise-wide risk.

How should leaders use this analysis?

The goal is not to create a larger architecture repository or a more elaborate diagram.

The goal is to make better technology and investment decisions.

A practical approach includes five steps:

1. Create or validate the architecture inventory. Capture the relevant business, application, data, integration, and infrastructure components.
2. Map direct dependencies. Identify what each component uses, supports, hosts, or exchanges data with.
3. Analyze indirect dependencies. Determine how a change could propagate through chains of connected components.
4. Identify architectural hotspots. Focus on large tightly connected cores, highly shared components, and dependencies associated with delivery, cost, resilience, or security risk.
5. Use the findings in investment and change decisions. Apply the analysis to modernization roadmaps, migration waves, retirement plans, risk assessments, and program governance.

The result is a more honest picture of the enterprise. Leaders can distinguish between systems that are merely old and systems that are structurally difficult to change. They can see where a seemingly contained initiative will require enterprise-level coordination and where a focused intervention can create meaningful improvement.

Frequently asked questions

What is the difference between enterprise architecture documentation and enterprise architecture analysis?

Documentation records the systems, components, and relationships that exist. Analysis uses those relationships to answer decision questions: where change will propagate, which components are structurally central, what areas create the most risk, and how to prioritize modernization work.

What does a high propagation cost mean?

A high propagation cost means a change to one component is likely to affect a larger portion of the architecture through direct and indirect dependencies. It is a signal that changes may require broader planning, testing, coordination, and risk management.

Does a large architectural core mean an enterprise architecture is broken?

No. Many enterprises have central platforms, shared services, and integrated application environments by design. A large core is not automatically a problem. It is a structural fact that should inform modernization strategy, change planning, resilience investments, and technical governance.

Why are indirect dependencies important?

Indirect dependencies reveal change paths that may not be visible in an application inventory or conventional architecture diagram. A component with few direct connections can still have broad impact if it connects into a highly interdependent area of the enterprise.

Can enterprise architecture analysis help with AI transformation?

Yes. AI initiatives interact with existing applications, data, identity, integrations, infrastructure, and governance. Dependency analysis helps organizations understand the structural constraints and potential change impact before new AI-enabled capabilities are scaled across the enterprise.

Does Silverthread analyze enterprise architecture or software architecture?

Silverthread’s CodeMRI® Suite measures architecture at the software system and portfolio level: core size, complexity, and modernization cost and risk within and across codebases. That analysis is complementary to enterprise-architecture mapping. An enterprise view identifies which systems matter structurally; a code-level view establishes what it will actually cost and how long it will take to change them.

From application inventory to architectural intelligence

Enterprise architecture should do more than document the technology estate.

It should help the organization understand the consequences of change.

When business capabilities, applications, data, and infrastructure are viewed as an interconnected system, leaders can identify hidden dependencies, plan modernization more realistically, and prioritize investments based on structural evidence.

That is the shift from enterprise architecture as documentation to enterprise architecture as decision support.

Silverthread helps organizations make complex software and enterprise architectures visible, measurable, and actionable—so technology leaders can understand change risk and focus modernization efforts where they will have the greatest impact.

Silverthread has analyzed more than 7,000 codebases across commercial enterprises, government agencies, and Fortune 500 organizations, using measurement techniques developed by its founders at MIT and Harvard Business School. If you are planning a modernization program, cloud migration, application rationalization, or post-acquisition integration and want to know where change risk actually sits, a CodeMRI® Discovery assessment is the place to start.

Source

Lagerström, R., Baldwin, C., MacCormack, A., and Dreyfus, D. “Visualizing and Measuring Enterprise Architecture: An Exploratory BioPharma Case.” Harvard Business School Working Paper 13-105 (2013).

‍