The enterprise IT zoo: causes, dependencies and a path to architecture

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 “migration has no rollback scenario”, and the decision boundary concerns infrastructure and security controls.

The practical focus is service resilience, transparent dependencies and a governed platform lifecycle. 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 business services and criticality.

What CNews actually published

The CNews article about the enterprise IT zoo was written by Denis Legezo; Maxim Kantarovich appears as a quoted expert. The distinction between article author and quoted expert is important for accurate attribution and is preserved in the source list.

Map a fragmented landscape from business services to applications, data, interfaces and owners. Only then do duplication, critical dependencies and the order of architecture changes become visible.

Subject model and boundaries

The subject model starts with two reference objects: infrastructure and security controls and versions, migrations and operations. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “describe business services”.

The primary boundary is infrastructure and security controls. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Control record 1. Object: Business services and criticality. Observable signal: Migration has no rollback scenario. Accountability: semantic owner and quality owner.
• Boundary 2. Object: Applications and components. Define the source, frequency, permitted transformations and response to “dependencies are known only to individual specialists”.
• Object 3: Integrations and data flows. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: A component cannot be replaced in isolation.

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 versions, migrations and operations.

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 “migration has no rollback scenario”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Record 5. Object: Versions, migrations and operations. Required details: identifier, lineage, quality rule and update event. Signal: Integrations have no owners.
• Subject area 4: Infrastructure and security controls. Verification basis: system of record, owner authority and the signal “there is no criticality classification”.
• Object 3: Integrations and data flows. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: A component cannot be replaced in isolation.

Services and critical dependencies

For versions, migrations and operations, the sequence begins with “identify critical dependencies”. 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 versions, migrations and operations. 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 “versions, migrations and operations”.
• 2. Action: map applications and data; verifiable result: business services and criticality.
• Decision 3: record interfaces and owners. The basis for the next step is applications and components.
• Step 4. Identify critical dependencies. Output: integrations and data flows.

Management question

State the decision before compiling requirements. It identifies business services and criticality, 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 “migration has no rollback scenario” and the risk “selecting a platform without a dependency map” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “identify critical dependencies” connects them in a testable scenario.

• Decision 1: object — business services and criticality; signal — integrations have no owners; action — identify critical dependencies.
• Decision 2: object — applications and components; signal — migration has no rollback scenario; action — design target transitions.
• Decision 3: object — integrations and data flows; signal — dependencies are known only to individual specialists; action — describe business services.

Where the problem becomes visible

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: migration has no rollback scenario. 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 “a component cannot be replaced in isolation”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Event to test: dependencies are known only to individual specialists. Evidence shows timing, frequency and consequence for versions, migrations and operations.
• Indicator: A component cannot be replaced in isolation. Analysis needs an actual example and the resulting change in business services and criticality.
• Diagnostic signal 3: There is no criticality classification. Its record contains an example and impact on applications and components.

Decision-rights matrix

For business services and criticality, the role model determines more than screen access. In the action “identify critical dependencies”, 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 business services and criticality, this separation is especially important because of the risk “a shared component becoming a new failure point”.

• For versions, migrations and operations, the assigned role is Business owner; its control duty is to describe business services.
• Architect: authority is linked to business services and criticality, and participation is tied to “map applications and data”.
• In the decision matrix, data owner connects applications and components with the action “record interfaces and owners”.
• Project manager: decision area — integrations and data flows; control action — identify critical dependencies.

Evidence that the solution works

Verification of business services and criticality 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 “migration has no rollback scenario” from the agreed source, understand its lineage, make an authorised decision, execute the action through the working environment and observe confirmed actuals for infrastructure and security controls.

• Evidence item 1 describes business services and criticality, comparable test conditions and the person accountable for interpretation. Signal: A component cannot be replaced in isolation.
• Test 2 concerns applications and components. The method, interpretation owner and outcome source are documented. Signal: There is no criticality classification.
• Control record 3: Integrations and data flows; data version, calculation rule, expected change and actual outcome. Signal: Integrations have no owners.
• Criterion 4 uses infrastructure and security controls; the result is compared with the baseline using one method. Signal: Migration has no rollback scenario.

Controlling critical dependencies

The risk map starts with two conditions: “selecting a platform without a dependency map” and “a shared component becoming a new failure point”. 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 “a shared component becoming a new failure point” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• Risk condition 1: Selecting a platform without a dependency map. Response: Design target transitions. Testable evidence: Applications and components.
• The risk scenario “claiming compatibility without testing” is addressed through “describe business services” and confirmed using integrations and data flows.
• Controlled constraint: a shared component becoming a new failure point. The owner performs “map applications and data” and provides infrastructure and security controls.
• For the risk “transition without operational criteria”, assign the action “record interfaces and owners” and evidence “versions, migrations and operations” in advance.

Materials for starting work

The first working session on infrastructure and security controls uses real material: a transaction example, report or plan, systems diagram, role list and the variance “migration has no rollback scenario”. Participants select one scenario, identify data gaps and perform the action “identify critical dependencies”.

The output is a decision pack: problem statement, object map, baseline sample, owners, dependencies, verification criteria and open questions. The risk “selecting a platform without a dependency map” 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 “versions, migrations and operations”.
• 2. Action: map applications and data; verifiable result: business services and criticality.
• Criterion 4 uses infrastructure and security controls; the result is compared with the baseline using one method. Signal: Migration has no rollback scenario.
• Criterion 5: Versions, migrations and operations; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Dependencies are known only to individual specialists.