Seeing an IT mess is one thing, but actually owning it is another. As enterprises rush to adopt generative models, gaps in the foundational value chain often slow or undermine the initiatives that matter most, namely, managing and governing IT resources. Maintaining a clean asset environment is rarely glamorous, and it seldom earns executive bonuses. Without a function with clear authority to enforce standards across the full ITAM-CMDB-EAM chain, basic asset management falls behind more visible priorities, and the AI capabilities layered on top inherit every gap beneath.
We spoke with José Freitas, Lead Enterprise Architect at the International Air Transport Association (IATA), to explore who actually owns that breakdown and what it takes to fix it. With more than 15 years of experience spanning aviation, banking, manufacturing, and telecommunications with companies like IBM, Freitas argues that most organizations misdiagnose where the value chain actually fractures.
"Most AI and data initiatives fail at the first step: there is no trusted system of record or solid data foundation beneath them, and no operating model or governance to turn pilots into scalable, value-generating solutions," he says. "Without a reliable data and asset backbone, you are just scaling uncertainty faster."
That foundation breaks in three places: the data you cannot trust, the governance nobody owns, and organizations that prevent either from being fixed.
Tech sprawl starts from the bottom up. Teams buy what they need to fix immediate problems, leaving a fragmented setup in their wake. No enterprise exists without legacy, which means governing sprawl requires a layered response: detection and remediation for what already exists, continuous discovery to prevent drift from compounding across the existing landscape, and design-before-execution governance gates applied strictly to new products and projects.
Infrastructure and security teams often operate under mandates that reward time-to-market, which can systematically deprioritize shared visibility. The result is fractured ownership.
"Most organizations don't have a visibility problem; they have an asset truth problem. If you can't trust your inventory, everything else is downstream noise," Freitas says.
That fractured ownership breaks the IT value chain at its most consequential point: the handoff between raw asset discovery and the governed configuration data on which everything depends. ITAM tools serve as the discovery engines of the value chain. The CMDB sits on that foundation and should reliably describe how assets relate to services, owners, and risk classifications that EAM tools and C-level decisions can trust. In practice, IT teams treat the CMDB as another automated system not a curated model of the enterprise model. Closing the CMDB data gap demands ongoing human stewardship over what the data means, not just that it exists. AI agents are accelerating the discovery, reducing the manual effort required to detect new assets, identify drift, and flag configuration gaps, but they do not replace the governance judgment required to certify what the data actually means.
"CMDBs fail not because the concept is wrong, but because they're treated as static tools instead of curated, living systems that require governance and ownership," says Freitas.
Because internal architecture teams often lack the organizational authority to enforce this curation, some organizations default to external consultants to implement IT service management platforms. External partners can accelerate delivery. But without an internal counterweight, they leave behind systems that the organization can operate but not govern or evolve. Weak CMDB foundations mean that every AI capability, every EAM investment, and every board-level technology decision is built on data no one has formally certified as true.
For Freitas, the value chain is sequential and unforgiving. ITAM feeds the CMDB with continuously discovered, versioned asset data. The CMDB translates that into governed configuration records that power downstream systems such as IT Service Management, Compliance, and Security Reporting. If the ITAM and CMDB are poorly maintained, even the best EAM platform will not deliver full value. "Even if you have all the bells and whistles, you will definitely not be able to use them," he says. A mature EAM platform built on ungoverned CMDB data does not reduce complexity; it just indexes it.
That same logic applies directly to AI. Without a solid handle on assets, dependencies, and ownership, automated data governance remains aspirational. Enterprises often frame the problem as analytics or AI readiness, but the real gap is foundational: fragmented systems of record across ERP, CRM, and infrastructure.
This does not mean AI investment must wait for perfect data foundations; no enterprise achieves full unification before deploying capability. It means the governance layer must advance in parallel with the AI layer, not trail behind it. Where foundations are ungoverned, AI does not resolve inconsistency, but it industrializes it.
To navigate this landscape, Freitas relies on a two-tiered architectural discipline: enforcing strict standardization at the governance layer (common data classification, asset ownership definitions, and CMDB schema) while maintaining deliberate diversity in the mission-critical infrastructure layer underneath it. The governance layer is what makes the value chain trustworthy. The infrastructure layer is what enables it to operate across jurisdictions and regulatory environments.
Pressure to consolidate on a single platform is real, and often driven by vendor familiarity rather than architectural fit. The assumption is that a sufficiently feature-rich platform will compensate for foundational immaturity. It will not.
"If the workload requires a bulldozer, insisting on a Prius does not make the problem simpler. Specialized problems need specialized tools. Choosing familiar platforms over fit-for-purpose architecture is how organizations scale the wrong answer faster."
Infrastructure diversity is a requirement. The risk is that diversity without a strict governance contract above it becomes sprawl by another name. Regional and regulatory constraints make global standardization impractical by definition. A company cannot run cloud infrastructure in China exactly as it does in Europe or the United States without addressing sovereign AI data management and local partnership requirements. Nor can it easily shift sensitive data in and out of sanctioned jurisdictions without encountering data sovereignty constraints.
Diversifying infrastructure and enforcing governance discipline both require organizational authority that many architecture teams simply lack. Freitas illustrated the hurdle with a simple scenario: an enterprise architect walks into a mining facility and shows a 30-year domain expert a business capability map. Without proper contextualization and explicit sponsorship, that conversation does not gain traction. It does not even begin.
Freitas pointed to one manufacturing engagement where the dynamic was different. The company was privately owned, and the CIO took a proposal to the owner and board to rationalize systems. After approving the initiative, the owner personally instructed division leaders to proceed with the work and asked each unit to appoint a designated point of contact. That clear instruction meant the architecture team arrived with an explicit mandate.
"If you don't have a clear, mandated, top-down push, everybody will always tell you they have more important things to do," Freitas says. "And we have to accept that; it's our obligation to show them the value of engaging with us."
Ultimately, much of the unmanaged enterprise sprawl is not a failure of individual competence. It is a set of predictable outputs of an organizational structure that places the architects responsible for governance below the delivery functions whose decisions they are meant to shape. In many enterprises, the architects tasked with governing the setup sit low in the hierarchy, reporting through delivery functions whose decisions they are meant to influence. They are often outranked by delivery team leaders, which makes it harder for their assessments to reach the C-suite unchanged.
Information rarely travels neutrally up a delivery-focused chain of command; each layer translates it through delivery priorities rather than governance accuracy. As Freitas says, "The people with decision authority are insulated from the technological reality of their organizations and with no mechanism to change that. Some of them have no background in IT, and they have no factual data to act on." When architects report through hierarchies, he adds, there is always "a layer in the middle that does whatever translation is required to convey their own message."
For Freitas, the structural remedy is clear. Risk and governance functions work best when they have enough independence to act as a counterweight to delivery. Enterprise architecture should be treated the same way, with a direct reporting line that bypasses the delivery chain it is meant to govern. To get unvarnished data to the C-suite, companies must design enterprise architecture as an independent reporting function, much like internal audit or corporate risk.
As organizations build out enterprise AI governance frameworks, Freitas sees structural independence not as an abstract ideal but as a practical precondition that makes every other investment credible. Regulated industries get that pressure from the outside from auditors, regulators, and mandatory frameworks. Unregulated or lightly regulated organizations must manufacture it internally.
Giving enterprise architecture a direct line to senior leadership, separate from bypassing day-to-day delivery, increases the odds that unbiased assessments reach decision-makers. It also makes it easier to align AI plans with governance functions such as risk, security, and compliance. Without that structural independence, the diagnosis reaches the C-suite only after it has been filtered, and filtered diagnoses lead to confident decisions based on incomplete data. The complexity that no one owns keeps compounding quietly.
At the end of the conversation, Freitas returned to what he sees as the real subject beneath it all: "If you don't have a clear, mandated, top-down push to get a foot in the door, everybody will always tell you they have more important things to do."
The obstacle is rarely technical illiteracy; it is that no one has been given both the authority and the accountability to make governance their actual job.
