Their work is relevant for anyone involved in making change happen in organisations, i.e. you, me, regular people, and those in roles such as line managers, project managers, programme managers, product managers, product owners, system owners, business architects, enterprise architects, business analysts, software architects and so many others.
There has been a strong backlash against architecture and, perhaps more to the point, architects in the software development field for many years. One source of that backlash are parts of the agile community. Some of the reasons for criticism are poor practices by some architects as well as a misunderstanding of the suggestion to avoid big design up-front. Software, solution, systems and enterprise architects seem to be the primary objects of this criticism.
To avoid doubt, some of that criticism is well-deserved. As always, the devil is in the details and context matters. This post is not about the details or about who is more wrong.
By and large, that conflict seems unnecessary to me. Many of the ideas popularized by the agile movement have been accepted by people far beyond the software development field. In particular, many architects (in the fields I mentioned above and beyond) don’t need convincing regarding the value of respect for people, cross-functional collaboration, outcome orientation, and responding to change.
Having begun reading their book “Building Evolutionary Architectures: Support Constant Change”, Neal Ford, Rebecca Parsons, and Patrick Ku explain very well how software architects can meaningfully contribute to modern software development efforts.
They describe their notion of evolutionary architecture as follows:
“An evolutionary architecture supports guided, incremental change across multiple dimensions.”
That is certainly compatible with my understanding of architecture and the architect’s role.
Against his information architecture background, Jorge Arango states:
“A design career is a progression from thin markers to fat markers.”
He also highlights the need for design work at different levels of precision:
“You can’t design exclusively using whiteboard markers any more than you can with only fine markers. You need a combination of both.”
“As a leader, you don’t necessarily stop being a practitioner; you just move on to a fatter marker.”
Architecture is design, so all of this is also applicable to the architecture fields I mentioned above. It is also compatible with the notion of guided, incremental change, as well as the fundamental principles popularized by the agile community.
Jorge provides a meaningful description of what an architect-as-practitioner looks like. To me, this in sharp contrast to naïve interpretations of the “architects must code” idea. It also is a clear rejection of the idea that fat-marker wielding architects could provide comprehensive, detail-level specifications to those wielding fine markers or IDEs.
While I’m not sure I’ve been actually aspiring to these ever fatter markers, they certainly have been coming my way throughout my career. And that’s alright for this practitioner.