On the surface, they seem to be two sides of the same coin, yet Enterprise Architecture (EA) and Configuration Management Database (CMDB) historically operated in separate silos. EA tools provide a top-down, strategic view of the business, connecting applications and technology to business capabilities and future-state plans. CMDBs, on the other hand, offer a bottom-up, operational view, tracking the physical and virtual assets that make up the current IT environment.
The idea of these two powerful systems merging isn’t just a fantasy; it’s the next logical step toward a truly unified enterprise. However, this convergence can only happen when we overcome two significant hurdles.
CMDB Tools Must Accommodate a Future State Profile
The core function of a CMDB has always been to document the “as-is” state of an organisation’s IT infrastructure. It’s a snapshot in time, a detailed inventory of what exists right now, or has previously existed. This is incredibly valuable for IT operations, providing the data needed for incident management, change management, and asset tracking. The problem is that this focus on the present leaves a critical gap.
An EA tool’s primary purpose is to help an organisation plan for the “to-be” state. It allows architects to model future scenarios, design new applications, and map out technology roadmaps.
For these two worlds to merge, CMDB tools must evolve beyond their traditional role. They need to incorporate into their purview the management of a “future state” within their application portfolio. This would mean:
- Modelling Changes: The CMDB-EA should be able to store and represent not only current assets but also planned-for, and potential changes, on strategic timescales – i.e beyond CAB – noting that there may be many possible futures
- Enabling Impact Analysis: With a future-state view, the CMDB-EA can perform more robust impact analysis, helping IT teams understand the consequences of a change before it happens.
This transformation would turn the CMDB from a static inventory into a dynamic blueprint that is constantly being updated with a strategic future in mind.
A Common Language is Essential
The second, and perhaps more significant, challenge to the CMDB-EA merger is the lack of a shared language. The vast majority of CMDBs are proprietary, locked into the specific data models and formats of their vendors. One vendor’s definition of a “business application” may be completely different from another’s.
This creates a serious data interoperability problem. An EA tool, which may be a different vendor’s product, can’t easily consume and make sense of the CMDB’s data. It’s like trying to have a conversation where one person is speaking English and the other is speaking Mandarin.
A common language is a critical prerequisite for a truly integrated ecosystem. This could take the form of:
- Standardised Data Models: A universal, open-source data model for CIs and their relationships would allow for seamless data exchange between different tools. Standards like the Common Service Data Model (CSDM) are a step in the right direction, providing a blueprint for how to structure CMDB data.
- Open APIs and Connectors: Vendors need to embrace open APIs that make it easy for other systems to read and write data, beyond clunky, one-off integrations.
- Shared Naming Conventions: Simply agreeing on a common vocabulary for object types—such as “Application,” “Service,” or “Technology Component”—would prevent a great deal of confusion and data reconciliation work.
The Organisational Challenge: The Tug-of-War for Data Ownership
Even with a common language and future-state capabilities, a successful merger hinges on acknowledging a crucial organisational reality: much of the same data will continue to be ‘claimed’ by separate teams that often work in different ways and with different priorities, leading to a continuous tug-of-war.
- IT Operations: a “business application” is a set of Configuration Items (CIs) in the CMDB—the servers it runs on, the databases it connects to, and the network components it uses. Their primary concern is accuracy for the purpose of incident management, change management, and asset tracking.
- The EA Function: a “business application” is a strategic asset that fulfils a business capability. They are concerned with its business value, its lifecycle, its alignment with strategy, and its total cost of ownership. They need to understand what the application does for the business, not just what technical components it comprises.
A merged system doesn’t change this fundamental conflict; it makes it a permanent part of the day-to-day process. The organisational difficulty lies in getting these two separate teams to agree on a single system of record and a common process for data governance, where a single data element can have different owners for different attributes. It requires a significant cultural shift for teams accustomed to operating independently.
Achieving this requires a robust data governance framework that clarifies:
- Who owns the data element at the master data level?
- What are the attributes of that data element that are owned by each team? For instance, the EA team might own the business_owner and strategic_fit attributes of an application, while the IT Operations team owns the operational_status and relationships to infrastructure.
Without a clear, agreed-upon model for shared data ownership, the CMDB-EA merger will fail, leading to inconsistent data, constant reconciliation work, and a lack of trust in the system’s ability to provide a single, unified view of the enterprise. The technical convergence is only possible if the organisation can first solve this deeply ingrained and complex political challenge. As a future plan this is surely in the realm of the EA, and their tools, but the CMDB world appears to be heading the charge. Is this to the detriment of the Enterprise Architect?… time will tell!
