Architecture context, source systems and data freshness

One application, several sources

A migration team finds an application marked as retired in the portfolio, active in the CMDB and still covered by a supplier contract. Each record answers a different question. Before removing the application from an impact analysis, the team needs to determine whether it still runs and who uses it.

A system of record is authoritative for a defined set of facts. The contract register may establish the signed expiry date; the operational inventory may establish the deployed component. Both systems may also contain useful relationships. The architecture model connects the facts needed for the decision while keeping their sources identifiable.

The context needed for a change

For a payments migration, the useful context includes the applications, the capabilities they support, the interfaces, the affected data and the requirements that constrain the solution. A link from a service to an application says something different from a link between two applications. Preserve the relationship type and direction.

The ADD uses that context to describe the current situation, compare options and record decisions. Source systems continue to own their operational or contractual records. A copied value in the architecture model needs a source and a rule for reconciliation when the original changes.

In ArchiLU, an assistant can retrieve architecture context through MCP and create or complete an ADD. The architect checks the scope and supporting facts before presenting the options. The review must also look for dependencies missing from the answer and the diagram.

Acquisition and reconciliation

Choose the source for each fact before importing data. For example, the application team can verify business usage, procurement can confirm the contract and operations can confirm a deployed component. An import that combines these sources still needs a rule for identifying the same application across them.

Stable source identifiers help match records. Names alone can hide duplicates or merge two different systems. Keep disputed values visible until the responsible person resolves them; record the reason when one source takes precedence.

• Identify the source, collection date and owner for each imported dataset.
• Match records with stable identifiers and review ambiguous matches.
• Check relationship types and directions before accepting the links.
• Send conflicts and missing references to the person responsible for the fact.
• Apply accepted corrections through the permitted change process.

Freshness at the level of the fact

A record modified yesterday can still contain an interface that nobody has checked for a year. A recent import date proves when the copy was made. Verification needs a source, a date and a person or procedure that checked the relevant fact.

Review frequency should follow the expected rate of change and the use of the information. A deployment inventory and a business capability description may need different schedules. Before a migration decision, recheck the dependencies that could change the outcome, even if their ordinary review date has not arrived.

An assistant can use freshness information if it is supplied in the retrieved context. When it is missing, the answer should identify the uncertainty and the check required. An absent relationship cannot establish that the application has no dependency.

A bounded readiness review

Select five applications involved in a planned change. For each one, compare the recorded owner, lifecycle state and dependencies with the relevant operational source and the application team. Keep the sample tied to the work being prepared.

Ask the assistant for the affected applications and a draft impact section. Check every cited object and investigate missing links. For this pilot, record factual errors, unresolved dependencies and the time needed to correct the draft.

If the evidence is incomplete, narrow the conclusion. The ADD can state the verified scope and leave a named interface pending confirmation. The decision-maker can then see which part of the proposal depends on that answer.

Responsibilities after the pilot

The application owner verifies usage and dependencies with operations. The architecture team maintains the shared names and relationship rules. Procurement updates contract facts. The project lead makes sure unresolved points are answered before the relevant decision.

Connect the review to events that already happen: a release, supplier renewal, application retirement or completed migration. A correction discovered while preparing an ADD should update the underlying model through the authorized process. Otherwise the next project will start with the same error.

Check the access granted to each source and the processing location of any assistant used in the workflow. The permissions on the original source and on a copied architecture record must both be considered when sharing the resulting context.