Application register
Every field carries a mandatory source and a verification date. Completeness is measured per system against a target you set, so you can see where the ground is thin before the first interview.
Application register
From a spreadsheet nobody trusts to a register that holds up when quoted.
Portvarde turns your system overview from a spreadsheet nobody trusts into a register with an owner, a classification and an audit trail on every single row.
Runs in your own Azure subscription. Sign-in with Entra ID.
Systems
4 of 214 shownAurora LMSTier 1
Nordvik ERPTier 2
Fjordheim CRMTier 3
Saltnes HRTier 4
Completeness68 %
Six moves
What the overview lacks is rarely more rows.
It lacks ownership that holds, a classification someone can defend, and a way to see what depends on what. Portvarde is built around those six.
Integration register
One row per data flow: the master for the data object, mechanism, frequency, authentication, error handling and monitoring. Also shown as a system × system matrix.
Capability map
A hierarchy based on a reference model, adapted to your organisation. Systems are placed underneath, white spots are marked, and duplication becomes visible instead of surfacing during the next procurement.
Tier classification
Tier 1–5 with a requirement checklist. The proposed tier is inherited from the most critical capability a system supports. Deviations require a reason, and you are warned about tier inflation.
Health scoring and TIME
Functional and technical scores with fixed anchors. An interactive TIME matrix where the axes cross at 3.0 and bubble size is annual cost. The calibration report flags when the anchors were not used.
Findings and risk
A rule engine flags missing owners, unknown hosting locations, an empty legal basis, weak authentication, contracts about to expire, overdue verification and competing masters.
The register
Every row also states how well it is known.
A field with no source and no verification date is a claim. The register separates the two, and measures the difference per system rather than presenting everything as equally certain.
| System | Owner | Tier | Source | Last verified | Completeness |
|---|---|---|---|---|---|
| Aurora LMS | Ingrid Hovden | Tier 1 | Contract | May 14, 2026 | |
| Nordvik ERP | Kjell Aasen | Tier 2 | Interview | Apr 2, 2026 | |
| Havbris betaling | Marit Løvold | Tier 2 | Contract | Jun 1, 2026 | |
| Fjordheim CRM | Tor Ekeberg | Tier 3 | Entra ID | Mar 19, 2026 | |
| Tindra datavarehus | No owner | Tier 3 | Spreadsheet | Feb 27, 2025 · overdue | |
| Bjerkely arkiv | Silje Brenna | Tier 3 | Spreadsheet | Sep 8, 2025 · overdue | |
| Saltnes HR | Ove Frantzen | Tier 4 | Interview | Jan 23, 2026 | |
| Vardøger portal | Hanne Rygg | Tier 5 | Spreadsheet | Jun 11, 2025 · overdue |
Illustration using invented systems and figures. In a real register of 214 systems, the completeness figure – 68 % here – is what tells you how much of the picture is actually mapped.
Classification
A tier is inherited, not handed out.
The proposed tier is the most critical capability a system supports. That way the discussion does not start from zero for every system, and disagreement is about something concrete.
Tier 1Round-the-clock operation, tested recovery, two named owners1 systems
Tier 2Operated in business hours, documented recovery, two owners2 systems
Tier 3Agreed response time, backup verified within the past year3 systems
Tier 4Best effort, a backup exists1 systems
Tier 5No operational commitment beyond what the contract states1 systems
41 % of the portfolio sits on Tier 1–2. The threshold is 40 %, and above it the classification has usually drifted rather than the risk having grown.
Inherited from capability
Records and documentsTier 5Bjerkely arkivProposed Tier 5
Set to Tier 3 instead of Tier 5. A deviation is not saved without a reason.
Illustration using invented systems and figures. A deviation is allowed but requires a reason that stays on the row. When the Tier 1–2 share passes 40 %, the classification has usually drifted – and that, rather than the operations budget, is what to look at first.
Health and TIME
The placement is a result, not an opinion.
Functional and technical scores are set against fixed anchors rather than judgement in the moment. That way two people can assess different systems and still produce numbers that compare.
- Aurora LMSMigrateNOK 2.4M
- Nordvik ERPMigrateNOK 3.1M
- Havbris betalingInvestNOK 1.2M
- Fjordheim CRMInvestNOK 780K
- Tindra datavarehusInvestNOK 920K
- Bjerkely arkivTolerateNOK 310K
- Saltnes HRTolerateNOK 540K
- Vardøger portalEliminateNOK 260K
Illustration using invented systems and figures. The axes cross at 3.0, and bubble size is annual cost – an expensive system in the wrong quadrant is the one that costs most to leave alone. The calibration report flags when the anchors were not used, or when too much clusters around the middle.
Capabilities
Two questions a spreadsheet cannot answer.
What do we not cover, and what do we cover twice. Both only become visible once systems hang under the capabilities they actually support.
Learning and teachingTier 1
- Aurora LMS
Finance and procurementTier 2
- Nordvik ERP
- Havbris betaling
Customer and relationsTier 3
- Fjordheim CRM
PeopleTier 4
- Saltnes HR
Records and documentsTier 5
- Bjerkely arkiv
- Vardøger portal
Duplication – two systems cover the same ground
Analytics and reportingTier 3
- Tindra datavarehus
Identity and accessTier 2
No systems
Contract managementTier 4
No systems
2 capabilities with no system, 1 with more than one.
Illustration using invented systems. White spots and duplication are marked with words, not colour alone – a map that has to be explained by someone who already knows it is not a map. Duplication is most common after a merger, where two organisations each arrived with their own system for the same job.
Integrations
The question is not how many, but who owns the truth.
One row per data flow, with the master for the data object, mechanism, frequency, authentication, error handling and monitoring. The matrix answers something a list cannot: who writes to whom.
| From ↓ / to → | Aurora | Nordvik | Havbris | Fjordheim | Tindra | Bjerkely | Saltnes | Vardøger |
|---|---|---|---|---|---|---|---|---|
| Aurora LMS | Aurora LMS writes participant to Tindra datavarehus | |||||||
| Nordvik ERP | Nordvik ERP writes invoice to Havbris betaling | Nordvik ERP writes employee to Saltnes HR | ||||||
| Havbris betaling | Havbris betaling writes invoice to Tindra datavarehus | |||||||
| Fjordheim CRM | Fjordheim CRM writes customer to Tindra datavarehus | |||||||
| Tindra datavarehus | ||||||||
| Bjerkely arkiv | Bjerkely arkiv writes document to Tindra datavarehus | |||||||
| Saltnes HR | Saltnes HR writes employee to Aurora LMS | Saltnes HR writes employee to Fjordheim CRM. Competing master: another system already masters this data object. | ||||||
| Vardøger portal |
One marked cell: two systems master “employee”. When they disagree, there is no source to check.
Illustration using invented systems. Two systems mastering the same data object is not an integration fault – it is a decision nobody made, and it only becomes visible once the flows are set against each other.
Findings and risk
A finding that separates fact from opinion holds up when quoted.
A rule engine runs across the register and flags the conditions that recur: missing owners, unknown hosting locations, an empty legal basis, weak authentication, expiring contracts and competing masters.
CriticalSystem without an ownerTindra datavarehus
- Observation
- Tindra datavarehus has no registered system owner, and its verification date is more than a year old.
- Assessment
- Nobody can confirm whether the details hold, and nobody receives notice about the running contract.
- Recommendation
- Assign an owner before the next attestation round. The source should move from spreadsheet to interview.
CriticalCompeting masterSaltnes HR
- Observation
- Saltnes HR and another system both write the “employee” data object to receiving systems.
- Assessment
- When they disagree there is no source to check. Errors propagate to both receivers.
- Recommendation
- Decide on one master for the data object, and make the other a receiver.
ImportantWeak authentication on an integrationBjerkely arkiv
- Observation
- The integration from Bjerkely arkiv uses a shared key with no expiry.
- Assessment
- The key cannot be tied to a person or a service, and in practice is never rotated.
- Recommendation
- Move to a service identity in Entra ID. Set a rotation interval in the contract.
LowContract expiringVardøger portal
- Observation
- The contract for Vardøger portal expires in less than 18 months.
- Assessment
- The system sits in Eliminate and has low completeness. Renewing would tie up funds in something on its way out.
- Recommendation
- Take the decommissioning decision before the renewal deadline, not after.
Findings export as a markdown note, with the three parts kept apart.
Illustration using invented findings. The three-way split is the point: the observation can be checked against the register, the assessment is an opinion, and the recommendation is someone's decision. Put them in one sentence and the opinion reads as fact.
Diagrams
A diagram that hides its guesses gets quoted as if it knew.
Nine predefined views are generated straight from the register data, as Mermaid and Structurizr DSL. No drawing to keep up to date alongside the register.
34 % of the connections in this diagram rest on assumptions rather than a confirmed source. The share appears on every generated view.
Illustration using invented systems. The caveat appears on every generated view, not only this one: a generated diagram looks equally certain whether its connections were confirmed or assumed, which is exactly why the share has to be on it.
Ownership and attestation
A register decays unless someone confirms it.
Users come from Entra ID via Microsoft Graph – no separate user administration to maintain. The same person cannot hold both owner roles on a critical system.
Confirmed by owner50 %
- Aurora LMSIngrid HovdenConfirmed
- Nordvik ERPKjell AasenConfirmed
- Havbris betalingMarit LøvoldConfirmed
- Fjordheim CRMTor EkebergCorrection reported
- Saltnes HROve FrantzenWaiting
- Bjerkely arkivSilje BrennaWaiting
Confirming sets the last-verified date. Reminders go to the owner, not to a shared mailbox.
Illustration using invented systems and owners. “Correction reported” is there because it is the point: a campaign whose only outcome is “confirm” measures that people clicked, not that the details hold.
Getting started
Four steps, and the last one repeats.
You start from what you already have. No step assumes the previous one is finished for every system.
Import the spreadsheet
Upload the sheet you use today and review a preview before anything is saved. Columns you do not have stay empty and are counted as missing, not guessed.
Assign owners
Users come from Entra ID, so there is no separate user administration to maintain. An owner page shows each owner what is missing on their own systems.
Classify
A tier is proposed from the capabilities a system supports, and the health scores place it in the TIME matrix. You override where you disagree, and the reason is kept.
Attest annually
A campaign asks each owner to confirm or report a correction on their own rows. Confirming sets the last-verified date, so next year you know what was actually checked.
Request a demo
See the register with your own systems in it.
A 30–45 minute walkthrough. We show the register, the tier ladder and the TIME matrix, and go through what the spreadsheet you have today would look like imported.
- No preparation needed. You do not have to tidy anything up first.
- We answer what can be configured and what cannot.
- If you want to try it yourselves afterwards, we arrange a pilot on your own data.