Comments on my last blog led me back to an older thought I had about managing and implementing architecture. It is the application of “mission type tactics”, which comes basically from military leadership practice and partially is and was adopted as a management instrument as well.
The basic idea of “mission type tactics” is that a person / organisation in a more global position (e.g. higher up in the command hierarchy or having more authority) is managing the according executing parties in his area of control by giving them a clear and understandable order, that contains a concise description of the expected outcome or goal. Instead of prescribing every step to achieve the desired result the order can be “locally” interpreted and the tools and methods used by the executing group are based on their decision as long as the do not neglect the goal. Not sure if this is a great description or definition, nevertheless I hope you get the point.
Doing this unveils a few interesting aspects in general:
a) the basic assumption that the local group is able to act according the goal
b) the empowerment of the local group to take their own decision
c) the unamendable requirement, that the local group understands the goal
d) the enforced intelligence of a local group to solve local challenges on their own behalf, which requires insight into the global target or goal.
In military history there had been some interesting aspects to address some of this points. One approach included the education and training of people one level above their orignal position or level. This basically means that one tries to enforce the look across the fence upfront. One can translate this into architeture management at least partially.
I would like to start with the tricky part upfront: in military hierarchy is the preveiling structure, that means upper levels command lower levels. This is not quite true for large software systems with respect to architecture. Managing the global picture is a different task than managing a certain component of it – not necessarily a top down thing. In other words in some areas the global architect is responsible in other aspects a local authority is dominating. Enforcing the global requirements and cross cutting concerns is often done via architecture govenernance and central architecture management and design, however many decisions are taken on a local basis and some of these local decisions are feeding back to the global picture.
Management of the global picture has to be addressed by the guys working on the parts and pieces making up the big picture. A pure upfront architecture design will not work and here (at least I believe) one can incorporate the mission type architecture idea with more emphasis.
What are the measures one can take for doing so? An interesting one is the education and knowledge (see above). It would be a good idea if the projects working on one piece or part understand the big picture and accept it as a desirable outcome. I would summarize this as insight into the global challenge. From my view point this also addresses the “not invented here syndrom”, which basically often leads to rewriting of functionality. It is especially this point that I think we should turn too much more. I changed my definition of architecture by saying that it is to 80% communication of simple goals and to the rest ingenious and original design (obviously a bit exaggerated).
But there is no end here. We can centrally command to the projects the execution of architecture as well. Which can be addressed to different types of project management. In the classical project charter one has to incorporate the architecture goals as a deliverable and not a side effect and for agile methods like Scrum architecture belongs to the definition of “done”.
The last point sounds like being very obvious but I have to often seen that the overall picture is not mandated. There is no doubt, that there is always a big picture, but without managing it one gets just an arbitrary one – probably not the best one.