IT trends and business models: separating signals from durable change

The decision in two paragraphs

A roadmap becomes actionable when it links the target state, initiatives, dependencies, resources, stage gates and decision owners. A dated project list without those links remains a statement of intent. For this task, the initial evidence is “competing initiatives without shared criteria”, and the decision boundary concerns goals and management decisions.

The practical focus is the connection between strategy, decisions, the change portfolio and target architecture. 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 data and measures.

IT trends: author and scope

The Systems.Education article on IT trends in digitalisation is by Alexander Chernov. This guide preserves accurate attribution and addresses a different question: how to distinguish a technology signal from a durable change in the business model and management loop.

A trend becomes material when it changes decision economics, role authority, data availability or feedback speed. Technology novelty without such a change remains a market observation rather than a basis for an investment project.

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 “build the dependency map”, 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.

Dependencies and stage decisions

For capabilities and processes, the sequence begins with “describe the target state”. 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.

• Decision 1: describe the target state. The basis for the next step is systems and integrations.
• Step 2. Group initiatives by capability. Output: initiatives, dependencies and resources.
• Build the dependency map is the action at stage 3. The output documents goals and management decisions.
• At position 4, the action is “align resources and change windows”; its result is capabilities and processes.

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.

• Diagnosis records “recurring gaps between strategy and projects”, its recurrence and its impact on systems and integrations.
• Observation 2: Competing initiatives without shared criteria. Required fields: frequency, source and consequence for initiatives, dependencies and resources.
• Signal: Inconsistent system maps. Evidence includes an example, frequency and consequence for goals and management decisions.

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 the target state” connects them in a testable scenario.

• Decision 1: object — goals and management decisions; signal — recurring gaps between strategy and projects; action — describe the target state.
• Decision 2: object — capabilities and processes; signal — competing initiatives without shared criteria; action — group initiatives by capability.
• Decision 3: object — data and measures; signal — inconsistent system maps; action — build the dependency map.

Process and data owners

For data and measures, the role model determines more than screen access. In the action “describe the target state”, 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”.

• In the decision matrix, business owner connects systems and integrations with the action “assign stage-gate decisions”.
• Architect: decision area — initiatives, dependencies and resources; control action — describe the target state.
• Data owner is accountable for goals and management decisions and confirms the action “group initiatives by capability”.
• Role: Project manager. Decision object: capabilities and processes; verified step: build the dependency map.

Record lineage

Describe data exchange as a contract between owners. For capabilities and processes, 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 “competing initiatives without shared criteria” on both sides of the interface to distinguish a source error from transformation, delivery or loading failure.

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

Baseline and actual outcome

Verification of data and measures 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 “competing initiatives without shared criteria” 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 management decisions.

• Criterion 1. Object: Goals and management decisions. Test fields: baseline, target change, source and owner. Signal: Recurring gaps between strategy and projects.
• 2. Acceptance object: capabilities and processes; compare the baseline sample, expected change and confirmed actuals. Test signal: Competing initiatives without shared criteria.
• Evidence item 3 describes data and measures, comparable test conditions and the person accountable for interpretation. Signal: Inconsistent system maps.
• Test 4 concerns systems and integrations. The method, interpretation owner and outcome source are documented. 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 review starts with the condition “replacing architecture with a product list”. The decision uses the action “align resources and change windows” and data about goals and management decisions.
• Risk record 2. Condition: Planning projects without dependencies. Control action: Assign stage-gate decisions. Evidence source: Capabilities and processes.
• Risk: Disconnecting business goals from data. Control: describe the target state. Evidence: data and measures.
• Risk condition 4: Having no owner for the target model. Response: Group initiatives by capability. Testable evidence: Systems and integrations.

Initial working cycle

The first session examines one real case involving goals and management decisions. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “competing initiatives without shared criteria”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “describe the target state”; assign an additional test or stop condition to the risk “being unable to verify completion of the transition”.

• Decision 1: describe the target state. The basis for the next step is systems and integrations.
• Step 2. Group initiatives by capability. Output: initiatives, dependencies and resources.
• Test 4 concerns systems and integrations. The method, interpretation owner and outcome source are documented. Signal: Measures without decision owners.
• Control record 5: Initiatives, dependencies and resources; data version, calculation rule, expected change and actual outcome. Signal: Investment without a target state.