Old approaches like XP did not scale well for software architecture, mostly ignoring quality attributes. The effect is teams get focused on features and constantly defer technical debt and technical features, such as quality attributes.
What is Continuous Architecture? It is an architecture approach that follows six simple principles:
- Principle 1: Architect products; evolve from projects to products. Architecting products is more efficient than just designing point solutions to projects and focuses the team on its customers.
- Principle 2: Focus on quality attributes, not on functional requirements. Quality attribute requirements drive the architecture.
- Principle 3: Delay design decisions until they are absolutely necessary. Design architectures based on facts, not on guesses. There is no point in designing and implementing capabilities that may never be used- it is a waste of time and resources.
- Principle 4: Architect for change--leverage the "power of small." Big, monolithic, tightly coupled components are hard to change. Instead, leverage small, loosely coupled software elements.
- Principle 5: Architect for build, test, deploy, and operate. Most architecture methodologies focus exclusively on software building activities, but we believe that architects should be concerned about testing, deployment, and operation, too, in order to support continuous delivery.
- Principle 6: Model the organization of your teams after the design of the system you are working on. The way teams are organized drives the architecture and design of the systems they are working on.
The six principles are described in detail in Continuous Architecture! as well as listed in the front matter of this book. Those principles are complemented by a number of well-known architecture tools, such as utility trees and decision logs. These tools are also described in detail in Continuous Architecture. Here, in this book, we expand our practical advice by introducing a set of essential activities for architec-ture, which are detailed in the next chapter. The six principles, essential activities, and the tools assist the people conducting architectural activities in defining the key components of software architecture, such as:
- Context of the system.
- Key functional requirements that will impact the architecture.
- Quality attributes that drive the architecture.
- Architecture and design decisions.
- Architecture blueprints.From a Continuous Architecture perspective, we define the following essential activities for architecture:
- _Focus on quality attributes_, which represent the key cross-cutting requirements that a good architecture should address. Quality attributes- performance, scalability, and security, among others--are important because they drive the most significant architectural decisions that can make or break a software sys-tem. In subsequent chapters, we discuss in detail architectural tactics that help us address quality attributes.
- _Drive architectural decisions_, which are the primary unit of work of architectural activities. Continuous Architecture recommends explicitly focusing on architectural decisions because if we do not understand and capture architectural decisions, we lose the knowledge of tradeoffs made in a particular con-text. Without this knowledge, the team is inhibited from being able to support the lone-term evolution of the software product. As we refer to our case study, we highlight key architectural decisions the team has made.
- _Know your technical debt_, the understanding and management of which is key for a sustainable architecture. Lack of awareness of technical debt will eventually result in a software product that cannot respond to new feature demands in a cost-effective manner. Instead, most of the team's effort will be spent on working around the technical debt challenges--that is, paying back the debt.
- _Implement feedback loops_, which enable us to iterate through the software development life cycle and understand the impact of architectural decisions.
Feedback loops are required so that the team can react quickly to developments in requirements and any unforeseen impact of architectural decisions.
In today's rapid development cycles, we need to be able to course-correct as quickly as possible. Automation is a key aspect of effective feedback loops.| Type | Name | ID | Brief Description | Options | Rationale |
|---|---|---|---|---|---|
| Foundational | Native Mobile Apps | FDN-1 | The user interace on mobile deveices will be implemented as native iOS and Android applications. | Option 1, Develop native applications. Option 2, Implement a responsive design via a browser. | Better end-user experience. Better platform integration. However, there is duplicated effort for the two platforms and possible inconsistency across platforms. |
Functional requirements describe business capabilities that the system must provide as well as its rbehavior at runtime.
Quality attributes describe what the system must meet in delivering functional requirements.
Can refer to product quality model in ISO/IEC 25010 with 8 characteristics:
- Functional suitability
- Performance efficiency
- Compatibility
- Usability
- Reliability
- Security
- Maintainability
- Portability
Spend effort on those that are "architecturally significant".
- Stimulus: Describes what a user or external stimulus of the system would do to initiative the architecture scenario.
- Response: Describes how the system should be expected to respond to the stimulus.
- Measurement: Quantifies the response to the stimulus.
Should be clear (easy to understand and remember), provide guidance for decisions, and be atomic (requires no additional context or knowledge).
Personal note: This could be connected to the principle of sensing what a principle's "negative" position would be, i.e. is there a valid, possible opinion expressed in the principle's inverted variant?
This chapter discussed the essential activities of architecture and their practical implications in today's world of agile and cloud- -where we are expected to deliver solutions in increasingly shorter timeframes and at increasingly larger scale. We started by defining the following essential activities that highlight why architecture is important:
- Quality attributes, which represent the key cross-cutting requirements that a good architecture should address.
- Architectural decisions, which are the unit of work of architecture.
- Technical debt, the understanding and management of which is key for a sustainable architecture.
- Feedback loops, which enable us to evolve the architecture in an agile manner.
We emphasized that the objective of the essential activities of architecture is to influence the code running in the production environment. We spoke about the importance of architecture artifacts such as models, perspectives, and views. We explained that these are incredibly valuable tools that can be leveraged to describe and communicate the architecture. However, our view is that if you do not utilize the essential activities we emphasize, they are insufficient on their own.Key skills for conducting architectural practices:
- Ability to design
- Leadership
- Stakeholder focus
- Ability to conceptualize and address systemwide concerns
- Lifecycle involvement
- Ability to balance concerns