Jack Dorsey and Roelof Botha recently argued that corporate hierarchy was never a management philosophy but a workaround. A single leader can coordinate only three to eight people, so organizations added layers to move information up and down a chain of command. On this reading, every structure from the Roman legion to the McKinsey matrix has solved the same problem - coordination under a fixed human bottleneck - with the same instrument. The claim is that a system can now maintain a continuously updated model of an entire business and coordinate work across it, making the routing layer obsolete. Block is reorganizing around exactly this logic, replacing the pyramid with three roles: people who build, people who own specific outcomes, and player-coaches who develop others while staying close to the work.

The argument is clean, and the historical framing is largely correct. The interesting question is whether the proposed replacement holds under the conditions of an ordinary enterprise?

The assumption that carries the whole thesis

Everything rests on one claim:

The coordinating context, managers used to carry, can be relocated into a system.

Block calls this a company world model, built continuously from machine-readable artifacts - decisions, code, plans, progress - because the company is remote-first and records almost everything by default. Where work already exists as structured signal, an AI can plausibly maintain a live picture of what is being built, what is blocked, and where resources sit. Block pairs this with a customer world model fed by transaction data, on the reasonable premise that money is a more honest signal than surveys or clicks.

These are specific preconditions, not general ones. They are also where most enterprises diverge from the example.

Why the context does not transfer cleanly

In a typical enterprise landscape, the model of the business is exactly the artifact that has never existed in usable form. Systems of record are fragmented across ERP, CRM, ticketing, and a long tail of spreadsheets and shadow tools. The same entity - a customer, a product, an order - carries different identifiers and incompatible semantics in each. RAG over that estate retrieves inconsistency at scale, and no context window is large enough to reconcile meaning that was never agreed in the first place. The hard part of an enterprise data model is about semantics, ownership, and trust.

There is a second problem the routing metaphor understates. Middle managers do not only relay information. They absorb exceptions, resolve ambiguity, and carry tacit knowledge that lives in no repository: who to call, which policy is actually enforced, why a given process quietly deviates from its documentation.

Relocating coordination into a system assumes this context is legible and reasonably complete. In most organizations it is neither, and the gap tends to surface precisely at the moments that matter most.

The economic and governance dimension

Even where the technical preconditions hold, the operating model shifts risk rather than removing it. A system that composes actions across capabilities through tool calling - issuing a loan, adjusting a repayment schedule, moving money - is exercising authority that previously sat with an accountable human. That authority needs boundaries, audit trails, and reversibility. The cost of a wrong decision does not disappear when a manager leaves the loop; it migrates into architecture and governance, where it is easier to overlook and harder to attribute after the fact.

The economics deserve equal sobriety. Maintaining a continuously updated world model is not a one-time build. Inference, integration, data-quality remediation, and evaluation are recurring costs, and they scale with ambition rather than with headcount. For many organizations the honest comparison is not a leaner structure against a heavier one, but a new and volatile cost base against a known and depreciating one.

The question underneath the reorganization

Dorsey and Botha close with the question that actually matters, and it is worth restating in architectural terms: does your organization understand something genuinely hard to understand, and is that understanding deepening over time? If not, AI here is a cost-reduction story - fewer people doing the same work, with margins that improve for a while and then compress.

If the answer is yes, the calculus changes. The value lives in the model of reality the company maintains, and org structure becomes downstream of information architecture rather than of reporting convenience. That reframing is defensible. It also raises the bar considerably. A company world model is only as good as the data foundations, semantic discipline, and governance beneath it, and those are precisely the areas most enterprises have historically underfunded.

The decision, then, is not whether to flatten the org chart. It is whether the underlying system landscape can carry the context a hierarchy currently carries - and what it would concretely take to make that true. For most organizations that is an architecture programme measured in years, not a reorganization announced in a memo. The org chart may well become a strategic question. It becomes one through the data model, not around it.

This blog post draws on concepts from From Hierarchy to Intelligence by Jack Dorsey and Roelof Botha, published on Block webpage.

My content is carefully prepared, crafted and takes anywhere from a few days to several weeks. I sacrifice my free time to create high quality content for you.

The easiest way you can support ♥️ me? Subscribe, like and share this article.

If you like to know more about me, please contact me directly or visit my LinkedIn profile.

A plain-language guide to knowledge graphs, semantic layers, and why Enterprise Architecture was on the right path from the very beginning.

There is a question that sounds simple but keeps tripping up organisations spending millions on data infrastructure:

Why can't AI just answer the question? The data is all there.

The data is there. That's true. But data and meaning are two different things. Most organisations have invested heavily in the first while quietly ignoring the second.

This piece is about that gap, why it matters more than ever, and what closing it actually looks like in practice.

Imagine you're a very smart new employee

You just joined a company. You're brilliant - you've read millions of books, you speak perfectly, and you can do maths in your head instantly. But it's your first day.

Your manager walks up and says:

"Can you check if the conversion was good last quarter?"

You freeze. Not because you're stupid. But because you don't know:

• Does "conversion" mean sales leads turning into customers? Or the euro-to-dollar exchange rate? Or a file being saved in a different format?

• What counts as "good"? Good compared to last year? Good compared to a competitor? Good for which team?

• What is "last quarter" in this company? Do they run January–March, or is their fiscal year different?

You have intelligence but no context. And without context, you cannot reason correctly. You'd just be guessing.

That new employee is the AI.

This is not a flaw in the technology. It is an honest reflection of what AI systems are: extraordinarily capable reasoners that know nothing specific about your organisation unless you tell them. They are brilliant generalists dropped into a room full of specialist filing cabinets, with no map and no guide.

The filing room problem

Picture your organisation's data as a large room full of filing cabinets. Each one is labelled and well-organised inside. The sales cabinet has sales data. The finance cabinet has revenue data. The marketing cabinet has campaign data.

But here's the thing: The cabinets don't talk to each other.

The sales cabinet doesn't know it's related to the finance cabinet. Nobody wrote on the outside: "Hey, when a sale closes here, it eventually shows up over there as revenue - usually 30 days later."

That connection exists only in the head of the finance director who's been there 12 years.

So when the AI is asked "Did our Q3 marketing campaign make us money?" - it can open each cabinet just fine. It can read every column, every row, every figure. But it doesn't know why they're related, in what order things flow, or what the words inside actually mean in this company's language.

It will answer. It will sound confident. But it will be guessing.

The map on the wall

Now imagine someone - typically a seasoned Enterprise Architect, a data steward, or a senior analyst who's been around long enough to know where all the bodies are buried - sits down and draws a map.

On that map they write things like:

• "Conversion" here means a lead becoming a paying customer - see the Sales cabinet, column 4.

• "Marketing spend influences pipeline revenue - but with a 6-week delay."

• "Net revenue excludes refunds and VAT. It is NOT the same as gross revenue."

• "When the CFO asks this question, she means by product line. When Sales asks it, they mean by region."

That map doesn't replace the filing cabinets. The data still lives where it lives. But the map tells anyone - human or machine - what everything means, how it connects, and why.

This is what a semantic layer does. In more technical circles it is called a knowledge graph, an ontology layer, or a context graph. The name matters less than the function: it is your organisation's reasoning, written down in a form that machines can read.

Why AI specifically needs this

AI systems are, at their core, very fast pattern matchers trained on enormous amounts of language. They learned from the internet - which means they learned many possible meanings of every word.

Without your specific map, they will default to the most common meaning, not your meaning:

• "Pipeline" might be read as a water pipe, or a software deployment process - not your sales pipeline.

• "Net" might be a fishing net, or the internet - not net revenue after refunds.

• "Conversion" might be currency exchange - not the metric your marketing team lives and dies by.

The semantic layer is how you tell the machine: "In this organisation, these are the rules."

Once it has that map, it stops guessing. It knows that when the CMO asks about conversion, she means leads to customers, measured against the target set in the annual plan, compared to the same period last year. It knows the 6-week delay between campaign spend and revenue recognition. It knows that "good" means above 3.2%, because that's the threshold your business defined.

It doesn't guess any of that. It reads it from the map.

This is an Enterprise Architecture problem in disguise

Here is what makes this interesting for anyone who has worked in Enterprise Architecture: this is not a new problem.

EA frameworks like TOGAF and ArchiMate have been making exactly this argument for decades. Define your business capabilities. Map your information flows. Document your canonical data definitions. Surface the reasoning behind decisions, not just the decisions themselves. Keep the logical view of your organisation - what things mean and how they relate - separate from the physical view of where data actually lives.

The knowledge graph is that logical view, made machine-readable.

Which means organisations that have done their EA work carefully - that have a business glossary, a capability model, a proper information architecture - are sitting on the raw material for a knowledge graph already. They have a head start that companies who skipped that work and went straight to building data platforms do not.

The urgency is new. The discipline is not.

What is new is that machines now need to read the output. An EA deliverable that only humans ever consulted was better than nothing. But today, if your organisational reasoning isn't encoded in a form that a machine can traverse, query, and reason over - it effectively doesn't exist for the systems you're asking to run your business.

What "meaning" actually looks like in practice

To make this concrete: meaning in this context is not philosophy. It is three very specific things, working together.

The definition of your terms. Not the dictionary definition - your organisation's definition. What does "active customer" mean in your business? Is it anyone who bought in the last 12 months? The last 6? Anyone with an open contract? This definition lives differently in Finance, in Sales, and in Customer Success - and a machine needs to know which definition applies and when.

The relationships between your concepts. Campaign spend influences pipeline revenue. Net revenue drives bonus disbursement. NPS is a leading indicator of churn. These relationships are the organisational knowledge that nobody ever wrote down because everyone assumed everyone else already knew it. The semantic layer makes them explicit and traversable.

The context of who is asking. A CFO and a regional sales manager looking at the same underlying data need different framings, different aggregations, and different vocabulary. The semantic layer can hold those differences - not to rebuild personalisation from scratch, but to ensure that when the AI retrieves and presents information, it does so in the right frame for the right person.

Together, these three things transform data from a collection of facts into something a machine can actually reason with.

In three sentences

Data is the facts. Meaning is the story that connects the facts. AI can read the facts perfectly — but it needs you to write down the story first.

That is what a knowledge graph does.

And that is why, from an Enterprise Architecture perspective, this is not really a technology problem. It is a knowledge management problem that EA has been trying to solve for decades - with new urgency now that machines need to read the answer too.

The organisations that treat this as a quick technical fix will build pipelines that answer questions confidently and incorrectly. The organisations that treat it as the architectural discipline it actually is - patient, deliberate, grounded in how the business actually works - will build something that gets smarter over time.

The map on the wall has always mattered. We just never had to make it this legible before.

This blog post draws on concepts from What Makes Knowledge Graphs AI-Ready by Animesh Kumar, published in Modern Data 101.

My content is carefully prepared, crafted and takes anywhere from a few days to several weeks. I sacrifice my free time to create high quality content for you.

The easiest way you can support ♥️ me? Subscribe, like and share this article.

If you like to know more about me, please contact me directly or visit my LinkedIn profile.

Enterprise Architecture has a persistent credibility problem. Not because the discipline is conceptually flawed, but because most organizations implement it in a way that separates the feedback connections that would make it useful. The result is an architecture function that produces artifacts — roadmaps, reference models, principle catalogues — without producing measurable outcomes. The EA Value Cycle is an attempt to name what is actually required: not better documentation, but a closed system in which strategy, investment, design, delivery, and measurement reinforce each other continuously.

Strategy without architecture is wishful thinking.

Business strategy, in most enterprises, is articulated at a level of abstraction that makes it practically useless for technology decision-making. "Become a platform business" or "enable data-driven operations" are aspirations, not specifications. The architecture function's first obligation is to translate these statements into structural implications: which capabilities are currently absent, which integration points do not yet exist, which data assets are siloed in ways that prevent the stated ambition.

When this translation step is missing — or when EA teams produce capability maps that no one reads — the link between Business Strategy and Investment & Prioritization breaks. The consequence is not neutral. Investment decisions then revert to organizational inertia: existing budget owners defend existing systems, and the technology portfolio drifts further from strategic intent with each planning cycle. The architecture team, observing this drift, documents it. The documentation is filed. Nothing changes.

What the cycle requires at this stage is not more documentation but an architectural position that is explicit enough to be contested. An EA function that cannot say "this proposed investment contradicts our stated direction because it deepens dependency X, which we have committed to eliminate" has no leverage in investment governance.

Investment & Prioritization: Where architecture gets tested.

The Investment & Prioritization stage is where enterprise architecture either earns its seat at the table or loses it permanently. Portfolio decisions in large organizations are driven by a combination of regulatory pressure, business unit lobbying, vendor relationships, and whatever happens to be politically salient in the current fiscal year. Architecture can influence this process — but only if it offers something the business cannot produce on its own: a structured view of systemic risk, dependency cost, and long-term complexity accumulation.

This is not the same as saying "EA should approve all investments." That model fails for well-documented reasons: it creates bottlenecks, generates adversarial relationships, and eventually gets bypassed. What works, in practice, is an architecture function that provides decision-relevant information about consequence. Not "you cannot build this," but "if you build this here, in this way, the downstream integration cost is approximately X and the risk of data inconsistency in systems A, B, and C increases materially." Whether the business proceeds is its decision. Whether it proceeds with eyes open is the architecture function's contribution.

The critical failure mode at this stage is an EA team that provides architectural input after investment decisions have already been made. Retrospective compliance review is not governance. It is administrative overhead dressed as governance.

Architecture & Design: From principle to constraint.

Architecture & Design is where abstract principle meets concrete system reality, and where most enterprise architecture frameworks quietly collapse. A principle that states "prefer API-first integration" is not an architectural decision — it is an aspiration. An architectural decision specifies which integration patterns are permitted in which contexts, which authentication mechanisms are required, which data contracts must be versioned and how, and which deviations require explicit exception approval.

The discipline required here is precision, not creativity. Enterprise system landscapes are rarely greenfield. They contain a mixture of legacy platforms with undocumented integration dependencies, SaaS products with constrained extensibility, custom-built components that have drifted from their original specifications, and a layer of middleware that was itself supposed to be temporary fifteen years ago. Architecture decisions that ignore this reality do not govern the landscape — they coexist with it, decoratively.

Effective architecture at the design stage means maintaining a current and accurate model of the existing landscape — not a conceptual target state, but the actual state - and using it to constrain solution design before implementation begins. The cost of an architectural violation discovered during delivery is an order of magnitude higher than the cost of a design review. This is not a philosophical position; it is a project budget observation that can be verified empirically in most large program post-mortems.

Delivery & Ops: Where reality diverges from intent.

Delivery & Ops is where the EA Value Cycle most commonly breaks down in practice, and the break is structural rather than accidental. Architecture teams produce designs; delivery teams implement them under time pressure, with incomplete information, using the tools and skills actually available rather than the tools and skills assumed in the architectural model. The result is an as-built state that diverges from the intended design in ways that are individually defensible and collectively significant.

The architecture function has two choices when confronting this divergence. It can treat every deviation as a governance failure, which produces a compliance posture that delivery teams learn to route around. Or it can treat deviation as signal information about where the architectural model was unrealistic, where tooling is insufficient, where team capability requires investment, or where the design itself contained assumptions that did not survive contact with operational constraints.

The second approach requires humility, but it also requires instrumentation. An architecture team that has no visibility into what is actually deployed cannot learn from the gap between intent and reality. This is why the connection between Delivery & Ops and Measured Value is not cosmetic — it is the mechanism by which the cycle either closes or remains permanently open.

Measured Value: The condition that makes everything else credible

Measured Value is the stage that most EA programs either skip entirely or implement as a retrospective satisfaction survey. Neither approach closes the cycle. What is required is a measurement framework that connects architectural decisions — made at the Investment & Prioritization and Architecture & Design stages — to outcomes that are observable in the Delivery & Ops stage and meaningful at the Business Strategy level.

This is technically harder than it sounds. Architectural quality is not directly observable in the way that revenue or system uptime is. It manifests in proxy indicators: the time required to integrate a new capability into the existing landscape, the frequency and blast radius of incidents that cross domain boundaries, the cost of change in systems that were designed for flexibility versus those that were not. Building the instrumentation to capture these indicators requires investment, organizational agreement on definitions, and a willingness to report numbers that may be unflattering to current architecture decisions.

The return on that investment, however, is substantial. An EA function that can demonstrate that architectural governance decisions reduced integration cost by a quantifiable amount, or that systems designed to a defined standard exhibited measurably lower incident rates, is an EA function that can make a credible case for continued investment. More importantly, it is an EA function that can feed measured reality back into Business Strategy discussions, closing the cycle with evidence rather than assertion.

The Cycle as governance model, not process chart.

The EA Value Cycle is most usefully understood not as a process flow — a sequence of stages through which work passes — but as a description of the information dependencies that must be maintained for enterprise architecture to function as a governance discipline rather than a documentation exercise. Each stage depends on outputs from the previous stage and produces inputs for the next. When any connection is severed, the cycle degrades into a set of disconnected activities that each consume organizational energy without reinforcing each other.

The practical question for any EA function is not "do we do all five of these things?" but "are the connections intact?" Does architectural input actually shape investment decisions, or does it arrive after the fact? Does design intent actually constrain delivery, or does delivery produce a fait accompli that architecture retrospectively blesses? Does measurement actually feed back into strategy, or does it disappear into a quarterly report that no one acts on?

Answering those questions honestly is, in most organizations, more useful than any framework adoption or tooling investment. The cycle either closes or it does not. If it does not, the value that enterprise architecture could deliver remains theoretical — well-described in the methodology, invisible in the P&L.

My content is carefully prepared, crafted and takes anywhere from a few days to several weeks. I sacrifice my free time to create high quality content for you.

The easiest way you can support ♥️ me? Subscribe, like and share this article.

If you like to know more about me, please contact me directly or visit my LinkedIn profile.

How do we automate Architecture efforts with AI?

Is this really the right question to ask?

It sounds logical, but it rarely leads to the highest return on investment. The better question to ask is: 

What are architectural preconditions for AI agents to function reliably, economically, and at scale?

There is a growing assumption that the need to clean up enterprise IT landscapes will diminish as AI systems become more capable. Agent-based AI promises to work with unstructured data, undocumented interfaces, and heterogeneous legacy environments. 

If intelligent agents can navigate chaos, why invest in order?

This assumption does not hold under closer technical, architectural, and economic considerations. Not everything needs to be modernized. But the right things must be. Enterprise Architecture becomes the vehicle that decides where investment is mandatory and where technical debt can remain tolerated.

 The illusion of autonomous agents

Agents understand natural language, orchestrate workflows across systems, and solve problems autonomously. In controlled demonstrations, an agent retrieves information from multiple systems and produces coherent outcomes with minimal configuration.

The implicit conclusion is seductive: if agents are intelligent enough, the underlying architecture becomes secondary.

What these narratives hide is the difference between a demo environment and a production enterprise landscape. Under the surface of every AI initiative sit legacy systems, fragmented data models, undocumented integration logic, and accumulated operational shortcuts. The question is not whether an AI agent can technically operate in such an environment, but under which conditions it does so predictably, cost-efficiently, and in a way that is in line with governance and compliance. 

Answering that question requires an understanding of the concrete limitations of today's AI capabilities.

Context window constraints - why structure still matters

Large Language Models operate within a bounded context window. Depending on the model, this ranges from several thousand to a few hundred thousand tokens. While this appears generous, it is quickly exhausted in enterprise scenarios.

Business documents, API responses, historical records, and conversational state all compete for limited context capacity. When an agent aggregates information from multiple poorly structured systems, the context fills up before any meaningful reasoning begins.

RAG (Retrieval Augmented Generation) can mitigate this problem, but only if the underlying data is semantically indexed, and accessible in a predictable way. Larger context windows do not eliminate the issue; they amplify the cost and increase the probability of degraded reasoning as irrelevant or redundant information accumulates.

For enterprise architecture, the implication is straightforward: unstructured abundance is not an asset. Context is a scarce resource. Applications that expose concise, well-scoped, and semantically coherent data reduce both, operational cost and reasoning risk.

Hallucination risk and the cost of inconsistency

AI systems generate outputs that are plausible, not guaranteed to be correct. When inputs are inconsistent or contradictory, the probability of hallucination increases sharply. 

In many enterprises, the same business fact exists in multiple systems with subtle variations. Contract dates, customer statuses, or entitlement rules may differ depending on the source. A human user recognizes these discrepancies through experience. An AI agent does not. It selects one version and proceeds with confidence.

This is not a theoretical problem. In use cases where AI agents support or prepare business decisions, inconsistent data becomes a direct risk factor. Single Sources of Truth are therefore not an academic ideal, but a practical necessity for any AI-enabled decision flow.

Importantly, this does not require replacing all legacy systems. It requires explicit architectural decisions about data ownership, authoritative sources, and governance enforcement. Enterprise Architecture is the discipline that makes these decisions visible and enforceable.

Tool calling and the reality of enterprise integration

AI agents interact with applications through API calls. This mechanism assumes well-defined functions, stable parameters, and predictable responses. Modern REST APIs fit this model well. Batch interfaces, proprietary protocols, undocumented side effects, and implicit defaults do not.

In most enterprises, critical applications were not designed for real-time, fine-grained interaction. Mainframe transactions, file-based exchanges, and tightly coupled application logic remain common. AI agents cannot reason reliably about such interfaces.

The architectural implication is not a wholesale replacement of legacy applications, but targeted encapsulation. Applications that are relevant for AI-driven workflows require explicit API façades that make behavior, constraints, and errors visible. Systems that are irrelevant for AI use cases do not. Again, differentiation is the core task.

 Latency, cost, and the economics of reasoning

Agent-based workflows multiply these interactions through planning, execution, validation, and error handling steps.

In a fragmented architecture, an agent must navigate ambiguity. It makes more calls, retries more often, and consumes more context. Operational costs rise accordingly. What appears as a minor architectural inefficiency becomes a recurring expense at scale.

A cleaner architecture does not merely improve elegance. It reduces reasoning depth, minimizes retries, and lowers per-transaction cost. Architecture quality directly influences the economic viability of AI use cases.

Failure modes and undocumented behavior

Legacy systems often exhibit undocumented behavior. Default values, silent error handling, and implicit corrections may be well understood by long-tenured staff but are invisible to automated agents. 

For AI systems, such behavior is indistinguishable from correct output. This creates failure modes that are difficult to detect and harder to audit.

The architectural response is not to rewrite every legacy component, but to introduce boundaries. Interfaces must make errors explicit, validate inputs rigorously, and expose constraints clearly. Where institutional knowledge has been lost, this work becomes non-trivial, but it is unavoidable for AI-critical systems.

Reproducibility, explainability, and compliance

AI models are inherently non-deterministic. The same prompt can yield different results across executions. In regulated environments, this is not acceptable for final decision-making.

Architectures that incorporate AI agents must therefore enforce traceability by design. Inputs, prompts, model versions, outputs, and downstream decisions must be logged and versioned. Deterministic rule engines must validate AI-generated proposals. Human-in-the-loop mechanisms must be explicit, not implicit.

These requirements are not regulatory overhead. They define which systems are eligible for AI integration and which are not.

What actually needs to be cleaned up

The critical insight is that not everything requires modernization. The wrong insight is that nothing does.

First, AI relevance. Systems that will never participate in AI-driven workflows do not need to be optimized for AI consumption.

Second, data quality versus data access. APIs without trustworthy data are as ineffective as high-quality data locked behind inaccessible interfaces.

Third, use-case criticality. Exploratory or internal use cases tolerate uncertainty. Customer-facing or decision-making use cases do not.

The intersection of these dimensions determines where architectural investment is mandatory.

Enterprise Architecture as investment navigator

The objective is not to automate architectural documentation, but to guide investment decisions under AI-driven constraints.

AI readiness becomes a measurable architectural attribute. Systems are assessed for relevance, accessibility, data quality, and compliance exposure. Use cases are prioritized based on business value. Dependencies are mapped explicitly. Gaps become visible and actionable.

Architecture roadmaps are then synchronized with AI initiatives, not treated as parallel efforts. Standards for APIs, data quality, logging, and human oversight prevent the creation of new technical debt under the banner of innovation. 

Conclusion: Focus on the right things

The underlying enterprise landscape will not disappear. Legacy applications, integration debt, and undocumented behavior will remain realities for the foreseeable future.

The question is not whether everything must be modernized, but what must be modernized, why, and in which order.

AI agents have concrete technical limitations. These limitations are not negotiable, and they are not evenly distributed across the landscape. Enterprise Architecture provides the structure to navigate this reality.

My content is carefully prepared, crafted and takes anywhere from a few days to several weeks. I sacrifice my free time to create high quality content for you.

The easiest way you can support ♥️ me? Subscribe, like and share this article.

If you like to know more about me, please contact me directly or visit my LinkedIn profile.

Executives rarely wake up and decide to block progress.
Yet across organizations, digital initiatives stall every day.

• Customer experience programs drag on.

• Data platforms miss their promised impact.

• Transformation roadmaps quietly slip by quarters.

The default explanation is familiar: organizational silos, lack of alignment, resistance to change.

But after reviewing dozens of delayed or stalled initiatives across mid-market and large organizations, a different pattern consistently emerges.

Digital transformation does not fail because of technology.
It fails because organizational and architectural dependencies remain invisible until execution begins.

The silent failure pattern

A marketing team launches a customer experience initiative to improve personalization.

Only later does IT discover that the required data sits in finance-owned systems. Finance cannot commit without operational approval due to data quality and regulatory constraints.

Operations, meanwhile, is already engaged in a multi-year supply chain transformation.

No one made a mistake.
Everyone acted rationally within their own domain.

And yet, six months later, progress has effectively stopped.

This pattern repeats in different forms:

• A data platform initiative that assumes standardized master data that does not exist

• A process automation effort blocked by unclear system ownership

• A cloud migration delayed by dependencies on legacy integrations no one documented

These are not execution problems. They are design problems.

Where Enterprise Architecture actually adds value

Enterprise Architecture is often associated with documentation, standards, or technology roadmaps.

In reality, its highest value appears before initiatives are funded or launched.

This is where Enterprise Architecture intervenes.

First, it makes dependencies explicit.
Not at a system level, but at a business level.

Which value streams are affected?
Which capabilities need prioritized technology investments?
Which data domains, platforms, and teams are involved?

What often feels like “unexpected complexity” later was always present — just unseen.

Second, it creates a shared execution view.

initiatives across domains into a single, coherent picture.

This is not about central control.
It is about shared understanding.

When multiple initiatives touch the same capabilities, data, or platforms, Enterprise Architecture surfaces those intersections early — before optimistic timelines turn into coordination overhead.

Third, it reframes decision-making.
The critical question is no longer, “Can we build this?”

It becomes, “What else moves when we do?”

Most organizations have no natural owner for that question.
Enterprise Architecture exists precisely for this purpose.

Why some organizations move faster than others

The organizations that execute transformation successfully are not the ones with fewer silos.

They are the ones with architectural transparency.

In these organizations:

• Initiatives are anchored in value streams, not departmental goals

• Capability dependencies are visible before roadmaps are finalized

• Ownership across business, IT, and operations is explicit

• Sequencing decisions are deliberate, not accidental

This visibility changes behavior.

Teams stop optimizing locally and start designing for the enterprise. Coordination shifts from reactive escalation to intentional design.

Recent industry research reflects this shift.
High-impact architects now spend the majority of their time on value stream and experience mapping, rather than maintaining static technical documentation.

Not because documentation is unimportant — but because visibility is decisive.

The strategic role of Enterprise Architecture

Enterprise Architecture is not a control function.
It is not a compliance layer.

And it is not an IT-only discipline.

It is the strategic capability that makes complexity navigable.

By connecting strategy, execution, and structure, Enterprise Architecture enables leaders to see:

• How initiatives interact

• Where constraints actually sit

• Which decisions must be synchronized

• And where investment will create friction rather than value

Without this visibility, organizations do not move slower because they lack ambition.

They move slower because they discover reality too late.

The most important architectural decision is not the choice of platform or tool. It is whether the organization designs before it executes.

And that is where Enterprise Architecture earns its place at the leadership table.

My content is carefully prepared, crafted and takes anywhere from a few days to several weeks. I sacrifice my free time to create high quality content for you.

The easiest way you can support ♥️ me? Subscribe, like and share this article.

If you like to know more about me, please contact me directly or visit my LinkedIn profile.

These aren’t rules. It is about a state of mind. Ten virtues to remind you why you design – and for whom. They’re the foundation for architecture that endures, uplifts, and delivers value.

I. Clear needs before fancy solutions

Virtue: Listen deeply. Clarify. Speak clearly.

“The beginning is half of the whole.” – Aristotle

Architecture doesn’t begin with tools. It begins with understanding. If you build without knowing for whom – your work will stand empty. Whether it’s code or concrete, clarity of need is the birthplace of clarity in design.

II. Allow for doubt

Virtue: Ask questions. Even the uncomfortable ones.

“I know that I know nothing.” – Socrates

The greatest architects aren’t order-takers. They’re seekers of meaning. Doubt isn’t weakness – it’s wisdom in disguise. It keeps you awake, sharpens your craft, and opens the door to better solutions.

III. Responsibility over excuse

Virtue: Decide – and own your decision.

“Act so that you can take responsibility for the consequences of your action.” – Hans Jonas

Design has consequences. Always. Every choice you make shapes systems that outlive the project. True mastery begins when you take full responsibility – not just for success, but for compromise.

IV. Communication as partnership

Virtue: Speak human. Listen actively. Seek consensus without dilution.

“Only what all affected can accept in dialogue is legitimate.” – Habermas

Architecture happens through conversation – not command. No ivory towers. No hidden jargon. The true architect builds understanding through clear language, open exchange, and genuine empathy.

V. Integrate change

Virtue: Plan for change – not against it.

“Everything flows.” – Heraclitus

The only constant is movement. Resisting change is losing ground. Welcoming it is evolution. Architecture is a living system – flexible in detail, firm in principle.

VI. Simplify, don’t manage complexity

Virtue: Reduce. Clarify. Liberate.

“Less is more.” – Mies van der Rohe

Complexity is easy. Simplicity is mastery. Great architects reveal the essence. Clarity is beauty. And beauty is understanding.

VII. Ethics before efficiency

Virtue: Choose sustainability over speed.

“Do unto others as you would have them do unto you.” – The Golden Rule

Technology can accelerate – but not excuse. Design is power. Use it consciously. Ethics isn’t an accessory. It’s the foundation.

VIII. Design for longevity

Virtue: Build so others can continue.

“Human life extends beyond the moment.” – after Hannah Arendt

Good architecture outlives its author. It’s documented, transparent, and open. It gives freedom – especially to those who come after.

IX. Sense of beauty

Virtue: Design with grace.

“Beauty is that which pleases universally without concept.” – Kant

Function isn’t enough. Beauty builds trust. It’s not luxury – it’s language. Beauty says: “someone cared”.

X. Empowerment over control

Virtue: Create space – not fences.

“The capacity for self-determination is a goal of human development.” – Nussbaum

Architecture should enlarge people, not limit them. It should give freedom, not fear. When you empower, you build justice.

My content is carefully prepared, crafted and takes anywhere from a few days to several weeks. I sacrifice my free time to create high quality content for you.

The easiest way you can support ♥️ me? Subscribe, like and share this article.

If you like to know more about me, please contact me directly or visit my LinkedIn profile.

The world is constantly changing. How can you be successful today? What do you need to learn to stay relevant in the future?

The content is created by me personally. It is meant only for people to read and must not be used to train any machine learning models, including but not limited to AI systems like large language models (LLMs).

Growth Mindset

The world is changing fast. And with the latest innovation in AI, at an incredible speed. Now, what does this mean for you? It is more important than ever, to stay curious. The only survival strategy is continuous learning and the desire to grow. Take the time to test latest innovation, e.g. try different AI applications and form your own opinion about it. What you have once learned may not be relevant anymore or has changed significantly.

And while there is a lot of change, be aware of your own bias. It is crucial to unlearn things. I have a great book recommendation for you.

Back to the incredible pace of change. The art is to understand when to go deep and when to trust range. By the way – Range – there is another book that I would like to recommend to you:

Spoiler art:

"It is generalists who are more likely to excel in the long run. Those who explore broadly, try different paths, and develop diverse skills."

Epstein argues that breadth of experience and the ability to pivot are more powerful than narrow expertise. Especially in a fast-changing, interconnected world.

The growth mindset is not limited to learn about latest shifts in technology. It covers organizational psychology, market trends and other soft skills, which we will learn about in this article.

Being open minded is key and to admit that learning is lifelong is the new reality.

Adaptability

It is essentially one of the most important soft skills. If not the most important one.

Adaptability is the skill to adjust to new conditions, embrace change, and remain flexible in the face of uncertainty. It involves staying open-minded as part of the desire to grow. Learning from experience, and quickly applying new knowledge or skills when circumstances shift.

Industries are transforming and job roles are changing. It's a natural process that changes in the architecture profession will occur, too. Unexpected shifts will happen. This will require individuals and organizations to adapt. Those who embrace change will be better equipped to handle uncertainties, remain productive and grab new opportunities. Adaptability is highly valued in modern workplaces.

Artificial intelligence (AI) will replace the Architecture profession? AI will replace those who do not make use of it. Make sure to get familiar in the application of AI and incorporate AI into your work.

HI + AI > AI

HI = Human Intelligence

Negotiation & selling ideas

to get everyone aligned and agree on solutions. To achieve results, that in the end meet business, organizational and technical needs. Is there a way to find common ground among several perspectives? You will face different incentives, agendas and – as it is about people – egos are always present.

So, we need an ability to navigate through conflicting demands. To bring the perspectives of your stakeholders in harmony with ours. To watch out for synergies and puzzle pieces that may lead to a breakthrough in your own thinking. You need to understand the underlying motivations of your stakeholders. And you need to link them to your rationale Architecture decisions.

You are expected to clearly articulate the value of architectural decisions, bridge gaps between technical and business teams, and ensure alignment with organizational goals. Do not make the mistake to talk in technical language and overcomplicate things. Try to use simple language and always reference your architecture recommendations to the overarching strategy.

Influencing

One of the terms disliked by many people. The term that emerged out of the social media bubble. Often associated with people showing products in the camera to advert and provide a discount.

Now, try to take a different perspective. Do you think you can be successful without influence in an enterprise? I doubt. It is not about direct authority. It's about an inherent, implicit authority. The one that is earned with trust, expertise and leadership.

You're guiding teams, stakeholders and entire organizations towards a shared target state. Influence is based on understanding people and get their buy-in. You need to ask yourself how you can help people. With an ever increased complexity in business and technology, it is an architecture superpower to simplify. The art of turning complexity into clarity and convincing others to follow your path.

Analytical & systems thinking

It's an highly demanded ability to break down complex problems into pieces. During the process you will identify patterns, and understand how those building blocks fit together within a broad ecosystem. You stop solving problems in isolation and instead understand how they are connected. If you focus on cause and effect, interdependencies and feedback loops, you will see the whole and not just the parts.

To an Enterprise Architect, this means holistic thinking. Not just to see individual technologies or processes but how they interface to enable business objectives. The skill to unpack complexity and see the big picture is a unique ability.

As companies pursue transformation, automation, and evidence-driven strategies, it is an indispensable skill for every aspiring Enterprise Architect.

My content is carefully prepared, crafted and takes anywhere from a few days to several weeks. I sacrifice my free time to create high quality content for you.

The easiest way you can support ♥️ me? Subscribe, like and share this article.

If you like to know more about me, please contact me directly or visit my LinkedIn profile.

No one has told you about this. How does it feel to enter the Architecture profession? Does it match with what you had in mind? What turns out to be a fallacy?

The content is created by me personally. It is meant only for people to read and must not be used to train any machine learning models, including but not limited to AI systems like large language models (LLMs).

“Hello, Architecture World!“

when I joined the space of Architecture, I felt like an explorer. And I came in with excitement, a touch of imposter syndrome, and a strong sense of responsibility. What is this all about? How can I become successful? How does “perfect“ Architecture look like?

I do not know about your experience and feelings. Maybe, you felt the same? Well, I can tell you. I had a lot of questions in mind.

Which skill set is required? What state of mind is needed to become a successful Architect? And on top of this all the different Architecture roles:

Software Architect, Infrastructure Architect, Solution Architect, Business/Technical Domain Architect, Enterprise Architect..

Want some more? This is perfect for a dedicated article on this topic.

Back to the origin. Before I took the new role, I was managing a larger application suite. Nowadays, this is the typical Product Owner role. Taking care of the development and roadmap of the applications and ensuring stable operations. I always had a strong focus on translating business needs into solutions. I was confident. The experience I have made, along with my analytical sharpness would help me in my new role.

Now, I took the transition into the role of a Solution Architect. More than excited and fully of energy and enthusiasm. How will my first steps look like? Will it be similar to my previous role? Do I just have to take a broader view? Will I be able to design a perfect Solution Architecture?

The first weeks passed. And I knew what to do — joke aside. Every conversation. Every discussion. Every appointment. Every sketching. Every drawing. I did not expect how much I did not know. And I learned. I learned a lot of things. It was a huge learning experience - without doubt.

And do you know why I was able to learn?

“Hello, Mentor.“

who already went through all of this. Someone who takes care of you and your development. Someone who is patient and allows you to make mistakes. Someone who takes time, teaches and guides. That someone gave me the space to fail safely and created the best learning environment I could have hoped for.

I had a great mentor and manager who took the time to take care of my development. And I have to admit, he has been very patient with me! I still admire his excellent skills to present and facilitate architecture decisions. I wonder if I'll ever get anywhere near him. Time will show.

Aren't these recurring patterns?

The many conversations with other architects, lead developers, project & product managers and business stakeholders shaped my thinking. I got a better understanding of what these roles usually expect from an Architect. And funny enough, the different expectations and understanding of what Architecture should do.

Apart from the experience gained internally, I followed industry leaders in software engineering and Architecture. I absorbed what they talked about, whether best practices, anti patterns and latest trends.

I have the privilege and am grateful that I have developed further. Whether in a supporting role of a Business Domain Architect, to further development at the flight level of an Enterprise Architect. I can tell you, it is of huge benefit to experience these different playing fields. It's about different roles on different flight levels, but they all have some in common.

I took quite a while to see certain patterns that stand out. I felt more clarity and my mind started to understand the actual purpose of the role and how it provides value to organizations. It turned out that the human side is of great importance.

With the growing understanding, it felt easier to grasp how one can thrive, grow and be successful in an Architecture role. Some of the learnings I want to share with you.

What I thought vs. what I learned

Architecture is all about technology.

Well, not quite. It's far more about people. Understanding different perspectives and incentives of stakeholders, navigating conflicts and communicating trade-offs. And do not underestimate to always start from the business side of things. Technology is not an end in itself. Even if it is tempting. You have the responsibility to deliver business outcomes enabled by technology. It's all about business outcomes. Never forget that.

Architects know all the answers.

That sounds too good to be true, right? Forget about the answers, focus on asking the right questions. Listen to people. Summarize what has been said in your own words. Try to point out potential misunderstandings and get the perspective of your stakeholders. Learn what it takes to ask the right questions. It sounds easy, but it is far more tempting to talk instead of thinking about the right questions to ask.

Architecture is static.

In a world full of changes, with an enormous pace of change — static? Architecture is a continuous exercise. Everything is in motion and changing. Driven by both internal and external influences. You have to adapt. Architecture has to adapt. Instead of blueprinting, think about your garden. It's more like gardening.

Architecture is perfect.

Architecture always depends on context. You're a decision professional. In a decision discipline. You need to understand the business context. The strategy and the current implications and constraints. Quite a lot of things in fact. But the most important, it is about trade-offs. Instead of chasing perfection, develop scenarios and show trade-offs. A “good enough“ decision today, with a path to change later, may hit the nail.

My content is carefully prepared, crafted and takes anywhere from a few days to several weeks. I sacrifice my free time to create high quality content.

The easiest way you can support ♥️ me? Subscribe, like and share this article.

If you like to know more about me, please contact me directly or visit my LinkedIn profile.

Buying software from the market vs. creating your own intellectual property. Or is there more to it? Timeless decisions that every organization must make for its own IT estate.

The context of this article

Before we go into details, let’s define the scope. This article is for large enterprises looking to improve their technology and business capabilities. It is not for companies that build and sell software products as their core business.

For product companies, the choice to buy or build is not just technical but rather strategic. It affects their ability to innovate, grow and compete.

This article assumes you have already checked if you own a solution to the problem.

Define Your Needs

Before choosing a third-party solution, ask yourself key questions. Do you really need an external provider for the business capability you want? Not all business capabilities matter equally when comparing your organization to competitors. You must know which ones must be strong and which only need to match others.

Business Capabilities fall into the following categories:

• Differentiating capabilities (Core): These help your company stand out. They are unique in your organization and differentiate you from your competitors. In competitive markets, investing in these capabilities makes sense because they give you an advantage.

• Supporting capabilities (Enabling): These help your core capabilities work. They are important but do not define your business. A core capability in one business may be a supporting one in another.

• Commodity capabilities (Generic): These are common needs, like accounting or managing the payroll. They do not set your company apart. You will find them in many organizations. The best approach is to use standard industry practices. They should be functional but not a focus for investment.

Deciding which category a capability belongs to depends on your business context and strategy.

💡

A commodity capability means you must adapt to the vendor’s standard way of doing things. This can change how you deliver value to customers. If industry norms do not hurt your business, a commodity approach works.

What makes your organization unique?

Sometimes, a capability that seems like a commodity may actually be a differentiator. This depends on how your company operates and your Unique Selling Proposition (USP).

• Keep in-house if it is a core skill, involves proprietary knowledge, or has high risk, regulatory, or quality concerns.

• Outsource if it is non-core, can be done faster and cheaper externally, and does not reduce strategic control.

Avoid defining your business capabilities too broadly. For example, instead of thinking about an entire Enterprise Resource Planning (ERP) system, break it down into smaller parts. Some may be commodities, while others provide an advantage.

Before buying, consider how the decision affects your key strengths. Vendors’ best practices may force changing your business processes and affect how your teams are organized. Consider how such decisions impact your entire value chain.

An approach to understand Commodities vs. Differentiators

"A Wardley map is a map for business strategy. Components are positioned within a value chain and anchored by the user need, with movement described by an evolution axis."
https://en.wikipedia.org/wiki/Wardleymap

Wardley Maps help your organizations to understand their market, find ways to stand out, and make better investment decisions.

They show you how capabilities, technologies, and services/products change over time within a value chain.

Wardley Mapping

How can you have better strategy discussions, in 90 seconds.

What is Wardley Mapping?

What about the existing IT estate?

Organizations must review their landscape on regular basis. The industry changes fast. An application that was unique a year ago may now be standard. Business priorities also shift. What seemed essential to build in-house may no longer be necessary. Prices may also change, making third-party solutions more attractive.

There is often a desire to replace old applications with new ones. This may be the right choice. However, first consider to extend the life of what you already have:

• Modernizing: Insource your differentiator, use cloud environments, and apply DevSecOps with automation. Make sure you have a good developer experience. Adhere to modern architecture principles.

• Extending: Add missing building blocks instead of replacing the entire application. Create a mobile or web front-end on top of legacy backends. Or build and integrate specific microservices to fill critical gaps. Weigh the total costs (!) against the benefits.

If third-party solutions fit better and updating your application is not worth it, start evaluating new options.

Conclusion  

There is no single answer to buy or build. It is not one or the other anymore. Organizations that value agility and resilience understand this. Modern architecture decisions go beyond buy versus build.

💡

Buy and Build. Blend and integrate.

A strong architecture function helps to manage trade-offs and keeps technology aligned with strategy. Decisions must consider integration, scalability, and operations. Clear architecture principles ensure consistency and adaptability.

The choice depends on your needs, current IT landscape, and technology importance to your business. Align decisions with goals and budget. Weigh benefits and risks. Consider long-term impact.

If you like my content and would like to support me, please subscribe and follow me on LinkedIn.