The role of the architect is widely accepted in the world of technology, but not clearly defined. This blog post provides a summary of the views we expressed in our book[i] as well as in an article published in IEEE Software[ii].
In general, the term architect exemplifies individuals who make key decisions about the structure and behavior of a system – be that software or other technology areas. Though software architect is the most commonly used term, there are network architects, storage architects, information and security architects. You could even say that any technology subject area has people that identify themselves as architects.
All these types of architects appear to share the following characteristics:
- Architects have deep knowledge in the domain of interest.
- They mostly do not directly implement (some architects can create executable prototypes during architecture sprints or runways), instead dealing with higher levels of abstraction by defining the structure of a system in the domain of interest.
- They have explicitly or implicitly the authority of making decisions in the domain of interest
In his book Mythical Man-Month[iii] Frederick Brooks talks about the conceptual integrity of a software product. This is a good place to start for defining the role of the architect – basically they are accountable for the ‘conceptual integrity’ of the entity that is being architected.
Architects deal with a higher level of abstraction than implementers, developers or engineers, do. Their concerns include the main components of the system and how they interface and they continuously validate the architecture against different scenarios. They need the ability to traverse different levels of abstraction between concepts, models and implementation details.
The role of the architect in agile development is hotly debated in the industry. Some Agile practitioners believe that there is no need for an overall architecture, since the architecture “emerges” through the implementation of stories and refactoring. We believe that such a view applies only to simple and fairly self-contained projects. If you are architecting a product or try to operate at a large scale you do need to think of the architecture – however, this does not mean that you need a separate architect, but the role of the architect is still crucial to success.
We recommend three focus areas for defining the role: Unit of Work, Product Focus and the Realized Architecture.
Unit of Work
An interesting way of considering architect role is to focus on their key activities. In other words, what is the key unit of work of an architect? Is it a fancy diagram, a logical model, a running prototype? We believe that the basic unit of work for an architect is an architectural decision. As a result, the most important output of any architectural activity is the set of decisions made along the software development journey. Surprisingly, little effort is spent in most organizations on arriving at and documenting architectural decisions in a consistent and understandable manner.
We can state that, the key responsibility of an architect is to drive architectural decisions to a conclusion.
We purposely used the term drive to a conclusion rather than make. The term drive to a conclusion implies that the architect engages with stakeholders and works through the options to arrive at a decision. It does not mean that an architect can abdicate responsibility for making sure that architectural decisions are made. An architect must make sure that decisions are made in a timely manner.
As explained in our book, we believe that architects should focus on architecting products, not just solutions for stand-alone projects. It follows that the architect should operate as part of a team – in this case a product team. This implies that communication and collaboration skills become highly relevant.
Within the context of a single product, the architect plays a key role in the product team. Her/his main responsibility is to balance the demand from the client as represented by the product manager, with the delivery focus provided by the product delivery manager. The architect has to make sure that the architecture of the product is coherent and sustainable. Especially in the initial phases of a product life cycle, there is often a “negotiation” between product management and the “art of the possible”. Managing this conversation is a key responsibility of the architect.
The real architecture of a system is represented by the code that is running on the physical infrastructure. We will call this the “realized architecture.”We believe that the days of an architecture only represented as a set of documents are over.
The role of the architect is to understand, influence, improve and communicate the Realized Architecture.
Therefore, it is important for an architect to understand the code running on the physical architecture.
We can summarize our views by defining the role of the architect as:
An architect is responsible for enabling the implementation of a software product by driving architectural decisions in a manner that protects the conceptual integrity of the software product.
[i] M. Erder and P. Pureur, Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World, Morgan Kaufman, 2015
[ii] M. Erder and P. Pureur, What’s the Architects Role in an Agile, Cloud-Centric World, IEEE Software Vol 33, No 5, pp. 30-33
[iii] Brooks, Frederic, 1975 & 1995, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, ISBN 0-201-00650-2 (1975 ed.), 0-201-83595-9 (1995 ed.)