IT Projects & Technical Due Diligence
Architecture reconstruction distinguishes intended design from the system that was actually built and operated. The examination uses architecture descriptions, ADRs, repositories, deployment definitions, interfaces and operational evidence to reconstruct decisions, their stated rationale, alternatives and resulting technical dependencies.
Short answer
An architecture diagram is evidence of intended or documented structure, not automatically the productive system. The actual architecture is reconstructed from code, runtime topology, deployment configuration, interfaces and observable dependencies.
Technical risk is not the same as deviation from an architectural preference. A risk should identify a technical condition, the quality objective it affects, plausible impact and the evidence supporting that relationship.
1. Separate architecture intent from actual system state
Documentation and runtime topology can differ
Architecture descriptions can define components, interfaces and intended relationships. Repositories, deployment manifests, infrastructure definitions and runtime inventories show how the system was actually realised.
Version context matters. A current diagram may represent a later target architecture rather than the state at the disputed project milestone. The reconstruction should therefore date or version each relevant source.
Where documentation and implementation diverge, the divergence is first a technical finding. Whether it is a defect depends on the applicable requirements and assessment criteria.
2. Reconstruct decisions, rationale and alternatives
A decision record is more useful when its context is visible
Architecture Decision Records, meeting minutes, design documents, tickets and pull requests can reveal why an option was chosen, which alternatives were considered and what constraints applied.
Not every project records decisions formally. In that case, the reconstruction can infer decision points from technical changes, but such inference should be labelled and distinguished from documented rationale.
Later explanations should not be projected backwards as if they were contemporaneous. The report identifies whether reasoning is contemporaneous evidence or retrospective interpretation.
3. Relate quality goals to architecture characteristics
Architecture should be assessed against explicit technical objectives
Performance, availability, security, maintainability, portability and scalability can each be affected by architectural choices. The examination states which quality attribute is relevant before describing a choice as risky.
ISO/IEC/IEEE 42010 provides concepts for architecture descriptions and viewpoints. It can help structure the examination without turning the project into a claim of formal standard conformity.
Metrics, load tests, failure tests or code-level evidence can strengthen the relation between an architecture characteristic and the observed quality outcome.
4. Examine dependencies and interfaces as risk drivers
Dependencies can amplify technical consequences
Shared databases, synchronous chains, single identity providers, third-party APIs, proprietary libraries or tightly coupled deployment processes can create concentration and propagation risks.
The examination distinguishes existence of a dependency from risk created by that dependency. Redundancy, caching, circuit breakers, fallback paths or operational procedures can materially change the impact.
External dependencies should be described with the evidence available. Lack of access to a provider's internal design limits conclusions about that provider while still allowing the client-side dependency to be documented.
5. Do not confuse technical risk with mere architectural deviation
A different design is not automatically a bad design
Projects can validly deviate from reference architectures or earlier plans. The technical question is whether the implemented decision creates a material, supported risk relative to the project's requirements and operating context.
Risk statements should identify likelihood conditions or triggering scenarios carefully. A theoretical failure mode becomes stronger when historical incidents, monitoring evidence, stress tests or configuration comparisons support it.
Where testing in production would be unsafe, staging evidence, incident data or controlled simulation can be used, with the transferability of those observations explicitly limited.
6. Keep architecture reconstruction reviewable
Each conclusion should trace back to a system state and source
An architecture reconstruction can include component maps, interface inventories, dependency matrices, decision records and a risk register linked to evidence. Each element should state its applicable version or time period.
Contradictions between diagrams, code and runtime observations are preserved rather than harmonised without evidence. This can reveal undocumented migration states or abandoned design assumptions.
The technical report should separate observed architecture, reconstructed decision rationale, risk interpretation and any unverified assumptions.
Is the architecture-risk finding supported by the implemented system and explicit quality goals?
- Are architecture documents dated or versioned relative to the system state?
- Is the actual implementation checked through code, deployment or runtime evidence?
- Are decision rationale and alternatives distinguished from later explanations?
- Is each risk tied to a stated quality objective or technical requirement?
- Are dependencies and interfaces mapped with their mitigations and failure paths?
- Are deviations distinguished from material technical risks?
- Are tests or operational evidence used where they can strengthen the risk claim?
- Are contradictions and unavailable components retained as limitations?
Constructed example
A project document describes an asynchronous service boundary, while deployment and code inspection show that two critical services make synchronous calls through a shared database. Monitoring data show that outages of the database have affected both services simultaneously.
The technical finding is not simply that the implementation differs from the diagram. It identifies the actual dependency, the relevant availability objective and the evidence showing a shared failure mode. Whether the deviation was contractually prohibited remains separate.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- International standard ISO/IEC/IEEE 42010:2022, used for concepts and requirements relating to architecture descriptions. Open source.
- Technical security framework OWASP SAMM, including practices relating to secure architecture and architecture assessment. Open source.
- Author methodology Sources and Methodology of the German knowledge base. Open source.
Further reading
- Defining the Subject of Examination for Technical Due Diligence
- Reconstructing Project Documentation and Decision History
- Reconstructing Change Requests and Change States
- Reconstructing Test, QA and Release Evidence
Critical review and methodological limitation
Architecture assessment is context-dependent. A pattern that is appropriate for one scale, reliability target or operating model can be unsuitable for another.
Technical risk should therefore be derived from the actual system, requirements and evidence rather than from stylistic preference or a generic reference architecture.
- Intent vs state: documented architecture and implemented architecture must be checked separately.
- Decision vs hindsight: contemporaneous rationale is different from later explanation.
- Deviation vs risk: a different architecture only becomes a material finding when its technical consequences are supported.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
IT Project Assessments & Project Reconstruction
Traceable reconstruction of requirements, change states, repositories, releases, technical decisions and project risks.
Explore this assessment service