Writing an effective End-to-End High-Level Design - TheOpenArch Architecture (2024)

Writing an effective end-to-end High-Level Design:

In this article we outline best practice on what constitutes a high quality E2E solution design.

The Architecture Design Blueprint or Technical Options Assessment is an effective way to produce a lean and just-in-time architecture that is aligned with the shorter sprint cycles of incremental product delivery. End-to-End HLDs are needed for undertaking complex transformation projects such as introduction of new IT stack, the introduction of a new product line, or a new business.

A draft E2E HLD is produced with the engagement of the stakeholders across Business, Technology, Suppliers, and the Project team through Architecture and Design workshops. The E2E HLD is produced over several design sprints with walkthroughs to the relevant stakeholders. The main components are:

• Application Context “as-is” and “to-be” diagrams are created and used to illustrate the impacted Applications and the logical interfaces.
• Technical Flow diagrams are used to illustrate the Interfaces between applications and information flow.
• Data Flow diagrams are used to illustrate the flow of data between applications.
• Architecture and Design RAIDD is used to manage the Risks, Assumptions, Issues, Decisions, and Dependencies log.
• The Requirements Traceability Matrix is used to demonstrate E2E traceability.
• The key to the successful E2E solution design delivery for a complex transformation project is a comprehensive E2E HLD structure that provides a holistic view of the solution and continuous collaboration with all key stakeholders: business, technology, and all suppliers.

It is important to establish a framework and process for a quality design deliverable.

Comprehensive End-to-End HLD Template

A typical End to End HLD template structure includes:

1. Introduction:

Provides an overview of the project and a brief summary of the solution to set the scene to the stakeholders. Provides a technical view of the project scope and outlines where some of the requirements are to be met by non-technical means such as business processes. Outlines dependency on other projects and the impact of the solution proposed in this HLD on other projects.This section establishes a common high-level understanding of the project scope and the proposed solution for stakeholders at all levels.

1. Project Summary
2. Project Scope (In/Out)
3. Document Context
4. Target Audience
5. RAIDD
6. Glossary/Definitions

2. Architecture

a. Architecture Diagram

Provides the overall Solution Context Diagram (example in the diagram above) that highlights the impacts to Business, Application, Technology layers, clearly marking the modified, newly introducing and decommissioning components.This section visually establish the boundaries of the overall solution and the proposed solution context for stakeholders at all levels.

b. Target Architecture Considerations

Provides background to relevant target solutions, Enterprise Architecture roadmap/guidance, including those partially-relevant and those looked at but not relevant, so that the consideration is captured in case of later questions.Solution is ensured to :

• Deliver towards Enterprise Architecture Strategy and Roadmap
• Align with all Architecture & Design patterns
• Meet best practice guidelines
• Comply with current IT strategy including introduction of new components & obsolescence roadmap
• Follow the Business, Regulation, System, Cloud and Network security guidelines and be compliant with the Security & Non-Functional requirements

c. Architecture Principles & Patterns

Provides the list of applicable Architecture Principles and Patterns, and more importantly identifies the need for any new principles and patterns.This section demonstrates the adherence to the Enterprise Architecture Principles & Patterns and where gaps were found to create new Patterns and Principles.

d. Architecture Dispensations

Outlines the deviations from the target Enterprise Architecture roadmap and best practice. Discusses the longer term plan to move toward the more desirable approach. In particular, outlines the steps to be taken within the project, or separately to “make good” any undesirable aspect of the proposed approach.This section establishes the approach to reducing Technical Debt, cost of the Technical Debt and the approach to bring the alignment to Enterprise Architecture Strategy.

3. Solution Description

Provides a summary of the overall technical solution, applicable Architecture and Design patterns, clearly stating what the project is adding or changing, Application Impact Matrix, impacts to Customer Journey, Customer/User Experience, Use Cases/Technical Flows depicted as UML Sequence diagrams, changes to Business Processes and Business Service.This section establish a common understanding of the technical solution for stakeholders including Business, Technology and Suppliers’ teams.

1. Overall Solution
2. Customer Experience
3. Customer Journey
4. Business Processes
5. Application Impacts

This section details the changes/impacts to each Application or element of the Application. Each sub-section covers the work for a given Application, the Functional/Capability Design, Interface Impacts, Data Entity Impacts, Infrastructure Impacts, Capacity Impacts, Operational and Support Impacts, Business Continuity and Resilience Impacts, Testing Impacts, Security Impacts, Reporting Impacts, End‑to‑end Service Impacts, and non-functional issues such as Capacity, Regulatory, Security and Non-functional Impacts.This section provides a 360° coverage of the solution for each Application and establish the boundaries of delivery for the Application Owners, Application Delivery & Application Support teams.

5. Interfaces

This section lists the impacted Interface Matrix and details each interface changes with a Technical Flow Diagram represented as a UML Sequence Diagram, applicable business rules, message flow, service orchestration, applicable integration patterns, principles and implementation guidelines.This section establishes the Integration and Interface Impacts, and for each Interface, establish the boundaries of delivery.

6. Data Impacts

This section details the changes to key data entities and their relationships, data changes subject to review as part of Data Architecture and Information Governance, Data Master-ship, Data Residency, applicable Data Security principles and patterns, applicable Regulations such as GDPR and Data Policy Impacts.This section establishes the Data Impacts and helps seek the approval of Information Asset Owners, Information Governance and Security Teams.

7. Reporting

This section details the impacts to Management Information/Business Information Reporting, including changes to existing reports, new reports required, data sources for reporting, non-functional reports, applicable information retention policies.This section establishes the reporting impacts and provides the correct level of reporting to the Business & Management.

8. Infrastructure

This section details the end-to-end impacts to On-premise & Cloud Infrastructure including hardware, data centre and cloud connectivity, location, issues of deployment and decommissioning of live and test environments.This section establishes the Infrastructure needs, the solution alignment with Infrastructure Strategy and communicates the solution to the Infrastructure Build & Deployment Teams.

9. Testing & Environments

This section details any Architecture and Design Impacts arising from Testing, in particular for the environments considered for testing and the test software.This section clearly indicates to the Test Teams Environment considerations.

10. Implementation & Deployment (per release)

This section details the implementation and deployment approach, describing the capabilities, release dependencies and ongoing change impacts.This section provides the necessary considerations for the Application Build & Release Teams.

11. Operational Impacts

This section details the Operational impact the Project and the proposed design introduces, the list of non-functional deliverables for Security, Availability Management, Service Levels, Service Capacity, Performance, In-life Support, Backup and Archiving, Business Continuity & Disaster Recovery and Service Failure Impacts and Service Recovery Mechanisms.

This section provides the necessary due diligence to Operations & Service Teams and the Service Owners.

1. Non-functional Deliverables
2. Security
3. Information Governance
4. Availability Management
5. Service Levels
6. Service Design
7. Performance
8. In-life support
9. Backup & DR
10. Failure

12. Decommissioning & Obsolescence

This section details opportunities for decommissioning of applications, hardware or individual element/interface. It also covers the migration of interface/data prior to decommissioning.This section identifies all the opportunities for decommissioning and achieving Organisational benefits in reducing complexity, support costs, licenses, and resources.

13. Legal & Regulatory

This section articulates how the solution meets the applicable regulatory and compliance requirements including Information Governance, GDPR, Health & Safety, Equality, Environment Policy, Accessibility Standards, Sarbanes Oxley, Business Continuity, Security Policy, Public Sector Network compliance, Data Retention and Disclosure.This section provides the necessary due diligence to Legal, Regulatory & Compliancy.

All companies have a different way of delivering change, this is why the support of expert professionals is important.Our Partner Bruhati can help you to define governance frameworks, templates, and tools.For more information and a FREE consultation please visitwww.bruhati.comor write atsales@bruhati.com.