The APM+ data model

1. Entity-relationship diagram

Applications sit at the centre. Everything else — capabilities, vendors, owners, cost and lifecycle — hangs off them, so a single change (an owner leaving, a support date lapsing) ripples through every view.

erDiagram
    accTitle: APM+ entity-relationship diagram
    accDescr {
        Applications sit at the centre of the model. An application supports many
        business capabilities, is accountable to contacts through stakeholder roles,
        is supplied by a vendor and runs on vendor software, is built from technology
        stack components, is licensed under a licence model and metered by licence
        metrics, holds a lifecycle status, and integrates with other systems through
        interactions. Capabilities form a parent-child hierarchy and can be owned by
        a contact.
    }
    APPLICATION {
        string name
        string description
        enum   criticality
        date   in_service_date
        date   out_of_service_date
        int    freshness_score
    }
    CAPABILITY {
        string capability_code
        string name
        enum   criticality
    }
    VENDOR {
        string name
        string website_url
        enum   record_type
    }
    VENDOR_SOFTWARE {
        string name
        string version
        date   primary_support_end_date
        date   extended_support_end_date
        date   sustaining_support_end_date
    }
    CONTACT {
        string name
        string email
    }
    STAKEHOLDER_ROLE {
        string name
    }
    LIFECYCLE_STATUS {
        string name
    }
    LICENCE_MODEL {
        string name
        string cost_model
    }
    LICENCE_METRIC {
        string metric
        int    quantity
    }
    TECH_STACK_COMPONENT {
        string role
    }
    INTERACTION {
        enum   interaction_type
        enum   direction
    }

    APPLICATION      }o--o{ CAPABILITY          : "supports"
    CAPABILITY       ||--o{ CAPABILITY          : "parent of"
    CAPABILITY       }o--o| CONTACT             : "owned by"
    APPLICATION      ||--o{ APPLICATION_STAKEHOLDER : "accountable via"
    APPLICATION_STAKEHOLDER }o--|| CONTACT       : "is"
    APPLICATION_STAKEHOLDER }o--|| STAKEHOLDER_ROLE : "plays"
    APPLICATION      }o--o| VENDOR              : "supplied by"
    APPLICATION      }o--o| VENDOR_SOFTWARE     : "runs on"
    VENDOR           ||--o{ VENDOR_SOFTWARE     : "publishes"
    APPLICATION      ||--o{ TECH_STACK_COMPONENT : "built from"
    TECH_STACK_COMPONENT }o--|| VENDOR_SOFTWARE : "component"
    APPLICATION      }o--o| LICENCE_MODEL       : "licensed under"
    APPLICATION      ||--o{ LICENCE_METRIC      : "metered by"
    APPLICATION      }o--o| LIFECYCLE_STATUS    : "in status"
    APPLICATION      ||--o{ INTERACTION         : "integrates via"
                    

Diagram generated from the shipping schema. Some supporting entities (logical applications, per-status lifecycle dates, assessments and risk records) are omitted here for legibility — they are described below.

2. Application

The central record. An application carries a name, description and a criticality rating, links to the vendor and vendor software behind it, a lifecycle status, in-service and out-of-service dates, and a computed freshness score. It maps many-to-many to the business capabilities it supports and to logical applications (the business-facing grouping above physical systems).

Accountability is expressed through stakeholders and roles rather than a single owner field (see §5), so “who owns this?” is answered by role — Business Owner, Technical Owner, and so on.

3. Capability

A business capability has a code, a name, a criticality and an optional owner. Capabilities form a hierarchy — each can have a parent — so you can model an APQC-style tree and roll coverage up from leaf capabilities to domains. Applications attach to the capabilities they realise, which is what powers the heatmap: duplicate coverage in one place, gaps in another.

4. Vendor & vendor software

A vendor publishes one or more vendor software products. Each product records version, category, deployment type, and the three end-of-support dates that drive the lifecycle exposure view — primary, extended and sustaining support end dates (validated to fall in chronological order). System-maintained vendor records feed the public EOL database; tenants can also add their own.

5. Stakeholders & roles

Accountability is a through-relationship: ApplicationStakeholder ties an application to a contact in a named role (StakeholderRole). An application can have many stakeholders, and the same person can hold different roles on different applications. The refresh-campaign flow targets the Business Owner stakeholder specifically.

6. Lifecycle

An application has a current lifecycle status plus a history of dated lifecycle events (a status and the date it took effect), so you can see both where an application is now and its planned trajectory. Combined with vendor support dates, this is what the roadmap and the two-year exposure view are built from.

7. Cost & licensing

Cost is modelled, not a single number. An application references a licence model (which carries a cost model) and has one or more licence metrics — a metric and a quantity (seats, cores, and so on). Total cost of ownership is derived from these rather than typed into one field, so the working behind a TCO figure is always visible.

8. Technology stack & interactions

Tech-stack components link an application to the vendor-software products it is built from, so a single end-of-support date can be traced to every application that depends on it.

Interactions record application-to-application integrations — which systems exchange data, in which direction, and by what type — so the portfolio is a graph, not just a list.

9. Freshness (cross-cutting)

Every portfolio record carries a freshness score — a decaying measure of how recently it was confirmed accurate. Editing a field does not reset it; only an explicit owner confirmation or a refresh-survey writeback counts as a review. Scores are recomputed on a schedule, not on save, so “this record was last verified in March” is a fact you can trust rather than a side effect of someone tweaking a description.

10. Tenancy

Every portfolio entity above is scoped to the companies you can access; queries are constrained to your organisation's data at the data layer, not just hidden in the UI. See the Trust & Security page for how isolation and data residency work.