Terminology and Processes

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 — Business, Data, Application, Technology — 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: https://www.digital.govt.nz/standards-and-guidance/technology-and-architecture/government-enterprise-architecture/

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.