Urban Systems Platform: services, data and dependencies

Answer for management practice

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 measure is disconnected from an activity”, and the decision boundary concerns goals and public programmes.

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 measures and sources.

Official sources for a public-sector environment

Federal Law No. 149-FZ provides the general legal context for information and information systems. Applicable requirements are mapped to goals and public programmes, a specific process stage and an accountable owner; other specialised rules are determined from the actual project scope.

The requirements register distinguishes a legal rule, an organisational decision and technical implementation. Each entry identifies the official source, current version, interpretation owner, affected data and evidence of fulfilment; the control signal here is “a measure is disconnected from an activity”.

Subject model and boundaries

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

Test the link between goals and public programmes and activities and projects using an end-to-end example. The team performs “record interfaces and owners”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Control record 1. Object: Goals and public programmes. Observable signal: Execution cannot be verified against a source. Accountability: semantic owner and quality owner.
• Boundary 2. Object: Activities and projects. Define the source, frequency, permitted transformations and response to “one object is duplicated across registers”.
• Object 3: Measures and sources. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: A measure is disconnected from an activity.

End-to-end scenario data

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is activities and projects.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “a measure is disconnected from an activity”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Record 5. Object: Scenarios, directives and control. Required details: identifier, lineage, quality rule and update event. Signal: A project is not linked to a programme goal.
• Subject area 4: Registers and sector systems. Verification basis: system of record, owner authority and the signal “a situation centre only visualises data”.
• Object 3: Measures and sources. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: A measure is disconnected from an activity.

Services and critical dependencies

For activities and projects, the sequence begins with “describe business services”. 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 activities and projects. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• 1. Action: describe business services; verifiable result: scenarios, directives and control.
• Decision 2: map applications and data. The basis for the next step is goals and public programmes.
• Step 3. Record interfaces and owners. Output: activities and projects.
• Identify critical dependencies is the action at stage 4. The output documents measures and sources.

Management question

The article addresses “Urban Systems Platform: services, data and dependencies”. The adjacent management issue is services, data and dependencies. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “a project is not linked to a programme goal”, the material risk is “requirements without a current official regulatory source”, and the testable action is “record interfaces and owners”. This chain turns a broad term into a concrete decision.

• Decision 1: object — goals and public programmes; signal — one object is duplicated across registers; action — describe business services.
• Decision 2: object — activities and projects; signal — a measure is disconnected from an activity; action — map applications and data.
• Decision 3: object — measures and sources; signal — a situation centre only visualises data; action — record interfaces and owners.

Where the problem becomes visible

Diagnosis examines a concrete episode involving goals and public programmes. Its record states the time, participants, data used, decision made and consequence; recurrence is checked against a second sample.

Review the signal “a project is not linked to a programme goal” with the process owner. If its cause lies outside the selected boundary, record the dependency separately and do not expand scope without a new decision on timing, resources and acceptance.

• Diagnostic signal 1: One object is duplicated across registers. Its record contains an example and impact on scenarios, directives and control.
• Management signal 2: A measure is disconnected from an activity. Use condition: a link to an actual example and to goals and public programmes.
• Diagnosis records “a situation centre only visualises data”, its recurrence and its impact on activities and projects.

Decision-rights matrix

Build the authority matrix around decisions concerning measures and sources. Assign the right to change a rule, duty to prepare data, authority to approve an exception and accountability for confirming the outcome separately.

Define the escalation path for “describe business services” concerning measures and sources in advance. The business owner is accountable for decision meaning, the data owner for evidence fitness, the architect for dependency integrity and the project manager for the agreed work sequence.

• Business owner: authority is linked to scenarios, directives and control, and participation is tied to “describe business services”.
• In the decision matrix, architect connects goals and public programmes with the action “map applications and data”.
• Data owner: decision area — activities and projects; control action — record interfaces and owners.
• Project manager is accountable for measures and sources and confirms the action “identify critical dependencies”.

Evidence that the solution works

Verification of measures and sources starts with the baseline. The sample, period, calculation rule, known exceptions and interpretation owner are preserved. After the change, the same scenario is repeated under comparable conditions; a new method or data population is documented as a separate version.

A functioning feature is not yet acceptance evidence. A user must receive the signal “a measure is disconnected from an activity” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for goals and public programmes.

• 1. Acceptance object: goals and public programmes; compare the baseline sample, expected change and confirmed actuals. Test signal: A measure is disconnected from an activity.
• Evidence item 2 describes activities and projects, comparable test conditions and the person accountable for interpretation. Signal: A situation centre only visualises data.
• Test 3 concerns measures and sources. The method, interpretation owner and outcome source are documented. Signal: A project is not linked to a programme goal.
• Control record 4: Registers and sector systems; data version, calculation rule, expected change and actual outcome. Signal: Execution cannot be verified against a source.

Controlling critical dependencies

For the risk “requirements without a current official regulatory source”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

Verify the regulatory basis against an official source and current version. Map it to activities and projects in a requirement–process–data–control matrix and assign an owner for interpretation.

• Controlled constraint: claiming access to public-sector data. The owner performs “design target transitions” and provides activities and projects.
• For the risk “one platform without an authority model”, assign the action “describe business services” and evidence “measures and sources” in advance.
• Risk review starts with the condition “requirements without a current official regulatory source”. The decision uses the action “map applications and data” and data about registers and sector systems.
• Risk record 4. Condition: Centralisation without sector data owners. Control action: Record interfaces and owners. Evidence source: Scenarios, directives and control.

Materials for starting work

The first session examines one real case involving goals and public programmes. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “a measure is disconnected from an activity”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “describe business services”; assign an additional test or stop condition to the risk “a measure without a management action”.

• 1. Action: describe business services; verifiable result: scenarios, directives and control.
• Decision 2: map applications and data. The basis for the next step is goals and public programmes.
• Control record 4: Registers and sector systems; data version, calculation rule, expected change and actual outcome. Signal: Execution cannot be verified against a source.
• Criterion 5 uses scenarios, directives and control; the result is compared with the baseline using one method. Signal: One object is duplicated across registers.