Target Enterprise Architecture: services, data and dependencies

The decision in two paragraphs

For “Target Enterprise Architecture: services, data and dependencies”, define the outcome as a change in management practice. The central object is capabilities and processes; it needs an agreed source, decision owner and observable state after the action “describe business services”.

The first evidence is not a solution presentation but a reproducible example of “competing initiatives without shared criteria”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

Applied analysis: Target Enterprise Architecture: services, data and dependencies

For “Target Enterprise Architecture: services, data and dependencies”, separate the required outcome from the implementation method. Define the outcome through data and measures and the owner's decision; assess technical options only after that pair is explicit.

Prepare a real example of the signal “competing initiatives without shared criteria” and locate its point of origin. Then assign the action “describe business services”, its owner and the permitted response time.

The acceptance record connects the baseline sample to data and measures. It states the expected change, actual outcome, interpretation owner and decision for the next cycle.

• Working object: Goals and management decisions.
• Diagnostic signal: Competing initiatives without shared criteria.
• Response action: Describe business services.
• Controlled risk: Disconnecting business goals from data.

What belongs in scope

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

Test the link between goals and management decisions and capabilities and processes 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.

• Subject area 1: Goals and management decisions. Verification basis: system of record, owner authority and the signal “measures without decision owners”.
• Record 2. Object: Capabilities and processes. Required details: identifier, lineage, quality rule and update event. Signal: Investment without a target state.
• Control record 3. Object: Data and measures. Observable signal: Recurring gaps between strategy and projects. Accountability: semantic owner and quality owner.

Record lineage

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 capabilities and processes.

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 “competing initiatives without shared criteria”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Object 5: Initiatives, dependencies and resources. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Inconsistent system maps.
• Boundary 4. Object: Systems and integrations. Define the source, frequency, permitted transformations and response to “competing initiatives without shared criteria”.
• Control record 3. Object: Data and measures. Observable signal: Recurring gaps between strategy and projects. Accountability: semantic owner and quality owner.

Services and critical dependencies

For capabilities and processes, 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 capabilities and processes. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• Stage gate 1 connects the action “describe business services” with the result “systems and integrations”.
• 2. Action: map applications and data; verifiable result: initiatives, dependencies and resources.
• Decision 3: record interfaces and owners. The basis for the next step is goals and management decisions.
• Step 4. Identify critical dependencies. Output: capabilities and processes.

The decision point to resolve

State the decision before compiling requirements. It identifies data and measures, 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 “competing initiatives without shared criteria” and the risk “disconnecting business goals from data” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “describe business services” connects them in a testable scenario.

• Decision 1: object — goals and management decisions; signal — recurring gaps between strategy and projects; action — describe business services.
• Decision 2: object — capabilities and processes; signal — competing initiatives without shared criteria; action — map applications and data.
• Decision 3: object — data and measures; signal — inconsistent system maps; action — record interfaces and owners.

Starting situation and evidence

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

Review the signal “measures without decision owners” 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.

• Event to test: recurring gaps between strategy and projects. Evidence shows timing, frequency and consequence for systems and integrations.
• Indicator: Competing initiatives without shared criteria. Analysis needs an actual example and the resulting change in initiatives, dependencies and resources.
• Diagnostic signal 3: Inconsistent system maps. Its record contains an example and impact on goals and management decisions.

Process and data owners

For data and measures, the role model determines more than screen access. In the action “describe business services”, 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 data and measures, this separation is especially important because of the risk “being unable to verify completion of the transition”.

• For systems and integrations, the assigned role is Business owner; its control duty is to design target transitions.
• Architect: authority is linked to initiatives, dependencies and resources, and participation is tied to “describe business services”.
• In the decision matrix, data owner connects goals and management decisions with the action “map applications and data”.
• Project manager: decision area — capabilities and processes; control action — record interfaces and owners.

Baseline and actual outcome

The acceptance criterion for data and measures 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 “measures without decision owners”, passes through an authorised decision and “record interfaces and owners”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Evidence item 1 describes goals and management decisions, comparable test conditions and the person accountable for interpretation. Signal: Recurring gaps between strategy and projects.
• Test 2 concerns capabilities and processes. The method, interpretation owner and outcome source are documented. Signal: Competing initiatives without shared criteria.
• Control record 3: Data and measures; data version, calculation rule, expected change and actual outcome. Signal: Inconsistent system maps.
• Criterion 4 uses systems and integrations; the result is compared with the baseline using one method. Signal: Measures without decision owners.

Assumptions, stop signals and rollback

For the risk “disconnecting business goals from data”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

An assumption concerning capabilities and processes remains valid only until its review event. If the source, scope or accountable role changes, update the decision boundary and repeat the affected test.

• Risk condition 1: Replacing architecture with a product list. Response: Identify critical dependencies. Testable evidence: Goals and management decisions.
• The risk scenario “planning projects without dependencies” is addressed through “design target transitions” and confirmed using capabilities and processes.
• Controlled constraint: disconnecting business goals from data. The owner performs “describe business services” and provides data and measures.
• For the risk “having no owner for the target model”, assign the action “map applications and data” and evidence “systems and integrations” in advance.

Initial working cycle

The first working session on goals and management decisions uses real material: a transaction example, report or plan, systems diagram, role list and the variance “competing initiatives without shared criteria”. Participants select one scenario, identify data gaps and perform the action “describe business services”.

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

• Stage gate 1 connects the action “describe business services” with the result “systems and integrations”.
• 2. Action: map applications and data; verifiable result: initiatives, dependencies and resources.
• Criterion 4 uses systems and integrations; the result is compared with the baseline using one method. Signal: Measures without decision owners.
• Criterion 5: Initiatives, dependencies and resources; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Investment without a target state.