27 separate products that still read as one system.
Not because they share a database; they do not. Because the same record rules, the same shared registers and the same way of stating a number hold across every one of them.
- 0
- Independently operable applications
- 0
- Layers that hold across all of them
- 0
- Named records that cross a boundary
- 0
- Applications relevant in more than one area
Five layers, from the record upward.
This is what makes the portfolio an architecture rather than a catalogue. Each layer holds identically in every application, which is why an integrity register and a contract register behave the same way under audit.
- Layer 1
The record
Each application owns one class of industrial record end to end; the risk, the interface, the certificate, the reading, the transmittal; and is the system of record for it. Nothing else in the portfolio claims that record.
One owner per record class - Layer 2
The rules on it
Immutability, effective dating, supersession and segregation of duties are implemented the same way wherever they apply, so a control behaves identically in the integrity register and in the contract register.
The same controls, everywhere they apply - Layer 3
The shared registers
Equipment, personnel, organisations and locations exist once and are referenced rather than copied, which is why the same vessel is the same vessel in the logistics record and in the offshore day.
One entity, referenced not duplicated - Layer 4
The crossings
Where the work passes from one team to the next, one named record crosses with it. The receiving application holds its own view of that record and keeps its own history; nothing is merged.
A named record, not a shared database - Layer 5
The reporting language
Derived figures are stated the same way across the portfolio: what it counts, what it excludes, and what it refuses to compute. That is what lets a board read eight areas without eight glossaries.
One way of stating a number
One named record, handed across one boundary.
Integration in this portfolio is not a data lake. Where the work passes from one team to the next, a single named record crosses with it; and the receiving application keeps its own view and its own history of it.
- PMSLGMS
The receipt: what was bought becomes something that has to be moved
- LGMSCCMS
The delivered item: what arrived becomes what can be installed and tested
- CCMSSPIR
The completed system: what was proven becomes what is handed over
- QMSCCMS
The inspection and test record: quality evidence becomes completion evidence
- IFMSPDMS
The open interface: a boundary nobody has closed becomes a delivery exposure
- TSMPSM
The safety-critical element: a design definition becomes an operating obligation
- PSMAIRMS
The barrier: an assurance obligation becomes an inspection and integrity activity
- AIRMSEAMS
The defect: an integrity finding becomes maintenance work with a verification step
- EAMSRAMS
The failure event: a work order becomes evidence in a reliability model
- RAMSOMS
The critical item: a reliability driver becomes a supportability exposure
- FAMSHAMS
The production network: an engineered flow path becomes a measured quantity
- HAMSESG
The measured production: an operating figure becomes a disclosure figure
- HSERMS
The incident: an occupational event becomes enterprise risk evidence
- HSELLMS
The investigation: a finding becomes a lesson the next project can reach
Four things this portfolio deliberately does not have.
Most of what makes an architecture trustworthy is what it refuses to build. These are the four refusals that keep the applications genuinely separable.
No shared database
Applications do not read each other’s tables. A crossing is a named record handed across a boundary, with each side keeping its own history of it.
No single status field
There is no portfolio-wide health number rolling eight areas into one figure. Each area reports in its own terms, and the differences are the point.
No mandatory order of adoption
The architecture has no first application. Any of the applications can be the only one an organisation ever runs.
No hidden dependency
Where an application is more useful next to another, it says so. It does not fail, degrade or nag when that other one is absent.
One operating model, and honest cross-relevance.
Every application has one primary operating area. 12 are also relevant to another operating area, and the portfolio architecture records those relationships explicitly.
- Also relevant:EDMS
The same vessel is the same vessel in every application that mentions it.
Shared registers are the unglamorous half of this architecture and the half that decides whether two systems can be read together at all. Equipment, personnel, organisations and locations exist once and are referenced, never copied.
- An entity is created once and referenced everywhere it appears
- A crossing hands over a named record, leaving each side its own history
- Derived figures are stated the same way across all eight operating areas
Two other ways to read the portfolio.
This page argues the architecture. If you want to choose an application, or look one up, these are quicker.
Bring two systems that have to agree.
The interesting part of this architecture is the boundary between them. We will show you what crosses, what does not, and why.