### 7.1.3 Architecture Overview The Architecture Overview provides a **high-level view** of the information system’s software architecture to be developed, including the major **building blocks** of the architecture and a description of how the architecture contributes to all capabilities of the system. The Architecture Overview formally **documents the critical architectural decisions** made and how **compliance concerns** (e.g. security, data protection, anti-fraud) are addressed by the information system. When an **IT Reference Architecture** is in place, the Architecture Overview documents how the information system uses the Reference Architecture guidelines to ensure consistency and efficiency throughout the IT landscape. The Architecture Overview also addresses **reusability concerns** by providing a checklist of commonly used components/services within the Organisation. A key aspect of the Architecture Overview is to ==enable communication between the project stakeholders to understand the information system’s structure and validate the implications of the chosen architectural approach==. This artefact is also crucial when there are **dependencies** between information systems since it conveys, from a high-level perspective, what building blocks constitute the information system and what type of interfaces may exist to support interoperability. The Architecture Overview is extremely important when developing solutions based on new approaches or technologies. In systems where there is already a well-defined architecture, this artefact can be lighter and refer to the existing architecture. | Key Participants | Description | |:------------------------ |:----------- | | Team Coordinator (TeCo) | Supports the Architecture Owner (ArOw) by facilitating the process of obtaining any needed information from the project level. | | Agile Team Member (ATeM) | Supports and actively contributes to the definition of the Architecture Overview. | | Architecture Owner (ArOw) | Responsible for creating the Architecture Overview and ensuring compliance with the organisation’s standards regarding the IT Architecture (Reference Architecture). | | Product Owner (PrOw) | Is informed of the Architecture Overview to have an overall understanding of the key architectural decisions and constraints. | | Project Manager (PM) | Accountable for the Architecture Overview’s output, the Project Manager (PM) needs to understand the essential architectural decisions and constraints and ensure that the project stakeholders are aware of them. | **Guidelines** - **Understand the Problem to be solved** – Before defining a solution and the corresponding Architecture, it is paramount to clearly understand what problem is to be solved and which needs are to be fulfilled. The Business Case and Project Charter provide this information. - **Use both internal and external standards** – In the IT landscape, dozens of ==internationally recognised architecture standards and architectural patterns== can be used to help making decisions and define software architecture. Additionally, the organisation itself may also have its own standards for which the Agile Project Core Team (A-PCT) and in particular the Architecture Owner (ArOw) should be fully familiarised. - **Refer to the existing components’ catalogue** – If there is a components’ catalogue that an Architecture Office maintains, evaluate usage while ensuring that the trade-off in cost, risk and functionality is understood and accepted by the project stakeholders. - **Make use of different models** – Because there are many diverse perspectives for Architecture, PM2-Agile suggests using several different UML models (Class and Package diagrams, Object diagrams, Component diagrams, etc). - **Take into account compliance concerns** – Every organisation has standards and policies that can affect the way the solution architecture is conceived. Therefore, compliance concerns need to be addressed in information system’s architecture, especially in regards to security, document management and data protection. - **Strive for a solid Architecture** - Have an architecture that can be (the following list is not exhaustive): - Consistent — All parts of the architecture are in harmony, and there are common approaches to partitioning and allocation. - Loosely coupled — Architectural components are independent and loosely coupled. - Generic — Architectural components function in various environments and contexts. - Extensible — The architecture can be extended. - Simple — A good architecture should be ‘as simple as possible but no simpler.’ - **High level with just enough detail** - Ensure that the Architecture Overview, in an initial stage, is detailed enough to provide the overall technical approach at a high level. - **Keep updating the Architecture Overview** - As the project evolves and there is a better understanding of the solution, ==refine the Architecture Overview== to provide adequate support to the information system’s development. As the development of the information system ‘tests’ the architecture, ensure that any decisions or changes are included in the Architecture Overview. - **Supported by the Operational Model** - Ensure the ==alignment between the Architecture Overview and the Operational Model== so that the ‘operational’ aspect of the IT system’s architecture is up to date and hosting requirements are identified and managed. - **Source of enablement work** – Because the Architecture Overview includes a picture of the architecture supporting the solution, It ==serves as an invaluable source of Enablers that will populate the Work Items List (WIL)==. ![[7.1.3 Architecture Overview — Inputs and main roles.png]]