A practitioner’s inspiration for enterprise architects who want to move from static models to navigable architecture experiences

Enterprise Architecture has no shortage of methods, metamodels, frameworks, and tooling. What it still lacks in many organizations is traction. Too often, architecture remains a static discipline: a collection of diagrams, principles, standards, and repositories that architects understand but the rest of the enterprise only tolerates. The problem is rarely the framework itself. The problem is that architecture is still too often delivered as documentation, while the business increasingly needs it as a usable navigation layer for change.

A more effective approach is to treat Enterprise Architecture as both a modeling discipline and a communication discipline. That is the essence of Visual Enterprise Architecture: making the relationships between strategy, capabilities, processes, applications, data, technology, risks, and roadmaps visible enough to guide decisions. This does not weaken TOGAF; it makes its output easier to consume and therefore more useful across all architecture layers. Tools such as Microsoft Sway support that communication layer by allowing architects to create interactive reports and presentations and to embed content from sources including Sway itself, OneDrive documents, Power BI, Stream, and LinkedIn Posts.[support.microsoft]

This article is written from the perspective of a practicing enterprise architect for fellow architects—experienced and beginning alike—who want to make architecture more actionable. Some readers will work in organizations that can fund an enterprise-grade EA platform. Others will need to build credible architecture practices using inexpensive or free tools. Both routes are viable. The core message is simple: start with the architecture outcomes you need, then choose the lightest toolset that can support those outcomes.

Why visual architecture matters now

Architecture has always promised alignment between business and IT, but alignment rarely emerges from static repositories alone. Decision-makers need to see dependencies, options, future-state designs, and the consequences of change. A capability map, an application portfolio heatmap, a target-state process narrative, or an embedded demo of a new customer journey can often create more stakeholder understanding in ten minutes than a hundred pages of formal documentation.

That matters even more in transformation programs where the architecture spans all TOGAF domains. Business architecture needs to connect to strategy and operating model; data architecture to governance and information quality; application architecture to portfolio choices and integrations; technology architecture to risk, obsolescence, and modernization. Visual Enterprise Architecture helps bridge those layers with a format that non-architects can follow.

In practical terms, that means architecture should be delivered not only as models but as a navigable architecture experience. One stakeholder might start at the strategy map, drill into capabilities, open a process view, review the impacted applications, inspect a Power BI heatmap, and then watch a short solution demo. Sway is especially useful for this because it supports interactive storytelling and allows a Sway to be embedded inside another Sway, as well as documents, dashboards, videos, and other supported embeds.[support.microsoft]

The architecture tool question

The market now offers at least three broad categories of tooling.

• Enterprise-grade EA suites such as Bizzdesign, MEGA HOPEX, and SAP LeanIX.

• Classic modeling platforms such as Sparx Enterprise Architect.

• Free or lightweight visual stacks built from Archi, Excel, Power BI, Visio, draw.io, Miro, SharePoint, and Sway.

The wrong question is “Which tool is best?” The better question is: what architectural capability is actually needed right now? If the immediate need is disciplined ArchiMate modeling, a free or low-cost tool may be enough. If the need is enterprise-wide portfolio governance, workflows, role-based publishing, and automated discovery, a professional platform may be justified. If the need is stakeholder communication, even the best repository will still need a presentation layer.

Professional tools: where they shine and where they hurt

Bizzdesign Horizzon

Bizzdesign is one of the better-known enterprise transformation and architecture platforms. It offers broad support for architecture disciplines, modeling, analysis, roadmapping, and publishing, and public marketplace information shows license pricing that can range from low-cost viewer access to several thousand pounds per license per year depending on role and service scope.[applytosupply.digitalmarketplace.service.gov]

Strengths

• Strong support for structured enterprise modeling and analysis.

• Mature support for roadmaps, heatmaps, dependency views, and stakeholder-oriented outputs.

• Good fit for organizations that want to professionalize architecture governance and publication.

Trade-offs

• More platform than tool: adoption requires governance, ownership, and implementation effort.

• The learning curve can be significant for teams that are new to metamodel-driven EA.

• The platform still benefits from a complementary storytelling layer for executives and business stakeholders.

MEGA HOPEX

HOPEX is positioned as a broad enterprise transformation platform that connects EA with adjacent domains such as risk and data governance.[platform.softwareone]

Strengths

• Strong repository thinking and cross-domain coverage.

• Good fit when architecture must link closely to compliance, risk, and portfolio control.

• Capable of supporting large, structured enterprises with complex governance requirements.

Trade-offs

• Typically sits in the enterprise-budget category, both in licenses and in implementation effort.

• Best value is realized only when the organization is ready to commit to process, governance, and sustained ownership.

• Can feel heavy for small teams or organizations still maturing their EA practice.

SAP LeanIX

LeanIX is widely used for application portfolio management and modernization transparency. Third-party pricing intelligence reports a median annual contract value of about USD 58,456, illustrating that it is usually procured as an enterprise SaaS platform rather than a low-cost modeling tool. LeanIX documentation also positions the platform around transparency, cost, and portfolio management across the application landscape.[vendr]

Strengths

• Excellent fit for application portfolio management, lifecycle transparency, and rationalization.

• Strong SaaS experience and strong relevance for CIO and transformation offices.

• Useful when the architectural pain point is not modeling purity but portfolio visibility and roadmapping.

Trade-offs

• Less focused on deep hands-on modeling than a classic architecture workbench.

• Costs can be hard to justify for small teams or organizations without a formal EA mandate.

• Visual storytelling for broader stakeholder engagement still requires complementary tooling.

Sparx Enterprise Architect

Sparx Enterprise Architect remains one of the most cost-effective serious modeling environments on the market. Public price lists in Europe show named-user licenses starting around EUR 225 and rising into the high hundreds depending on edition and floating-license options.[sparxsystems]

Strengths

• Exceptionally broad modeling support, including UML, BPMN, ArchiMate, and other notations.[sparxsystems]

• Much lower entry cost than most enterprise EA suites.[sparxsystems]

• Useful for enterprise, solution, and technical architecture work in a single platform.

Trade-offs

• Collaboration, web publishing, and stakeholder-friendly consumption are less elegant than in modern SaaS EA platforms.

• The user experience can feel dated, especially for teams expecting cloud-native collaboration.

• Teams often need additional tooling to turn models into communication products.

Archi and the free-tool route

Archi remains one of the best entry points for architects who want solid ArchiMate support without license cost. It is explicitly positioned as a free and open-source ArchiMate modeling toolkit.[archimatetool]

Strengths

• Free, cross-platform, and focused enough to be useful quickly.[trilogix]

• A practical starting point for ArchiMate-based architecture work.

• Excellent for teams that want method before platform.

Trade-offs

• No enterprise-grade governance, portal, workflow, or analytics layer out of the box.

• Requires self-discipline for repository hygiene, publication, and stakeholder engagement.

• Usually needs companion tools to become an enterprise-facing architecture service.

Free stack versus professional stack

The real comparison is not tool against tool, but operating model against operating model.

If budget is near zero

A credible Visual EA practice can still be built with a lightweight stack such as:

• Archi for ArchiMate modeling.[archimatetool]

• Excel for inventories, application lists, capability mappings, and lifecycle scoring.

• Power BI for heatmaps, portfolio views, and basic architecture dashboards.[support.microsoft]

• Visio, draw.io, or Miro for diagrams and workshops.

• SharePoint or Teams for publication and collaboration.

• Sway as the presentation and navigation layer, embedding dashboards, documents, videos, Forms, and even another Sway.[support.microsoft]

This route demands more manual discipline. The repository is lighter, governance is more manual, and consistency depends more heavily on the architects. But it works, especially for a small architecture function proving value.

If budget is modest

A very practical middle path is:

• Sparx Enterprise Architect as the architecture workbench.[sparxsystems]

• Excel or Dataverse for supplemental inventories.

• Power BI for dashboards.

• Sway or SharePoint as the executive-facing architecture portal.[support.microsoft]

This combination often gives a better return than jumping too early into a large enterprise suite. The team gets modeling depth at low cost, while retaining freedom to build a communication layer that matches the organization.

If budget is enterprise-scale

This is where platforms such as Bizzdesign, HOPEX, and LeanIX become compelling.[applytosupply.digitalmarketplace.service.gov]

They are strongest when the organization needs:

• A governed repository with ownership and workflows.

• Role-based publication at scale.

• Portfolio analytics and impact analysis across many domains.

• Integration with CMDB, ITSM, discovery, or data governance sources.

• A sustainable operating model beyond a few architects.

Even then, the lesson remains the same: the repository alone is not the experience. Many organizations still need a front-end communication layer to explain transformation journeys in a way the business can absorb.

A practical Sway-based Visual EA pattern

For architects who want a pragmatic, low-friction way to present TOGAF-aligned architecture, Sway is more powerful than it first appears. Microsoft documents that Sway can embed content from Microsoft Forms, Sway, OneDrive documents such as Word, Excel, PowerPoint and PDF, Power BI, Stream, LinkedIn Posts, SlideShare, and other supported sources. It also explicitly supports embedding one Sway inside another Sway, which makes hierarchical “architecture atlas” structures possible.[support.microsoft]

A practical pattern looks like this:

Level 1: the enterprise landing Sway

This is the top-level narrative. It explains:

• strategic themes,

• transformation priorities,

• operating model context,

• architecture principles,

• and navigation links into deeper domains.

Think of it as the front door to the architecture landscape.

Level 2: domain Sways per TOGAF layer

Create separate Sways for:

• Business Architecture,

• Data Architecture,

• Application Architecture,

• Technology Architecture,

• and optionally Security, Risk, or Transformation Portfolio.

Each domain Sway can contain its own diagrams, linked documents, demo videos, embedded dashboards, and nested sub-Sways.

Level 3: subject Sways or deep-dive pages

Use these for:

• a capability heatmap,

• a target-state application domain,

• a modernization roadmap,

• an integration domain,

• a business process journey,

• or a solution option set.

This creates a tree-like structure without overwhelming the reader on the first page.

What to embed

The best Sway-based architecture stories mix four types of evidence:

• Models — ArchiMate views, process maps, reference architectures.

• Facts — portfolio tables, lifecycle heatmaps, KPI snapshots, costs, risk scores.

• Experience — demo videos, clickable prototypes, AI HTML apps, interactive spreadsheets.

• Narrative — short architect-written explanations that say why the view matters.

That mix is usually more effective than publishing a repository view directly.

Adding AI and interactive simulation

The next step beyond static visualization is interactive architectural simulation. This does not require a full commercial digital-twin platform on day one. Even lightweight approaches can help.

Examples include:

• a small HTML application that lets users choose a target-state scenario and see impacted applications,

• an AI assistant that explains a capability map or application heatmap in plain language,

• a chatbot over your repository export,

• a simulation that shows how retiring a platform affects processes, interfaces, cost, or risk.

In lower-budget settings, these can be simple AI-supported HTML apps embedded into Sway alongside diagrams and dashboards. In higher-budget settings, newer tools are increasingly moving toward AI-assisted architecture and more dynamic impact analysis. The key idea is that architecture becomes something stakeholders can interact with, not just read.

Cost logic: when to pay and when not to

A common mistake in EA is buying a powerful platform too early. Another is refusing to invest even after the organization has outgrown spreadsheet governance. The right time to pay for a professional tool is usually when one or more of the following become true:

• the application estate is too large for manual stewardship,

• multiple architecture teams need a shared repository and governance workflow,

• portfolio decisions require reliable analytics and traceability,

• architecture outputs must be consumed by many non-architect stakeholders,

• integration with discovery, CMDB, or portfolio systems is required.

Until then, free and low-cost tools can be more than enough—provided the architect is disciplined. The real bottleneck is often not the tool but the operating model: ownership, update cadence, agreed viewpoints, publication discipline, and stakeholder engagement.

Practical recommendations for beginning and experienced EAs

For beginning enterprise architects

Start small. Use Archi or Sparx, model only what you can keep current, and publish what stakeholders actually use. Avoid the trap of building a perfect repository before proving relevance. One clear capability map and one credible application heatmap can create more trust than a repository nobody opens.[archimatetool]

A very effective starter pattern is:

• Archi for models,

• Excel for inventories,

• Power BI for a few visual reports,

• Sway as the story layer.[archimatetool]

For experienced enterprise architects

Use high-end platforms only when they fit a deliberate architecture operating model. If the organization needs enterprise-scale governance, auditability, analytics, and publication, then Bizzdesign, LeanIX, or HOPEX may be worth the cost. But do not mistake platform adoption for architecture maturity. A mature practice is defined by relevance, clarity, and update discipline, not by license size.[platform.softwareone]

The most mature pattern is often hybrid:

• a professional repository for governed architecture data,

• BI and reporting for analytics,

• and a lightweight story layer such as Sway, SharePoint, or another presentation surface for decision-makers.[support.microsoft]

The MCP server inventory

Building the enforcement layer for your agent estate

Author:  Wim Vanhoorne  ·  Enterprise Architect  ·  Moore Belgium

Published:  June 2026

Series:  Agentic AI & Enterprise Architecture  ·  Part 3 of 3

The floor plan exists. Every capability in the enterprise has a zone assignment. The architect knows which agent actions are free, which are supervised, and which are blocked.

None of that means anything until it is built.

The gap between an autonomy zone model and a governed agent estate is exactly one deliverable: the MCP server inventory. Not a technology asset register. Not a network diagram. An architectural decision record that maps enterprise capabilities to agent tools, agent tools to zone assignments, and zone assignments to enforcement mechanisms. The document that tells the platform team what to build, and tells the auditor what was decided, by whom, and why.

This is where the three-part argument closes. The architect who owns the entrance, the floor plan, and the enforcement layer can govern ten thousand agents without reviewing a single line of code.

What the MCP server inventory is not

Before defining what the inventory is, it helps to clear two common misunderstandings.

It is not an API catalogue. An API catalogue records what systems can do. The MCP server inventory records what agents are permitted to do. The distinction is the difference between capability and authorization. A system may expose fifty endpoints. The inventory may permit agents to invoke three of them, and specifies, for each of those three, under what conditions and with what governance controls.

It is not a security configuration. Security configuration is what the platform team produces when they implement the controls the inventory defines. The inventory precedes the configuration. It is the architectural input that makes configuration decisions traceable to business decisions rather than to individual engineers making their best judgment at implementation time.

The inventory is architecture documentation with operational consequences. Every entry is a decision. Every decision has an owner. Every owner is accountable when an agent acts within the boundaries that decision created.

The four elements every record needs

Each entry in the MCP server inventory describes one agent tool, one action an agent can invoke against one enterprise system. Four elements define the record completely.

The first is the enterprise capability the tool touches. Not the system name. The capability, the business function the system performs. Financial reporting. Accounts payable. Financial compliance. Anchoring the tool to a capability connects the inventory to the capability map, which means every tool record inherits the risk and classification context that the capability already carries. It also means the inventory speaks the language of the business, not the language of the platform.

The second is the agent action itself, the specific operation the tool performs. Read general ledger balances. Create vendor invoice record. Release vendor payment. These are distinct tools with distinct zone assignments. The granularity here is deliberate. An agent that can read a balance is not equivalent to an agent that can release a payment. The inventory must reflect that distinction explicitly, not leave it to platform configuration to infer.

The third is the zone assignment: Free, Supervised, or Blocked. This is the output of the zone mapping exercise from Part 2 of this series, applied at the tool level. One field. Non-negotiable. The zone assignment is not a recommendation. It is a constraint that the enforcement mechanism must implement.

The fourth is the enforcement mechanism, the specific control that gives the zone assignment operational meaning. For free zone tools: unrestricted invocation, logged for audit. For supervised zone tools: approval workflow required before execution, with the approver role defined explicitly. For blocked zone tools: not registered in the MCP server. A tool that does not exist cannot be invoked. The enforcement mechanism for a blocked zone is absence, not restriction.

From inventory to implementation

The inventory is the EA deliverable. What happens next belongs to the platform team, and the handoff is clean precisely because the inventory has done the architectural thinking in advance.

The platform team takes each MCP server record and makes three implementation decisions. Which tools get registered in the MCP server at all, blocked zone tools do not. Which tools get an approval wrapper, supervised zone tools require one, with the approver role and escalation path specified in the inventory record. Which tools execute freely, free zone tools are registered and invocable without additional workflow, but every invocation is logged.

That is the full implementation brief. The platform team does not need to make governance judgments. Those judgments are already made. The inventory is the specification. The platform team builds to it.

The inventory as a compliance instrument

The MCP server inventory is not only a governance tool. It is the evidence base for EU AI Act compliance, and for every board-level conversation that follows an agent incident.

The EU AI Act's high-risk AI obligations, effective August 2026, require organizations to demonstrate that autonomous systems operating on consequential data do so within defined, documented, and auditable boundaries. The MCP server inventory is that documentation. Every supervised zone tool has an approver role on record. Every blocked zone tool has an explicit exclusion on record. Every free zone tool has an audit log attached. The inventory does not create compliance. It makes compliance demonstrable.

When an agent incident occurs, and in an estate of any scale, one will, the first question is always: what was this agent authorized to do? The inventory answers that question in one document, at the tool level, with a traceable decision chain from business capability to zone assignment to enforcement mechanism. That is not a small thing. That is the difference between an organization that can explain its agent governance and one that cannot.

The inventory is never finished

One final point that the practitioner needs to hear, because it is the one most frequently omitted from governance frameworks.

The MCP server inventory is not a project deliverable. It is an operating model responsibility.

Agent estates evolve. New capabilities are automated. Existing tools are extended. Business risk profiles change. Zone assignments that were correct at deployment may not be correct eighteen months later. The inventory must be maintained with the same discipline as the capability map it connects to, reviewed at each architecture checkpoint, updated when capabilities change, and audited annually against the actual configuration of the MCP servers in production.

The architect who builds the inventory and then moves on has built a document. The architect who builds the inventory and maintains it has built a governance instrument. The distinction matters because the agent estate will outlive the project that created it, and the governance obligations that come with it do not expire.

The argument, closed

Three articles. One chain of reasoning.

Enterprise architecture must own the MCP governance layer, because the entrance to the enterprise for AI agents is an architectural decision, not a development decision.

The autonomy zone model is the floor plan, a structured, auditable assignment of every agent action to a zone that defines the conditions under which that action may proceed without human approval.

The MCP server inventory is the enforcement layer, the architectural decision record that translates zone assignments into platform specifications, compliance evidence, and operational accountability.

The architect who holds all three owns the governance of the agentic enterprise. Not by reviewing agent code. Not by sitting in every deployment decision. By designing the structure within which agents operate, and maintaining that structure as the estate grows.

Appendix  ·  MCP server inventory, reference format

The following table illustrates the four-column structure applied to a representative finance domain. Zone color coding: green = Free, amber = Supervised, red = Blocked.

Autonomy zones

The architect's control model for agentic AI

Author:  Wim Vanhoorne  ·  Enterprise Architect  ·  Moore Belgium

Published:  June 2026

Series:  Agentic AI & Enterprise Architecture  ·  Part 2 of 3

The entrance is designed. The door is built. The governance layer is in place.

Now the agents are inside the building, and nobody has decided which rooms they can enter.

That is where most agentic AI deployments are today. The integration problem got solved. The governance problem got deferred. Organizations have agents operating across their enterprise systems with no architectural model defining where autonomous action is permitted, where human judgment is required, and where certain actions are simply off the table regardless of context.

The autonomy zone model is the answer to that deferred question. It is not a security policy. It is not a compliance checklist. It is an architectural construct, the floor plan that tells every agent, every platform, and every governance team exactly which category of action they are dealing with.

What an autonomy zone actually is

An autonomy zone is an architectural boundary that defines the conditions under which an AI agent may act without human approval.

The key word is conditions, not capabilities. The question is not what the agent can technically do. The question is what the organization has decided it should be permitted to do on its own, and under what circumstances that permission changes.

TOGAF practitioners will recognize this as a constraint applied at the architecture definition stage, a policy that shapes solution design before implementation begins. The autonomy zone model applies that same principle to agent behavior: define the boundaries in the architecture, enforce them in the platform, audit them in operations. The sequence matters. Constraints defined after deployment are not architecture. They are damage control.

The three-zone model

Every agent action in an enterprise falls into one of three zones. The architect's job is to assign them, not the developer, not the platform team, not the security operations center after an incident.

Free zones

Free zones contain actions that are high-volume, low-ambiguity, and fully reversible. Agents operating in free zones act without requesting approval. Reading data, generating reports, populating dashboards, drafting content for human review, routing notifications. The defining characteristic is that if the agent gets it wrong, a human can correct it without material consequence. These zones are where automation delivers its clearest ROI and where human-in-the-loop requirements would simply destroy the value of having an agent at all.

Supervised zones

Supervised zones contain actions that are consequential, externally visible, or irreversible. The agent proposes, a human approves, the action executes. Creating purchase orders, modifying master data, sending external communications, triggering financial transactions, updating customer records. The agent does the work of preparation and judgment. The human provides the authorization. This is not a failure of AI capability. It is a deliberate architectural choice about where human accountability must remain in the loop.

Blocked zones

Blocked zones are different in kind from the other two. These are not actions that require approval. They are actions that are never permitted, regardless of context, regardless of who asks, regardless of how the request is framed. Deleting audit logs, modifying access controls, self-modifying the agent's own instructions, acting on instructions embedded in external content. Blocked zones are hard architectural constraints, not runtime policy decisions. They live in the architecture because they are too consequential to be managed by any approval workflow.

How to map your enterprise

The practical question is how an architect identifies which actions belong in which zone. Two axes determine the assignment: risk and reversibility.

Risk asks: if this action produces an incorrect result, what is the business impact? Low risk actions, read-only, internal, bounded in scope, belong in the free zone. High risk actions, financial, regulatory, reputational, or cross-organizational, belong in the supervised zone or the blocked zone depending on whether they should ever happen at all.

Reversibility asks: if this action produces an incorrect result, can it be undone? Fully reversible actions can tolerate autonomous execution because the correction cost is low. Irreversible actions, sent communications, committed transactions, deleted records, require human authorization precisely because the correction cost is high or the action cannot be corrected at all.

The instrument for this mapping is the capability map. Every organization running TOGAF-based EA already has one, or is building one. The autonomy zone assignment is a property of each capability, not a separate exercise. For each capability that agents will touch, the architect adds two attributes: risk level and reversibility. The zone assignment follows from those two attributes. It is not a judgment call made capability by capability. It is a rule applied consistently across the map.

The zone model without enforcement is just a diagram

Autonomy zones defined on paper and not enforced in the platform are architectural intent, not architectural governance.

MCP is the enforcement layer. Each MCP server exposes a defined set of tools, actions the agent can invoke. The zone assignment determines which tools require an approval workflow before execution, which tools execute freely, and which tools are simply not exposed at all. A tool that does not exist in the MCP server cannot be invoked. A blocked zone action that has no MCP tool cannot be taken. The architecture enforces what the policy describes.

This is why the autonomy zone model and the MCP governance design are inseparable. You cannot enforce zones you have not defined. You cannot define zones that mean anything without an enforcement layer. The two must be designed together, by the same discipline, before either goes to the platform team to build.

What breaks without this

Organizations that deploy agents without an autonomy zone model do not end up with ungoverned agents by accident. They end up with ungoverned agents by default, because every agent, in the absence of defined boundaries, defaults to what it is technically capable of doing.

The failure pattern is consistent. An agent is deployed to handle a routine process. It handles that process well. A slightly adjacent request arrives. The agent handles that too, because nothing told it not to. The adjacent request involves an action with higher consequence. The agent has no mechanism to recognize the difference. The action executes. The incident happens. The governance conversation begins.

That conversation, after the fact, is always the same. Someone asks why the agent was permitted to do that. The honest answer is: because nobody decided it shouldn't. Not because the technology failed. Because the architecture was never designed.

Coming next in this series

The zone model tells you what each agent is permitted to do. The MCP server design tells you how that permission is enforced in practice.

Part 3 of this series goes to the engineering of that enforcement layer: how to structure your MCP server inventory, how to translate zone assignments into tool exposure decisions, and how to build an architecture that a governance team can audit, a platform team can implement, and an agent fleet can operate within, without anyone needing to review a single line of agent code.

Part 3:  The MCP server inventory, building the enforcement layer for your agent estate.

MCP The plug nobody planned for

MCP is the new integration governance layer, and enterprise architects, not developers, must own it.

Author:  Wim Vanhoorne  ·  Enterprise Architect  ·  Moore Belgium

Published:  June 2026

Series:  Agentic AI & Enterprise Architecture  ·  Part 1 of 3

Every building has an entrance

The architect designs it. The entrance defines who gets in, under what conditions, and with what level of oversight. The carpenter builds the door. The locksmith specifies the mechanism. Each discipline does what it does best, in the right sequence.

Nobody argues about who owns the entrance. The sequence makes it obvious.

Enterprise architecture is facing exactly that situation right now, and most teams haven't noticed yet.

A fragmentation problem that APIs didn't solve

When AI agents first appeared in enterprise environments, each one needed its own bespoke connection to each enterprise system. A Copilot agent accessing SharePoint required one custom integration. The same agent touching a database required another. An agent in D365 talking to a ticketing system required a third.

The result was a many-to-many integration problem, identical in structure to the fragmentation that REST APIs solved a generation earlier. Every vendor built its own approach. Every enterprise maintained its own inventory of custom connectors. Architecture became a web of proprietary tunnels, each one impossible to govern consistently.

Model Context Protocol, MCP, is the standard that resolves this.

What MCP actually is

Released by Anthropic in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025, MCP is now an open standard co-governed by Anthropic, Microsoft, Google, AWS, and OpenAI. Every major AI vendor has adopted it. As of early 2026 it has surpassed 97 million monthly SDK downloads and over 10,000 active public servers.

The technical description is simple. MCP is a common wire protocol, built on JSON-RPC 2.0, that standardizes how AI agents discover and invoke tools, read enterprise data, and execute actions across systems. It abstracts three primitives: tools (actions the agent can take), resources (data it can read), and prompts (reusable instruction templates).

The analogy that has stuck is USB-C: one standard connector that replaced dozens of proprietary ones. An AI agent built against any major frontier model can, in principle, consume tools and data from any MCP-compliant server, regardless of vendor.

The architect designs the entrance

When a new building goes up, nobody asks the carpenter to decide what kind of people should have access to which floors. That question belongs to the architect. The carpenter's job starts once the access model is defined, not before.

MCP is the entrance to the enterprise for AI agents. It is the layer where access boundaries are drawn, where audit trails are generated, where approval workflows are enforced, where data visibility is scoped to least privilege.

If enterprise architecture does not define that model before the builders start, the builders will make their own decisions. Those decisions will be technically competent and architecturally ungoverned. You will end up with an entrance, but nobody planned it.

This is not a turf argument. It is a sequencing argument. Platform engineering implements the MCP servers. IT security hardens the deployment. EA defines what the entrance must achieve, what risks it must contain, and what governance obligations it must satisfy. That sequence is not controversial. What is controversial is that most organizations are currently running it in reverse.

The governance surface is already defined

Three external forces have already determined what the MCP governance layer must deliver. The enterprise architect does not need to invent these requirements, only to translate them into architecture decisions.

OWASP published the Top 10 for Agentic Applications in December 2025: the first formal taxonomy of risks specific to autonomous agents. Goal hijacking, tool misuse, identity abuse, memory poisoning, cascading failures. Every one of these risks materializes through the MCP layer. Every one of them requires an architectural response, access boundaries, approval thresholds, audit logging, identity verification, before a single agent goes to production.

The EU AI Act's high-risk AI obligations take effect in August 2026. Autonomous agents operating on enterprise data and triggering business actions will fall inside that scope for most European organizations. The audit trail MCP can generate is only useful if EA has defined what must be logged, retained, and reported. That definition does not come from the compliance team. It comes from the architecture.

Microsoft has already built its governance plane around MCP. Entra ID and Purview provide the identity and data governance surface. Microsoft Agent 365, generally available since May 2026, operates within that plane. Microsoft Foundry gives architects governed access to multiple AI models under a single governance surface. For organizations already on the Microsoft stack, the infrastructure exists. The architecture decisions do not.

The strategic risk is lock-in by default

There is one more dimension the architect must address before the builders start: vendor independence.

MCP's open governance, under the Linux Foundation, co-governed by competing vendors, means that an MCP-compliant connector built today works with any future model or agent framework. An agent architecture built on a proprietary orchestration layer compounds vendor lock-in at every layer of the stack.

The architect's job is to make that choice deliberately, not to discover it retroactively when the migration cost lands.

Three decisions that belong to EA

Before any MCP server goes into service, enterprise architecture must answer three questions.

Which enterprise systems will agents be permitted to access, and under what conditions? This is the access boundary map. It is the equivalent of the floor plan: which rooms are open, which require credentials, which require an escort. It is an EA deliverable.

Which agent actions require human approval before execution? Agents that trigger financial transactions, modify master data, or communicate externally on behalf of the organization are not equivalent to agents that read a report. The approval threshold model must be defined in the architecture before it can be enforced in the platform.

How will compliance with the EU AI Act be demonstrated? The audit trail MCP supports is only an asset if the retention requirements, reporting obligations, and incident response procedures are designed into the architecture from the start. Retrofitting governance onto a live agent estate is the agentic equivalent of trying to install a fire suppression system in an occupied building.

Coming next in this series

Defining the access boundary map is the first EA deliverable for the agentic enterprise. But the boundary map is only the floor plan.

The next question is harder: within the permitted access zones, which agent actions should require no human approval at all? Which should pause and wait? Which should be blocked entirely regardless of context?

That is the autonomy zone model, and it is where enterprise architecture moves from governance framework to operational intelligence.

Part 2:  Autonomy zones, the architect's control model for agentic AI

How enterprise architects can, and should,govern D365 Finance & Operations implementation quality

The solution architecture is signed off. The extensibility strategy follows Microsoft's guidelines. Integration patterns are documented in ArchiMate. The EA's work is done.

Then development starts.

And what actually gets built diverges from the architecture, one sprint at a time, in ways that don't appear in any architecture review, don't trigger any governance checkpoint, and don't surface until the first major platform upgrade lands eighteen months after go-live.

This is the EA's blind spot in ERP implementations. And in D365 Finance & Operations, where customization pressure is high and the stakes of getting it wrong are architectural, not just technical, it is a blind spot worth closing.

Why Custom Code Is an Architecture Decision

Enterprise architects work at the level of patterns, principles, and constraints. The temptation is to hand off once the blueprint is complete. In D365 FO, that handoff is premature.

Every X++ customization is an architectural decision in disguise. The choice between overlayering and extension patterns, between modifying Microsoft's base code directly versus extending it through Chain of Command and event handlers, determines the upgrade path for the next ten years. An overlayered customization that works perfectly in the current release becomes a breaking change in the next. A portfolio of those decisions, accumulated across two years of sprints, becomes a structural constraint that the architecture review never captured.

Microsoft moved D365 FO to a pure extension model for a reason. Extensions are upgrade-safe; overlayering is not. When developers bypass that model under deadline pressure, and they will, absent governance, they are making an architectural choice with architectural consequences. The EA needs to be in that loop.

The Tooling Landscape: What Exists and What It Does

Microsoft has built a surprisingly coherent set of quality controls into the D365 FO platform. Most EAs are not aware of them, because they sit below the line of sight of TOGAF-level governance. Understanding what exists is the prerequisite for positioning it in a governance model.

The X++ compiler and Visual Studio analyzers run best practice checks on every build. These checks enforce extension patterns, flag performance anti-patterns, identify unsafe data access, and surface a range of code quality issues. They are FXCop-equivalent rules for X++. The output is a set of best practice warnings and errors that can be made blocking in a CI/CD pipeline, meaning code that violates these rules cannot be merged into the main branch. This is the closest thing D365 FO has to an automated architecture compliance gate.

Azure DevOps build pipelines with Microsoft's standard build tasks for FO enforce the same checks in the continuous integration environment. The pipeline is where quality governance becomes structural rather than advisory. A properly configured pipeline does not ask developers to follow best practices, it prevents them from shipping code that does not.

Lifecycle Services (LCS) provides performance and health monitoring that can surface implementation quality issues at runtime. CPU patterns, query execution times, lock contention, these are the symptoms of architectural anti-patterns in custom code. LCS does not catch the root cause, but it makes the consequence visible in production.

FastTrack Architecture Insights and Success by Design provide the methodological layer. Microsoft's FastTrack program runs architecture reviews informed by thousands of implementations. Success by Design codifies best practices for extensibility strategy, integration patterns, ALM, and testing. These are EA-level resources, they operate at the level of patterns and principles, not individual code quality. The FastTrack Architecture Insights series, including sessions specifically on ALM strategy for FO apps, is underutilized by EAs who do not know it exists.

The D365 Implementation Portal and Implementation Guide on Microsoft Learn represent Microsoft's most recent consolidation of governance guidance. The Implementation Guide covers extensibility, data, integration, security, and ALM in terms that map directly to EA concerns. The Implementation Portal provides self-service assessments and checklists. These are not developer tools, they are governance frameworks that EAs can deploy.

What the EA Should Own in the Governance Model

Understanding the tooling is necessary but not sufficient. The EA's contribution is to position these tools within a governance model that makes quality a structural property of the project, not a dependent on individual discipline.

Three things belong in that model.

The first is the extensibility policy. Before a line of code is written, the EA needs to define, in writing, as a binding project constraint, that overlayering is not permitted, that extension patterns are mandatory, and that deviations require architectural sign-off. This is not a developer guideline. It is an architectural constraint with the same status as integration patterns and security policy.

The second is the quality gate. The CI/CD pipeline's best practice checks should be configured as blocking, not advisory. The EA does not need to configure the pipeline personally, but the EA does need to specify the requirement: code that triggers best practice errors cannot be promoted to the release branch. This translates the extensibility policy into an automated enforcement mechanism.

The third is independent validation. Sprint-level BP warning reports from the implementation partner are self-assessments. An independent architectural review, not at go-live, but mid-project, after the first substantive release, is the only mechanism that verifies the self-assessment against reality. The EA is the natural owner of commissioning and interpreting that review. It is architectural work: pattern compliance, extensibility risk, integration coherence. Two to five days of an independent architect's time, timed six to eight weeks before go-live, is the highest-leverage quality investment available.

The Gap in Standard EA Frameworks

TOGAF's Architecture Repository, ArchiMate's layered model, BDAT's business-technology alignment, none of these naturally capture implementation-level quality in a running ERP project. The architecture is governed at inception. What happens in the development phase, sprint by sprint, falls into the gap between the EA's delivery and the IT project manager's scope.

This is not a failure of the frameworks. It is a scope assumption that no longer holds in complex platform implementations. D365 FO customizations are not generic software development. They are platform-specific decisions with platform-specific constraints, upgrade implications, and long-term cost profiles. They belong in the EA's governance scope.

The tools are there. The Microsoft guidance is there. The gap is the EA's presence in the governance model, not just at the architecture review, but throughout the implementation, with a defined set of quality gates that outlast the project.

The Question That Changes the Dynamic

Enterprise architects are in a structurally powerful position in ERP projects. They have the seniority and the framework vocabulary to make quality governance a project requirement rather than a developer preference.

That power starts with one question, asked early and asked consistently: is the extensibility strategy that was agreed at architecture review being enforced at code level, and who, other than the implementation partner, has verified it?

If nobody has a clean answer, that is where the EA's work begins.

The Microsoft tooling referenced in this article includes: Visual Studio X++ best practice analyzers, Azure DevOps FO build tasks, Lifecycle Services health monitoring, FastTrack Architecture Insights (available on Microsoft Learn), the D365 Implementation Guide, and the D365 Implementation Portal. The F&O Implementation Best Practices, Patterns and Anti-Patterns resource on GitHub provides practitioner-level detail on common implementation mistakes and their architectural consequences.

In April 2026, Mercor, a U.S. AI company valued at about $10 billion, disclosed that it had been affected by a supply-chain attack tied to the open-source LiteLLM project. The lesson for enterprise architects is straightforward: the most important weakness in an AI-enabled business may not sit inside a model, but inside a dependency, connector, or agent buried in the delivery stack.

That is why AI security should not be treated as a side topic for the CISO alone. For enterprise architecture, AI changes the shape of trust, ownership, and control across business capabilities, platforms, and value streams.

AI is not the strategy

Enterprise architects should keep one principle clear: technology is a tool for achieving business goals, not a goal in itself. AI only creates value when it improves a real business capability such as customer service, decision support, operational efficiency, risk detection, or speed to market. When AI is introduced without a clear business purpose, it usually expands cost, complexity, and exposure faster than it improves outcomes.

That is why enterprise architecture must start with the use case, not the model. The key questions are practical. Which business process is being improved? Which decisions are being supported or automated? What data is being used? What happens when the output is wrong, manipulated, or incomplete?

What enterprise architecture must change

Most EA teams are still equipped to model applications, integrations, and technology standards. That is no longer enough. AI adds new architectural elements that cut across traditional boundaries: models, copilots, agents, prompts, vector stores, orchestration layers, connectors, and third-party AI services.

This means enterprise architecture must adapt in four ways.

First, architects need to model AI use cases, not just AI platforms. A generic “AI capability” box on a roadmap is not useful. Enterprise architects should document where AI assists, where it recommends, and where it acts on behalf of a user or process. That is the level where business value and business risk actually meet.

Second, architects need to make trust boundaries visible. In an AI-enabled workflow, trust can be crossed when a document enters a RAG pipeline, when a copilot calls a connector, when an agent triggers an API, or when a third-party model receives internal context. These flows should be treated as first-class design concerns, not implementation details.

Third, enterprise architecture must include the AI supply chain. Libraries, model providers, plugins, gateways, and orchestration tools are now part of the architectural risk surface If they are not inventoried, owned, and reviewed, they become invisible dependencies with direct business impact.

Fourth, architecture governance must move from static standards to operational guardrails. In the AI era, it is no longer enough to publish principles and assume delivery teams will work out the rest.

Practical design rules for EAs

Enterprise architects do not need to become data scientists or red teamers. They do need to define practical rules that guide design and delivery.

A useful baseline includes the following:

• Every AI use case must have a business owner and a technical owner.

• No production AI use case should run without logging, access control, and a rollback or kill-switch option.

• Agents and connectors should follow least-privilege principles; an AI assistant should never inherit broad human permissions by default.

• RAG solutions should classify and filter content before indexing, not after leakage happens.

• High-impact decisions in finance, legal, HR, or safety-related operations should remain human-accountable, even when AI is involved.

These are not security add-ons. They are architecture decisions that shape whether AI remains a business accelerator or becomes a source of unmanaged exposure.

Governance must become architectural

Many organizations respond to AI by creating parallel governance structures. That usually adds friction without solving the real problem. A better approach is to embed AI into the gates that already matter: architecture review, procurement, change management, secure SDLC, and third-party risk management.

This is where enterprise architects can add disproportionate value. They sit at the intersection of strategy, operating model, and delivery. They can translate legal and security concerns into architecture patterns, design constraints, and review criteria that delivery teams can actually use.

An EA team that adapts well will do three things consistently. It will maintain an inventory of AI-enabled business capabilities and dependencies. It will publish reusable architecture patterns for copilots, agents, and enterprise RAG. And it will make trust, ownership, and control explicit in every important AI-related design decision.

A practical agenda for the next 12 months

For AEA members, the priority is not to create a separate “AI architecture” discipline. The priority is to modernize enterprise architecture so it can govern AI in the same disciplined way it governs applications, platforms, and transformation roadmaps.

A practical agenda is short:

• Extend application and integration inventories to include models, agents, connectors, and key AI dependencies.

• Update architecture review checklists with AI-specific questions on data, trust boundaries, permissions, and vendor dependencies.

• Publish two or three reference patterns for common scenarios such as enterprise search, copilots, and agent-based automation.

• Work with security and legal to define minimum controls that must be present before an AI use case moves into production.

• Track AI Act milestones so high-risk and transparency-related use cases are visible before compliance deadlines arrive.

By August 2, 2026, a major part of the EU AI Act starts to apply, including transparency obligations and rules affecting many high-risk systems. Organizations that still do not know which AI systems they run will not have a compliance problem first. They will have an architecture problem.

Closing thought

The role of enterprise architecture is not to slow innovation down. It is to make innovation usable, governable, and scalable. In the AI era, that means designing for trust as deliberately as designing for integration, performance, or cost.

The organizations that succeed with AI will not be the ones with the most pilots. They will be the ones whose enterprise architects can connect business goals, technology choices, and trust boundaries into one coherent operating model.

Most organizations treat AI as a technology decision. Enterprise architects know better, it's an architecture decision. And it starts at the wrong layer every time.

The pattern is familiar: a vendor demo impresses the C-suite, a tool gets procured, and IT is handed the integration problem. Months later, adoption is low, governance is unclear, and the business wonders why the ROI isn't there.

TOGAF tells us why. Every layer of the Business-Data-Application-Technology stack has something to say about AI, and skipping the business layer first is exactly how you end up with the right tool solving the wrong problem.

Here is how the 3+1 AI architecture layers map to TOGAF, and what each one means for your business.

🏛️ Business Architecture, where AI must start

TOGAF's Business Architecture defines capabilities, processes, value streams, and the operating model. This is where AI earns or loses its mandate.

The first AI layer, Understanding (NLU), lives here. Before selecting a model, the architecture question is: what business capability are we augmenting? Contract review? Customer intake? Supply chain analysis? The answer determines whether you need deep contextual understanding across long documents or fast intent classification across short queries.

Standards that matter here: intent classification, Named Entity Recognition (NER), and context windows. A 1M-token context window is not a technical luxury, it is the difference between an AI that reads your full tender document and one that reads a summary someone else wrote. That is a business capability decision before it is a technology decision.

Business benefit: Capabilities are correctly scoped before procurement. The AI augments a defined process rather than searching for a use case after deployment.

📊 Data Architecture, the layer that determines truth

TOGAF's Data Architecture governs information assets, data flows, master data, and quality standards. This is where AI reliability is either engineered or left to chance.

RAG (Retrieval-Augmented Generation) is a Data Architecture concern. It defines which data sources the AI can query, under what governance rules, and with what freshness guarantees. Without a data architecture decision, the AI answers from its training data, which may be months old, generically trained, and entirely disconnected from your business context.

RBAC (Role-Based Access Control) is equally a Data Architecture concern. The moment AI can access internal documents, CRM data, or operational systems, your data governance framework must define who can ask what, and what the AI is permitted to surface in response.

Independent research confirms that RAG reduces AI hallucinations by up to 71% on average. That is not a model quality improvement, it is a data architecture improvement.

Business benefit: AI answers from your data, not generic training. Governance is defined before deployment, not retrofitted after a data leak.

⚙️ Application Architecture, where reasoning becomes process

TOGAF's Application Architecture defines the application portfolio, services, APIs, and integration patterns. This is where AI moves from answering to acting.

The second AI layer, Reasoning, maps directly here. Chain-of-thought reasoning is the AI equivalent of a decision service: structured, auditable, multi-step logic that can be integrated into existing process flows. Tool calling is an API integration pattern: the AI invokes an external service, retrieves a result, and incorporates it into its response, exactly as any orchestration layer would.

MCP (Model Context Protocol) is an emerging open standard for AI-to-application integration, the equivalent of REST for AI tool use. Architects who define MCP integration patterns now will have a reusable, platform-agnostic connector framework as agentic AI matures.

Multi-step memory, the AI's ability to maintain state across a sequence of actions, is a session management concern. It determines whether the AI can execute a multi-step workflow or collapses after the first response.

Business benefit: AI is integrated as a service within the application portfolio, not bolted on as a separate tool. Automation is bounded, auditable, and connected to existing business logic.

🖥️ Technology Architecture, the ecosystem that enables or limits

TOGAF's Technology Architecture covers infrastructure, platforms, security standards, and interoperability. This is the +1 layer, the Ecosystem, and it is where most AI projects either scale or stall.

Platform choice here is not neutral. Microsoft Copilot runs natively on Azure AD and Microsoft Graph, inheriting FedRAMP and HIPAA compliance through existing M365 governance. Gemini Enterprise connects to Google Cloud, Workspace, Salesforce, and SAP via centralized agent governance. Claude and ChatGPT offer flexibility via API but require explicit integration architecture decisions.

For organizations already invested in M365, the architecture principle is clear: leverage existing governance frameworks rather than introducing parallel ones. Copilot's native RBAC, sensitivity label enforcement, and SharePoint/Outlook data access are not features, they are architecture assets already paid for.

Business benefit: Technology selection aligns with existing platform investments and compliance posture. Integration costs are minimized. Security governance does not need to be reinvented.

⚠️ Cross-cutting concern: Reliability

In TOGAF terms, reliability is an architecture principle, non-negotiable, applicable across all layers, and defined before technology selection.

In the AI layer model, reliability surfaces differently in each TOGAF domain. In Business Architecture: does the AI answer the right business question? In Data Architecture: is it grounded in current, governed data? In Application Architecture: does it reason transparently and produce auditable outputs? In Technology Architecture: are access controls enforced and actions logged?

Independent benchmarks (Vectara HHEM, AA-Omniscience, BenchLM 2026) show that model choice influences but does not determine reliability. Claude leads on calibrated uncertainty, it refuses rather than guesses, producing lower error rates on knowledge benchmarks. Gemini leads on grounded summarization. ChatGPT performs strongest with live web access enabled.

The architecture conclusion: reliability is engineered across all four TOGAF layers, through RAG on governed data, human-in-the-loop validation for high-stakes outputs, RBAC for access control, and audit logging for every AI action.

You cannot buy reliability. You design it in.

How do the major platforms perform, mapped to the TOGAF stack?

(see comparison)

The ADM implication

TOGAF's Architecture Development Method is iterative by design. AI does not change the method, it changes the urgency of getting it right.

Phase A (Architecture Vision) must define which business capabilities AI will augment, not which tools will be deployed. Phase B (Business Architecture) must map AI to value streams before Phase D (Technology Architecture) selects a platform. Phase E (Opportunities & Solutions) must assess AI integration against the existing application portfolio, not evaluate AI in isolation.

Organizations that skip to Phase D, and most do, end up with capable tools in the wrong architecture. The business layer is not optional. It is the only layer where value is created or destroyed.

The real EA question is not "which AI platform is best?"

It is: at which TOGAF layer does your current architecture have the most critical gap?

Business capabilities undefined → start at Phase B before touching technology. Data ungoverned → RAG without a data architecture is a liability, not an asset. Application integration unplanned → tool calling without an API governance framework creates shadow integrations. Technology platform misaligned → procuring AI outside your existing compliance posture creates duplicate governance overhead.

And if you are already running Microsoft 365 with Azure AD governance: your Technology Architecture foundation is in place. The constraint is not platform, it is business and data architecture maturity.

Next week: AI agents, and what TOGAF's governance framework needs to look like when AI moves from answering to acting autonomously inside your business processes.

Where in the ADM cycle is your organization today, and which layer is the real constraint?

The article is deliberately positioned for an audience that already speaks TOGAF, but the business benefit framing keeps it accessible to C-suite readers who don't. Each layer closes with a business benefit statement rather than a technical conclusion, which is the right register for a CEO/CIO audience being guided by an EA practitioner.

In early 2026, CrowdStrike, Flashpoint, and CyberProof independently published their threat analyses of 2025. Three sources, one conclusion:

Attackers are no longer breaking in. They're logging in.

Stolen identities, session tokens, and cloud credentials have rendered the perimeter model definitively obsolete. Agentic AI is now scaling this to machine speed.

For a SOC, this is operational news. For an enterprise architect, it is a design failure that requires structural correction.

What This Says Architecturally

The reports don't document a new attack technique. They confirm that identity is the new perimeter — and that most organizations have not aligned their architecture accordingly.

That is an information architecture problem. Identity is still managed as an IT tool rather than positioned as the foundation on which application and business capabilities rest. The gap between principle and implementation is wide — and is now being actively exploited.

Three architectural consequences are immediate:

Least privilege is a design constraint, not a configuration setting. Over-provisioned access rights are not primarily an IAM problem — they are the result of applications that define access too broadly. This must be resolved in the design, not patched in after the fact.

Data classification replaces network segmentation as the protection logic. When the perimeter disappears, the data determines the protection level. That requires the information architecture to make this explicit — and to translate it consistently across the application and technology layers.

Architectural debt is now a quantifiable security risk. The window between vulnerability disclosure and mass exploitation effectively vanished in 2025. Legacy systems and undocumented integrations are no longer just technical liabilities — they are open attack vectors.

The EA's Role Here

Threat intelligence traditionally lands with the security team, which converts it into operational measures. The EA function typically sits outside that loop.

That is precisely the problem. The 2026 reports don't describe operational incidents — they describe structural shifts in the attack landscape. That is EA territory.

The architect who picks up this signal translates it into three concrete contributions: reviewing principles for perimeter-based assumptions, prioritizing identity-first capabilities on the roadmap, and quantifying architectural debt as risk input for the board.

That last one is also a communication opportunity. "Attackers are logging in as your employees using permissions nobody needs anymore" is a board conversation. "We have an IAM maturity gap" is not.

Conclusion

Security is not a layer on top of the architecture. It is a property of the architecture itself.

The 2026 reports don't make that a new idea. They make it important and they give the enterprise architect concrete grounds to have that conversation now.

Enterprise Architecture has an image problem. Too slow, too abstract, too disconnected from the business. POPIT offers a refreshingly simple framework to close that gap — not by producing more diagrams, but by asking the right questions.

If you're honest with yourself as an EA practitioner, you know it: architecture documents go largely unread, transformation programs stall on organizational resistance, and the business keeps asking what they're actually getting out of all those models. The challenge isn't the quality of our frameworks — it's their relevance in a world that changes faster than our review cycles.

POPIT — originally developed as a holistic analysis method in business analysis — represents five interconnected dimensions of every organizational change:

What makes POPIT powerful isn't the completeness of its five categories — other frameworks have that too. It's the equality between them. Too many architecture exercises start at the T and work their way backwards to the P. The result: technically sound solutions that stall on processes left unchanged, people who don't understand the new way of working, or an organizational structure that completely undermines the governance of the new platform.

"Implementing a new ERP without fundamentally rethinking your processes and roles is just an expensive way to digitize existing problems."

Traditional EA operates in long-horizon cycles: architecture principles, capability maps, three-year roadmaps. These have value — but only as a complement to a practice that stays relevant in the day-to-day. POPIT fits naturally into that faster EA mode, as a conversation structure rather than a deliverable.

Suppose a business unit asks for faster quoting through a new CRM. The EA reflex is a capability assessment and an integration map. What if the first question instead were: do we cover all five POPIT dimensions? Who are the people who will need to work differently? What role does the sales manager play in the new approval process? What level of data quality is needed for accurate pricing? By introducing this structure early in the conversation, you position EA as a thinking partner — not a bottleneck.

The real power of POPIT lies in its connection to measurable business outcomes. Each dimension maps to a distinct results area:

An architecture that scores well only on the T dimension while underperforming on People and Organization will rarely achieve the expected business results. POPIT forces architects and business stakeholders alike to have this conversation explicitly — ideally before the first sprint, not after.

POPIT doesn't need to become a formal artifact. Start with a simple 90-minute POPIT canvas workshop for every significant change initiative. Bring business owners and IT leads together to jointly populate all five dimensions. Which dimensions carry the most uncertainty? Where are the risks concentrated? That output — half a page of sticky notes — is often more valuable than an elaborate architecture document nobody reads.

The EA practitioner who wants to stay relevant in 2026 is not a drawer of towers. They're a facilitator of informed choices. POPIT is a simple but powerful compass for that role: it keeps attention on the whole picture, anchored in the outcomes the business actually needs.

Architecture is not a final deliverable. It's an ongoing conversation about how people, processes, and technology work together to create value. POPIT keeps that conversation whole.

How to get started : https://sway.cloud.microsoft/4WcENotnToF5nJfx?ref=Link

For the Association of Enterprise Architects (AEA) community, the release of Dynamics 365 version 10.0.47 (March 2026) represents a fundamental paradigm shift. We are witnessing the evolution of ERP from a monolithic database with rigid API layers into a sophisticated, context-aware ecosystem. The linchpin of this transformation is the ERP MCP Server (Model Context Protocol).

Architectural Framework: From APIs to Intent

Traditionally, integrations and AI interactions were built upon technical "access surfaces": OData endpoints, custom services, and complex Dataverse mappings. This created a brittle structure with high technical debt.

The ERP MCP Server introduces a standardized abstraction layer between the Large Language Model (LLM) and the ERP business logic. Instead of point-to-point integrations, MCP enables the AI to interpret the semantic structure of the data. For an Enterprise Architect, this implies:

• Decoupling of Logic: The AI "reasons" across data entities without requiring every interaction to be pre-defined.

• Unified Governance: Security roles and audit trails are inherited directly from the D365 core, mitigating "Shadow AI" risks.

Cross-Domain Intelligence: Practical Case Studies

The power of v10.0.47 lies in dissolving the silos between Finance, SCM, and HR via a shared contextual protocol.

1. Human Capital & Operations Alignment: An AI agent can now perform real-time Skill Gap Analysis. Query: "Which production lines in Zone B are at risk due to expiring safety certifications?" The MCP server correlates Worker data (HR) with Production status (SCM) instantly.

2. Conversational Warehousing: Optimized for wrist-mounted scanning, the system allows operators to request context: "Is there an alternative location for this item with an earlier expiration date?" The AI autonomously navigates the Warehouse Management logic.

Competitive Landscape: The Race to Agentic ERP

While Microsoft leverages the open-standard philosophy of MCP, other major vendors are pursuing proprietary paths toward "Agentic ERP":

• SAP: Relies on Joule and the SAP Datasphere to create a "Graph-based" integration. It is highly effective but remains a "clean core" play within the SAP ecosystem.

• Oracle: Focuses on vectorized search directly within the database layer (OCI HeatWave), prioritizing raw data performance.

• Salesforce/Workday: Utilizing Metadata Clouds (Agentforce/Illuminate) to power autonomous process agents.

Architectural Advantage: Unlike "walled garden" approaches, Microsoft’s MCP strategy focuses on Interface Standardization. By mapping AI to the Data Model Context rather than specific APIs, D365 reduces the "translation layer" that architects must maintain, offering superior flexibility for multi-vendor AI strategies.

Risks and Roadmap: Toward the "Agentic" Enterprise (v10.0.48+)

Architects must prepare for the transition to a "Copilot-first" infrastructure:

• Data Hygiene: The MCP server is a magnifying glass; poor master data leads to inaccurate AI reasoning.

• IAM & Security: A rigorous review of Security Duties is mandatory, as the AI operates within the user's security context.

• The Horizon (v10.0.48+): We are moving from Human-in-the-loop (10.0.47) to Autonomous Execution. Future agents will not just signal a late supplier but independently propose and reroute purchase orders based on historical performance.

Conclusion

Version 10.0.47 transforms Dynamics 365 into an intelligent operating system. For the enterprise, this results in a drastic reduction in integration complexity and a significant acceleration of the decision-making cycle.

Model Context Protocol in Dynamics 365 Finance & Operations

Despite being valuable data, lately it shows a worrying downward trend. A trend that portrays a steady decline of Enterprise Architecture.

Read the entire article here.

#EnterpriseArchitecture #Architecture #TOGAF #BizzDesign

https://ea-stories.blogspot.com/2023/02/the-decline-of-enterprise-architecture.html

All these teams and working groups are looking for capability-centric collaboration.

Read the entire article here.

#EnterpriseArchitecture #Capability #BusinessArchitecture #Architecture

https://ea-stories.blogspot.com/2022/12/the-need-for-capability-centric.html

More specifically, organisational ignorance is the main cause of the continuous immaturity of Enterprise Architecture within an organisation. That is, if you're lucky... Usually, it is this ignorance that leads to a complete failure of Enterprise Architecture.

Read the entire article here.

#Architecture #BusinessArchitecture #Capability #EnterpriseArchitecture #Strategy #Zachman

https://ea-stories.blogspot.com/2022/11/ignorance-is-why-enterprise.html

Read the entire article here.

#ArchiMate #Architecture #Drivers #EnterpriseArchitecture #EA #Goals #Principles #Strategy #TOGAF

https://ea-stories.blogspot.com/2022/10/making-sense-of-strategy.html

Read the entire article here.

#Architecture #Complexity #EnterpriseArchitecture #EA #Principles #Requirements #Standards

https://ea-stories.blogspot.com/2022/09/untangle-complexity-using-enterprise.html

Read the entire article here.

#OpenGroup #TOGAF #EnterpriseArchitecture #DYA #EA

https://ea-stories.blogspot.com/2022/08/the-art-of-architecture.html

Read the entire article here.

#architecture #certification #enterprisearchitecture #MasterArchitect #OpenCA #OpenGroup

https://ea-stories.blogspot.com/2022/07/enterprise-architecture-craftmanship-22.html

Why does the maturity of #architecture still lag behind in this sector?

Read the entire article here.

#EnterpriseArchitecture #EA #ArchitectureInHealthcare

https://ea-stories.blogspot.com/2022/06/why-architecture-in-healthcare-stays.html

Read the entire article here.

#LEGO #principles #architecture #enterprisearchitecture #EA

https://ea-stories.blogspot.com/2022/06/lego-and-architecture-principles.html

#EA #EnterpriseArchitecture #MasterArchitect #OpenCA #OpenGroup 

https://ea-stories.blogspot.com/2022/05/enterprise-architecture-craftmanship-12.html

Great Achievement for India Enterprise Architecture (IndEA) !!

The India Enterprise Architecture (IndEA) Framework has been notified as a national standard.

Find all the details in this article.

https://www.linkedin.com/pulse/fruition-indea-national-standard-initiate-innovate-dr-pallab/

The Article is published by :-

Dr. Pallab Saha Chief Architect,

The Open Group & President, Association of Enterprise Architects (India)

Web: www.opengroup.org

My name is Aderemi Ajagbe. I am a graduate student in the Enterprise Architecture degree program at Penn State World Campus.

This survey is part of my capstone project for the degree program. My research topic is Enterprise Architecture (EA) and Business Innovation. I invite you to participate in a brief survey designed to capture which of the EA focus area contribute more to business innovation. The survey does not collect personally identifiable information (PII). All of the responses will be kept confidential.

Also, the survey may ask which industry that you work. However, it will not ask for company names or other identifiable or disclosure information.There are a maximum 20 survey questions. It should take 5-10 minutes to complete.This survey was developed and is being distributed using the Qualtrics system.

Please follow the link below to access the survey.

https://pennstate.qualtrics.com/jfe/form/SV_eD9ELMmkkC4lvSZ

If there are questions about the survey or results please contact me at aba5332@psu.edu

Thank you for your time and participation.

Kind Regards,

Aderemi Ajagbe

• Corporate Digitization – Technologies have continued to mature in 2017 and ‘digitization’ has moved beyond a buzzword. Business and tech executives continue to execute ‘digital transformations’ that bring greater automation, user-self-service, and enable advanced eCommerce and SMAC techniques to engage with customers.

• Artificial Intelligence (AI), Machine Learning and Cognitive technologies – Tech analysts will remember 2017 as the year when business world finally started getting serious about the disruptive potential of AI. The tech Oligopoly – Apple, Amazon, Facebook, Google and Microsoft – announced large investments in AI and began showcasing solution offerings for consumers and businesses. 2018 is also likely to see startups, tech-service firms and the academia addressing the skill shortage.

• Big Data – Analytics, aggregation and visualization – We create 2.5 quintillion bytes of data every day; and over 90% of the data in the world today has been created in the last two years alone. As the challenges of big-data are being understood, innovative applications are highlighting potential to glean insights from the aggregated sources.

• Internet of Things (IoT) – Internet of Things (IoT) holds a lot of promise in machine-to-machine communication enabling ‘smart’ devices. IoT is really an aggregation of technologies with sensors that gather data, machine-to-machine communication and networks to a ‘gateway,’ big-data and analytics to enable storage, analysis and review of the findings. Innovative ideas range from applications in wearables, smartphones, smart meters, vehicles, factories, machines to other places where imagination takes us.

• Immersive Experiences, Virtual Reality and gaming – A combination of immersive and Virtual Reality technologies have been raising consumer expectations of video games. These technologies, enabled by advances in hardware and high performance computers, are beginning to blur the line between the physical, digital and simulated worlds, creating a sense of immersion.

• Voice recognition and Voice Activated UI – Adoption of voice recognition and voice activated technologies have been advancing at a fast pace. Voice based applications in the corporate world are also continuing to make strides. Widespread adoption of Interactive voice response (IVR) at call centers and for CRM based solutions are beginning to enhance productivity by allowing computers to interact with humans through the use of voice input.

• Blockchain – Bitcoin technology – The blockchain technology – popularized by digital currency Bitcoin – is increasingly being used to enable trust across industries. The underlying blockchain technology is a trust based protocol enabled by globally distributed, secure platform that enables a ledger or database where value could be stored and exchanged without powerful intermediaries.

• Technologies from Self-Driving cars – Auto manufacturers, ride share and technology companies are advancing research and development of self-driving cars. 2017 also saw a lot of mergers and buyout of niche technology companies. Autonomous vehicles are the leading edge of artificial intelligence investment and development and investments in that sector is a precursor of things to come in fields like natural language processing, image recognition, and others as these technologies gain commercial momentum.

• Robotics and automation – Automation, and use of bots aided by emerging techniques like artificial intelligence and machine learning are advancing at fast pace. Intelligent machines and ‘bots’ are already being employed in ways we never thought possible a few years ago. However, automation and robotics continues to be niche and fragmented business. Most large companies and manufacturers aggregate and integrate services from small, niche suppliers innovating on automation and robotics.

• Enabling Digitization – Organizations are interested in solving specific problems using some of these technologies. Such corporate digitization efforts translate to opportunity for consultants, system-integrators and software product development firms.

A PDF copy of the report is available for FREE download : http://www.mydigitalstartup.net/top10trends2018/

Enterprises are increasingly looking at holistic IT solutions towards meeting their “Digital” requirements. Now than ever before enterprises are hugely complex and beset with numerous problems related to lack of effective strategy, planning, architecture, IT procurement and fulfilment, contracts management  to name a few. The key is to look at these problems in an integrated manner.

Applying the concepts of an integrated IT management model, it is possible to design a target operating model which can run the IT as a lean, efficient and cost effective business.

Digital Disruption and IT4IT

IT is undergoing a massive transformation from many directions. Newer challenges in form of Business Demands, Innovation & Continuous Value differentiation and Rapid Adoption of Digital Disruptors

·       The demand for innovative and IP driven services shifting away from more traditional IT business models

·       Co-creation of Value with customers, partners, suppliers and the other key stakeholders

·       Software Defined Anything, IoT, Block chain, Big Data, API economy

·       The adoption of Bi-modal IT or multispeed IT Delivery

IT4IT is increasingly being recognized as an enabler to transform IT into a future unit of digital business. It is technology and vendor neutral and can be leveraged to suit the needs of bimodal delivery. It is a prescriptive framework which promotes value creation through the service offerings across the IT value chain.

What is IT4IT

The Porter’s IT Value chain comprising of Plan-Build-Deliver-Run activities can be broken down into 4 key value streams. These are core to the business of IT and need to be managed holistically to deliver innovative and value added services. There are supporting activities for the core business of IT. These enable effectiveness and efficiency for the primary value streams. Each value stream is anchored by the 4 pillars of Service, Information, Functional and Integration models. It is through a combination of Service Model, Functional Model and Data Model that the seamless management of IT value chain activities can be obtained.

The activities of the 4 key IT value streams need to be modeled using data objects. Functional models help in designing the business capabilities of the IT business. And the integration model help in designing the right set of relationships between the data objects to enable the IT business to function seamlessly. The huge traceability data collected  and analyzed across the IT streams leads to predicting business outcomes and giving business intelligence that in turn drive growth.

 How will it help digital organizations

Redesigning IT as a Business with the IT4IT Reference Architecture enables improved services orchestration across IT value chain and continuous delivery of value added services.

·       Provides End to End traceability between customer satisfaction index, operations, service delivery & fulfilment to IT service portfolio design

·       It is able to forecast service demand and ensure balance with supply

·       It frees up resources for Business Innovation

·       It makes IT simplified and sustainable with less cost and high efficiency

·       It is in complete alignment  amongst top 4 business priorities by CIOs of today’s digital businesses as reported from the CIO survey by Deloitte ie Growth, Innovation, Performance

I desired to upgrade myself from a Solution Architect to Enterprise Architect. The best option I could see was to get TOGAF certified. So I acquired it.

When I read the skill requirements demanded of an Enterprise Architect, the list is very exhaustive. The Architecture skill framework specifies that the skills should be at the level of detailed knowledge or expert. And this is also what the industry requires. Most of the positions listed are for Enterprise Architecture Manager with more than a decade of relevant experience. There are hardly any positions which call for a beginner in Enterprise architecture, be it in the business, technology or infrastructure domain.

So how does a beginner position himself for a role in Enterprise architecture?

This write up is with the intention of understanding and knowing how to get into the role of Enterprise Architecture (business or data or application). There may not be a specific method for doing this, but some pointers or hints may prove useful.

Given all the external (e.g., government regulations, privacy and compliance requirements, expanded patient choices, emerging technologies and service providers, the diverse healthcare players, etc.) and the internal (e.g., M&As, disjointed and complex infrastructure, tools and apps, new geographic service areas, new business capabilities to compete in the market place, etc.) factors that are affecting the landscape of the healthcare industry, Enterprise Architects are faced with enormous challenges in terms of creating a pragmatic and robust enterprise-wide Roadmap and future state architecture encompassing Business, Data, Application and Technology, as well as the Transition / Migration Plan from a baseline to a target architecture and timely solution delivery.

While the current healthcare scenarios present huge challenges, it opens the door for the Enterprise Architects to become the change agents, visionary, trusted advisors and navigators.

What do you think?

"Critical Infrastructure Protection Requirements for Enterprise Architecture"

Combined AEA/ISACA Event (Presentation) ISACA AGM at 1030 hrs 

Speaker: Government of Canada - Public Safety - Frank Turbide, GCFW, GCFA, GCIH, OPST

Mr.. Turbide has twenty five years' experience in the information technology field. He has spent the last seventeen years involved in all aspects of information technology security, first as an operational responsibility, in teaching, consulting and since 2010 as a Technical Analyst at the Canadian Cyber Incident Response Centre (CCIRC). He is a GIAC Certified Firewall Analyst (GCFW), GIAC Certified Forensic Analyst (GCFA), GIAC Certified Incident Handler (GCIH), and an OSSTMM Professional Security Tester (OPST).

Description: This event will provide a brief overview of CCIRC, its role within Canada's Cyber Security Strategy, what it does and the value it offers organizations in other levels of government and critical infrastructure. Mr. Turbide will also impart some insight into the types of incidents reported to the centre and the recurring issues.

Location: Ottawa Convention Centre, 55 Colonel By Drive, Ottawa, ON, K1N 9J2

Timings: June 20, 2014 Registration 8:30 – 9:00am

Presentation and Breakfast 9:00am–10:00am

Cost: $45 Members (ISACA and AEA); $25 Students. $55 Non-Members. Hot breakfast provided.

Payment and Registration at: http://www.isaca-ottawa.ca/payments/

See you there !!!! Bob

Solutions vs. Enterprise Architects: The Great LinkedIn Debate

By Steve Nunn, CEO, Association of Enterprise Architects

Over the past couple of months, the AEA discussion board on LinkedIn has been buzzing with an ongoing debate over the differences between Solutions vs. Enterprise Architects and the benefits of each.  This debate—which has generated well over 100 comments on the forum—was prompted by a simple question: Why should we hire an Enterprise Architect when we have so many great Solutions Architects?

The lively debate sparked by this question is one that EA community is all too familiar with. Enterprise Architecture—what it is, why it’s important, what we do as EA professionals—has been an ongoing debate for many years. Most organizations still do not understand the function of enterprise architecture nor do they understand why or how having an enterprise architecture or having a staff of enterprise architects can help their organization.

The difficulty in defining who we are and what we do is, in part, because we deal in abstractions. Enterprise architects, by nature, work with the big picture. In order to come up with the solutions needed to architect an entire enterprise, we have to look at the big picture. We need to be able to walk the walk of IT and talk the talk of business—and fill in the gaps between the two. The ability to have a broad perspective, communicate the big picture and come up with comprehensive solutions across an entire organization is exactly what sets the Enterprise Architect apart from the Solutions Architect. EA is an ongoing, never-ending function that is always evolving. In a twist on the old saying, an EA’s work is never done. Solutions, on the other hand, are just that—they solve a particular problem—they are project-oriented with a beginning, middle and end (subject, of course, to updates as requirements or regulations change).

Whether or not an organization needs Enterprise Architects or Solutions Architects—I would argue that they likely need both—is a question that each organization must ask itself. In small organizations, the roles may in fact be interchangeable simply because roles in small organizations are often less defined and people are required to do more. Large organizations, on the other hand, absolutely need people in both roles in order to get things done, just as any team needs both leaders and workers.

As has been reflected by this Great LinkedIn Debate, there are many opinions out there as to what the roles of both positions should or should not be, and those of us who care about this profession could continue this discussion until the proverbial cows come home. But ultimately the larger issues for us as a community of professionals are these:

·      How do we end such debates?

·      How do we raise our profiles within organizations and validate our worth?

·      How do we more easily articulate the separate functions of these roles within organizations?

·      How do we make sure that the C-Suite understands why they need Enterprise Architects and Solutions Architects?

Answering these questions is part of the work of a professional organization such as ours. It’s the reason we exist—to help professionals like you boost your hiring potential, keep up your skills, interact with others within the profession and to be advocates for Enterprise Architecture as a profession. It’s also the reason why the AEA is looking at ways to elevate EA to the status of a profession so that people will understand our role within organizations.

As with anything that deals in abstractions and intangibles, we may never be able to put an end to debates such as why organizations should hire an Enterprise Architects vs. Solutions Architects. But the more we can work together as professionals to showcase the results of our work and help others understand what Enterprise Architecture is and why it’s important through real, measureable and tangible results, the further the profession will get toward making the question moot. 

EA in Practice – A Conversation with Jason Uppal About Enterprise Architecture in the Healthcare Industry

AEA member and founder of the AEA Toronto Chapter, Jason Uppal is Chief Architect at clinicalMessage, Inc. and CEO of QRS, a company focused on Business Transformation. A division of QRS, clinicalMessage uses the business transformation methods developed by QRS to create a culture of quality and safety in healthcare organizations. Over the past three years, Uppal has worked extensively in healthcare settings researching, learning and listening to everyone from nurses, doctors and surgeons to administrators and senior management in hospitals, health authorities and at universities. This work has allowed Uppal and his team to apply EA and develop solutions that fit the particular needs of healthcare settings and environments. In 2012, the clinicalMessage capability was awarded the Edison Award for being an innovative health care application.. Uppal is also the Vice Chair of The Open Group’s newly launched Healthcare Forum. He divides his time between his home base in Toronto and Philadelphia.

We recently spoke to Uppal about the role of enterprise architecture in the health care industry, the problems that have surrounded the launch of the Obamacare website in the U.S. and how enterprise architecture can help with healthcare reform.

The rollout of Obamacare has been a bit of a fiasco. From the standpoint of Enterprise Architecture, what could they have done better?

Enterprise architecture (EA) could have helped them understand you don’t have to solve 100 percent of the problem. You solve the problems that are most important and leave the remaining for the next iteration —there are some opportunities to be had there, and that’s the focus of healthcare reform.

From the enterprise architecture point of view, they did some parts right, but I don’t think they thought about the transition plan well enough. They relied on a transition plan from consultants and lobbyists that said they could do it fast. The transition plan was not practical for two reasons. First, healthcare has not ever changed at this speed. If you have a whole industry that hasn’t had to change and you put the hammer on them, they don’t know how to do it…had they thought about it from an enterprise architecture standpoint they wouldn’t have done that. You just can’t do things fast because you want to. It doesn’t happen. Technology is not perfect from day one.

There’s nothing wrong with the architecture, it’s the transition plan. Transition is 99 percent of the problem that enterprise architecture addresses. We all know where we are and where we want to go, the problem is how do you get there, with minimum disruption to current operations while staying true to disruptive change.

The other part where EA could have helped was instead of solving every problem from every stakeholder’s point of view, they could have prioritized and tackled this one first, then the next. If you approach things from every stakeholder’s point of view, then every problem has to be done right away. From an EA standpoint, it could have been incrementally instead of a big bang where everything has to be done at once.

Are there problems that are specific to the healthcare industry that should be addressed up front to make projects like this run more smoothly? How can EA help healthcare?

One thing they could have done, they could have looked at the industry as a whole to see what they’re prepared to accept and what needs to change. It’s easy to think about at the 25,000-ft. level, but to bring it to the ground level where hospitals have to change while taking care of patients, this is a live world and you only have to make one mistake and you’re on the firing line. That’s a lot of change in an industry where there’s not a lot of change. You could be in a boardroom where nobody can say ‘yes’ and anyone can say ‘no.’ That’s unique to healthcare…everybody’s right and nobody’s wrong. They are very consensus-driven organizations on the inside. Command and control is not in that culture.

Change has to be delivered with command and control. One reason that systems like Kaiser Permanente or the Cleveland Clinic are much more productive and much faster at changing is because they have a CEO. At the end of the day they have a CEO that makes decisions…Those organizations are powerful enough to make changes fast, but in a lot of the healthcare system, it’s very consensus driven and change is next to impossible. The unfortunate thing is they think they have changed a lot, but in the scheme of things, they have changed very little. When compared to telecom, they haven’t seen an iota of change—nothing of that magnitude has happened in healthcare, but it’s coming.

EA can help in understanding an organizations’ preparedness to change. The second thing is to create a model that fits that organization and then get that change ready—where do you need to go, how fast and what do we need to augment that change.

What kind of architecture and security concerns need to be addressed when putting together a project of this scale that needs to be able to support many thousands of users simultaneously?

Some fundamental issues that we need to be concerned about are: Are there rules in place? For data ownership, who owns your health records? Is it the hospital? And also where it is—if they move it to the cloud, who owns it? There are all kinds of practical concerns around that. A concerted effort needs to be put in place—you need rules and regulations around that. Security and privacy are not an impediment; they’re the constraints that we need to deal with. It’s a red herring to think we don’t know how to handle those things…if you put in clearly defined rules; it’s not a problem. It doesn’t increase costs or anything, security and privacy management is just good business.

On a project such as Obamacare that combines government and private contracting resources, where ideally should the architecture sit?

They both have roles in it. At the big picture level, architecture needs to be done, and at the solutions level, there needs to be architecture. They need to sing from the same song sheet. The strategic needs to be at the governance level, solutions at the implementation level, but the solutions level needs to inherit from the enterprise architecture. It needs to be, otherwise it’s a waste of time and money. They need to work from the same set of principles.

Government IT projects are notorious for being over deadline, over budget and often for not working. How can enterprise architects help improve public infrastructure projects?

This is more of a problem of the healthcare industry as a whole, not a public infrastructure issue. In the healthcare industry, they still don’t know what a good architecture is. They don’t know what the costs and benefits are like in other industries. How do you measure the benefit of good healthcare? They’ve tried to apply private industry rules to healthcare and it’s not working very well. That’s why healthcare costs in the U.S. are twice that of other countries. The U.S. GDP spend is 18 percent on healthcare. Canada, Germany and Britain spend 8 percent, and it’s not that people are more healthy. You spend less but get better quality from a Canadian perspective.

That’s partially because it’s been thought of as a private business. You can’t have a private business when costs and benefits are not the same currency. The benefit in other industries is money. How do you quantify a $75,000 hip replacement for someone who is 92 years old? Is that a good investment? Those are the fundamental problems in healthcare that need to be dealt with. So, if you’re rich you can afford it, but if you’re not, you can’t? Is that an acceptable way to make decisions?

In Canada, they look at your need more than whether you can afford it or not, the physician decides what the treatment will be. In the U.S., the patient or insurance company decides what procedures you have and decides what you get—there’s  fragmentation. In the private sector, everybody makes their own deal with somebody. A procedure that costs $10 in Canada can cost $150 in the U.S. The hospital system is negotiating with insurance companies what they’ll get paid for something.

The new Obamacare site had a deadline of Dec. 1. How realistic is it to put deadlines on projects that need fixing on a scale like this?

From an architect’s point of view, deadlines are absolutely necessary. Bucketizing things and putting a wrapper around things are absolutely necessary. If you don’t, things have a nasty habit of staying around forever. I’m a big proponent of deadlines. They’re a must and limiting costs are a must, then you come up with a creative way of getting it done. Deadlines are not artificial—they’re real and they’re necessary.

By Steve Nunn, CEO, Association of Enterprise Architects,  Friday, February 14, 2014