Building a High Level Design from an existing environment is different from designing a new platform from a blank page. The first challenge is to establish what actually exists today, then separate current-state evidence from the target architecture that should follow.
This is common when documentation is incomplete, suppliers have changed or a cloud environment has grown incrementally. Reverse engineering provides the evidence needed to create a credible HLD.
Begin with an evidence plan
Decide which sources can describe the environment. Cloud inventories, configuration exports, network devices, firewalls, monitoring, backup tools, application documentation and stakeholder interviews can all contribute.
No single source should be assumed to be complete. The strongest picture comes from comparing several sources and recording inconsistencies.
Build the resource inventory
Start by identifying the major components: accounts or tenancies, regions, networks, compute, databases, storage, load balancers, gateways, identity objects and security services.
The inventory gives structure to discovery, but it is not the HLD. Its purpose is to support understanding of the architecture.
Map network topology
Network evidence often reveals how the environment is really connected.
Document address ranges, subnets, route tables, gateways, peering, private connectivity, firewalls and public endpoints. Then identify important traffic flows between application tiers, databases, users, on-premises systems and third parties.
The diagram should show relationships rather than every individual rule.
Understand identity and access
Review users, groups, policies, roles, workload identities and federation.
It is important to distinguish the existence of a policy from the effective access received by a user or workload. Missing user-to-group mapping, for example, should be recorded as an evidence gap rather than guessed.
DNC’s Corporate Architecture and Technology Services include reverse engineering, current-state discovery and HLD or LLD development.
Trace application dependencies
Infrastructure inventory does not explain the business service on its own.
Identify application tiers, databases, interfaces, batch processes, shared file systems, identity dependencies and external services. These relationships help explain why individual infrastructure components exist.
Include operational controls
Backup, monitoring, logging, patching, security tooling and automation should form part of the current-state view.
An HLD should explain how the platform is operated and protected, not only how workloads are connected.
Document ownership
Where several internal teams, MSPs and vendors are involved, identify who manages each major area.
Ownership gaps are architecture risks because they affect incident response, change control and recovery.
Do not hide uncertain ownership. Record it as an issue requiring resolution.
Separate fact, assumption and recommendation
Reverse-engineered documentation becomes unreliable when inferred information is presented as verified fact.
Use clear labels for confirmed evidence, assumptions and items that still need validation. Recommendations should also be kept separate from the current-state description.
This makes the document easier to review and challenge.
Create the current-state architecture first
Before proposing the target, produce a clear representation of the existing environment.
That current-state section can include diagrams, component descriptions, dependency views, security boundaries, resilience and known risks.
Stakeholders should be able to confirm whether it reflects the service they operate today.
Use gaps to shape the target HLD
Once the current state is understood, the design can address weaknesses such as unclear segmentation, excessive access, insufficient resilience, manual deployment or unsupported components.
The target HLD should explain the architectural changes and the requirements they address rather than simply showing a cleaner diagram.
Keep implementation detail in the LLD
The HLD should describe major components, relationships and design decisions. Exact IP addresses, rule sets, resource names and configuration values normally belong in the LLD or associated schedules.
This keeps the HLD readable while preserving enough detail for architecture review.
Validate with the people who operate the service
Technical evidence should be reviewed with engineers, application owners and suppliers who understand operational behaviour.
They can identify missing dependencies, explain unusual configuration and confirm which historical components are genuinely obsolete.
What good looks like
A strong reverse-engineered HLD clearly separates current state from target state, identifies evidence gaps and explains the relationships that matter to the business service.
Another competent architect should be able to understand the environment, challenge the design and trace recommendations back to observed risks or requirements.
Conclusion
Reverse engineering turns an undocumented environment into an evidence-based architecture baseline.
That baseline makes HLD development more accurate and gives migration, security and modernisation decisions a defensible foundation.
If you need help documenting an existing cloud or enterprise environment, see DNC’s Corporate Architecture and Technology Services or contact DNC.