In general, I would say that most people in the IT world would agree that a good architecture is of fundamental importance to any successful technology development. How would the Golden Gate Bridge have looked, if not for the architectural talents of Joseph Strauss? IT-Architecture is a profession, and the people that practice architecture require a specific set of skills and experience, in order to develop good architectures. Recently the concept of Agile Architecture considers architecture from two perspectives, Intentional Architecture and Emergent Design. While I have no argument with an evolutionary approach to architecture, I think it is relevant to question how much of Emergent Design is architecture.
As a starting point I always like to go back to the famous quote by Grady Booch.
“All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”, Grady Booch
What I like about this is statement is it gives us some leading principles for both what an architecture is and what the role of an architect should be.
Firstly, architecture is design. That means we make some kind of plan up front in order to help someone build something tangible. If you are building without a design, then you are just building ad hoc, generally not recommended for any complex problem software or otherwise.
Grady indicates that architecture is about “significant design decisions”, and the real emphasis here is on the word significant. When designing a large system or enterprise there will be a great number of design decisions made, but not all of these are architectural decisions. Many designs and decisions are made without having an effect on the architecture. Drawing the line between architecture decisions and software design decisions is perhaps the cause of friction between some architects and development teams, and it is a delicate balance. Architects we need to avoid micro-managing design but at the same time make the significant architecture decisions, without which a weak architecture is the result.
So where do we draw the line between architecture and other forms of design? Grady defines significant in terms of the “cost of change”, where that cost can come in many different forms. I consider this as not just to be the cost of making the changes to the technology, but the costs to the business. Examples of the cost of change may be, effort from business roles other than developers, testing, cost due to delayed projects or the cost of sub-optimization when an optimal design can no longer be achieved. The significant “cost of change” is the cost to the business, not just the effort from the development team.
So, which significant decisions in a technology development drive costs?
These are often decisions which are difficult to reverse. Changing such a decision may result in weeks or months of work. This is usually because other architectural or software design decisions will be made based on these significant decisions. Thus, changing such significant decisions will change a number of designs and technologies, requiring greater effort and time.
This is perhaps what we would call the Intentional Architecture in agile terms. These architecture decisions are required up-front and usually require a good deal of analysis before moving to execution. The reason being that the cost of change to the business has a significant effect on value delivery.
The following are some examples of decisions which fully or partly fall into this category:
- Style and Patterns – the choice of architectural style (for example service-oriented, tiers, cloud-based), or the choice of architectural patterns (for example MVC, MVVM, domain-driven). These patterns provide a foundation, structure and behavior for functional design, this is difficult to reverse, as it changes the very foundations upon which components are designed.
- Critical or major functional requirements – decisions regarding the functional design of a solution, which have a serious effect if they fail. For example, if failure results in serious financial loss, damage to business reputation, or injury/loss of life.
- Quality Attributes (a form of non-functional requirement) – design decisions regarding quality attributes such as security, performance, scalability, safety etc.., are often critical to a successful technology delivery. Functional designs for the technology are built upon the decisions made to meet Quality Attributes. This makes these decisions hard to reverse, since it will impact much of the functional design.
- Broad scope of change – decisions which have a broad impact on the business. Such a change may be broad in the terms that it affects many systems, business processes or many organizations within the business. A small technology change can drive a major change in the business.
So where does Emergent Design come into architecture? Well, to start with we have to remember that all design is not architecture, the architecture designs are of a significant nature. This is important for the architect and other roles which perform design, for example, lead devs, developers and UX. There needs to be room to take decisions close to the development team in order to facilitate agility. The architecture should provide a guide and a framework which helps the team to meet the architectural requirements, and feel confident about making their own design decisions.
Emergent Design is often design which is much closer to implementation and may well arise from prototyping in the source code. The question we have to ask ourselves here, is if we are happy to let these designs emerge so close to implementation, how significant are these decisions? Perhaps they are not even part of the architecture, but in fact just part of the solution design. Although, it may well be the case that a design pattern emerges during the solution design and may be adopted as part of the architecture.
While I don’t doubt the merits of working with Emergent Design, the value of an architecture lies in the significant and intentional design decisions. These are the design decisions which help keep a product sustainable and actually provide the platform for agility. The risk with focusing on Emergent Design as a process for constructing architecture is if you leave the significant architecture decisions until late in the development process, it might be too late. This may result in a refactoring hell, having to perform major re-designs, or in the worst case, explaining to your sponsor that the product is no longer sustainable from a cost perspective.
Architecturality 