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.

Request a demo See what the register holds

Runs in your own Azure subscription. Sign-in with Entra ID.

Systems

4 of 214 shown

Aurora 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.

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.

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.

Application register

System	Owner	Tier	Source	Last verified	Completeness
Aurora LMS	Ingrid Hovden	Tier 1	Contract	May 14, 2026	92 %
Nordvik ERP	Kjell Aasen	Tier 2	Interview	Apr 2, 2026	74 %
Havbris betaling	Marit Løvold	Tier 2	Contract	Jun 1, 2026	88 %
Fjordheim CRM	Tor Ekeberg	Tier 3	Entra ID	Mar 19, 2026	81 %
Tindra datavarehus	No owner	Tier 3	Spreadsheet	Feb 27, 2025 · overdue	47 %
Bjerkely arkiv	Silje Brenna	Tier 3	Spreadsheet	Sep 8, 2025 · overdue	55 %
Saltnes HR	Ove Frantzen	Tier 4	Interview	Jan 23, 2026	63 %
Vardøger portal	Hanne Rygg	Tier 5	Spreadsheet	Jun 11, 2025 · overdue	44 %

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 classification

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.

ReasonBjerkely arkiv holds personal data with a statutory retention period. The capability is not critical to run, but lost content cannot be recovered afterwards.

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.

TIME matrix

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.

Capability map

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.

Integration register

The row is the master for the data object, the column is the receiver.
From ↓ / to →	Aurora	Havbris	Fjordheim	Tindra	Saltnes
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.

Findings and risk

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.

Generated architecture diagram

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.

Attestation campaign

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.