A Causally-Grounded Approach to Health Services Enterprise Architecture

Carlos Trigoso

November 2025

Abstract

Healthcare organisations continue to struggle with fragmented systems and failed digital transformation initiatives despite decades of IT investment. This article argues that the problem is conceptual rather than technical. Conventional Enterprise Architecture approaches—TOGAF, ArchiMate, and their variants—position technology as purpose rather than instrument, data as foundation rather than trace, and systems integration as objective rather than consequence. This technology-first thinking produces capability inventories that lack well-defined foundations and architectural decisions that fragment rather than integrate organisations.

This article presents a causally-grounded alternative: an Enterprise Architecture framework based on a four-cause ontology that positions purposeful human action as the foundation of organisational design. By applying this framework consistently across organisational layers—from national policy to local service delivery—the approach reveals how to design integrated socio-technical systems that are immune to technological obsolescence. The framework has been developed in the context of NHS England Enterprise Architecture work, serving as both theoretical contribution and practical tool for healthcare and other services facing similar challenges.

Keywords: Enterprise Architecture, Health Services, Causality, Grounded Ontology, Technology-First Architecture, Person-Centric Architecture

The Problem: Why Conventional Approaches Fail Healthcare Organisations

For how did we say that digital transformation will solve healthcare’s systemic problems? That better data integration, new applications, new products will finally deliver the efficient, equitable services our population deserves? Yet after decades of IT investment, healthcare organisations continue to struggle with fragmented systems, isolated data, and technology solutions that somehow never quite deliver on their promises. Consider the recurring cycle of Electronic Health Record implementations that promise seamless care coordination but deliver data silos requiring yet another integration project.

This is not a technical problem. It is a conceptual problem.

Conventional Enterprise Architecture approaches—TOGAF, ArchiMate, and their variants—conceive organisations around technology artefacts. They create inventories of capabilities, applications, and data entities, then attempt to integrate these inventories through ever-more-complex middleware and governance structures. The underlying assumptions are that technology represents organisational capability, that data should organise processes, and that IT architecture by itself can drive business transformation.

These assumptions invert causality. They position technology as purpose rather than instrument, data as foundation rather than trace, and systems integration as objective rather than consequence. The result is technology solutionism—a technology-first approach, rooted in the belief that technology improvements will somehow, sometime, generate organisational effectiveness automatically, without addressing the fundamental purposes and human processes that technology should serve.

Consider the typical Architecture framework in healthcare: It identifies “capabilities” like Clinical Care Delivery, Patient Administration, and Data Management—then it “maps” these to application portfolios, technology platforms, and integration architectures. This produces neat diagrams and comprehensive inventories. What it does not produce is transformation, because the fundamental categories lack well-defined foundations. The questions expose the arbitrariness: Why these capabilities and not others? What are the dependencies between capabilities? How to choose between different industry nomenclatures and traditional taxonomies? Why is “Data Management” separate from “Service Delivery”? Why is “technology” treated as a parallel domain to “clinical care” rather than as an instrument within it?

The conventional answer appeals to pragmatism: “These categories reflect how organisations actually work.” But this is circular reasoning that mistakes effect for cause. Organisations fragment because we fragment them conceptually first. Arbitrary categories produce fragmentation because they create boundaries with no principled basis for integration—each boundary becomes a negotiation point, each interface a political compromise, each “integration project” a symptom of conceptual incoherence. We create separate IT departments because we position technology as a separate concern. We generate ever-more data integration projects because we treat data as an object to be managed rather than as trace of human action requiring coordination.

Healthcare suffers particularly acutely from this conceptual inversion. When we position Electronic Health Records as “foundational” to care delivery, we’re claiming that the shadow of clinical activities (their data trace) precedes the activity itself (the clinical encounter). When we separate “Digital Development” from service delivery capabilities, we’re suggesting technology exists independently of the human processes it serves. When we measure organisational performance through aggregated percentages without respecting local context, we’re pretending uniform targets make sense across profoundly different socio-economic realities—comparing a Trust serving affluent suburbs with one serving multiply-deprived communities as if identical adoption rates reflect equivalent achievement.

This matters because it determines not just how we describe organisations, but how we design and lead them. Architecture must be prescriptive, not merely descriptive, even if sound description provides necessary starting points. When our conceptual frameworks privilege technology over purpose and human action, we build organisations that privilege technology over purpose and human action.

The question then becomes: what alternative foundation exists? How do we ground Enterprise Architecture in something more principled than pragmatic inventories or technological categories? The answer requires examining the logical structure of purposeful human action itself.

Why Philosophical Foundations Matter for Enterprise Architecture

Let me be clear about my approach from the outset: this work is grounded in classical philosophical theories of causation not because ancient sages are fashionable in IT circles (they’re not), but because these theories provide non-arbitrary foundations for understanding purposeful human action. Are organisations, public or private, not systems of human action? And is action not a result of purpose?

The choice of philosophical foundation is not decorative. It’s not “interesting context” for an otherwise conventional framework. It’s the load-bearing structure. Here’s why.

When we analyse any human action—a clinical consultation, a recruitment decision, a budget allocation—we can ask four distinct types of causal questions:

1. Final Cause (Purpose): Why does this action exist? What is its telos, its aim? For healthcare: improving population health, alleviating suffering, enabling flourishing.

2. Formal Cause (Standards): What principles constrain this action? What standards, models, or specifications define “doing it properly”? For healthcare: clinical guidelines, quality standards, regulatory requirements.

3. Efficient Cause (Process): How does this action unfold? What workflows, procedures, or interventions constitute its execution? For healthcare: assessment protocols, treatment pathways, care delivery procedures.

4. Material Cause (Products): What tangible, measurable results does this action produce? What services, outputs, or traces evidence its occurrence? For healthcare: clinical encounters, prescriptions, health records.

This fourfold analysis is not simply one possible framework among many. It’s the logical structure of purposeful action itself. You cannot have meaningful organisational capability without purpose (“why it exists”), standards (“what governs it”), processes (“how it operates”), and products (“what results it achieves”). Attempting to describe business capabilities without this causal structure produces exactly what conventional Architecture exhibits: arbitrary lists of functions with no principled relationships between them.

Critically, these causes form a constraint chain. Purpose constrains what standards are appropriate. Standards constrain what processes are legitimate. Processes constrain what products emerge. This ordering is unidirectional and logically necessary. You cannot derive purpose from products (though many IT strategies try, inferring organisational aims from existing data assets). You cannot determine appropriate standards from processes alone. The constraint propagation flows in one direction only because purposes must exist before they can be specified, specifications must exist before they can be enacted, and enactments must occur before they can produce results.

This answers the arbitrariness question definitively. These are not “my” categories or “categories that work for NHS England.” These are the categories of purposeful human action, derived from the foundational ontology of what it means to act with intention in organised social contexts.

For clarity, I should note that I am not presenting some ultimate metaphysical truth here. These categories are appropriate for the analysis and design of human organisations precisely because these “four causes” are themselves human conceptual tools that make explicit the structure already inherent in social action. All purposeful collective action is structured by purposes, meanings, procedures, and products—the four-cause framework simply makes this implicit structure explicit and available for systematic analysis.

The framework’s validity derives not from correspondence to mind-independent reality, but from its capacity to articulate the conditions that make organised human action intelligible and designable.

Moreover—and this is crucial for practical application—this ontology positions technology and data exactly where they belong: as products of action (Material Causes) serving human purposes, never as organising principles by themselves. Technology appears in every capability, but always as instrument and never as end. Data emerges as trace or evidence of human processes, never as foundation upon which processes should be built. This positioning is not arbitrary preference but follows necessarily from the causal structure: tools and traces cannot logically precede the purposes and processes they serve.

The Framework: 16 Capabilities Across Four Causal Layers

The causally-grounded framework consists of sixteen foundational capabilities, each decomposed into four causal layers. These sixteen capabilities are not arbitrary selections but comprehensive coverage of healthcare system functions derived from systematic analysis of what healthcare organisations actually do.

The sixteen capabilities are:

Strategic Functions: (1) System Planning & Assurance, (2) Performance Management, (3) Financial Stewardship, (4) Workforce Development

Core Services: (5) Population Health Services, (6) Clinical Services, (7) Urgent & Emergency Services, (8) Planned Care Services

Support Functions: (9) Estate & Facilities, (10) Procurement & Supply, (11) Transport & Logistics, (12) Research & Innovation

Enabling Functions: (13) People Services, (14) Digital & Technology, (15) Knowledge & Intelligence, (16) Governance & Compliance

Each capability exists at four organisational layers matching NHS England’s actual structure:

Layer 1 (National/Central): Policy-setting, national standards, strategic direction

Layer 2 (Regional): Regional coordination, resource allocation, performance oversight

Layer 3 (Sub-regional ICBs/ICSs): System integration, commissioning, local planning

Layer 4 (Provider Trusts and Local Organisations): Direct service delivery, operational execution

And each capability decomposes into four causal elements:

A (Final Cause): Purpose and aims

B (Formal Cause): Standards and models

C (Efficient Cause): Processes and procedures

D (Material Cause): Products, services, and data traces

This produces a 16×4×4 structure: 16 capabilities × 4 organisational layers × 4 causal elements = 256 architectural components, each with defined relationships determined by the constraint chain.

The power lies not in the inventory but in the relationships. Within each capability:

A→B: Purposes constrain which standards are appropriate

B→C: Standards constrain which processes are legitimate

C→D: Processes constrain which products and data traces emerge

Across capabilities:

Strategic capabilities (1-4) set purposes and standards that constrain Core Services (5-8)

Core Services establish requirements that constrain Support Functions (9-12)

All capabilities are enabled by Enabling Functions (13-16), which provide cross-cutting infrastructure

Across organisational layers:

National purposes and standards (Layer 1) constrain Regional coordination (Layer 2)

Regional allocation constrains Sub-regional planning (Layer 3)

Sub-regional commissioning constrains Provider delivery (Layer 4)

Operational experience (Layer 4) provides feedback informing national policy (Layer 1)

This multi-dimensional constraint structure ensures that architectural decisions remain grounded in purposes propagating through standards and processes to produce coherent products and data, whilst respecting organisational realism about how distributed healthcare systems actually operate.

Data as Trace, Not Foundation: Architectural Implications

One of the framework’s most significant departures from conventional Enterprise Architecture concerns the position of data. Rather than treating data as a foundational layer upon which processes are built (the “data-driven” approach), this framework positions data as trace or evidence of human processes (the “data-centric” approach).

This distinction is not semantic. It has profound architectural implications.

In conventional approaches, organisations identify “data assets” first, then design processes to “leverage” these assets. The Electronic Health Record becomes the organising principle around which care pathways are structured. Data integration becomes the primary architectural objective. The assumption is that once data flows freely, effective processes will follow.

This reverses causality. Data doesn’t drive processes; processes generate data as trace. When we design care pathways, they produce clinical documentation as evidence. When we execute workforce processes, they generate employment records as trace. The data has no meaning independent of the processes that produce it.

A simple observation clarifies what the problem is: Conventional architecture claims that data (patient, staff, operational data) are not being used or are being used in a limited way. In other words, the conventional approach recognises that “data” by itself does not drive processes or capabilities. In fact, the reality that “data” is only a product and not a purposive force is confirmed by the “need” or the “lack” that everybody observes!

Architecturally, this means data appears exclusively in Layer D (Material Cause) of every capability. There is no separate “data capability” because data isn’t a distinct organisational function—it’s the trace left by every organisational function. Clinical Services (capability 6) produce clinical data. Workforce Development (capability 4) produces workforce data. Knowledge & Intelligence (capability 15) uses data traces from all capabilities to support decision-making, but doesn’t “own” data as a separate domain.

This architectural positioning has three critical consequences:

First, it prevents data silos by design. When each department, service, or organisation designs systems around “their data needs,” we create isolated silos because we’ve positioned data as organising principle rather than as trace of coordinated human action. The ever-present integration projects attempting to connect these silos treat symptoms whilst ignoring the root cause: the conceptual inversion that produced fragmentation in the first place.

The causally-grounded framework prevents this inversion architecturally. By positioning data uniformly in Layer D across all capabilities, and by requiring that Layer D elements derive from Layer C processes, the architecture enforces proper causal relationships. You should not design a “data management capability” separate from the human processes that generate data. You should not position technology as purpose. The ontological structure prevents the conceptual errors that produce fragmented systems.

Second, it clarifies integration requirements. Data integration becomes meaningful only when it reflects process coordination. If Clinical Services and Social Care Services need integrated data, that requirement derives from coordinated care processes spanning both capabilities. The integration architecture should mirror the process architecture, not exist independently of it. This prevents the common pattern of data warehouses created without clear process requirements, accumulating data without defined purposes, standards and processes.

Third, it positions technology correctly. Technology infrastructure appears in Layer D alongside data—both are products of human processes, instruments serving purposes, never organising principles themselves. Electronic Health Records, data platforms, AI systems, and analytical tools all occupy the same architectural position: Material Causes enabling the execution of Layer C processes that implement Layer B standards pursuing Layer A purposes.

This is not to diminish the importance of technology. Rather, it ensures technology importance is properly understood so that it is properly utilised. A sophisticated Electronic Health Record system is indeed critical infrastructure—but it is a product for coordinated clinical processes pursuing patient care purposes, not a foundational platform upon which care processes should be built. The distinction determines whether technology serves human purposes or displaces them.

Why This Matters: Immunity to Technological Change and Future-Proofing

Enterprise Architecture frameworks typically become obsolete within years of their creation, undermined by technological changes their authors did not anticipate. Service-Oriented Architecture (SOA) was supplanted by micro-services. Client-server models were disrupted by cloud computing. Current API-centric and data-driven architectures will be disrupted by whatever emerges next—perhaps AI systems, quantum computing, or technologies we have not yet imagined.

The causally-grounded framework is largely immune to this obsolescence because it’s not built on technological assumptions. The four causes describe the logical structure of purposeful human action, and that structure doesn’t change when new technologies emerge. Healthcare will always involve purposes (improving health), standards (clinical guidelines), processes (care pathways), and products (encounters, prescriptions, records)—regardless of whether those processes are supported by paper files, relational databases, or artificial agents.

As indicated above, this is not to claim technology doesn’t matter—obviously it does. But its architectural position matters more than its specific, contingent, current functionality. By positioning technology consistently as Material Cause (Layer D) across all capabilities, always serving human purposes and processes but never organising them, the framework accommodates technological change without architectural disruption.

Artificial Intelligence provides a telling example. Conventional approaches treat AI as a distinct architectural domain requiring separate governance, separate capabilities, separate data strategies. The causally-grounded framework positions AI as it should be positioned: an instrument in Layer D that can enhance Layer C processes (diagnostic support in Clinical Services, demand forecasting in System Planning, resource optimisation in Procurement).

The framework doesn’t need updating to “accommodate” AI because AI occupies the same architectural position as any other technology: instrumental implementation of human-designed processes pursuing human purposes according to human-established standards.

The same logic applies to emerging technologies. Quantum computing, neural networks, computer interfaces, intelligent buildings—whatever emerges will occupy the same architectural position. Technology serves; it does not command. This positioning provides what conventional EA cannot: longevity through ontological grounding rather than technological specificity.

Ontological foundations remain stable across technological change because those foundations describe human purposeful action—which remains the constant whilst technologies change. The framework will remain relevant as long as healthcare involves purposeful human action in organised social contexts—which is to say, indefinitely.

Practical Application and Organisational Realism

Some readers may worry that philosophical rigour produces frameworks too abstract for practical implementation. The opposite is true. By grounding architecture in how organisations actually operate—purposeful human action unfolding through causal chains—the framework is profoundly realistic.

The framework had to address actual organisational challenges: distributed decision-making across four organisational layers, chronic tension between national accountability and local autonomy, complex interactions between policy-setting and operational delivery, recurring cycles of IT investment producing limited transformation.

One concrete area of application is very promising: NHS England People Services (workforce management, recruitment, education, wellbeing) has evolved into a fragmented landscape of forty-three separate sub-capabilities identified through conventional analysis—each with its own IT systems, data definitions, and governance structures. Attempts to integrate these systems have failed in the past because the conventional capability model provided no complete basis for determining which integrations were necessary and which were arbitrary.

Applying the causally-grounded framework reveals that the forty-three “capabilities” are actually a mixture of purposes (Layer A), standards (Layer B), processes (Layer C), and data systems (Layer D) from just four coherent capabilities: Workforce Planning & Development, Employee Lifecycle Management, Workforce Wellbeing & Safety, and Employment Relations & Representation. The fragmentation resulted from treating data systems and process steps as if they were distinct capabilities requiring separate architectural treatment.

The application of the 16×4 matrix can clarify integration requirements immediately. Data integration is necessary where processes require coordination—for instance, Workforce Planning (Layer A purposes and Layer B models) needed data traces from Employee Lifecycle Management (Layer D records) to inform forecasting. Forcing integration between systems that support independent processes creates complexity without value. The framework not only describes the problem; it provides the prescriptive structure for redesign.

This calls for a parallel process of implementation:

Conceptual adoption: Orienting organisational thinking around purpose-first, causal structures rather than technology-first, inventory approaches. This requires education but resonates quickly with practitioners who have experienced the failures of conventional approaches—particularly when they recognise that the framework articulates what they learned through experience.

Capability mapping: Working with individual Trusts or ICBs to map their current capabilities to the 16×4 matrix, revealing where technology has displaced purposes in architectural thinking, where data is treated as foundation rather than trace, where standards have disconnected from the purposes they should serve. The mapping exercise is diagnostic, exposing conceptual inversions that produce operational dysfunction.

Architectural redesign: Using the causal constraint structure to guide system integration, revealing where current fragmentation results from conceptual errors rather than legitimate organisational boundaries. Data-centric (not data-driven) approaches naturally produce integrated systems because they design for coordinated human action rather than managing isolated data artefacts.

The multi-level structure (Central → Regional → ICBs/ICSs → Trusts/Local organisations) maps directly onto NHS England actual organisational structure, providing immediate relevance. But the principles apply to any healthcare system facing similar challenges: distributed structures, policy-practice tensions, national-local dynamics, and the chronic pattern of IT investment producing disappointing transformation.

Implications for Practice

What does this causally-grounded framework mean for those working in or leading healthcare organisations? Three audiences warrant direct address:

For Enterprise Architects and Technology Leaders: This framework provides theoretical foundations for positions you may have already reached intuitively—that technology shouldn’t drive strategy, that data integration requires process coordination, that capability models need principled foundations. The four-cause structure gives you a defensible basis for architectural decisions and a vocabulary for explaining why certain approaches fail. When stakeholders propose technology-first solutions, you can now articulate why this inverts necessary causal relationships rather than simply asserting “best practice.” The framework also provides political leverage: “This isn’t my opinion—this is the logical structure of purposeful action.”

For CIOs and Digital Leaders: The framework reframes your role from “delivering technology solutions” to “ensuring technology serves organisational purposes.” This is not a diminution but a elevation—it positions you as guardian of causal coherence rather than manager of IT portfolios. It also provides diagnostic power: when digital transformation initiatives fail, the framework reveals whether failure stems from poor execution or conceptual inversion. Many initiatives fail not because of inadequate technology but because they position technology as purpose rather than instrument. The framework helps you distinguish genuine opportunities from technology solutionism disguised as innovation.

For Policy-Makers and Executive Leaders: The framework explains why decades of IT investment have produced limited organisational transformation. The problem isn’t insufficient investment, inadequate governance, or resistance to change—it’s conceptual inversion embedded in how we think about organisations. Technology and data positioned as foundations rather than instruments inevitably fragment organisations because they create artificial boundaries requiring endless integration projects. The causally-grounded alternative offers a path toward genuine transformation: architecture that starts from purposes, flows through standards and processes, and positions technology exactly where it belongs. This requires no additional investment—it requires conceptual reorientation.

Conclusion: Architecture as Grounded Practice

I began by claiming that healthcare’s digital transformation failures reflect conceptual problems, not technical problems. Let me conclude by making this claim more precisely.

Enterprise Architecture is not a technical discipline that benefits from philosophical grounding. It is a philosophical discipline that expresses itself technically. When we design organisational structures, define capabilities, specify systems, and measure performance, we’re instantiating value commitments and ethical choices—usually implicitly and unreflectively, occasionally explicitly and rigorously.

The conventional Architecture approach instantiates a cluster of implicit philosophical commitments: empiricism (we list what we observe without asking why these categories are necessary), technological determinism (we assume technology shapes organisation rather than vice-versa), reductionism (we aggregate data without respecting measurement types), and managerialism (we privilege controllability over legitimacy).

The causally-grounded approach instantiates different philosophical commitments explicitly: foundationalism (causality grounds all categories), instrumentalism (technology serves human purposes), and legitimacy through purpose (organisational authority derives from achieving worthy aims, not from control).

These philosophical differences produce radically different architectures—not surface differences but fundamentally different conceptions of what organisations are and what architecture does.

If you accept that organisations exist to achieve purposes through coordinated human action, that technology serves human purposes rather than organising them, that data traces action rather than driving it, and that local context profoundly shapes what “good performance” means—then you need architecture grounded in causality, positioning technology instrumentally, treating data as trace, and respecting organisational diversity.

If you believe organisations are primarily technical systems that happen to involve people, that better technology produces better outcomes directly, that data should organise processes, and that uniform performance targets enable fair comparison—then conventional approaches may suffice.

I submit that the former accurately describes organisational reality whilst the latter produces a never-ending, paradoxical cycle of innovation without transformation.

Decades of failed digital transformation initiatives suggest this assessment is not merely academic theorising but documented organisational experience.

A causally-grounded, person-centric Enterprise Architecture framework offers healthcare organisations—and others beyond healthcare facing similar challenges—an alternative to technology-first solutionism: architecture that starts from human purposes, respects philosophical rigour, acknowledges organisational reality, and positions technology exactly where it belongs—as instrument serving human ends, never as end itself.

This is Enterprise Architecture as it should be: purposeful, rigorous, realistic, and immune to the technological fashions that render conventional approaches obsolete before implementation completes.

The question now is not whether this alternative is theoretically sound—the arguments stand on their merits. Nevertheless, whether this alternative gains traction depends not on philosophical argument alone, but on practical implementation across all levels of the organisation.

Author Note

Carlos Trigoso is Lead Enterprise Architect at NHS England. Previous publications are available by request.

Email address: carlos.trigoso@nhs.net