Agile Architecture
Lean Architecture Principle #7: Architecture Initiated by Business Goals 
Gero Vermaas 21 Jun, 2010
Share 
This is the sixth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The sixth principle we discuss applies to the process of architecting and is called “Iterative Architecture Development”.
The goal of architecture is to support the business by delivering artifacts like applications that are beneficial to the business and support the strategic goals of the business. One of the big pitfalls of architecture is to come up with a big plan, consisting of a beautiful landscape of applications. By the time this whole landscape is implemented; business has moved on, and the landscape is no longer aligned to the needs.
Lean architecture focuses on adding value by creating artifacts that aid the business, and by reducing waste. The iterative architecture development principle focuses on the process of architecture. One of the ways waste is introduced is by making big, elaborate plans, and trying to implement the whole plan at once. During the development and implementation of the plan, the business gains no value at all. From a lean perspective is it best to focus at usable sub results, results that add value for the business.
The principle of iterative architecture development proposes to shift focus to usable sub results by introducing iterations. An iteration is a process phase that, when finished, delivers a finished artifact. This artifact should aid the business. For example an artifact could be an infrastructure element for secure backups to aid the stability of the business. The most effective way to use iterations is to make them fixed time, or time-boxed. This helps in gaining focus.
During an iteration we apply a modified version of the Deming-circle: Plan, Do, Check, Act. As an architect, we continuously learn new things about our architecture: we gain new business knowledge, we need to adapt to changing business needs etc. Therefore we propose a slightly different cycle: Speculate, Collaborate, Learn. At the start of a time-boxed iteration we speculate on what we know and how the artifact should be constructed. During the iteration we collaborate with stake-holders like analysts, developers and infrastructure specialists to come to the best solution. At the end of the iteration we evaluate, learn. We do this by taking into account new situations, feedback from customers and other input from stakeholders.
This brings us to the third element of this principle. Applying iterations to develop architecture implies that components or subparts should be able to change over a number of iterations. The architecture of artifacts delivered by each iteration should be able to deal with changing structure. We learn as we go along, and therefore change to earlier artifacts is inevitable.
While executing these iterations, it is important to keep the big picture in mind. See principle #2: Think Big, Act Small.
So how does this principle map onto the 3 C’s of architecture? A higher cohesion is reached because the architect doesn’t construct a huge monolithic structure of applications and systems, but instead focuses on constructing usable subparts. These subparts (applications or components or any other artifact) focus on adding value for the business. The subparts have a higher internal cohesion, and increase cohesion over time if the iterative nature of this principle is followed. Newly gained knowledge can be used to increase cohesion within the application or subpart.
Connection to the business is improved, as the business has a better picture of what architecture really does for them. The business sees the results earlier, and is thus able to provide valuable feedback earlier. This helps to tighten the Plan-Do-Check-Act cycle.
Changeability is improved, as the architecture delivers smaller “building-blocks”. Also the business gains a higher frequency of moments to offer input to steer development of architecture. The architecture becomes more agile, able to react to changes.
This was the sixth in a series of blog posts on Lean Architecture principles, the next one will follow in about a week.
This is the sixth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The sixth principle we discuss applies to the process of architecting and is called “Iterative Architecture Development”.
The goal of architecture is to support the business by delivering artifacts like applications that are beneficial to the business and support the strategic goals of the business. One of the big pitfalls of architecture is to come up with a big plan, consisting of a beautiful landscape of applications. By the time this whole landscape is implemented; business has moved on, and the landscape is no longer aligned to the needs.
Lean architecture focuses on adding value by creating artifacts that aid the business, and by reducing waste. The iterative architecture development principle focuses on the process of architecture. One of the ways waste is introduced is by making big, elaborate plans, and trying to implement the whole plan at once. During the development and implementation of the plan, the business gains no value at all. From a lean perspective is it best to focus at usable sub results, results that add value for the business.
The principle of iterative architecture development proposes to shift focus to usable sub results by introducing iterations. An iteration is a process phase that, when finished, delivers a finished artifact. This artifact should aid the business. For example an artifact could be an infrastructure element for secure backups to aid the stability of the business. The most effective way to use iterations is to make them fixed time, or time-boxed. This helps in gaining focus.
During an iteration we apply a modified version of the Deming-circle: Plan, Do, Check, Act. As an architect, we continuously learn new things about our architecture: we gain new business knowledge, we need to adapt to changing business needs etc. Therefore we propose a slightly different cycle: Speculate, Collaborate, Learn. At the start of a time-boxed iteration we speculate on what we know and how the artifact should be constructed. During the iteration we collaborate with stake-holders like analysts, developers and infrastructure specialists to come to the best solution. At the end of the iteration we evaluate, learn. We do this by taking into account new situations, feedback from customers and other input from stakeholders.
This brings us to the third element of this principle. Applying iterations to develop architecture implies that components or subparts should be able to change over a number of iterations. The architecture of artifacts delivered by each iteration should be able to deal with changing structure. We learn as we go along, and therefore change to earlier artifacts is inevitable.
While executing these iterations, it is important to keep the big picture in mind. See principle #2: Think Big, Act Small.
So how does this principle map onto the 3 C’s of architecture? A higher cohesion is reached because the architect doesn’t construct a huge monolithic structure of applications en systems, but instead focuses on constructing usable subparts. These subparts (applications or components or any other artifact) focus on adding value for the business. The subparts have a higher internal cohesion, and increase cohesion over time if the iterative nature of this principle is followed. Newly gained knowledge can be used to increase cohesion within the application or subpart.
Connection to the business is improved, as the business has a better picture of what architecture really does for them. The business sees the results earlier, and is thus able to provide valuable feedback earlier. This helps to tighten the Plan-Do-Check-Act cycle.
Changeability is improved, as the architecture delivers smaller “building-blocks”. Also the business gains a higher frequency of moments to offer input to steer development of architecture. The architecture becomes more agile, able to react to changes.
This was the sixth in a series of blog posts on Lean Architecture principles, the next one will follow in about a week.
