Why architecture matters
Changing systems without a coordinated plan is how organisations end up with tangled, fragile estates that nobody fully understands. With the groundwork in place on how electricity works and what London Grid Distribution does, the remaining question is the one 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
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?
Architecture is the discipline that stops a company optimising each part of the business separately and discovering too late that the parts will not work together. That scenario is fictional, but the pattern is not: organisations across every industry make the same mistake repeatedly. What follows explains what architecture means in plain terms, without 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 interruptions and customer minutes lost (the counts of how many customers lose supply and for how long, which Ofgem uses to reward and penalise distribution network operators), or investment plans, the regulator notices.
The 4 architecture decisions and failures they should prevent
Before any change crosses a domain boundary, TOGAF Phase G governance asks four checks, capability, authority, integration and governance, and records each, so a single skipped check cannot name a defect the other three are unable to recover.
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. The figure above names four such questions as checks a change should clear before it goes live: capability, authority, integration, and governance.
Capability: is the cross-domain scope agreed? Before you change anything, you need to know which teams and systems the change touches. Architecture gives the company a clear, shared picture of what exists across those domains, so a fix is not taken in isolation and does not break a handover nobody named.
Authority: is the source of truth confirmed? When two systems could each claim to hold the correct answer, architecture settles which one owns it and logs that ownership in the repository, so teams stop working from conflicting facts.
Integration: is the contract agreed up front? Changes rarely stand alone. Architecture surfaces the hidden dependencies between systems and gets agreement on how they will connect before the change ships, rather than letting a downstream system break silently once it is live.
Governance: is the decision logged in full? Architecture provides a set of principles and rules that guide decisions as changes are made, and it records who decided, when the decision will be reviewed, and how to roll it back if needed. That record is what lets an audit trace the decision later.
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.
The architecture practice as a closed control cycle
Architecture governance runs as a loop, not a one-off review: each change is reviewed, its decision recorded into the repository, and that updated repository becomes the informed context for the next change, so skipping the final step lets a settled decision return.
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 72 numbered modules in total (plus phase summaries and scenario practice at the end of each stage). 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 and TOGAF 10 in Practice (8 modules). You learn what enterprise architecture is, how TOGAF is structured, what the key concepts mean, and how Requirements Management sits at the centre of the method. London Grid is introduced as the company whose transformation the course will follow.
Stage 2: Preliminary Phase and Architecture Vision (8 modules). 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 (10 modules).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 (11 modules). You learn how to design data and application architectures, including data, analytics and AI governance. 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 and Cross-Cutting Design (9 modules). You learn how to design the technology foundation, including a cloud target architecture and landing zones. 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, Solutions, Migration, and Delivery (8 modules). 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: Running EA as a Capability (11 modules). You learn how to run Phase G Implementation Governance and Phase H Architecture Change Management, set up the governance structures that keep architecture alive after the initial design, choose an operating model, measure and report architecture value, and communicate it to executives. London Grid establishes its Architecture Board, compliance processes, and change control mechanisms.
Stage 8: Comparison, Tailoring, Limitations, and Capstone (7 modules). You bring everything together in a capstone exercise. London Grid's full architecture is reviewed, challenged, and refined.
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?
Core distinctions
- 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