Regional IT Architecture: services, data and dependencies

The decision in two paragraphs

Architecture should show which decision each component supports, which data it exchanges, who owns the interface and what happens when it changes or fails. An application diagram alone is insufficient. For this task, the initial evidence is “a situation centre only visualises data”, and the decision boundary concerns activities and projects.

The practical focus is connecting goals, programmes, measures, registers, projects and directives with verifiable execution. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is registers and sector systems.

Applied analysis: Regional IT Architecture: services, data and dependencies

The practical framing of “Regional IT Architecture: services, data and dependencies” connects process, data and authority. Activities and projects defines the boundary, while “execution cannot be verified against a source” identifies the moment when a decision is required.

Diagnostic evidence for “execution cannot be verified against a source” must be reproducible. Another participant should use the same source and agreed rule to reach a comparable conclusion.

Acceptance uses evidence for registers and sector systems. Method, period and source of actuals remain comparable with the baseline; exceptions are recorded separately.

• Working object: Activities and projects.
• Diagnostic signal: A situation centre only visualises data.
• Response action: Map applications and data.
• Controlled risk: Centralisation without sector data owners.

What belongs in scope

Describe the boundary through object records rather than system names. For activities and projects, record meaning, identifier, source, quality owner and update event; for measures and sources, also document the relationship rule.

Test the link between activities and projects and measures and sources using an end-to-end example. The team performs “identify critical dependencies”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Subject area 1: Goals and public programmes. Verification basis: system of record, owner authority and the signal “a project is not linked to a programme goal”.
• Record 2. Object: Activities and projects. Required details: identifier, lineage, quality rule and update event. Signal: Execution cannot be verified against a source.
• Control record 3. Object: Measures and sources. Observable signal: One object is duplicated across registers. Accountability: semantic owner and quality owner.

Record lineage

Describe data exchange as a contract between owners. For measures and sources, specify the triggering event, system of record, mandatory fields, pre-transfer control and the recipient's response to an error.

Choose the transport mechanism after frequency and resilience requirements are known. Check “a situation centre only visualises data” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Object 5: Scenarios, directives and control. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: A situation centre only visualises data.
• Boundary 4. Object: Registers and sector systems. Define the source, frequency, permitted transformations and response to “a measure is disconnected from an activity”.
• Control record 3. Object: Measures and sources. Observable signal: One object is duplicated across registers. Accountability: semantic owner and quality owner.

Services and critical dependencies

For measures and sources, the sequence begins with “map applications and data”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for measures and sources. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• Describe business services is the action at stage 1. The output documents registers and sector systems.
• At position 2, the action is “map applications and data”; its result is scenarios, directives and control.
• Stage 3: record interfaces and owners. The working artefact describes goals and public programmes.
• Stage gate 4 connects the action “identify critical dependencies” with the result “activities and projects”.

The decision point to resolve

State the decision before compiling requirements. It identifies registers and sector systems, the role authorised to choose, the permitted action and the evidence participants will use to accept or reject an option.

Do not combine the signal “a situation centre only visualises data” and the risk “centralisation without sector data owners” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “map applications and data” connects them in a testable scenario.

• Decision 1: object — goals and public programmes; signal — a measure is disconnected from an activity; action — map applications and data.
• Decision 2: object — activities and projects; signal — a situation centre only visualises data; action — record interfaces and owners.
• Decision 3: object — measures and sources; signal — a project is not linked to a programme goal; action — identify critical dependencies.

Starting situation and evidence

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: a situation centre only visualises data. It should be supported by a real example such as a document, data sample, decision record or registered variance.

The first scope is limited to one object and one decision. Changing every process, master-data set and system at once obscures causality. For the signal “execution cannot be verified against a source”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Indicator: One object is duplicated across registers. Analysis needs an actual example and the resulting change in registers and sector systems.
• Diagnostic signal 2: A measure is disconnected from an activity. Its record contains an example and impact on scenarios, directives and control.
• Management signal 3: A situation centre only visualises data. Use condition: a link to an actual example and to goals and public programmes.

Process and data owners

For registers and sector systems, the role model determines more than screen access. In the action “map applications and data”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For registers and sector systems, this separation is especially important because of the risk “claiming access to public-sector data”.

• Business owner is accountable for registers and sector systems and confirms the action “design target transitions”.
• Role: Architect. Decision object: scenarios, directives and control; verified step: describe business services.
• Data owner decides within goals and public programmes; the basis is prepared through “map applications and data”.
• For activities and projects, the assigned role is Project manager; its control duty is to record interfaces and owners.

Baseline and actual outcome

The acceptance criterion for registers and sector systems includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “execution cannot be verified against a source”, passes through an authorised decision and “identify critical dependencies”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Criterion 1 uses goals and public programmes; the result is compared with the baseline using one method. Signal: One object is duplicated across registers.
• Criterion 2: Activities and projects; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: A measure is disconnected from an activity.
• Criterion 3. Object: Measures and sources. Test fields: baseline, target change, source and owner. Signal: A situation centre only visualises data.
• 4. Acceptance object: registers and sector systems; compare the baseline sample, expected change and confirmed actuals. Test signal: A project is not linked to a programme goal.

Assumptions, stop signals and rollback

The risk map starts with two conditions: “centralisation without sector data owners” and “claiming access to public-sector data”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

A regulated environment maintains a register of applicable requirements: official source, version, interpretation owner, affected process and confirmation method. The risk “claiming access to public-sector data” is reviewed whenever affected data, integrations, roles or control scenarios change.

• The risk scenario “claiming access to public-sector data” is addressed through “identify critical dependencies” and confirmed using goals and public programmes.
• Controlled constraint: one platform without an authority model. The owner performs “design target transitions” and provides activities and projects.
• For the risk “requirements without a current official regulatory source”, assign the action “describe business services” and evidence “measures and sources” in advance.
• Risk review starts with the condition “centralisation without sector data owners”. The decision uses the action “map applications and data” and data about registers and sector systems.

Initial working cycle

The first working session on activities and projects uses real material: a transaction example, report or plan, systems diagram, role list and the variance “a situation centre only visualises data”. Participants select one scenario, identify data gaps and perform the action “map applications and data”.

The output is a decision pack: problem statement, object map, baseline sample, owners, dependencies, verification criteria and open questions. The risk “centralisation without sector data owners” helps determine the next format: a pilot, architecture discovery, competitive selection or process correction without a new system.

• Describe business services is the action at stage 1. The output documents registers and sector systems.
• At position 2, the action is “map applications and data”; its result is scenarios, directives and control.
• 4. Acceptance object: registers and sector systems; compare the baseline sample, expected change and confirmed actuals. Test signal: A project is not linked to a programme goal.
• Evidence item 5 describes scenarios, directives and control, comparable test conditions and the person accountable for interpretation. Signal: Execution cannot be verified against a source.