Tag: Enterprise Architecture

  • EA Part Three: The Architecture in Motion (Worked Examples)

    The true test of any architectural framework is how it handles reality. When subjected to the friction of legacy infrastructure, human behavior, and budget constraints, theoretical models often collapse.

    To demonstrate how the 7-System model survives this friction, we will look at two distinct enterprise scenarios: a massive infrastructure transformation and the launch of a new consumer capability.

    Example 1: The Infrastructure Transformation

    The Capability: Zero-Trust Enterprise Connectivity

    Imagine an enterprise executing a 15,000-user network migration. The objective is to deprecate legacy perimeter VPNs and implement modern, identity-driven security baselines perfectly aligned with UK NCSC (National Cyber Security Centre) principles.

    If this is managed purely by the IT department as a Technology project, it will almost certainly cause massive operational disruption. Here is how an architect maps this capability across all seven systems to guarantee success:

    • 1. Value: The ultimate outcome is not “installing new software.” The value is a resilient enterprise where employees can securely access necessary resources from any location, protecting the business from breach-related reputational and financial ruin.
    • 2. Governance: This system drives the constraints. NCSC principles dictate that trust is never assumed based on network location. The Governance system establishes the rules: No device connects to internal data without passing real-time identity and device-health checks.
    • 3. Technology: To enforce those Governance rules, the Technology system deploys the required infrastructure—SD-WAN architecture, identity providers (IdP), endpoint management agents, and micro-segmentation firewalls.
    • 4. Information: The Technology is useless without telemetry. The Information system must constantly route data: user credentials, behavioral analytics, device OS patch levels, and threat intelligence feeds. The network uses this Information to make millisecond routing decisions.
    • 5. Work: This is where migrations usually fail. How does a workforce of 15,000 actually authenticate at 8:00 AM on Monday? The Work system maps the new login process. If the security friction takes 10 minutes per user per day, the Work system is broken, and productivity plummets.
    • 6. Organisation: Legacy networks often have a “Network Team” and a “Security Team.” Zero-trust blurs these lines. The Organisation topology must adapt, shifting authority so that Identity, Endpoint, and Network teams operate in a tightly coupled, unified structure.
    • 7. Economics: The financial model shifts from heavy CapEx (buying giant physical firewalls every 5 years) to OpEx (per-user cloud licensing). The Economics system must also account for the cost of potential downtime during the migration phase.

    The Diagnostic Power: During the migration rollout, remote users suddenly cannot access an internal legacy application. Using the framework, the architect traces the fault. The Technology (the routing agent) blocked access correctly because the Information (device health state) showed an unpatched OS. Why was it unpatched? Because the Work process for pushing updates was broken by a recent Governance freeze on patching during a busy financial quarter.

    The fix isn’t a network routing change; it’s aligning Governance and Work.

    Example 2: The Digital Product Launch

    The Capability: Automated, Frictionless Customer Onboarding

    Consider a retail business or financial institution launching a new digital app where users can register, verify their identity, and make their first transaction in under 90 seconds.

    • 1. Value: For the consumer, the value is immediate gratification and access to services without walking into a physical branch. For the business, the value is a drastically lowered customer acquisition cost.
    • 2. Governance: The regulatory constraints are severe. The business must comply with KYC (Know Your Customer) and AML (Anti-Money Laundering) laws, accepting the legal risk of digital fraud.
    • 3. Work: The user’s activity must be reduced to taking a photo of an ID and a selfie. Internally, the Work system shifts from manual document review to exception handling (humans only reviewing edge-cases the AI flags).
    • 4. Information: The system must instantly ingest the ID image, parse the text, and cross-reference it against external government and credit databases in real-time.
    • 5. Technology: The enablers are mobile application front-ends, OCR (Optical Character Recognition) APIs, biometric matching algorithms, and cloud-native microservices.
    • 6. Organisation: Authority to approve an account shifts from a human branch manager to an automated algorithm overseen by a fraud operations team.
    • 7. Economics: The business pays per API call for the external database checks. If the OCR technology has a high failure rate, human exception handlers must intervene, driving the Economics (cost per acquisition) up and destroying the Value.

    The Diagnostic Power: If the business notices a 40% drop-off rate during the selfie-capture stage, the Executive View flags a Value leak. The Operational View reveals that the Work (the sequence of taking the photo) is confusing. The Engineering View shows the Technology (the camera API) is timing out on older Android devices. The business can then decide if the Economics of fixing the API are worth the recovered customer base.

    Example 3: The Tactical Hardware Deployment

    The Capability: Rapid-Deploy Aerial Communication Relay

    Consider a field operations team deploying a multi-node temporary aerial communication network using drones. The objective is to establish an instant mesh network over a remote area where terrestrial infrastructure is nonexistent.

    • 1. Value: Uninterrupted, high-bandwidth communication for ground teams operating in a disconnected or compromised environment.
    • 2. Governance: Strict aviation regulations (e.g., line-of-sight rules, altitude caps), RF spectrum licensing, and operational safety boundaries.
    • 3. Technology: The physical hardware—a four-node drone fleet, customized RAK4630 communication boards, 18650 lithium-ion battery arrays, and the mesh routing protocols.
    • 4. Information: Continuous, low-latency telemetry routing to the ground station: battery degradation curves, GPS coordinates, signal-to-noise ratios, and node health.
    • 5. Work: The kinetic, unforgiving sequence of field operations. Teams must unpack, calibrate, launch, and precisely swap nodes before battery depletion drops the mesh.
    • 6. Organisation: A highly disciplined field topology featuring a “Pilot in Command” who holds ultimate safety authority, separated from the payload/network operator who manages the data flow.
    • 7. Economics: The capital expenditure of the hardware versus the operational burn rate of battery cycle degradation, physical attrition of drones, and transport costs.

    The Diagnostic Power: The mesh network drops for three minutes in the middle of a deployment. The immediate assumption is a Technology failure (a burned-out board). However, the architecture reveals a different root cause: the Information (battery telemetry) was accurate, but the Work (the physical node-swap sequence) was too slow because the Organisation required the single Pilot in Command to manually authorize every landing, creating a bottleneck.

    Example 4: The Global Logistics Pivot

    The Capability: Dynamic Supply Chain Routing

    A global manufacturer needs the ability to instantly reroute component sourcing and freight when a primary shipping lane is blocked or a tier-1 vendor goes offline.

    • 1. Value: Continuous factory production and unbroken fulfillment to the end customer, regardless of global geopolitical or environmental disruptions.
    • 2. Governance: Compliance with international trade embargoes, fast-tracked customs laws, and strict vendor quality-assurance standards.
    • 3. Technology: Cloud-based ERP (Enterprise Resource Planning) systems, automated risk-alert APIs tracking global freight, and algorithmic logistics modeling.
    • 4. Information: Real-time visibility into buffer inventory levels, transit delays, and the available stock of secondary and tertiary backup suppliers.
    • 5. Work: The process of procurement teams voiding purchase orders, redirecting physical freight mid-ocean, and adjusting factory intake schedules to match the new arrival times.
    • 6. Organisation: Decentralized authority. A regional procurement manager must have the operational mandate to execute a massive vendor shift without waiting for a global HQ committee to convene.
    • 7. Economics: Balancing the severe premium cost of emergency air-freight or expedited secondary suppliers against the catastrophic, compounding cost of a halted production line.

    The Diagnostic Power: A vital component is delayed, and a factory stops production. The Technology worked perfectly—the API flagged the delay, and the Information showed a viable backup supplier. But the system failed because of an Organisation and Governance misalignment: the regional manager lacked the financial authority (Governance) to approve the emergency air-freight (Economics) without a VP’s signature, stalling the Work.

    Example 5: The Digital Entertainment Studio

    The Capability: Web-Native 3D Interactive Delivery

    An independent game studio is launching a multi-level 3D side-scrolling browser game. The objective is to deliver high-fidelity gameplay seamlessly in a web browser without requiring a heavy client download.

    • 1. Value: Frictionless, immediate entertainment for the player, bypassing app store gatekeepers and hardware restrictions.
    • 2. Governance: Data privacy compliance (handling player analytics), intellectual property protection, and managing age-gate or content rating requirements.
    • 3. Technology: The JavaScript codebase, WebGL/Three.js rendering pipelines, physics engine integrations, and edge-caching CDNs to deliver assets rapidly.
    • 4. Information: Real-time player telemetry, framerate drop logs, crash reports, and player save-state data continuously syncing to the cloud.
    • 5. Work: The development and CI/CD (Continuous Integration / Continuous Deployment) pipeline. This is the sequence of integrating level transitions, compiling master build scripts, and pushing live updates without breaking the active game.
    • 6. Organisation: A cross-functional structure where the lead developer holds strict authority over the master branch, while level designers and artists asynchronously push assets into the pipeline.
    • 7. Economics: Cloud hosting and CDN costs that scale variably with player concurrency, balanced against the monetization model (ads, microtransactions, or premium access).

    The Diagnostic Power: Upon launch, players experience massive frame-rate lag. The team assumes the Technology (the Three.js physics implementation) is poorly optimized. However, a systemic review shows the Technology is fine. The issue is Information (bloated texture files uploaded by artists) moving through a broken Work pipeline (no automated file-compression step before the master build compilation), resulting in massive server payloads that blow up the Economics of the hosting bill.

    Conclusion

    Whether you are migrating 15,000 users to a secure architecture or launching a consumer app, the enterprise is never just its org chart, and it is never just its tech stack.

    By defining the Capabilities your business needs, bounding them into logical Domains, looking at them through stakeholder-specific Views, and recognizing that every capability must be supported by all Seven Systems—Value, Work, Organisation, Information, Technology, Economics, and Governance—you move from reactive troubleshooting to true enterprise engineering.

  • EA Part Two: Domains, Views, and How to Use the Architecture

    If the seven structural systems (Value, Work, Organisation, Information, Technology, Economics, Governance) are the physics of the enterprise, and Capabilities are the vocabulary, then Domains and Views are how we organize and navigate this complexity without becoming paralyzed by it.

    You cannot comprehend an entire enterprise at once. If you try to map every connection across a large organization, you end up with an unreadable diagram that is immediately out of date.

    To make this architecture actionable for decision-makers, architects, and consumers, we must slice the enterprise logically (Domains) and look at it through specific lenses (Views).

    1. Domains: The Boundaries of Cohesion

    A Domain is a logically bounded context of the business. It is an area of cohesive capability, operating independently enough that it doesn’t require constant, synchronous entanglement with the rest of the enterprise.

    Crucially, a Domain is not a department. A department (like “HR” or “IT”) is an artifact of the Organisation system. A Domain is a sphere of business reality—such as “Customer Identity & Access,” “Core Order Routing,” or “Infrastructure Provisioning.”

    Within every single Domain, all seven structural systems exist.

    Why Domains Matter: Controlling the Blast Radius

    In traditional, tightly-coupled businesses, a change in one area breaks something seemingly unrelated. By organizing the enterprise into Domains, architects create clear boundaries.

    • High Cohesion, Loose Coupling: Inside a Domain, the Work, Information, and Technology are deeply entangled (High Cohesion). Between Domains, they communicate only via strictly defined contracts or APIs (Loose Coupling).
    • Autonomy of Change: If the “Secure Enterprise Connectivity” Domain needs to update its network routing Technology or its access Governance, it should be able to do so without requiring permission from the “Payroll” Domain, provided the external contracts remain intact.

    2. Views: The Stakeholder Lenses

    If you put a 300-page architectural schematic in front of a CEO, they will ignore it. If you put a one-page “Value Strategy” slide in front of a network engineer, they cannot build from it.

    A View is a filter applied to the architecture. It acknowledges that different stakeholders need to see different intersections of the seven systems to make decisions. The underlying reality remains the same, but the lens changes.

    The Executive View (The “Why” and “How Much”)

    • Focal Systems: Value, Economics, Governance.
    • What it shows: This view strips away Work and Technology to focus on outcomes. It shows what Value is being generated, the Economics required to fund it, and the Governance risk profile accepted to achieve it.
    • Used by: C-Suite, Board, Investors.

    The Operational View (The “Who” and “How”)

    • Focal Systems: Work, Organisation, Information.
    • What it shows: This view reveals the actual engine of the business. It shows how human and automated nodes (Organisation) process data (Information) through specific activities (Work). It highlights bottlenecks, manual workarounds, and friction.
    • Used by: COOs, Process Engineers, Department Heads.

    The Engineering & Security View (The “What” and “Where”)

    • Focal Systems: Technology, Information, Governance.
    • What it shows: This view maps the hard infrastructure. It details how data flows across networks, where strict security baselines are enforced, and how physical or cloud hardware is structured. It translates the Governance system’s rules into hard-coded constraints within the Technology system.
    • Used by: Chief Architects, Network Engineers, CISOs.

    3. How to Use This Architecture

    Understanding the framework is only half the battle. Here is how architects and business leaders actually deploy it in the field.

    A. Designing a Transformation (Impact Analysis)

    When the business decides to introduce a massive change—such as rolling out a new product line or migrating thousands of users to a new secure network architecture—the framework acts as a checklist for reality.

    1. Define the Capability: What is the new vocabulary? (e.g., “Zero-Trust Remote Access”).
    2. Isolate the Domains: Which Domains will this touch?
    3. Cross the 7 Systems: For every affected Domain, you map the change.
      • Work: Do user workflows change?
      • Governance: How does this alter our compliance posture?
      • Economics: What are the new licensing and operational costs?
      • (Repeat for all 7)

    If a transformation plan only has a budget (Economics) and a software vendor (Technology), the framework immediately flags it as guaranteed to fail upon colliding with Work and Organisation.

    B. Diagnosing Failure (Root Cause Analysis)

    When a critical failure occurs, natural instinct isolates the blame to the immediate symptom. If a secure connection drops, the blame falls on Technology. If a customer is angry, the blame falls on Work (a bad process).

    Using the architecture, you trace the failure vertically. A catastrophic data breach might manifest in Technology, but the root cause trace usually reveals a failure in Governance (poor risk policy), which was caused by bad Information (no visibility into assets), driven by a flawed Organisation structure (security team lacked authority).

    C. Communicating with Consumers and Stakeholders

    Consumers (whether internal staff consuming IT services or external buyers) do not care about your Work, Information, or Technology. They only experience the Value and the Economics (price).

    By using the right View, the business can translate complex backend realities into simple consumer promises. It prevents leaders from exposing their internal operational chaos (Systems 2 through 7) to the people who only care about System 1.

  • EA Part One: The Anatomy of the Enterprise

    To understand a business is to look past its marketing, its mission statements, and its organizational chart. Beneath those abstractions, a business is an engineered entity—a complex, dynamic machine designed to process demand and output value.

    For business decision-makers, architects, and consumers, visualizing the enterprise as an interacting grid of seven fundamental systems changes the conversation. It moves discussions away from isolated departmental silos and toward systemic health.

    Here is the architectural treatise on those seven systems, and the crucial vocabulary that binds them.

    The Core Distinction: Capabilities vs. Systems

    Before examining the systems, we must define the spine of the architecture: Capabilities.

    A capability is the vocabulary of what the business must be able to do. “Secure Data Routing,” “Next-Day Order Fulfillment,” or “Automated Customer Onboarding” are capabilities. They are agnostic to how they are achieved.

    The most common—and expensive—architectural mistake is treating a capability as a system. You cannot buy a “capability” off a shelf. You can buy technology, but to manifest an actual capability, you must thread it through the seven structural systems below.

    The Seven Structural Systems

    1. Value (The Outcomes)

    What outcomes does the organization produce, for whom, and why do they matter?

    Value is the compass. It defines the external reality of the business. For a consumer, this is the product or service they exchange capital for. For an architect, Value dictates the non-negotiable requirements of the system. If an outcome does not matter to the end user (internal or external), then any energy spent optimizing it is wasted.

    • Architectural lens: Value dictates scale and resilience.
    • Decision-maker lens: Value determines market viability.

    2. Work (The Engine)

    What activities transform demand into those outcomes?

    Work is the actual sequence of kinetic events. It is the value stream. This system is entirely concerned with processes, workflows, and the physical or digital transformation of raw inputs into the Value defined in System 1.

    • Architectural lens: Work requires minimizing friction. It is the mapping of dependencies and the elimination of bottlenecks.
    • Decision-maker lens: Work is where efficiency is won or lost.

    3. Organisation (The Topology)

    Who performs the work, and where does authority sit?

    Organisation is not merely the HR hierarchy; it is the topology of authority and execution. It defines human nodes. If a system requires rapid pivoting, but the Organisation system dictates a rigid, multi-layered approval matrix, the system will fail.

    • Architectural lens: The structure of the technical systems will inevitably mirror the communication structures of the Organisation (Conway’s Law).
    • Decision-maker lens: Aligning authority with the people doing the Work.

    4. Information (The Bloodstream)

    What facts, records, and knowledge make the work possible?

    Information is the state of the business at any given millisecond. It includes everything from transactional databases and customer records to institutional knowledge and telemetry. Work cannot happen without Information routing to the right nodes in the Organisation.

    • Architectural lens: Establishing single sources of truth, data taxonomy, and ensuring low-latency access to required knowledge.
    • Decision-maker lens: Ensuring data quality enables accurate forecasting and reality-mapping.

    5. Technology (The Infrastructure)

    What systems automate, constrain, or enable the work?

    Technology is the physical and virtual tooling. It is the hardware, the codebase, and the networks. Crucially, Technology does not do the work; it enables or automates the Work (System 2) using Information (System 4) governed by rules (System 7). Whether migrating thousands of users across a distributed network or enforcing strict security baselines, Technology must serve the capability, not dictate it.

    • Architectural lens: Ensuring systems are scalable, interoperable, resilient, and secure by design.
    • Decision-maker lens: Managing technical debt and ensuring infrastructure investments directly enable Value.

    6. Economics (The Fuel and Exhaust)

    What resources are consumed, and where does value leak?

    Every action in the other six systems incurs a cost—time, capital, attention, or physical resources. The Economics system tracks this consumption. Value leakage occurs when Work is inefficient, Technology is bloated, or Governance is overly bureaucratic.

    • Architectural lens: Optimizing computing resources, licensing models, and operational overhead.
    • Decision-maker lens: Maximizing the ratio of Value created to Economics consumed (ROI).

    7. Governance (The Brakes and Steering)

    Who decides, who controls, who accepts risk, and who is accountable?

    Governance is the system of constraints. It includes regulatory compliance, security policies, risk management, and strategic decision-making. Governance ensures that the business survives its own operations. It determines what the organization will not do, even if it is technically possible and economically viable.

    • Architectural lens: Enforcing policies, audit trails, and security baselines without strangling Work.
    • Decision-maker lens: Balancing the acceptance of operational risk against the pursuit of Value.

    Summary of the Architecture

    A healthy business operates these seven systems in equilibrium. A failure in one propagates through the rest.

    If you attempt to upgrade Technology without addressing Organisation, the new tools will be rejected by the culture. If you attempt to optimize Work without the right Information, you merely execute the wrong processes faster. If Governance ignores Economics, the business regulates itself into bankruptcy.

    Whenever a new Capability is required, the architect must ask: How will this change the Value, Work, Organisation, Information, Technology, Economics, and Governance of the enterprise?

  • Canto X – Enterprise Architecture

    Canto X of Dante’s Inferno maps surprisingly well onto some of the recurring structural failures of Enterprise Architecture.

    The central analogy is this: the heretics in Canto X can see the distant future, but they cannot properly perceive the present. That is an uncomfortably accurate description of a weak EA function.

    Enterprise Architecture often becomes excellent at describing a future state—target architectures, capability maps, principles, strategic roadmaps, reference models—while having only an approximate understanding of how the organisation actually works today.

    Farinata is therefore a useful patron saint of dysfunctional architecture.

    He can see far away. He cannot see what is directly in front of him.

    In EA terms, the organisation has a beautifully articulated Target Architecture for 2030 but cannot answer basic questions such as:

    • Which applications actually support this business process?
    • Which team owns that integration?
    • Why does Finance still depend on this spreadsheet?
    • Which Oracle database is really authoritative?
    • Why are there three identity stores?
    • What happens if this server is switched off?
    • Which project introduced that interface?
    • Who is actually paying for it?

    This is the first structural problem: strategic farsightedness combined with operational blindness.

    Canto X goes further. The inhabitants of the sixth circle are enclosed in burning tombs. Each tomb contains people whose intellectual position has become, quite literally, their permanent enclosure.

    That is a good metaphor for architecture domains.

    Business Architecture sits in one tomb.

    Solution Architecture sits in another.

    Security Architecture has a particularly well-governed tomb with an approval workflow.

    Infrastructure Architecture has several tombs because nobody completed the consolidation programme.

    Data Architecture has drawn a conceptual model of the cemetery.

    Each discipline possesses a coherent internal worldview. The difficulty is that the enterprise exists in the spaces between them.

    This produces what might be called the architecture-of-tombs problem: organisational structures encourage architects to optimise their own representational domain rather than understand the operating system of the enterprise as a whole.

    Business architects produce capabilities.

    Application architects produce portfolios.

    Data architects produce information models.

    Infrastructure architects produce platforms.

    Security architects produce controls.

    None of these things is necessarily wrong. But the organisation does not actually operate as a capability model, application portfolio, information model, technology stack or control framework.

    It operates through transactions, decisions, dependencies, people, contracts, workarounds, incentives and exceptions.

    That distinction is fundamental.

    Cavalcante introduces another EA pathology.

    He misinterprets Dante because his information is incomplete. Dante uses a tense that Cavalcante interprets as evidence that his son Guido is dead. The inference is rational given the available information, but wrong.

    Enterprise Architecture routinely does exactly this.

    An architecture repository says:

    Application: ACTIVE

    The architect concludes:

    Application is operationally required.

    But perhaps the application is technically active and functionally obsolete.

    Or:

    Capability: CUSTOMER MANAGEMENT

    The architect assumes there is a coherent organisational capability behind the box.

    There may instead be six departments, four SaaS products, two outsourced teams, thirteen spreadsheets and a woman called Janet who reconciles the whole thing every Thursday.

    The architecture model is not necessarily false. The problem is that semantic compression destroys context.

    Architecture repositories tend to replace complicated operational truths with categorical statements:

    Strategic

    Tolerate

    Invest

    Retire

    Compliant

    Non-compliant

    Cloud-ready

    Legacy

    These categories become dangerous when decision-makers forget that they are abstractions.

    Cavalcante makes precisely this mistake. He takes an incomplete representation for reality.

    There is another, more uncomfortable parallel in Farinata.

    Even in Hell, Farinata remains obsessed with Florentine factional politics.

    His circumstances have changed absolutely.

    His mental model has not.

    This happens constantly in enterprise transformation.

    The organisation announces:

    Cloud first.

    But procurement remains designed around buying servers.

    It announces:

    Product operating model.

    But funding remains annual project funding.

    It announces:

    Agile delivery.

    But governance still requires eighteen sequential approvals.

    It announces:

    Data-driven organisation.

    But authority remains hierarchical and political.

    It announces:

    Zero Trust.

    But network access is still implicitly trusted according to location.

    This is the Farinata problem: organisations carry obsolete institutional identities into radically changed environments.

    The architecture changes.

    The institution does not.

    A new target operating model can therefore reproduce the old organisation almost perfectly underneath different terminology.

    Departments become “value streams.”

    Projects become “products.”

    Technical design authorities become “architecture enablement forums.”

    The old bureaucratic relationships survive.

    This connects to another feature of Canto X: the damned remain intensely interested in Florence despite being permanently excluded from it.

    Enterprise Architecture can develop the same relationship with delivery.

    Architects discuss delivery continuously while being structurally separated from it.

    They review designs.

    They issue principles.

    They maintain standards.

    They chair governance boards.

    They create roadmaps.

    But they may not build, operate, support or retire anything.

    EA therefore risks becoming an exiled class describing the city from outside its walls.

    That produces predictable consequences.

    Delivery teams perceive architecture as theoretical.

    Architects perceive delivery teams as undisciplined.

    Programmes seek dispensations.

    Architecture creates stronger governance.

    Programmes create better techniques for avoiding governance.

    Eventually the architecture repository records an enterprise that exists primarily inside the architecture repository.

    There is also a temporal problem embedded in the canto.

    Architecture normally describes three temporal states:

    Current → Transition → Target

    The model looks rational.

    Real enterprises behave more like:

    Past + current + abandoned future + emergency workaround + acquisition residue + regulatory exception + someone's strategic pilot

    all operating simultaneously.

    Enterprise systems are archaeological.

    You rarely replace one architectural era completely. You accumulate them.

    Mainframe assumptions survive inside APIs.

    1990s organisational structures survive inside cloud tenancy models.

    Old ERP data structures determine modern business processes.

    Temporary integrations become permanent.

    Pilot platforms become strategic because somebody built something important on them.

    The enterprise therefore resembles Dante’s Hell more than an architecture roadmap: layers of historical decisions continue to exist after the circumstances that produced them have disappeared.

    There is a final and particularly useful lesson from Canto X.

    The damned know the future only while there is a future to know. Eventually even that form of knowledge disappears.

    Architecture faces an analogous problem.

    The farther a target state extends into the future, the less it describes an actual destination and the more it becomes an argument about desired direction.

    A five-year architecture cannot sensibly specify detailed systems.

    Technology will change.

    Suppliers will change.

    Regulation will change.

    Business strategy will change.

    Acquisitions will happen.

    Projects will fail.

    Someone will buy Salesforce.

    Consequently, mature EA should not primarily attempt to predict the future.

    It should improve the enterprise’s capacity to change.

    That means the real architectural objects of interest become things such as modularity, substitutability, interoperability, ownership, dependency transparency, data semantics, technical debt, lifecycle state, operational coupling and decision rights.

    Instead of saying:

    In 2031 the enterprise shall consist of these twenty-three strategic platforms.

    EA should be able to say:

    If strategy changes, these components can be replaced independently; these dependencies are understood; these interfaces are governed; these data responsibilities are explicit; and these systems can be retired without discovering that an unknown payroll process depends upon them.

    That is a fundamentally different conception of architecture.

    And it gives Canto X an unexpectedly good architectural maxim:

    Do not become so good at seeing the distant future that you lose the ability to see the enterprise standing immediately in front of you.

    The deepest structural failure of EA is therefore not bad modelling.

    It is confusing knowledge about the enterprise with the enterprise itself.

    Dante’s damned inhabit their intellectual constructions forever.

    Enterprise architects should probably take the hint.


    Canto 10 takes place in the Sixth Circle of Hell, inside the walls of the City of Dis. Here Dante encounters the heretics, specifically those associated with the Epicurean belief that the soul dies with the body. They are imprisoned in burning open tombs. (Digital Dante)

    The canto is important because it is simultaneously about religion, Florentine politics, family, prophecy, and the strange nature of knowledge in Hell.

    The first major figure is Farinata degli Uberti, a powerful 13th-century Florentine Ghibelline leader. He rises from his tomb almost majestically, standing upright “from the waist upwards,” behaving as though even Hell cannot humiliate him. (dantelab.dartmouth.edu) Dante and Farinata immediately recognise one another as political enemies: Dante’s family were associated with the opposing Guelf faction.

    Their conversation is remarkably political. Farinata is dead, burning in Hell, yet remains obsessed with Florence and factional politics. He reminds Dante that Dante’s ancestors were expelled from Florence; Dante replies that they managed to return, unlike Farinata’s family. (Bicerin)

    This gives the canto one of its central ironies: death has not freed Farinata from worldly identity. He is still a Florentine aristocrat, still proud, still fighting political battles that no longer matter.

    Then Cavalcante de’ Cavalcanti suddenly rises from the same tomb. He is the father of Guido Cavalcanti, Dante’s friend and fellow poet. Cavalcante asks why Guido is not accompanying Dante.

    Dante answers in a way that accidentally uses the past tense. Cavalcante interprets this to mean that Guido has died. Horrified, he collapses back into the tomb before Dante can explain that Guido is actually still alive. (La Divina Commedia)

    That apparent misunderstanding leads to one of the most interesting ideas in the entire Inferno.

    The dead can see distant events in the future, but they cannot properly perceive the present. Farinata explains that their knowledge resembles farsightedness: distant things are visible, but things immediately before them are obscure. (LitCharts)

    So the damned possess a grotesque kind of prophetic knowledge.

    They can see what is coming.

    They cannot see what is happening now.

    And after the Last Judgement, when there is no longer any future to see, their knowledge will effectively disappear.

    That is part of the contrapasso—the poetic correspondence between sin and punishment. These people denied an eternal spiritual existence and concentrated excessively upon the temporal world. They now exist eternally but experience time imperfectly.

    The canto also contains an important prophecy concerning Dante himself. Farinata predicts that Dante will soon understand how difficult exile is. This anticipates Dante’s real political exile from Florence in 1302. The fictional journey of the Inferno is conventionally set in 1300, so Dante is writing retrospectively while allowing characters in Hell to “predict” events that the author already experienced.

    That date structure matters:

    • 1260: Farinata and the Ghibellines defeat the Florentine Guelfs at the Battle of Montaperti.
    • 1264: Farinata dies.
    • 1300: fictional date of Dante’s journey through Hell.
    • 1302: Dante is exiled from Florence.
    • c. 1308–1321: Dante composes much of the Divine Comedy.

    The commonly reconstructed chronology places Canto X around Holy Saturday, 9 April 1300, although the precise chronology of Dante’s journey has generated scholarly debate. (Wikipedia)

    The deeper structure of Canto 10 is therefore rather elegant. Dante puts people who believed that death ends consciousness into tombs where consciousness never ends. He gives politically obsessed men knowledge of Florence’s future but denies them knowledge of its present. He gives Cavalcante prophetic sight but prevents him from knowing whether his own son is alive.

    And Farinata is perhaps the most striking contradiction: physically damned but psychologically undefeated. His body rises from a grave while his personality remains completely intact—proud, aristocratic, partisan and contemptuous.

    That is why Canto X is one of the first places in the Inferno where the damned stop feeling merely like examples of sins and become extraordinarily convincing human personalities.