A practical method for moving from current to target architecture

What to do in practice

For “A practical method for moving from current to target architecture”, define the outcome as a change in management practice. The central object is goals and management decisions; it needs an agreed source, decision owner and observable state after the action “design target transitions”.

The first evidence is not a solution presentation but a reproducible example of “recurring gaps between strategy and projects”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

Role of the SystemsDesign source

SystemsDesign hosts a page for Maxim Kantarovich's talk on target architecture models. Maxim Kantarovich is identified here as the speaker; the event page is not attributed to him as an authored article.

The practical method documents current constraints, describes target capabilities, maps transitions, identifies dependencies and supports decisions for each change wave.

Objects, identifiers and owners

Describe the boundary through object records rather than system names. For initiatives, dependencies and resources, record meaning, identifier, source, quality owner and update event; for goals and management decisions, also document the relationship rule.

Test the link between initiatives, dependencies and resources and goals and management decisions using an end-to-end example. The team performs “map applications and data”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Boundary 1. Object: Goals and management decisions. Define the source, frequency, permitted transformations and response to “inconsistent system maps”.
• Object 2: Capabilities and processes. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Measures without decision owners.
• Subject area 3: Data and measures. Verification basis: system of record, owner authority and the signal “investment without a target state”.

Sources and integrations

Describe data exchange as a contract between owners. For goals and management decisions, 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 “recurring gaps between strategy and projects” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

• Control record 5. Object: Initiatives, dependencies and resources. Observable signal: Competing initiatives without shared criteria. Accountability: semantic owner and quality owner.
• Record 4. Object: Systems and integrations. Required details: identifier, lineage, quality rule and update event. Signal: Recurring gaps between strategy and projects.
• Subject area 3: Data and measures. Verification basis: system of record, owner authority and the signal “investment without a target state”.

Services and critical dependencies

For goals and management decisions, the sequence begins with “design target transitions”. 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 goals and management decisions. 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: data and measures.
• Decision 2: map applications and data. The basis for the next step is systems and integrations.
• Step 3. Record interfaces and owners. Output: initiatives, dependencies and resources.
• Identify critical dependencies is the action at stage 4. The output documents goals and management decisions.

Decision and supporting evidence

State the decision before compiling requirements. It identifies capabilities and processes, 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 “recurring gaps between strategy and projects” and the risk “planning projects without dependencies” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “design target transitions” connects them in a testable scenario.

• Decision 1: object — goals and management decisions; signal — investment without a target state; action — design target transitions.
• Decision 2: object — capabilities and processes; signal — recurring gaps between strategy and projects; action — describe business services.
• Decision 3: object — data and measures; signal — competing initiatives without shared criteria; action — map applications and data.

Checks before the project

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

Review the signal “inconsistent system maps” 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: Recurring gaps between strategy and projects. Its record contains an example and impact on data and measures.
• Management signal 2: Competing initiatives without shared criteria. Use condition: a link to an actual example and to systems and integrations.
• Diagnosis records “inconsistent system maps”, its recurrence and its impact on initiatives, dependencies and resources.

Roles in the operating environment

Build the authority matrix around decisions concerning capabilities and processes. 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 “design target transitions” concerning capabilities and processes 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 data and measures, and participation is tied to “identify critical dependencies”.
• In the decision matrix, architect connects systems and integrations with the action “design target transitions”.
• Data owner: decision area — initiatives, dependencies and resources; control action — describe business services.
• Project manager is accountable for goals and management decisions and confirms the action “map applications and data”.

How to verify the change

The acceptance criterion for capabilities and processes 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 “inconsistent system maps”, passes through an authorised decision and “map applications and data”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• 1. Acceptance object: goals and management decisions; compare the baseline sample, expected change and confirmed actuals. Test signal: Investment without a target state.
• Evidence item 2 describes capabilities and processes, comparable test conditions and the person accountable for interpretation. Signal: Recurring gaps between strategy and projects.
• Test 3 concerns data and measures. The method, interpretation owner and outcome source are documented. Signal: Competing initiatives without shared criteria.
• Control record 4: Systems and integrations; data version, calculation rule, expected change and actual outcome. Signal: Inconsistent system maps.

Decision risks

The risk map starts with two conditions: “planning projects without dependencies” and “having no owner for the target model”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

Every assumption has an owner, supporting evidence and a review event. The risk “having no owner for the target model” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• Controlled constraint: replacing architecture with a product list. The owner performs “record interfaces and owners” and provides initiatives, dependencies and resources.
• For the risk “planning projects without dependencies”, assign the action “identify critical dependencies” and evidence “goals and management decisions” in advance.
• Risk review starts with the condition “disconnecting business goals from data”. The decision uses the action “design target transitions” and data about capabilities and processes.
• Risk record 4. Condition: Having no owner for the target model. Control action: Describe business services. Evidence source: Data and measures.

Pack for the first decision

The first session examines one real case involving initiatives, dependencies and resources. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “recurring gaps between strategy and projects”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “design target transitions”; assign an additional test or stop condition to the risk “having no owner for the target model”.

• 1. Action: describe business services; verifiable result: data and measures.
• Decision 2: map applications and data. The basis for the next step is systems and integrations.
• Control record 4: Systems and integrations; data version, calculation rule, expected change and actual outcome. Signal: Inconsistent system maps.
• Criterion 5 uses initiatives, dependencies and resources; the result is compared with the baseline using one method. Signal: Measures without decision owners.