traceinthesand.com Blog

Complex software is a collective work product, so constructing software systems necessarily has a social dimension, complicated by the fact that the work is innovative and non-routine. And we can’t just dispense with teams: software teams are about two things: getting more expertise so we can build better products and applications, and getting more bandwidth. Yes, these are two things:

• The first is about the complexity of today’s products requiring such depth of expertise in diverse areas that it becomes unlikely that just one person holds all that expertise. 

• The second is about the number of person-hours required to construct the product or application. We can’t wait hundreds of years for software that takes hundreds of person-years to construct!

Architects who recognize that they are more effective when they enable their communities to be more effective, are well on the road to being great. It is not just about the architect making technically solid decisions. It is about enrolling others, and empowering them, to contribute their best. It is about inspiring and motivating, it is about generating goodwill, and it is about enabling co-ordination so that all the pieces will be the best they can be, and the system, composed of the pieces will be the best it can be. (And of course, by “best” I mean best fit to the need taking into account constraints and tradeoffs that have to be made.)

Yes, the great architect is technically great. If it were just about the people side, then we could have stopped at technical project managers and we would not have seen software architects emerge in all kinds of organizations and industries over the past decade or so. There is a strong technical dimension to the role. You can’t just slice-and-dice a system any old way and parcel the pieces out to teams and individuals to build and then recompose the pieces into systems that deliver the services with the intended characteristics or qualities! Even if you start with a common vision, but only have a rough cut at divvying up the system, then you either have endless unproductive bickering about what the pieces mean and who must do what, or you have people going off and making their best guesses at what they were meant to do and maybe, eventually, through immense hard work and mass self-sacrifice, get to something that works. But this path is littered with failures!

So, it takes experience and talent to create a great architecture—architecture that clearly identifies the structures and mechanisms that must be built to deliver the differentiating value propositions and foundational services of the system.  And it takes other skills to help the communities involved make their best contribution to the success of the system.

The architect who understands that he must get the great architecture that is in his head into the heads of the team, is the architect who begins to get the full scale of the challenge! And no matter how great we think the architecture in our heads is, it will be greater if we include others in the process of creating it. We will understand better what the architecture needs to be, to meet the needs of all who have a stake in it. This includes those who will create it, and those who have a perspective on the value this system could, and should, offer.