#🎯practice Solution architecture is a discipline focused on systematizing [[software development]] to meet stakeholders' explicit and implicit expectations in a measurable and sustainable way. As such, it emerged during the era dominated by the Waterfall methodology, when development was often preceded by years of preparation, including workgroup meetings, system analyses, documentation, and planning. Today, despite the shift to an Agile mindset, the influence of the Waterfall methodology continues to cast a shadow on architectural practices. This often leads to prolonged preparation phases with no visible outcomes until the final solution is completed, at which point the responsible architect may no longer be available for consultation. However, when combined with Agile principles, the discipline of architecture allows to retein the essential benefits from preparation steps while dynamically responding to incoming changes. While it may be tempting for those involved in software development to jump directly into decision-making and implementation, doing so can incur significant risks and lead to waste for the business. Adhering to the practices and principles of solution architecture is a way to mitigate most foreseeable pitfalls. --- ## Main concepts Some common concepts defined by the Software Engineering Institute (SEI): ### Business Drivers Business drivers are the factors that motivate or influence the development of a software system. These drivers may include market demands, competitive pressures, regulatory requirements, technological advancements, cost considerations, and strategic objectives. Solution architects must have a clear understanding of the business drivers behind the project and effectively address them through architecture design. By aligning the architecture with these drivers, architects can ensure that the resulting solution provides tangible value to the organization and answers the essential question of **WHY** the software system should exist. ### Stakeholders Any individual or group who has an interest in the business, product or system is considered a stakeholder. Besides the apparent candidates, such as owners, investors, management and domain experts, the list of stakeholders also includes users, developers, regulatory bodies, etc. Essentially anyone who might positively or negatively affect the business should be considered as a source of expectations, requirements, priorities and concerns. By involving stakeholders throughout the architecture process, architects can ensure that the resulting solution meets the expectations and requirements of all the parties involved. ### Requirements Architects are among the key participants in the [[product specification]] process, often taking lead on some of the aspects, and responsibility for some of the artefacts. Understanding and elaborating [[product specification#Functional Requirements|functional requirements]] (**WHAT** the system should do) is a critical activity in solution architecture. Workshops are often conducted to gather and refine the requirements, clarify ambiguities, resolve conflicts, and prioritize features. Another key activity is understanding **HOW** the system should behave via extracting [[product specification#Non-Functional Requirements|non-functional requirements]] from the functional requirements, non-obvious conditions, and limitations. They are the cornerstone for correct decision-making from the early stages. Essentially, it's the main focus of a Solution Architect. ### Quality Attributes To ensure that system is actually usable and able to deliver functional requirements in a real world, the Architect needs to define and consider various non-functional requirements such as performance, scalability, [[reliability]], [[security]], [[maintainability]], and others. Formulated as measurable and observable metrics wrapped in a goal - they are defined as Quality Attributes. They allow your system to get evaluated at any stage of the development cycle to ensure that development is following the design, while the design continues to address the goals. ### Architectural Patterns, Styles and Tactics The set of proven architectural approaches to guide the design of software systems. Examples include layered architecture, client-server architecture, [[microservice architecture]], [[modular architecture]], or event-driven architecture. These patterns provide reusable solutions to common design problems and help maintain consistency and coherence in the architecture. Often driven by non-functional requirements, they provides a cookbook of the recipes to achieve a particular goal. Balancing the requirements and concerns, while applying the correct tactics is probably the second most important skill of a Solution Architect. ### Documentation The modern architecture guidelines emphasise keeping the documentation minimalistic, but sufficient to track software system specifications and design decisions. Moving out from the comprehensive, detailed diagrams with deep technical notations and endless texts, it remains essential to keep the description and the rationale for decisions, what requirements they were addressing, and what alternatives were considered. It's hard to overestimate the value such documentation brings for the next generations of dev teams, newly onboarded teammates, and reviewing architects. --- These were some fundamental concept, while [SEI](https://www.sei.cmu.edu/), [IEEE Computer Society](https://www.computer.org/), [the Open Group](https://www.opengroup.org/), and other associations provide many more tools and practices. They offer different toolsets in the form of decision-making and analysis frameworks, workshops, templates and recommendations that allow to develop and maintain complex systems in a managed way. --- <font style="color: #F86759">Contributors:</font> *[[Eugene]]*, [[Jaros]] <font style="color: #F86759">Last edited:</font> *2024-08-11*