Technology layer

The Application layer says what software runs the enterprise. The Technology layer says what that software runs on — the machines, the platform software, the networks, and the deployable artifacts. It is the bedrock of the model: everything above it ultimately lands here, on a node in a store or a cluster in a cloud.

This page pins down the five technology building blocks — node, device, system software, communication network, artifact — builds the Cadence Cycles infrastructure landscape, and then draws the infrastructure-usage view that shows where each application component actually runs.

What the Technology layer captures

• Active structure — nodes (a computational or physical resource that hosts software), the more specific devices (a physical node — a terminal, a server), and system software (the platform a component executes on: an operating system, a database engine, a container platform).
• Behaviour — technology services, the platform equivalent of an application service (e.g. "persistence," "compute").
• Passive structure — artifacts: a physical, deployable file — a container image, an installer, a JAR — that realises an application component.
• Connectivity — communication networks: the links the nodes sit on.

In the TOGAF ADM this is Phase D — Technology Architecture: the platform services and infrastructure that realise the application and data components, and the standards (the "technology reference model") they conform to.

Node, device, and system software

A node is the general idea: a place software runs. A device is a node that is specifically physical hardware — a store's POS terminals, an on-prem ERP server. System software is the platform layer a component needs in order to execute — a Kubernetes cluster (K8s), a PostgreSQL database, a content delivery network (CDN). The three nest naturally: system software runs on a node, a device is a node you can touch.

Cadence's estate splits cleanly in two, and that split is the omnichannel transformation seen from the basement. The stores run on devices — POS terminals on an in-store network — that predate the programme. The digital channel runs on a Cloud Platform node hosting a Kubernetes cluster and a CDN. And one deliberate hold-out, the On-prem ERP server, sits apart: the Motivation-layer constraint "ERP replacement out of scope this cycle" is, at this layer, a single node everyone integrates with but nobody is allowed to move.

Communication network and artifact

A communication network is the connectivity a set of nodes shares — the Store LAN/WAN inside the shops, the Internet between the stores and the cloud. Networks are what make "distributed" concrete: they are the thing an architecture review asks about when it wants to know how a store keeps selling if the link to the cloud drops.

An artifact is the deployable: the actual file that gets shipped and run — a container image, an installer package. Artifacts matter because they are the bridge back up to the Application layer: an artifact is deployed on a node (or its system software) and realises an application component. "The Ecommerce Platform" the business talks about is, down here, an ecommerce (container image) artifact running on the Kubernetes cluster — and naming that link is what makes a deployment diagram part of the same model as the capability map, rather than a disconnected ops wiki page.

The Cadence Cycles technology landscape

The technology view is the infrastructure inventory with its wiring, read left to right: a network connects a node, a node hosts its system software, and that platform deploys the artifact that realises a component.

The Cadence Cycles technology landscape — an authentic Archi export. Green is the Technology layer. A solid arrow is a serving relationship (a network connects a node); a line with a filled ball is assignment — used here for hosting (a node hosts its system software) and deployment (the platform, or node, deploys an artifact).

Read the two halves. The store half is short: the Store LAN/WAN serves the Store POS terminals, which run the pos-app (installer) — a self-contained till that keeps working on the shop floor. The cloud half is a small platform stack: the Internet serves the Cloud Platform, which hosts the Kubernetes cluster and the CDN; the cluster in turn deploys the ecommerce and oms container images. A separate Data platform node hosts PostgreSQL, the shared store of record beneath the online components. That structural difference — a flat device in the store, a layered platform in the cloud — is the omnichannel programme's operational cost, drawn to scale.

The infrastructure-usage view: where the applications run

The payoff view, and the mirror of the application-usage diagram one layer up. Two tiers: the application components (cyan, top) and the technology nodes (green, bottom) that host them. Every arrow is a serving relationship pointing up — from infrastructure to the software it runs.

Where the applications run — an authentic Archi export. Cyan is the Application layer, green the Technology layer; every arrow is a technology node → application component serving relationship. Read a component downward to see the node it runs on.

The shape is the whole story: a Cloud Platform fan hosting five components at once — Ecommerce Platform, OMS, Inventory Service, PIM, and CRM — with just two things left off it. The POS System runs on its own store terminals (it has to keep selling if the cloud is unreachable), and the ERP stays on its on-prem server (the constraint, again, made physical). The external Payment Gateway appears on neither tier — it runs on the provider's infrastructure, so the honest thing to draw is nothing at all. That one absence is a real architectural fact: a dependency Cadence relies on but does not operate.

The two usage views are one traceable chain

Stack this view under the application-usage view and you can trace a single line of sight from a customer promise to a machine: Online Purchase is served by Manage Order, which is realised by the OMS, which runs on the Cloud Platform. That unbroken thread — business service → application service → component → node — is the entire point of a layered model: change or outage at any level, and you can read off exactly what it touches above and below.

So what — which decision this drives

The technology layer turns "what happens if X goes down?" and "where is our risk concentrated?" into diagrams you can act on. The landscape shows the store/cloud split and the ERP hold-out — so a resilience review knows a store can trade offline but the online channel is wholly cloud-dependent. The usage view shows the Cloud Platform carrying five components — a single concentration to put behind real redundancy — and an external Payment Gateway nobody controls. These are the inputs to the availability targets, the disaster-recovery plan, and the cloud-migration roadmap — and, because they hang off the very same model as the capability map, they stay honest as the estate changes.

Where to go next

• Application — the components these nodes host and the services they expose to the business.
• Business — the value streams and processes that ultimately run, several layers down, on this infrastructure.
• Strategy — the capability map these systems and nodes exist to make real.