-k.

I’ve recently encountered a project where the application architects are very detached from the development team. The Architects sit on high making proclamations for the developers to follow. They draw diagrams, proclaim standards and generally ignore pragmatic needs, instead focusing on white papers, rambling meetings, and modelling tools.

Now there is a place for white papers and modelling tools. My concern is that the architects, while not really being bad people, just aren’t really responsible for delivery. They seem to make arbitrary decisions about the way the system should be partitioned and constructed with little concern for the practical downstream effects. The effect, in my opinion, on the project concerned has been disastrous.

The system seems incredibly complex for the functionality it delivers. Tasks that would normally take a competent developer a few hours take days, sometimes weeks. Subtle side effects leave people scratching their heads looking for answers. What would normally be done in a few lines of code in a couple of methods is done with a dozen classes and as many xml configuration files. Worst of all developer moral is incredibly low and belief in what they are doing is almost non-existent.

My solution is simple; make the architects lead the delivery teams. That way they share their wisdom and reasoning in a collaborative manner. They also become responsible to the project for the decisions at a very practical level. They are the ones responsible for delivery of the component. When it takes weeks to deliver something that would normally be estimated in days because flexibility never used is designed in, they are the ones explaining it to the project.

Good architecture needs to be pragmatic and responsible. I’ve worked with some good architects in the past. These architects focused on the practical outcomes of their decisions as well as the latest white paper.