Continuous Architecture
What is Continuous Architecture?
Continuous Architecture is an architecture style that follows six simple principles:
- Architect products, not just solutions for projects. Architecting products is more efficient than just designing point solutions to projects and focuses the team on its customers.
- Focus on Quality Attributes, not on functional requirements. Quality attribute requirements drive the architecture.
- 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.
- Architect for change—leverage “the power of small.” Big, monolithic, tightly coupled components are hard to change. Instead, leverage small, loosely coupled services
- Architect for build, test, and deploy. Most architecture methodologies exclusively focus on software building activities, but we believe that architects should be concerned about testing and deployment activities in order to support Continuous Delivery.
- Model the organization after the design of the system. The way teams are organized drives the architecture and design of the systems they are working on. [1]
Continuous Architecture is a set of principles and tools targeted at bridging the gap between Agile delivery and architecture practices within an organization.
Continuous Architecture is about using the appropriate tools to make the right decisions and support Continuous Delivery, Continuous Integration and Continuous Testing
“Continuous Architecture” is an approach based on a toolbox – not a formal process!
Continuous Architecture Goals
To create an architecture that can evolve with applications, that is testable, that can respond to feedback and in fact is driven by feedback
- To make Enterprise Architecture real
- To make Solution Architecture sustainable
- To create real world, actionable, useful strategies
Continuous Architecture Principles
- Architect Products – not solutions for Projects
- Focus on Quality Attributes – not on Functional Requirements
- Delay Design Decisions until They are Absolutely Necessary
- Architect for Change – Leverage “The Power of Small”
- Architect for Build, Test and Deploy
- Model the Organization of your Teams after the Design of the System You are Working on
See Also