Wardley Maps in Enterprise Architecture

How can Wardley Maps be integrated with Enterprise Architecture frameworks to improve strategic planning?

These slides accompany the paper: Wardley Maps in Enterprise Architecture

Most Enterprise Architecture frameworks — including TOGAF, ArchiMate, and Zachman — address business and technology change effectively, but few formally account for the broader context in which an organisation operates: where it sits in its competitive landscape, how its components are evolving, and what strategic options that evolution creates. This paper argues that Wardley Mapping fills precisely that gap, and proposes a concrete approach for integrating it with EA practice. Drawing on the Inspired Holistic Architecture Language (HAL), Graham McLeod shows that nearly all the concepts required for Wardley Maps — stakeholders, capabilities, value chains, maturity levels — are already present in a well-constructed EA meta model, making integration more straightforward than it might appear. The paper introduces a stratified Wardley Map format that aligns visual layers with EA meta model types, and reports on early use of the integrated approach in client workshops and a Business Architecture Mastery Programme. For enterprise architects and business architects, this integration offers a practical way to add dynamic, evolution-aware thinking to existing EA models without starting from scratch.

Originally published as a conference paper in the PoEM 2025 Companion Proceedings (18th IFIP Working Conference on the Practice of Enterprise Modeling), Geneva, 2025.

Integrated Meta Model for Enterprise Modelling including Strategy, Business Architecture, Risk and Change

How can a single integrated meta model support strategy, business architecture, risk, and change across multiple EA frameworks — and why do existing approaches fall short?

These slides accompany the paper: Integrated Meta Model for Enterprise Modelling including Strategy, Business Architecture, Risk and Change

The major enterprise architecture frameworks each bring something valuable, but none are sufficient on their own. TOGAF covers IT domains reasonably well but lacks the contextual concepts — competitors, legislation, market forces, ecology — essential for genuine strategic planning. ArchiMate is more rigorous and consistent but weak on data modelling and context. BizBOK is focused but narrow. None of them, individually or together, provide a single coherent foundation for the full scope of strategy, business architecture, risk, change, and programme management that large transformation efforts demand.

This paper describes the development of HAL2023, the latest iteration of the Inspired Holistic Architecture Language — built by systematically analysing and synthesising TOGAF 10th Edition, ArchiMate 3.2, BizBOK 11, SABSA, MEMO, DODAF, and the accumulated Inspired consulting models. The result is a large but well-structured integrated meta model, expressed at three levels — rich pictures for executives, conceptual models for architects, and fully attributed models for tooling — and validated across projects in banking, telecommunications, assurance, retail, healthcare, and government. Notable enhancements in this revision include richer contextual coverage, rationalised relationship types, financial aspects, customer journeys, architecture scenarios, and improved integration with risk, governance, and initiative management.

Crucially, the paper is practical as well as theoretical: it explains how the model should be used incrementally rather than exhaustively, with teams populating only what is relevant to current goals — progressively expanding coverage as new questions arise, much like the way an ERP system delivers increasing value as more modules are adopted.

Originally published as a conference paper by Graham McLeod in the PoEM 2023 Companion Proceedings (16th IFIP Working Conference on the Practice of Enterprise Modeling), Vienna, 2023.

How Business Architecture Informs Requirements

How does business architecture provide the context that makes requirements meaningful?

Requirements gathering that ignores the broader enterprise context produces solutions that solve the wrong problems. This presentation by Graham McLeod establishes why business architecture is a prerequisite for good requirements engineering, not an optional upstream activity. It walks through the key business architecture perspectives — motivation, value streams, operating models, functions, processes, services, and business capabilities — and shows how each one contributes to defining scope, surfacing gaps, and grounding solution requirements in business reality. A particularly useful section contrasts the enterprise architecture view (breadth, context, planning) with the solution architecture view (depth, design, delivery), using the analogy of city planning versus building design. The presentation also covers gap analysis and the role of reference models in assessing solution options against current capability.

Originally presented by Graham McLeod at Inspired events, 2018–2023.

The Power of Principles

Why are architecture principles the highest-return activity in enterprise architecture — and how do you define good ones?

Architecture principles are among the most powerful tools available to enterprise architects — yet they are frequently underdefined, poorly worded, or neglected altogether. This 2014 presentation by Graham McLeod makes the case that well-crafted principles, spanning business, application, information, and technology domains, represent the highest return on effort of almost any EA activity: a relatively small investment that shapes decisions across the entire organisation for years. Drawing on experience across banking, assurance, and telecommunications, the presentation covers what distinguishes a principle from a rule, how to structure principles effectively using the short name, statement, rationale, and implications format, and how to engage stakeholders in the definition process. A particularly useful concept is the "stealth payload" — the idea that while principle statements tend to be irrefutable, the implications are where the real architectural direction is embedded. The presentation also addresses compliance monitoring, showing how architecture assets can be mapped against principles and tracked over time to drive meaningful governance.

Originally presented by Graham McLeod at the Enterprise Architecture Conference Europe 2014 & Business Process Management Conference Europe 2014, June 2014.

Should Banks Outsource Operations Processing? Drivers, Constraints, and the EA Angle

What drives and constrains outsourcing decisions in corporate and investment banking — and what role should enterprise architects play?

Outsourcing operations processing is a live and recurring challenge for executive leaders in corporate and investment banking — and the decision is rarely as simple as comparing internal and external costs. This 2013 presentation by SJ van der Westhuizen, delivered at the Inspired TOGAF/EA Forum in Johannesburg, draws on research across thirteen banking organisations to map the full set of forces at play, distinguishing clearly between what drives outsourcing and what constrains it.

On the driving side, the research identifies capability maturity, capital preservation, management focus, and the formalising effect of contracts as significant positive forces. On the constraining side, organisational form complexity, responsiveness to change, reputational risk, management culture fit, and capability maturity concerns about prospective vendors all emerge as meaningful brakes. Cost and revenue, often assumed to be the dominant drivers, are shown to be more nuanced than executives typically expect.

A particularly valuable thread running through the presentation is the specific contribution enterprise architecture can make at each decision point — from capability-based planning and CMMI assessment, to operating model design, TOGAF governance frameworks, and the business model canvas. The central conclusion is direct: the greater the level of EA maturity in an organisation, the greater the number of business objectives achievable through outsourcing.

Originally presented by SJ van der Westhuizen at the Inspired TOGAF/EA Forum, Johannesburg, July 2013.

A Business and Solution Building Block Approach to EA Project Planning

How can enterprise architects bring clarity to project scope, release planning, and stakeholder communication across complex, interdependent programmes?

These slides accompany the paper: A Business and Solution Building Block Approach to EA Project Planning

When multiple projects are running in parallel — each with its own business analyst, development team, and agile backlog — it becomes surprisingly easy for scope, dependencies, and release content to become invisible to the people who most need to understand them: sponsors, stakeholders, and programme managers. This paper documents exactly that problem at a rapidly expanding South African telecoms company, where two major projects (Quoting and Billing) were underway with little consensus on scope, no agreed release breakdown, and a growing disconnect between business expectations and development plans.

The solution was a structured building block approach, distinguishing Business Building Blocks (BBBs) — capability-level components independent of technology choices — from Solution Building Blocks (SBBs), representing the actual systems, data sources, and infrastructure chosen to implement them. A facilitated workshop produced a BBB diagram showing capabilities, dependencies, and release groupings at a glance; a release matrix then mapped capability and content coverage to delivery timelines. Both were formalised in a meta model and implemented in the EVA Netmodeler repository, enabling traceability from business requirements through to agile backlogs and programme milestones.

The approach was well received across all stakeholder groups — sponsors, strategists, and programme managers reported that they finally had a clear, shared picture of what each project would deliver and when. The paper includes the full meta model, visual examples, and an honest reflection on adoption challenges, making it a practical reference for any EA function working to improve programme visibility and stakeholder alignment.

Originally published as a conference paper by Graham McLeod, Inspired.org / University of Cape Town, circa 2013–2014.

Real Business Architecture: Strategy, Design Thinking, and the Bigger Picture

How does business architecture go beyond conventional scope to become a genuine driver of business transformation?

Most treatments of business architecture focus on functions, processes, and capabilities — important, but incomplete. This 2012 presentation by Graham McLeod, delivered at The Open Group Enterprise Transformation Conference in Cannes, makes the case that the true scope of business architecture is much broader: encompassing innovation and design thinking, customer value and emotion, external context, emerging technology, and the full range of strategic concerns that drive organisational change. Drawing on TOGAF 9, Archimate 2, and the Inspired framework, the presentation maps out an expanded meta model that integrates motivation, functional, process, service, and capability perspectives — and shows how these are not competing views but complementary lenses that can be reconciled. A compelling section examines the transformative forces reshaping business in 2012 — cloud, big data, social media, additive manufacturing, and the rise of design-driven companies — and asks what business architects must do to stay relevant. Case examples from Apple, Volkswagen, and others illustrate how architectural thinking at the right level of abstraction enables the kind of strategic clarity that transforms organisations. The closing argument is unambiguous: business architecture practised at its full scope is a board-level strategic capability, not a documentation exercise.

Originally presented by Graham McLeod at The Open Group Enterprise Transformation Conference, Cannes, France, April 2012.

Engaging Real Business People in Real Business Architecture

Why do business executives avoid enterprise architecture — and how do you get them genuinely engaged?

The complaint is common among IT architects: business executives won't engage with enterprise architecture, leaving the whole effort directionless. But as this 2009 presentation by Graham McLeod argues, the real problem lies with what is typically presented to business people as "business architecture" — a technically framed, detail-heavy, IT-grown discipline that offers little of immediate relevance to the executives who actually own the business. Delivered at The Open Group EA Practitioners Conference in London, the presentation sets out both a diagnosis and a remedy. The diagnosis: most EA has grown upward from IT rather than downward from business strategy, and neither TOGAF nor most frameworks at the time adequately captured the full scope of genuine business architecture — context, markets, products, channels, customers, scenarios, and cross-cutting concerns like cost, risk, quality, and governance. The remedy: a comprehensive business architecture meta model, drawn from Inspired and PROMIS experience across banking, healthcare, assurance, telecommunications, and government, that gives executives models they recognise as their own. A particularly practical section addresses how architects must shift their role — from technical experts presenting conclusions to skilled facilitators asking good questions, holding up a mirror, and ensuring that models and content belong to the business rather than the architecture team. The presentation closes with specific suggestions for how TOGAF should expand its treatment of business architecture.

Originally presented by Graham McLeod at The Open Group EA Practitioners Conference (EAPC), London, UK, April 2009.

Service Orientation in Enterprise Architecture: Beyond Surface-Level Support

How should enterprise architecture frameworks and meta models be extended to provide genuine, deep support for service orientation?

Service orientation reshapes how applications are conceived, how systems are integrated, and ultimately how value is delivered to customers — yet most enterprise architecture frameworks treat it as a technical implementation detail rather than an architectural concern that spans the full enterprise stack. This 2008 presentation by Graham McLeod, delivered in his role as CTO of PROMIS Solutions AG, argues that achieving deep support for service orientation in EA requires rethinking frameworks and meta models from the ground up. The presentation distinguishes carefully between technical, application, information, and business services, and between logical service definitions — independent of technology and implementation — and their physical realisation, insisting that the mapping between these two levels is essential for meaningful planning and governance. A key architectural insight is the treatment of modern applications not as monolithic systems but as malleable bundles of functions exposed as services, where components can be replaced without impacting overall service delivery — a view that has significant implications for how application architecture is modelled. The presentation also addresses what it calls "enrichment": the additional concepts needed to govern services effectively, including intent (benchmarks, goals, objectives), responsibility and ownership, cross-cutting concerns (risk, cost, quality), and built-in computation and analysis. Archimate is proposed as a candidate notation for distinguishing domains and logical versus physical layers, with worked examples showing how service cross-referencing and traceability can be achieved in practice.

Originally presented by Graham McLeod at an Inspired/PROMIS event, December 2008.

The Central Role of Business Analysis in Enterprise Architecture

What role does business analysis play in enterprise architecture — and why is it central rather than peripheral?

Business analysis is frequently treated as a project-level discipline — something that happens within initiatives, not above them. This 2007 presentation by Graham McLeod challenges that view, arguing that business analysts have a central and irreplaceable role in enterprise architecture, particularly across the business and process architecture dimensions. Delivered to the IIBA Western Cape Chapter, the presentation walks through the components of EA using the Inspired frameworks, with detailed coverage of business architecture, business process architecture, and the relationship between strategy, architecture, and programme management. A key theme is requirements traceability — the clear linkage from business goals and events through to system and technology services — which demands the kind of domain knowledge and analytical rigour that experienced business analysts bring. The presentation concludes that EA represents a natural career growth path for analysts, and that organisations which keep the two disciplines separate are missing a significant opportunity.

Originally presented by Graham McLeod to the IIBA Western Cape Chapter, November 2007.

Breaking the EA Bottleneck: Collaborative and Distributed Enterprise Modelling

How can enterprise architecture move beyond the central "oracle" model to become a truly collaborative, distributed discipline?

The central architect as "oracle" — a single expert who holds all the knowledge and dispenses answers to those willing to make the pilgrimage — is a familiar and dysfunctional pattern in enterprise architecture. It creates bottlenecks, slows delivery, produces models that lack buy-in, and makes it almost impossible to integrate the perspectives of business, process, data, application, and technology teams who each hold a piece of the picture. This 2007 tutorial by Graham McLeod, delivered at the CAiSE conference in Trondheim, tackles this problem head-on with a comprehensive framework for collaborative, distributed enterprise modelling. The tutorial covers the full stack of enablers: shared meta models and naming standards as the foundation for integration; a structured process for identifying participants, educating them, collecting architecture elements, organising hierarchies, and building cross-domain relationships; and tool support that enables distributed teams to capture, relate, model, and share architecture content across geographies and time zones. A particularly useful section distinguishes the roles of framework, meta model, method, and repository tool — clarifying how each contributes to making collaboration work in practice. The benefits are concrete: higher quality inputs, faster results, greater organisational awareness, and significantly higher levels of architectural compliance, precisely because the people who need to act on the architecture helped build it.

Originally presented by Graham McLeod as a tutorial at CAiSE 2007 (19th International Conference on Advanced Information Systems Engineering), Trondheim, Norway, 2007.

What Should an EA Management Tool Actually Do?

What are the requirements for a truly effective enterprise architecture management tool — and how should one be designed?

The tools most organisations use to manage enterprise architecture — spreadsheets, presentation software, drawing tools — were built for entirely different purposes, and the gap shows. This 2005 presentation by Graham McLeod takes a rigorous look at what a purpose-built EA management tool actually needs to do, synthesising requirements from Zachman, Spewak, Schekkerman, TOGAF, and real-world RFPs into a comprehensive checklist spanning repository design, meta-modelling, collaboration, security, reporting, and governance support. The presentation then describes the design of Archi/WebModeler, Inspired's own web-based EA repository, and how its architecture addresses these requirements — including a runtime-extensible meta model, rich content types, inferencing and computation capabilities, visual modelling, and scenario management. Particularly notable is the emphasis on making the tool useful not just to enterprise architects but to the full range of stakeholders involved in EA: strategic planners, programme managers, risk managers, sponsors, and domain architects. For practitioners evaluating EA tooling or building the case for a dedicated repository, this presentation remains a clear-eyed benchmark of what good looks like.

Originally presented by Graham McLeod at an Inspired event, 2005.