Jiri’s Notepad

This is a fourth post in the series on architects collaboration.

If you follow the world of enterprise architecture (or at least its weblog echo), you may get an impression that architects live in the world of frameworks, modelling, processes and tools. So it may possibly come as a surprise that these first impressions are deceiving as ‘build and deploy’, the bread and butter of all IT organisations takes in fact the most of the architecture effort. Take my last big project as an example: Out of two and half years it took, we spent probably half a year preparing for its initiation (which was prolonged by two rather traumatic events of changing the outsourcing partner and a merger with another company), then half a year developing the scope and architecture, followed by a year and a half of delivering what we promised. Considering delivery takes by far more people and takes longer than other phases, it is important to look at collaboration during this stage in the lifecycle.

Whereas organisation of architecture activities during the early stages of a project can be relatively simple, large number of people normally involved during delivery stages makes the organisation arrangement trickier. The bigger the project, the trickier the it gets.

The basic choices how to organise architects during delivery you have is to

1. Either maintain the architecture team centralised or
2. Federate responsibility for architecture to delivery teams.

Each of these two organisation arrangements has a different level of collaboration potential, but also different level of controllability, both of which need to be considered.

Centralised architecture team

If we put aside a project with no architects (which in most cases is an anti-pattern), this is the standard, traditional, organisational arrangement. Architects act as an advisory function to the programme board, developing high level architecture focused on ensuring alignment with business. When it comes to delivery, they hand over the collection of models, principles, assumptions and design guidelines to the delivery teams. At a macro level, the structure for such a project will look like this:

At a micro level, the architecture team will be kept broadly similar to what I described in the previous post.The downside of the model is that on its own, it is not very helpful for collaboration. Have you ever encounter a project where architecture team develops a perfect set of models, cross-functionally optimised, solution which no-one else understands and which in any way comes too late for delivery? That well could have been a result of a un-collaborative silo-ed centralised organisation. This is exactly the situation which leads to lots of beard stroking and meditation on whether the subject of a gap between architects and developers.

The best things managers in general can do to enable collaboration is to put the right people in the right place and then let things happen. Unfortunately in this model, each team will have their own objectives, their own managers and pursuing different objectives and so the will have to spend extra time and effort overcoming the friction to free inter-personal interactions. This is by far not terminal – many projects organised this way do collaborate successfully – but to me that implies that they had to make an extra effort to over-ride the negative influence of the organisations structure.

Federated architecture team

A naturally better way to achieve collaboration during the delivery phases is to place architects directly into delivery teams. This basically means moving architects in the last post’s diagram from the box in the middle (Architecture) to the right-hand box (Delivery), leading to a delivery team that looks a bit like the follows. (Note: please be aware that I am talking about collaboration and so don’t get too hung up on the organisation spider chart).

Sure this model has its limitations - you still need to put the right people in the right place and you still have an organisation boundary in a direction to the business customer which you need to overcome.But overall, this organisational arrangements make collaboration with delivery teams happen in a more natural way and often makes architects heroes of the pressured world of delivery. Because they are much closer to the action, such projects can shorten the timescales of their iterations (at least those dependent on software) and to connect directly to the customer using some of the agile methods. On a flipside, as with all types of delegated effort, there is less direct control and hence a bigger risk that an average project of this type will go wild. Again, this is not that bad, you just need to look a bit more on governance to offset the risks.

Conclusions

To summarise, you should to be aware of how your organisation arrangements support or do not support development of personal relationships between architects, business and delivery people. Not all organisation models are the same in this respect: centralised architecture model enables collaboration less than a federated architecture model. But each of them has its own benefits and concerns - you just need to be aware of them and offset the potential disadvantages of the model you are using by means outside the org structure.