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.

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.

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.