Hello!
Merry Christmas and if someone did not understand the title, is “Forget the architects!“. During recent years, when I worked in large organizations; I always found the “Architecture Team”. This team can be formed by one or more people and they are usually the ones in charge of great architecture decisions for the teams that finally develop products or applications.
This process is usually very bureaucratic, and this means that development teams have to wait X time (let’s say 3 months) before they can start to build software. In addition to all the problems that this waterfall approach includes; the more general scenario is that when the construction of software starts, changes and modifications must have to be implemented by the architecture team, then shared with team development and… back to start.
That’s break with all the principles for practices like SCRUM. A team that practices SCRUM let’s that architecture emerges as the software is built. Although we are accustomed to planning aspects of architecture, must understand that this approach does not leave out the architecture of software but instead it focus on provide value to the software at the same time that the software is built.
This is not an easy task and requires very good skills in a team (Professional, not amateur teams); Personally I still don’t feel comfortable without an initial design. Surely the first steps will be false, and we will have to return back several times before finding the right approach. However, this is the basis of an emergent process (planning incremental or incremental design). We have to accept the reality of not knowing all the variables that affect us as a team at the beginning of the project and one time assumed this reality start to work (and to rework in many cases). Finally, we have to understand that the benefits of the rework are when the product begins to take shape.
Of course that all this work / rework should be without impairing the quality with good practices such as continuous integration, BDD, etc. Here I refer to the great Rodrigo Corral when he wrote about “the quality in the software is not optional” (long time ago but still a great post).
A phrase or principle which is good to take into account if you want to get started with this approach is
Think Big, Act small, Fail fast and Learn Rapidly
This quote is from the book “Lean Software Development” of Mary and Tom Poppendieck and it represents the basic principles with which a team must work in only 4 sentences. If you move it to the day of a developer, you will understand it right away; and if you think about it from the point of view of a “software architect”, you will see that the principle is the same.
Another important point to keep in mind is that all decisions of architectures should be supported by code. The role of experts in Visio is not longer needed, emerging architectures are those that are part of a product, with its set of tests and finally proven product that is built. I’m not saying that it is necessary to forget about diagrams and drawings, but these diagrams represent existing code, which is where actually lives a product .
Note: In this regard, Visual Studio ALM does an excellent job!
Resources:
- My vision about the cone of uncertainty (link)
- The quality of the software is not optional (link)
- The Land that Forgot scrum by Uncle Bob (link)
Greetings @ La Rancherita
The Bruno
..
