### 1. What Enterprise Architecture is EA is defined three ways at once, and the three are not competing definitions — they're three facets of the same thing: 1. **A discipline** — a way of thinking about the structure of an enterprise (or an ecosystem). 2. **A process** — create, evolve, change, manage. 3. **A set of work products** — architecture models and representations. Most confusion about EA comes from someone using one facet while someone else hears another. "We have an architecture" (work products) is a very different claim from "we do architecture" (process) or "we think architecturally" (discipline). An organisation can have all three, or diagrams with no discipline, or discipline with no diagrams. **The formal course definition:** > Enterprise architecture (EA) is a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of business strategy. > > Enterprise architecture applies architecture principles and practices to guide organisations through the business, application, information, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes. Two load-bearing words: **holistic** (the whole, not a component) and **strategy** (EA exists to execute strategy, not to document systems for their own sake). #### 1.1 The Winchester House — the canonical anti-pattern Sarah Winchester's house, built 1884–1922: 38 years of continuous construction, 160+ rooms, 40 staircases, 47 fireplaces, 1200+ windows, 900+ doors. Cost US$5.5m (≈$78m today). Team: 147 builders, **0 architects**. Result: 65 doors opening onto blank walls, 13 staircases going nowhere, 24 skylights in the floor. The mechanism matters more than the trivia. Mrs Winchester **never had a master set of blueprints**, but she *did* sketch individual rooms — on paper and on tablecloths — and gave the foreman new instructions every morning. Every single instruction was locally sensible. There was no *global* view against which local decisions were checked. That is exactly the failure mode EA addresses. It's not that organisations make bad decisions; it's that a long series of individually reasonable decisions, made without a shared structural picture, accumulates into something nobody would have designed and nobody can now change. Hence the opening question in W1: *how many live applications does a decades-old bank or government agency have?* The options were 500 / 1,000 / 5,000 / **"They don't know"** — and the last one is the point of asking. ❓ *Poll results are an image on the slide; check the recording for what the room actually voted.* #### 1.2 The opposite of properly architected infrastructure: Shadow IT Where architecture doesn't reach, people route around it: - **Shadow applications** — unauthorised services/apps processing or storing business data - **Shadow AI / agents** — unauthorised AI services or agents - **Shadow devices** — unauthorised devices accessing business data - **Shadow APIs** — unauthorised ways business data reaches third parties The business-layer counterpart is called **workarounds**. Useful framing: shadow IT and workarounds are *symptoms*, not crimes. They're evidence of an unmet need the architecture didn't serve — which makes them a genuinely good source of requirements.