🧭

Greene King — Systems View, C4, ERD and Medallion Shape

A practical read of the current platform picture. No grandstanding, no made-up certainty, just a sensible view of how the parts hang together and where Dynamics 365, AWS, Cognos, Workday and Indigo WMS are likely to sit.

⚙️ The shape of it

Greene King is not doing one transformation. It is moving several parts of the business at once. That matters, because each domain can look tidy on its own while the whole thing still ends up a bit of a dog's dinner if the joins are weak.

The broad picture is simple enough: Workday for people data, Indigo WMS for stock and logistics, digital channels for bookings and customer touchpoints, IoT / smart pub kit for operational events, and AWS plus Cognos downstream for data processing and reporting. Dynamics 365 fits best as the operational customer and service layer in the middle, not as the owner of everything under the sun.

📊 Summary table

Domain What is going on Likely platform Where Dynamics 365 fits
HR & workforce HR, payroll, workforce structure, scheduling Workday Reference and integration only, perhaps assignment or service visibility
Customer experience App, website, bookings, customer interactions Digital channels + CRM Strong fit for customer service, interaction history, consent and customer operations
Pub operations AI trials, smart dispense, CCTV, energy kit, devices IoT / operational tech Useful for incident handling and tickets, not the raw telemetry master
Supply chain Warehouse, inventory, stock movement, shipments Indigo WMS Visibility into customer or service impact, but not SoR for stock
Analytics Processing, conformance, business reporting AWS + Cognos Source into analytics, not a replacement for the analytics layer
🧱 C4 in plain English

C4 is just a tidy way of showing a system at the right zoom level. Same estate, different altitude. Context gives the big picture. Containers show the major building blocks. Components open up one of those blocks. Code is the wiring detail if you really want to go that far.

In this case, the useful bit is not the textbook definition. It is that C4 stops people trying to cram strategy, application structure and low-level design into one heroic box diagram that nobody trusts by Friday.

Level 1 — Context

flowchart LR
    Customer["Customers (App / Web / In-Pub)"]
    App["Website & Mobile App"]
    D365["Dynamics 365 (Customer & Service Layer)"]
    Workday["Workday (HR / Payroll / Scheduling)"]
    WMS["Indigo WMS (Supply Chain / Logistics)"]
    IoT["Pub Systems (AI / IoT / Smart Equipment)"]
    Data["AWS + Cognos (Data & Analytics)"]

    Customer --> App
    App --> D365
    D365 --> Workday
    D365 --> WMS
    D365 --> IoT
    Workday --> Data
    WMS --> Data
    IoT --> Data
    D365 --> Data

Level 2 — Container view

flowchart TB
    subgraph Experience["Experience Layer"]
        App["Website & Mobile App"]
    end

    subgraph D365Layer["Dynamics 365 Layer"]
        CI["Customer Insights / Profiles"]
        CS["Customer Service / Cases"]
        MKT["Marketing / Journeys"]
        INT["Integration Layer"]
    end

    subgraph CoreSystems["Core Systems"]
        WD["Workday"]
        WMS["Indigo WMS"]
        IOT["IoT / Pub Systems"]
    end

    subgraph DataLayer["Analytics"]
        AWS["AWS Processing / Storage"]
        Cognos["IBM Cognos"]
    end

    App --> CI
    App --> CS
    CI --> MKT
    CS --> INT
    INT --> WD
    INT --> WMS
    INT --> IOT
    WD --> AWS
    WMS --> AWS
    IOT --> AWS
    CI --> AWS
    CS --> AWS
    AWS --> Cognos
🗂️ ERD — practical logical model

This is a sensible enterprise model, not a claim that every Greene King table is literally named this way. The aim is to show the shape of the data and where the joins are likely to be.

Area Main entities Likely source system
Customer Customer, Loyalty Account, Marketing Consent, Booking, Visit, Customer Interaction, Service Case App / website / Dynamics 365
Pub operations Pub, Pub Device, Device Event, Dispense Event, CCTV Event, Energy Reading, Maintenance Ticket Operational tech / IoT platforms
People Worker, Organisation Unit, Work Schedule, Payroll Result Workday
Supply chain Warehouse, Product, Inventory Balance, Stock Movement, Shipment Indigo WMS

ERD sketch in Mermaid

erDiagram
    CUSTOMER ||--o{ BOOKING : makes
    CUSTOMER ||--o{ CUSTOMER_INTERACTION : performs
    CUSTOMER ||--o{ SERVICE_CASE : raises
    CUSTOMER ||--o{ MARKETING_CONSENT : gives
    CUSTOMER ||--o{ LOYALTY_ACCOUNT : holds

    PUB ||--o{ BOOKING : receives
    PUB ||--o{ SERVICE_CASE : relates_to
    PUB ||--o{ PUB_DEVICE : contains

    WORKER }o--|| ORGANISATION_UNIT : belongs_to
    WORKER ||--o{ WORK_SCHEDULE : has
    WORKER ||--o{ PAYROLL_RESULT : receives

    WAREHOUSE ||--o{ INVENTORY_BALANCE : holds
    PRODUCT ||--o{ INVENTORY_BALANCE : counted_in
    PRODUCT ||--o{ STOCK_MOVEMENT : moves_as
    WAREHOUSE ||--o{ STOCK_MOVEMENT : occurs_in
    STOCK_MOVEMENT }o--o| SHIPMENT : grouped_into
    SHIPMENT }o--|| PUB : destined_for

    PUB_DEVICE ||--o{ DEVICE_EVENT : emits
    DEVICE_EVENT ||--o| MAINTENANCE_TICKET : creates
🏛️ System of record mapping

This is the bit that usually saves grief. Not every system should own every fact. Some things are mastered once, copied where needed, and reported elsewhere. Mix those up and you get duplicate truth and long meetings.

Entity / domain System of record Notes
Worker, org structure, schedule, payroll Workday Clear fit. Dynamics should reference, not own.
Warehouse, stock, movements, shipments Indigo WMS Logistics truth lives here.
Service case, customer interaction Dynamics 365 Strong operational CRM fit.
Booking creation App / website / booking engine Can be copied into Dynamics for action and visibility.
Device events, telemetry, smart pub signals IoT / operational tech Dynamics may consume alerts, but should not pretend to be the raw event store.
Reporting marts and dashboards None — analytical only AWS and Cognos consume and shape data; they do not create business truth.
Practical rule: Workforce belongs to Workday. Stock belongs to WMS. Service belongs to Dynamics. Telemetry belongs to the operational kit. Reporting belongs downstream.
☁️ AWS + Cognos — where they fit

AWS and Cognos are easy to muddle if people talk too loosely. AWS is the processing and storage side of the house. Cognos is the reporting face put on top of prepared data. Neither should be treated as the place where operational truth is born. 

flowchart LR
    Source["Operational Systems
Workday / WMS / Dynamics / IoT / App"]
    AWS["AWS
processing / storage / shaping"]
    Cognos["IBM Cognos
dashboards / reports"]
    Users["Business users"]

    Source --> AWS
    AWS --> Cognos
    Cognos --> Users

Put bluntly: AWS gets the data into shape. Cognos gives people something sensible to look at.

🥇 Bronze / Silver / Gold — medallion view

This is the cleanest way to explain the downstream data shape. Bronze is what arrived. Silver is what it means. Gold is what the business is allowed to argue about.

Medallion diagram

flowchart LR

    subgraph Sources["Operational Source Systems"]
        App["Website / App / Booking"]
        D365["Dynamics 365"]
        Workday["Workday HR / Payroll / Scheduling"]
        WMS["Indigo WMS"]
        IoT["Pub IoT / Smart Equipment / CCTV / Dispense"]
    end

    subgraph Bronze["Bronze - Raw Landing"]
        B1["Raw App / Booking Data"]
        B2["Raw Dynamics Data"]
        B3["Raw Workday Data"]
        B4["Raw WMS Data"]
        B5["Raw IoT Event Data"]
    end

    subgraph Silver["Silver - Cleaned / Conformed"]
        S1["Customer & Booking Model"]
        S2["Service & Case Model"]
        S3["Workforce Model"]
        S4["Inventory & Logistics Model"]
        S5["Pub Operations / IoT Model"]
        S6["Conformed Reference Data
Pub / Product / Worker / Date"]
    end

    subgraph Gold["Gold - Business Ready"]
        G1["Customer Experience Mart"]
        G2["Operations Efficiency Mart"]
        G3["Workforce & Labour Mart"]
        G4["Supply Chain Mart"]
        G5["Executive KPI Mart"]
    end

    Cognos["IBM Cognos Analytics"]

    App --> B1
    D365 --> B2
    Workday --> B3
    WMS --> B4
    IoT --> B5

    B1 --> S1
    B2 --> S2
    B2 --> S1
    B3 --> S3
    B4 --> S4
    B5 --> S5

    S1 --> S6
    S2 --> S6
    S3 --> S6
    S4 --> S6
    S5 --> S6

    S1 --> G1
    S2 --> G1
    S5 --> G2
    S4 --> G2
    S3 --> G3
    S4 --> G4
    S1 --> G5
    S2 --> G5
    S3 --> G5
    S4 --> G5
    S5 --> G5

    G1 --> Cognos
    G2 --> Cognos
    G3 --> Cognos
    G4 --> Cognos
    G5 --> Cognos
Layer What it is for Examples here
Bronze Raw landing, traceability, replay Raw Workday, raw WMS, raw Dynamics, raw app events, raw IoT events
Silver Cleaning, conformance, business meaning Customer model, service model, workforce model, logistics model
Gold Business-ready marts for reporting Customer experience mart, executive KPI mart, supply chain mart

The reason this matters is simple. If Cognos reads random raw tables from whatever system shouted loudest, you get conflicting numbers and a weekly row over whose spreadsheet is holy.

🧩 Where Dynamics 365 actually earns its keep

Dynamics 365 is most useful here when it behaves as the customer and service operating layer. That means cases, interactions, perhaps consent, perhaps ticketing, and a joined-up view of customer-facing activity.

It is far less convincing if someone tries to wave it around as the master for payroll, stock, logistics, telemetry and reporting all at once. That is how platforms end up blamed for jobs they were never meant to do.

Useful stance: Dynamics is the operational glue between customer touchpoints and the deeper estate. It is not the entire estate.

🏁 Bottom line

The pattern is fairly standard once you strip away the labels. Systems of record sit in their own lanes. Dynamics 365 handles customer and service operations. AWS and Cognos sit downstream. A medallion approach keeps reporting from turning into guesswork.

If this were my deck, the message would be: modernise by domain, integrate with discipline, and do not let reporting masquerade as data architecture.