The Commercial Model That Changed Everything
Most consulting engagements are structured to reward delivery, not outcomes. You scope the work, you staff the project, you bill the hours, and when the engagement ends, the responsibility for whether it worked passes entirely to the client. The incentives are misaligned in a way that everyone acknowledges and almost nobody changes.
The São Paulo engagement was structured differently. We had entered into a profit-sharing arrangement with the client — one of Brazil’s largest diversified conglomerates — that tied our commercial outcome to the business outcomes we were supposed to deliver. If the Enterprise Architecture practice we built improved operational efficiency and reduced technology costs, both parties benefited. If it didn’t, we felt it too.
This arrangement changed the character of every decision I made. Recommendations that would have been commercially safe under a time-and-materials model — phased implementations that stretched engagements, technology choices that favored our own product stack, governance frameworks complex enough to require ongoing consulting support — became bad ideas the moment our incentives were aligned with the client’s. When your fees are tied to the client’s efficiency gains, you stop optimizing for billable scope and start optimizing for results. It is a more uncomfortable way to work. It is also a more honest one.
I mention this first because it shaped everything that followed. An EA practice built by a vendor who shares the downside looks different from one built by a vendor who doesn’t.
The Problem: A Conglomerate Operating as a Collection of Fiefdoms
The client’s portfolio spanned manufacturing, finance, retail, and technology — divisions that had grown through acquisition and organic expansion over decades, each with its own systems, processes, governance structures, and IT teams. This is a common pattern in large conglomerates, and it creates a specific class of problem: the organization as a whole cannot move at the speed of any of its parts, because the parts don’t share infrastructure, data, or vocabulary.
The practical consequences were visible in the cost base and the product roadmap. Technology costs were higher than they should have been because similar capabilities had been built independently across multiple divisions. Projects that required cross-divisional coordination — which included most significant strategic initiatives — took longer than they should because there was no shared understanding of how the systems connected, and no agreed-upon way to describe what each division needed from the others.
Enterprise Architecture was the proposed solution. The discipline, practiced properly, creates exactly what was missing: a shared map of the organization’s technology landscape, a common vocabulary for describing business capabilities and their supporting systems, and a governance mechanism for making cross-divisional decisions without requiring every decision to escalate to the executive level.
The challenge was that “Enterprise Architecture” is also one of the most reliably oversold and underdelivered disciplines in technology consulting. Every dysfunctional EA practice in existence was built by someone with good intentions and a comprehensive framework. Intent and framework are not sufficient. Execution is what separates EA as a genuine organizational capability from EA as an expensive shelf document.
Building the Capability Map
The first concrete artifact we produced was a business capability model — a structured description of what the organization does, independent of how it currently does it. Not org charts, not system diagrams, not process maps. Capabilities: the stable, durable things a business does that don’t change when systems are replaced or divisions are restructured.
For a diversified conglomerate, this is a significant modeling exercise. The capability set of a manufacturing division and a financial services division overlap in areas like customer management, procurement, and reporting, and diverge sharply everywhere else. The model had to be specific enough to be useful and abstract enough to remain valid across divisions with fundamentally different business models.
Once the capability model existed, we could do something that had not previously been possible: map the technology landscape against it. For each capability, we could identify which systems supported it, how many redundant implementations existed across divisions, where significant investment gaps were creating operational risk, and where shared services could replace siloed solutions. The resulting heat map was the first time the organization had seen its own technology portfolio in terms of business function rather than system inventory. It was a genuinely new way of looking at a landscape they had been operating in for decades, and it changed several investment decisions almost immediately.
The capability model also became the shared vocabulary I had been trying to establish. When business stakeholders and IT teams had a common language for describing what was needed — not “we need a new CRM” but “we need improved capability in customer relationship management, specifically in post-sale service tracking” — the conversations became more precise and the gap between business intent and technical implementation became narrower.
The Outage That Proved the Architecture’s Value
Enterprise Architecture has a credibility problem: its value is largely invisible under normal operating conditions. You cannot easily demonstrate to a skeptical CFO that the architecture governance you’ve been practicing for eighteen months is why certain problems haven’t occurred. The absence of problems is not a compelling narrative.
What changes the narrative is a crisis handled well.
Midway through the engagement, a major system failure threatened to derail a significant product launch. The failure cascaded in a way that was initially opaque — a platform going down had consequences that weren’t immediately traceable because the dependencies between systems weren’t documented in any accessible way. In most organizations at that stage, the response would have been a war room, manual tracing of system relationships by engineers who carried the knowledge in their heads, and days or weeks of diagnosis before the remediation could begin.
We had the dependency map. The current-state architecture documentation we had produced as foundational EA work — the system inventory, the integration diagram, the data flow documentation — meant we could identify affected systems, trace the blast radius, and sequence the remediation within hours rather than days. The product launch was preserved with a matter of days to spare.
This incident did more for EA’s internal credibility than any presentation I gave or framework I explained. The CFO who had been politely skeptical about architecture governance attended the post-incident review, saw how the resolution had worked, and became the practice’s most effective internal advocate. Credibility earned under pressure is more durable than credibility built through endorsement.
The Politics of Standardization
The technical work was tractable. The organizational work was harder.
Each division’s IT function had operated independently for years, with the authority to make its own technology decisions and the budget to implement them. Enterprise Architecture, in practical terms, represents a partial transfer of that authority to a central function. Standards that constrain local technology choices, governance processes that require cross-divisional review, shared service mandates that replace locally controlled systems — all of these reduce the autonomy that divisional IT leaders had previously held. The resistance this generates is rational, not irrational. People protect their authority because their authority is real and valuable.
The approach that worked was not to argue for centralization as an organizational principle but to demonstrate the specific value of each shared service or standard before requiring adoption. Where we could show that a shared procurement platform would reduce costs in a specific division by a specific amount, the conversation shifted from “you’re losing control” to “you’re gaining efficiency.” Where we couldn’t make the case concretely, we reconsidered whether the standardization was justified.
The governance framework we built was deliberately minimal. Many EA governance frameworks fail because they attempt to control too much, generate too much process overhead, and ultimately get bypassed by teams who can’t afford to wait for architectural review on every decision. We built a tiered model: significant architectural decisions — new platforms, major integrations, cross-divisional data sharing — required review. Everything else was guided by published standards that teams could apply without approval. The goal was to govern the decisions that mattered at a level that didn’t make the framework an obstacle to getting work done.
What the Profit-Sharing Model Revealed
By the end of the engagement, both parties had seen the commercial arrangement validated. The efficiency gains from eliminated redundancy and shared services produced measurable cost reductions. The improved cross-divisional coordination shortened project delivery timelines. The metrics were clear enough to make the profit-sharing calculation straightforward.
But the more durable lesson was about the structure of the arrangement itself. The profit-sharing model forced a kind of rigor that standard consulting engagements rarely produce. When your fee depends on the outcome, you invest more carefully in understanding what will actually drive the outcome rather than what will satisfy the client’s immediate expectations. You have less tolerance for architectural decisions that look good on paper but add operational complexity. You push back harder on scope that won’t move the efficiency needle.
If I were advising an organization on how to structure a major architecture engagement today, I would advocate for outcome-linked pricing. It is uncomfortable for both parties at the contracting stage. It produces better results.
Three Things That Carry Forward
A business capability model is worth building before anything else. It provides the shared vocabulary that makes every subsequent conversation between business and IT more productive, and it creates the foundation for investment prioritization that cannot exist without it. It is also the deliverable that survives the longest — a well-constructed capability model remains useful through multiple technology generations.
EA’s credibility depends on a crisis going well. You cannot manufacture this, but you can ensure that when a crisis occurs, the foundational artifacts — dependency maps, system inventories, integration documentation — are current and accessible. The practice that maintains this discipline is the practice that survives long enough to matter.
Governance fails when it tries to control too much. The EA frameworks that generate the most documentation and require the most process are usually the ones that get bypassed. Design governance for the decisions that actually require it, and publish clear standards for everything else. Less control, applied consistently, produces better outcomes than comprehensive control that nobody follows.
The São Paulo engagement ended. The capability model remained in use. That is the most honest measure of whether the architecture practice was real or cosmetic — not whether the engagement was well-regarded, but whether what it produced continued to do useful work after the consultants left.
