Connected Systems

Definition

In business architecture, connected systems refers to the discipline of tracing which IT applications, platforms, and technical assets support which business capabilities, value streams, and processes. It is the connective layer between what the business does (captured in capability maps and value stream maps) and how technology enables it (captured in application portfolios and technology architecture). Practitioners often call this exercise capability-to-application mapping or capability-to-system cross-mapping, and it typically results in a matrix or heat map showing, for every capability, which systems provide support and how well. Connected systems mapping is distinct from a simple application inventory or CMDB (configuration management database) listing. An inventory tells you what exists; connected systems mapping tells you why it exists in relation to the business — which capability a system serves, how critical that support is, and whether multiple systems are redundantly serving the same capability. This relational view is what makes it valuable for investment decisions rather than just asset tracking. It's important to draw a boundary: connected systems mapping does not replace technology architecture (the TOGAF domain covering applications, data, and infrastructure in depth). Instead, it sits at the intersection of business and technology architecture, providing the traceability that lets architects and executives reason about business impact when a system changes, fails, or needs retirement.

Origin & Context

The concept draws on TOGAF's Architecture Development Method, which explicitly calls for linking the Business Architecture phase to the Application and Technology Architecture phases through traceability artifacts. The Business Architecture Guild's BIZBOK Guide formalized this further with its concept of cross-mapping capabilities to other architectural domains, including IT systems, as a core business architecture deliverable.

Why It Matters

CIOs and enterprise architects rely on connected systems mapping to identify redundant or overlapping applications before committing to costly modernization or cloud migration programs. Business architects use it to make the business case for retiring legacy systems by showing exactly which capabilities depend on them and how critical that dependency is. During M&A integration, connected systems mapping is often the single fastest way to spot duplicate platforms across merging entities and prioritize rationalization. Without this mapping, technology investment decisions get made on system age or vendor pressure rather than actual business value delivered.

Common Misconceptions

Myth: Connected systems mapping is the same thing as an application inventory or CMDB.

Reality: An inventory lists what systems exist. Connected systems mapping is relational — it shows which capability each system supports, how critical that support is, and where multiple systems overlap on the same capability. The value is in the relationship, not the list.

Myth: This is purely a technical architecture concern and doesn't require business architect involvement.

Reality: Business architects are essential because they define the capability taxonomy that gives the mapping meaning. Without a stable, business-validated capability map, connected systems mapping collapses into an arbitrary technical exercise disconnected from strategy.

Myth: Once you've mapped capabilities to systems, the artifact stays accurate indefinitely.

Reality: Systems get replaced, capabilities get restructured, and mergers introduce new platforms constantly. Connected systems mapping requires ongoing governance, ideally supported by a living platform rather than a one-time spreadsheet exercise.

Practical Example

A mid-size insurer had grown through several acquisitions, each bringing its own claims processing system. The enterprise architecture team suspected redundancy but had no way to quantify it. Working with business architects, they built a capability map centered on the Claims Management capability and its sub-capabilities, then cross-mapped each against the applications actually in use. The resulting heat map revealed four separate claims systems partially supporting the same sub-capabilities, with inconsistent data models and duplicated maintenance costs. Armed with this connected systems view, the CIO built a rationalization business case prioritized by capability criticality rather than system age or contract renewal dates. The business architecture team also used the mapping to identify which capabilities had no adequate system support at all, informing the next investment cycle. The exercise turned a vague sense of technical debt into a defensible, capability-driven roadmap that both business and technology leaders could align behind.

Industry Applications

Financial Services

Mapping regulatory reporting capabilities to the systems that generate compliance data, ensuring auditors and regulators can trace requirements to specific technical sources.

Healthcare

Connecting patient care and clinical documentation capabilities to EHR and interoperability platforms to identify integration gaps affecting care coordination.

Manufacturing

Mapping supply chain and production planning capabilities to ERP modules across plants, often surfacing standardization opportunities after facility acquisitions.

Related Terms

• Heat Map: a common visualization technique used to display connected systems mapping results
• Application Portfolio: the technology-side inventory that connected systems mapping links to business capabilities