[XXX] High Level Design

Solution

[Category]

Version 1, Draft A

[Publication Date]

Contents

1	Contents	2

2	Document Review and Approval	3

3	Notices	4

4	Architecture Overview	5

4.1	Purpose of the Document	5

4.2	Project Objectives (ref Business Case)	5

5	Known Dependencies with other projects	5

6	Architectural Change	6

6.1	Current State	6

6.1.1	Application View	6

6.1.2	Technology View	6

6.2	Target State	6

6.2.1	Application View	6

6.2.2	Technology View	7

7	Alignment with architecure	8

7.1	Alignment with principles	8

7.2	Technical debt added or removed	8

8	Architecture Governance	9

8.1	Waivers	9

8.2	Further design Tasks	9

8.3	Significant Architecture Decisions	9

8.4	Design decisions to be validated	9

8.5	Assumptions	9

9	Appendices	10

9.1	Appendix 1 - Socialization comments	10

Notices

All printed copies are to be treated as uncontrolled.

[All guidance text in blue must be deleted prior to submission to the ARB.]

[Where relevant, sections not required should be deleted prior to submission to the ARB.]

[Unless it is explicitly intended, only version 1.0 or higher should be submitted to the ARB for approval. Draft document will not be accepted.]

Version History

Version	Status/Changes	Date	Author

Referenced Documents

Ref.	Document Title	Version	Date	Link
[1]
[2]
[3]

Document Review and Approval

[All required review and approval must be obtained prior to submission to the ARB. This is not required if a draft review is explicitly requested by the author.]

Action	Role	Name	Conditions of Approval	Date
Publish	Authoring Architect
Review	Peer Architect Reviewer
Acceptance	MCA Managing Architect	[if HLD was published by a third party]
Approval	MCA Enterprise Architect
Approval	MCA Security Architect
Approval	MCA Data Architect
Approval	MCA Head of Solution Architecture

Architecture Overview

Purpose of the Document

The purpose of this document is to outline the high-level design (HLD). The HLD provides an initial view around the solution and aims to communicate the intent of the change.

Project Objectives (ref Business Case)

[This should derive from the Executive Summary of the approved Business Case or Brief and should provide the reader with the Business context.]

Known Dependencies with other projects

[Required. Call out all interdependencies with current, or planned, projects that this change may be reliant on, or may be altering the same elements at the same time as this change is planned. If none, replace with – There are no dependencies on other projects for this design to the realised.]

Project	Impacted Element(s)	Nature of Dependency	Prerequisite (Y/N)

[or]

There are no dependencies on other projects for this design to the realised.

Architectural Change

[This should call out the current and future states of the architecture. Detail of the viewpoints required can be found here in the ArchiMate 3.2 specification.]

Current State

Application View

[An Application Structure ArchiMate view, stored in the BizzDesign repository, must be supplied for all new applications proposed by this design.]

[An Application Cooperation ArchiMate view, stored in the BizzDesign repository, must be supplied for all new applications proposed by this design.]

[Addition views, in alternative notations if required, may be supplied to provide additional context for all new applications proposed by this design.]

Impacted Applications

[Provide a discription and nature of impact on existing applications. Recommend the use of BizzDesign publishing of all decriptions and relevant attributes. Extended as required.]

Technology View

[An Technology ArchiMate view, stored in the BizzDesign repository, must be supplied for all new applications proposed by this design.]

[An Technology usage ArchiMate view, stored in the BizzDesign repository, must be supplied for all proposed designs.]

[Additional views, in alternative notations if required, may be supplied to provide additional context for all new applications proposed by this design.]

Impacted Technology

[Provide a discription and nature of impact on existing technology. Recommend the use of BizzDesign publishing of all decriptions and relevant attributes. Extended as required.]

Target State

Application View

[An Application Structure ArchiMate view, stored in the BizzDesign repository, must be supplied for all new applications proposed by this design.]

[An Application Cooperation ArchiMate view, stored in the BizzDesign repository, must be supplied for all new applications proposed by this design.]

[Addition views, in alternative notations if required, may be supplied to provide additional context for all new applications proposed by this design.]

Proposed Aplications

[Provide a discription and nature of impact of new applications proposed by this design. Recommend the use of BizzDesign publishing of all decriptions and relevant attributes. Extended as required.]

Technology View

[An Technology Usage ArchiMate view, stored in the BizzDesign repository, must be supplied for all new applications proposed by this design.]

[An Technology ArchiMate view, stored in the BizzDesign repository, must be supplied for all proposed designs.]

[Additional views, in alternative notations if required, may be supplied to provide additional context for all new applications proposed by this design.]

Proposed Technology

[Provide a description and nature of impact of new technology. Recommend the use of BizzDesign publishing of all decriptions and relevant attributes. Extended as required.]

Alignment with architecure

Alignment with principles

[Required. Call out all the alignment with the architecture principles: showing alignment = ‘Y’, not applicable = ‘N/A’, not aligned = ‘N’ or not known= ‘?’. Note it is not acceptable to have non-alignment with principles]

[Latest version of the principles can be found on MCA’s Strategy, Design & Architecture site]

Principle Area	1	2	3	4	5	6	7	8	9	10
Sourcing
Application
Information
Technical
Radio & Comms
Security
End User Compute

Comments on not application, not aligned or not known

Area	Principle	Comment

Technical debt added or removed

[Technical Debt is defined as deficiencies in the system, technical documentation, development environments, 3rd-party tools and development practices, which makes the systems hard or expensive for the team to change at a later point in time]

Debt	Added/Removed	Comments

Architecture Governance

Waivers

[Provide descriptions of any exceptions required due to non-compliance with architecture principles, standards, or the inclusion of other technical debt as a result of this design.]

Wavier	Description	Date	Acceptance	Current Status
1
2

Further design tasks

Task	Description	Authority (Who)
1	Low Level Design

Significant Architecture Decisions

[If applicable, Provide a view of a decision log, outlining the key decision points, the rationale around the decision and the outcome. Ensure that the date and agreed by fields are completed.]

Design decisions to be validated

[Required. Call out all any design decisions that need validated as part of the low-level design]

Design Decision that need validation	Actions to validate

Assumptions

Assumption	Comments

Appendices

Appendix 1 - Socialization comments

Area	Person	Date	Comment	Response