### 2. Terminology: from IT architecture to digital architecture Four concepts, appearing roughly a decade apart, each **incorporating** (not replacing) the previous: ``` ┌─────────────────────────────────────────────┐ │ Digital Architecture (of ecosystems) │ │ ┌────────────────────────────────────────┐ │ │ │ Enterprise Architecture (EA) │ │ │ │ ┌───────────────────────────────────┐ │ │ │ │ │ IS/IT Landscape Architecture │ │ │ │ │ │ ┌──────────────────────────────┐ │ │ │ │ │ │ │ IS/IT Systems Architecture │ │ │ │ │ │ │ └──────────────────────────────┘ │ │ │ │ │ └───────────────────────────────────┘ │ │ │ └────────────────────────────────────────┘ │ └─────────────────────────────────────────────┘ ``` | Era | Concept | What drove it | Scope | |---|---|---|---| | ~1980s | **IS/IT Systems Architecture** | Stakeholders hold different views of a system; systematic IS development spans layers from business to technical; each view/layer needs its own (integrated) modelling method | One system | | ~1990s | **IS/IT Landscape Architecture** | Cost and complexity of whole IS/IT landscapes became visible; architecture management emerged as a systematic way to plan and realise landscapes | All systems in an organisation | | ~2000s | **Enterprise Architecture** | Enterprise-wide architecture management as the means to **business–IT alignment**; business processes, capabilities and models became central; EA as a discipline for holistic business management | The whole enterprise, business included | | ~2010s–20s | **Digital Architecture of Ecosystems** | Holistic architecture beyond a single organisation → business-ecosystem perspective; digitalisation of whole business and operating models; continuous deployment and evolution of digital services | Networks of organisations | **Business ecosystem** (Moore, 1996): the unit of analysis is no longer the firm but the network — suppliers, customers, complementors, competitors, and digital platforms. **Coopetitors** blur the organisational boundary: organisations that compete and cooperate simultaneously (an airline alliance; two banks sharing payments rails). Once the boundary blurs, you cannot architect only up to your own edge. **Practical upshot:** "digital architecture" is not a rebrand of EA. It's EA plus (a) the ecosystem beyond the firm's boundary and (b) the assumption that architecture is continuously evolving rather than periodically redesigned. --- ### 3. The five architecture layers The organising spine of the whole course. | Layer | What lives here | Guiding question | |---|---|---| | **Goals & Strategy** | Enterprise strategy, goals, objectives | What to do, and how to do it? | | **Business** | Business processes supporting the strategy, operational organisation, value delivery | How does the organisation actually operate? | | **Applications & Systems** | Applications supporting the business; business functions implemented in information systems | What software realises the business? | | **Data & Information** | The organisation's information — *"the fuel that drives the processes"* | What does the organisation know, and where does it live? | | **Network & Infrastructure** | Technical components (servers, networks) and technology (platforms, clouds) supporting the IS | What runs it all? | Notes: - The layering is a **dependency and motivation stack**, not an org chart. Each layer exists to serve the one above and is enabled by the one below. - Course slides order it Goals → Business → Applications → Data → Infrastructure in the visual, but Data & Information is conceptually cross-cutting: every layer produces and consumes it. - This maps onto TOGAF's **BDAT** — **B**usiness, **D**ata, **A**pplication, **T**echnology — with Goals & Strategy corresponding to ArchiMate's Motivation and Strategy layers. † - New Zealand's Government Enterprise Architecture is a live public example of a framework built on this idea: --- ### 4. Architecture as a process: baseline → target #### 4.1 The three-step spine > **(BASELINE) ──── transition ────▶ (TARGET)** | Step | Question | Work | |---|---|---| | 1 | Find out where you are | Business modelling · current data & applications · issues | | 2 | Work out where you're going | Goals · requirements · target-state modelling | | 3 | Plan how to get there | Roadmaps · project initiation · transition planning | #### 4.2 Transformation vocabulary (Week 2) The four terms sit at different points on the baseline→target arrow, and mixing them up is the classic early error: ``` Trigger Transformation Capabilities Benefits │ │ │ ▼ ▼ ▼ [ Baseline ] ────────── Transition / Transformation ──────────▶ [ Target ] ▲ │ Drivers ('where to? why?') ``` | Term | Definition | Test | |---|---|---| | **Trigger** | The specific event or realisation that *started* the initiative | A moment in time. "What happened that made them act *now*?" | | **Driver** | The ongoing condition or force motivating the change — 'where to? and why?' | A standing state of the world. Doesn't go away when the project starts | | **Transformation capability** | The knowledge, skills, processes and culture the organisation **developed and used** to transform itself successfully | Something the organisation had to *become able to do* in order to change | | **Benefit** | The realised value at the far end | Only meaningful after the target state exists | A trigger is a *spark*; a driver is *fuel*. "Margins slipped 4% over two years" is a driver. "A board member said the business is run by systems" is a trigger. #### 4.3 Three directions of transformation Most architectural transformation initiatives follow one or more of these, positioned on an internal↔external axis: ``` internal focus ◀─────────────────────────────────────────▶ external focus Streamlining / Reorganising the IT Digitally transforming enhancing internal landscape to increase interactions with operations efficiency and agility external clients/customers ``` Cross this with a second axis — **incremental ↔ radical** (limited to extensive change) — and you get a simple 2-D map for classifying any case study. The W2 cases are best read as points on this map: | Case | Likely direction | ❓ Confirm against your own case reading | |---|---|---| | Australian Retailer | internal ops / IT landscape | ❓ | | USAA | external (life-event integration) | ❓ | | LEGO | external + business model | ❓ | | Hummel | external (omnichannel) | ❓ | | DBS | all three, in phases | ❓ | #### 4.4 Three approaches to architecting | Approach | What it means | When it fits | |---|---|---| | **Full organisation architecting** | A complete architecture approach across the enterprise | Large-scale, well-resourced, long-horizon | | **Targeted architecting** | Architecture for a project in one business or ecosystem area | Most real projects — and the model for the Coffee Co. assignment | | **Architecting as a way of doing things** | Architecture *principles* applied in all BA and implementation work; architectural *thinking* across business and IT | The BA's default mode — no formal EA function needed | #### 4.5 What EA is claimed to be good for Three cited sources, three angles: - **Niemi & Pekkola (2020)** — benefits of EA in organisational transformation. - **Ahlemann, Legner & Lux (2021)** — a resource-based view: EA supports the management of both IS *and* the business, including "cleaning up the mess" left by *n* years of no architectural oversight. - **Saleem & Fakieh (2020)** — business support splits into **external competitive advantage** and **internal agility**. Worth holding a sceptical thought here: EA benefits are notoriously hard to attribute, which is why the literature keeps producing benefit taxonomies rather than effect sizes. Useful for a critical reflection paragraph. ---