Why architecture matters
This is the last of the three Foundations primer modules. You now know how electricity works and what London Grid Distribution does. This module answers the question that connects the primers to the rest of the course: why does a company like London Grid need something called "architecture" to manage change?
By the end of this module you will be able to:
- Describe what typically goes wrong when a company changes its systems without a coordinated plan
- Explain what architecture gives an organisation in plain, non-technical language
- Preview what enterprise architecture is and how the course will introduce it properly in Module 1
- Explain how London Grid Distribution is used as a running case study across all 8 stages of the course
Fictional scenario · London Grid Distribution
Five new systems. None of them talk to each other.
London Grid Distribution faces a familiar problem. Over the past three years, five different departments have each bought a new computer system to solve their own pressing problems. The connections team bought a new customer portal. The control room upgraded its monitoring system. The asset management team bought a new condition-monitoring platform. The data team procured an analytics tool. And the finance team replaced its ageing ERP system.
Each purchase made sense on its own. Each team chose the best product for their specific needs. Each project came in on time and on budget. From the outside, it looked like a company making good decisions.
But when the new chief executive asked a simple question: "How many customers are affected by our ten worst-performing circuits, and what is the investment plan to fix them?" the answer took six weeks to assemble. The data existed, but it was spread across five systems that could not share information with each other. Staff had to export spreadsheets from one system, reformat them, and manually import them into another. Some data did not match because the systems used different codes for the same substations.
The company had spent over eight million pounds on five good systems that, together, could not answer a basic question. The problem was not the systems. The problem was that nobody had asked how they would work together before buying them.
If five different teams each buy the best system for their own needs, but nobody checks whether those systems can share data, what is likely to happen?
That scenario is fictional, but the pattern is not. Organisations across every industry make this mistake repeatedly: they optimise each part of the business separately without thinking about how the parts connect. Architecture is the discipline that prevents this. This module explains what that means, without using any technical jargon from the enterprise architecture world yet.
0C.1 What goes wrong without architecture
When a company changes its systems, processes, and technology without a coordinated plan, several predictable problems appear.
Systems that cannot talk to each other. Each team picks the best tool for its own job, but nobody checks whether the tools can share data. The result is islands of information that require manual effort to connect. Staff spend hours copying data between spreadsheets instead of doing useful work.
Duplicated effort and wasted money. Two teams might buy two different mapping tools because neither knew the other was looking. Three teams might build three different customer databases because there is no shared view of what already exists. The company pays multiple times for capabilities it only needs once.
Decisions made without the full picture. When information is scattered across disconnected systems, leaders cannot get a clear view of what is happening. They make decisions based on incomplete data, or they wait weeks for someone to manually pull together a report that should take minutes.
Change becomes slower and riskier. When systems are tangled together in undocumented ways, changing one thing can break another. Teams become afraid to change anything because they do not know what depends on what. The company slows down at exactly the moment it needs to speed up.
Regulatory problems. For a regulated company like London Grid Distribution, poor coordination can lead to compliance failures. If the company cannot produce accurate data about its network condition, customer minutes lost, or investment plans, the regulator notices.
“The biggest risk is not that any single system fails. It is that nobody understands how all the systems fit together, so changes in one place cause unexpected problems somewhere else.”
Common observation across enterprise transformation programmes - Coordination failure patterns
This is the core problem that architecture solves. It is not about drawing diagrams. It is about making the relationships between systems, data, and processes visible enough that the company can change things safely and deliberately.
0C.2 What architecture gives you
Architecture, in the simplest possible terms, is a way of thinking about how all the parts of a company fit together before you start changing them. It does not mean drawing hundreds of diagrams. It means asking a few important questions early enough to avoid expensive mistakes later.
A shared map of what exists. Before you can decide what to change, you need to know what you have. Architecture gives the company a clear, shared picture of its current systems, data, and processes, so that everyone is working from the same understanding.
A clear picture of where you want to get to. Architecture helps the company describe its target state: what the systems, data, and processes should look like once the changes are complete. This target is not a fantasy. It is a realistic, agreed picture that teams can plan towards.
A plan for how to get there. The gap between where you are and where you want to be is rarely something you can close in one step. Architecture helps the company sequence the changes: what to do first, what to do next, and what can wait. This sequencing prevents the company from trying to change everything at once and failing.
A way to check that changes stay on track. Architecture provides a set of principles and rules that guide decisions as the changes are made. When a team proposes a new system or a change to an existing one, the architecture gives a way to check: does this fit with the plan? Does it create new problems elsewhere? Is there a better option that has already been agreed?
Think of it like renovating a house. You could just start knocking down walls and buying new furniture. But if you draw a plan first, agree what each room is for, check that the plumbing and wiring work with the new layout, and then build in a sensible order, you are much more likely to end up with a house that works. That planning step is what architecture provides for an organisation.
Common misconception
“Architecture is just about drawing diagrams and producing documentation.”
Documentation is a by-product, not the purpose. The purpose of architecture is to help the organisation make better decisions about change. If the architecture work does not improve the quality of decisions, it is not doing its job, no matter how many diagrams it produces.
0C.3 A preview of enterprise architecture
When the word "architecture" is applied to an entire enterprise (meaning the whole organisation, not just the IT department), it becomes enterprise architecture. This is a discipline that looks at four big areas together:
Business. What the organisation does, how it is structured, what capabilities it needs, and what processes it runs. For London Grid, this includes fault management, connections, asset maintenance, and regulatory reporting.
Data and information. What data the organisation creates, stores, and shares, and how that data flows between people and systems. For London Grid, this includes asset records, customer data, network readings, and regulatory submissions.
Applications. The computer systems and software that the organisation uses. For London Grid, this includes SCADA, DMS, GIS, OMS, ERP, and many smaller tools.
Technology. The physical and cloud infrastructure that those applications run on: servers, networks, data centres, security tools, and communication links. For London Grid, this includes the operational technology network that connects substations to the control room.
Enterprise architecture looks at all four areas together and asks: how do they connect? Where are the gaps? What needs to change? In what order? Module 1 of this course introduces enterprise architecture properly, using a formal framework called TOGAF. The Foundations primers have given you the context to understand why that framework matters.
Note: this preview deliberately avoids formal definitions and framework-specific language. Module 1 will introduce those properly. The point here is to give you the intuition first, so the definitions make sense when you meet them.
0C.4 How the course uses London Grid Distribution across all 8 stages
The Enterprise Architecture course has 8 stages plus these 3 Foundations primers, with 67 modules in total. London Grid Distribution appears throughout as the running case study. Here is a preview of how the company's story develops across the stages:
Stage 1: Orientation (Modules 1 to 8). You learn what enterprise architecture is, how TOGAF is structured, and what the key concepts mean. London Grid is introduced as the company whose transformation the course will follow.
Stage 2: Architecture Vision (Modules 9 to 16). You learn how to define the scope, stakeholders, and vision for an architecture effort. London Grid's executive team commissions a transformation programme and the architecture team defines what it needs to achieve.
Stage 3: Business Architecture (Modules 17 to 24). You learn how to map business capabilities, value streams, and organisational structure. London Grid's business processes (fault management, connections, asset planning) are analysed and redesigned.
Stage 4: Information Systems Architecture (Modules 25 to 32). You learn how to design data and application architectures. London Grid's data flows and system landscape (SCADA, DMS, GIS, OMS, ERP) are mapped and a target state is designed.
Stage 5: Technology Architecture (Modules 33 to 40). You learn how to design the technology foundation. London Grid's infrastructure, including its operational technology network and cyber security posture, is assessed and a target technology architecture is designed.
Stage 6: Opportunities and Migration (Modules 41 to 48). You learn how to identify change opportunities, assess readiness, and plan the migration from current state to target state. London Grid builds its transformation roadmap.
Stage 7: Governance (Modules 49 to 56). You learn how to set up the governance structures that keep architecture alive after the initial design. London Grid establishes its Architecture Board, compliance processes, and change control mechanisms.
Stage 8: Capstone (Modules 57 to 64). You bring everything together in a comprehensive capstone exercise. London Grid's full architecture is reviewed, challenged, and refined.
“Every concept in this course is grounded in a specific London Grid Distribution scenario. The company grows more complex as the course progresses, so that by Stage 8, you have seen enterprise architecture applied to a complete, realistic organisation.”
Course design principle - Running case study approach
The fictional company is not decoration. It is the primary teaching mechanism. Every framework concept, every technique, and every governance structure is demonstrated through London Grid scenarios before being applied more broadly.
London Grid Distribution spent eight million pounds on five new systems, but none of them can share data with each other. What is the root cause of this problem?
Enterprise architecture looks at four big areas together. Which of the following correctly lists all four?
Key takeaways
- Without architecture, companies typically end up with disconnected systems, duplicated effort, incomplete data for decisions, slow and risky change, and regulatory problems.
- Architecture is not about drawing diagrams. It is about asking how all the parts of a company fit together before you start changing them, so that changes are coordinated, sequenced, and traceable.
- Enterprise architecture looks at four areas together: business, data and information, applications, and technology. Looking at all four is what makes it enterprise rather than just technical.
- London Grid Distribution is the running case study across all 67 modules of this course, from these Foundations primers through the 8 main stages. Every concept is grounded in a realistic London Grid scenario.
Standards and sources cited in this module
The TOGAF Standard, 10th Edition (C220)
Part 0, Introduction and Core Concepts
Referenced as the source of the enterprise architecture domain model (business, data, application, technology) previewed in Section 0C.3. The full framework is introduced in Module 1.
Ofgem, Digitalisation Strategy and Action Plan Guidance for regulated energy companies
Expectations for data sharing, system interoperability, and digital investment planning
Background reference for the regulatory pressure that makes coordinated system change essential for distribution network operators. Referenced in Section 0C.1 (regulatory problems).
The Foundations primers are complete. You understand what electricity is, what London Grid Distribution does, and why architecture matters. The next module introduces enterprise architecture properly, using TOGAF 10, and begins the first of 8 stages.
Foundations · Enterprise Architecture