Good Architecture, Good Leadership

supported a retail distribution operation. It was a middleware application that created a cache of record information to provide greater responsiveness to client programs that needed to quickly acknowledge receipt and produce label information for cases and pallets as they rolled of the trucks. The complexity of the original design resulted in developers who didn’t want to "fix" it, never-ending trouble ticket calls, and literally the loss of good people from the team. Let’s examine how a software architect can apply each of the five practices to this scenario.

Model the Way: For the architect, this is about using modeling to model the way. That play on words is meant to highlight two perspectives of modeling. The engineer’s understanding of modeling is to capture the essence of a problem through various viewpoints. That act supports Kouzes and Posner’s concept of modeling in the sense that you should live according to the vision you want others to follow.

Think about it. When modeling in the architectural sense, you are establishing standards, guidelines and constraints that should be followed by all the developers. In other words, if you decide to do a last minute "hack" that runs against the grain of your standards, don't be surprised if you have opened the door for others to do the same.

Further, by adopting patterns and explaining them, you are communicating an expectation. At the same time, the developer is growing professionally through the exposure of best practices. Indeed, in Just Enough Architecture [2], George Fairbanks notes that the constraints "are a means of transferring wisdom." By sharing knowledge, you are encouraging others on the team to do the same.

In my personal example, a critical success element was openness to each other's ideas. For instance, once team members agreed on basic patterns, it was critical that they saw buy in from me for their suggestions as well as mine.

Inspire a Shared Vision: In Working with Emotional Intelligence , Daniel Goleman cites research that suggests that leaders who facilitate teams are more effective than managers who supervise. There is a fine line between supervising and facilitating. You know you are seen as a supervisor when you receive very little feedback because everyone assumes you will make the decision. Facilitating, on the other hand, is the art (and courage) of stepping back and putting the decision-making process in the hands of others while keeping everyone focused on the problem.

For me, the best approach is to come to the table with a proposal whether it is a deployment diagram or prose of some kind, a practice inspired by Frederick Brooks in The Mythical Man Month [5] where he notes that once something is written down it takes on a life of its own. The art of being an architect is awareness that this is to start the conversation.

Again, after I presented my idea of the major structural change to the application, we certainly debated and questioned some assumptions. More importantly, much of the ownership of the design transitioned from me to the team as others began adding details. It was that sense of ownership that brought others into the shared vision.

I should add that this worked because as a group we instinctively respected each other, and the ongoing dialog reinforced this.

Challenge the Process: This does not imply going rogue. It does place the responsibility, though, on the leader’s shoulders to be vigilant of decisions done purely out of convenience. An example of this is in the use of a presumptive architecture described by Fairbanks. Often, a presumptive architecture is one that is