Architecture and empowerment
How bad could organizational hierarchies be for the advance of professionalism in the business of software creation? In particular, command and control organizational hierarchies derived from misinterpretations of the concept of ‘governance’.
I suggest that the advance of professionalism should be part of the strategic interests of a business for both, the short and the long term. That is why the inquiry of the opening question is relevant to a software business.
A proper association between authority and responsibility, that is, a proper empowerment, is crucial to a mature professionalism; otherwise professional accountability has little ground on which to build upon. Hence, unbalanced levels of authority and responsibility work against the advance of professionalism; therefore, against the business. That is, if a level of authority has been given to a person to take strategic design decisions then the same person should have the same level of responsibility for the consequences of those very same design decisions. How authoritarian hierarchies help or hindrance a proper empowerment for a given software project? Of course, the original design of those authoritarian hierarchies could not be intended to care for the professionalism in software.
This inquiry is not about the formal discourse on the matter but about the actual happenings on a given software endeavor when unmanaged complexity shows its ugly face. Also, this inquiry is intended, first, to understand what those actual happenings are; and, second, to transform those happenings into other possibilities based on a greater level of professionalism.
One cause for improper empowerment is contextual mismatch. For example, if architectural decisions, or most design decisions, are based on previous experiences in the same business domain —at best— and those decisions are taken by people at a different level of empowerment than those in the actual development team, then there are good chances that those previous experiences relate to an older context, even in the same domain, because of a non-trivial number of changes in the factors of the current context, which by now has become a significantly different context. Most of the people are different, most of the technology is different and, most importantly, most of the problem is different.
“ .. but , the difference is not that much... ”, if there is not enough and solid evidence to support such opinion then it should be regarded as a mere manifestation of wishful thinking. Traits of mature professionalism relate less with wishful thinking than with critical thinking.
How important critical thinking is for emotional and intellectual maturity. Examples of the traits of critical thinking: before taking a position and having a discussion with someone on any given subject, learn about the counter arguments. The purpose of critical thinking is to gain better understanding and to get to the truth of the matter, not about "winning" a debate. If you want to truly understand counter arguments to your position and to be persuasive with people, learn to put yourself in the shoes of the person holding different views. Think of yourself as an actor taking on a role which is different than yours: learn about the person, their values and their background. Do not only focus on attempting to refute their position.
Some references for further thinking:
What Killed Waterfall could Kill Agile. -now, nov. 2017, available at What Killed Waterfall could Kill Agile
What Critical Thinkers Can Learn From Actors
Notes:
1. My post could be discussed in an application architecture community, but it could also be relevant for a discussion within an enterprise architecture community because it could relate to The generalized "Peter Principle".
2. Do not miss an historical perspective from the first referenced hyperlink in my post: What Killed Waterfall could Kill Agile.
3. I am aware of the schools of thought, in the realm of philosophy of art and literature, that regard architecture as something not related to the concrete nuances of engineering; whereas I see great transformational value in those schools of thought, especially from their ability to bring about new narratives with different interpretations of reality, I also see that, in software, those “engineering nuances” are not so different than a well-crafted ontological reasoning. So, in software, there is not a radical dichotomy between ‘architecture’ and ‘engineering’.