## 4.9 Architecture When implemented, specific software architecture decisions made in every IT project, complement the overall enterprise architecture. Just like with other Agile practices, PM2-Agile applies this same principle to solution architecture, ensuring balance between autonomy and coherence. The Agile Project Core Team (A-PCT) should work in an environment that supports original design decisions and innovation. To achieve long-term efficiency (e.g. by reuse of services and components), interoperability and flexibility, the team should follow the enterprise architecture principles and standards. As defined by an IT Governance Body and supported by an Enterprise Architecture Office, PM2-Agile uses two key artefacts as a standardised way to document the solution architecture and the related deployment aspects. - **Architecture Overview** - Projects that include an information system development aspect should use this artefact. It conveys the governing ideas (compliance) and illustrates the essential nature of the proposed architecture and its major building blocks. - **Operational Model** - Describes the operational aspect of the architecture, focusing on the IT system infrastructure. The Operational Model is highly recommended for information systems that are hosted in a corporate data centre. These two artefacts provide an established way of documenting certain solution architecture decisions. However, they do not ensure a structured and comparable way of documenting that allows an impact or compliance analysis. One of the tasks of an Architecture Office is to improve and harmonise the applied Enterprise Architecture methods and techniques. As the solution becomes clearer and the software architecture and infrastructure requirements evolve, both artefacts should be kept up to date. Depending on the progress of the project and the impact of the changes, the artefacts should be periodically re-submitted to the IT Governance body. Depending on the organisation, the importance of upfront architecture design and documenting decisions, patterns, etc. may vary. If a Reference Architecture already exists, architectural mechanisms, patterns, and styles are expected to be used has they have already been evaluated, chosen and standardised by the organisation. PM2-Agile addresses software design decisions through the practice of Evolutionary Architecture. This practice describes how to incrementally build and improve the software architecture while uncovering and addressing architectural issues found during software development. This reduces technical risks without significant upfront architectural effort. This practice: - improves quality and productivity by reducing the need to make time-consuming, error-prone fixes to late-detected problems that result from architectural flaws. This is possible because the architecture is validated early, allowing key architectural problems to be corrected before most of development work is done; - reduces time to market by focusing on reusing existing components. It improves the consistency and maintainability of the system by incorporating lessons learnt from development back into the architecture. - increases predictability by identifying and implementing the highest-risk technical areas first. It improves the team’s responsiveness to change by shortening the architectural cycle and minimising time wasted in architectural rework when changes arise. The key principles of Evolutionary Architecture are: - Perform architecture work ‘just in time’ for all other work. - Document key architectural decisions and outstanding issues. - Implement and test key capabilities as a way to address architectural issues. It’s a common practice to perform high level architectural modelling in early stages of the project life cycle. This helps the team and other stakeholders agreeing on the technical strategy to follow during the project. It also improves productivity, reduces technical risks and development time, improves communication and team organisation and enables scaling Agile software development. When adopting Evolutionary Architecture, the baseline Architecture Overview and Operational Model will evolve. Changes to these artefacts should be managed and documented within the Project Core Team (PCT), ensuring both artefacts are up-to-date and all the impacted stakeholders are informed of the main changes.