Good Architecture, Good Leadership

already in place and many assume its reuse. Identifying the failure of presumptive architectures is a form of Challenging the Process.

Going back to that specific experience, the troublesome application was based heavily on a third party's object libraries. The pattern of objects in a hierarchy of linked lists essentially took a query from the database and renormalized the result set. Up to this point, everyone assumed that approach was essential because of the legacy nature of the application. The approach I suggested was to use a block of shared memory to cache the query results. That high-level redesign change created enthusiasm among the developers because it was understandable. That positive feedback from the developers was also encouraging to the higher management levels (more stakeholders) to support the rewrite of the application.

Enable Others to Act: This is where we begin to see the already discussed practices support each other. By working through critical decisions with the developers, the architect has set the stage for more effective development. In other words, developers have a known starting point.

Further, there is a parallel human element for each architectural decision made. For example, good architecture clearly identifies boundaries where interfaces are needed. Behind each interface on paper, there are often people on each side of those interfaces that represent another set of interests. So, identifying the interfaces is also providing a map of "relationships" with specific information to team members of conversations they should initiate.

Encourage the Heart: This practice represents the synergy created by the preceding four. In essence, architecture communicates the big picture, and, because there is a big picture, all stakeholders have the sense that the goal is attainable.

Encouraging the heart is also accomplished through the assignment of work.  The simple act of partitioning is not only modeling, it also becomes the basis of assigning work to developers. That distribution of work should clearly communicate that you believe in that developer’s ability.

   Another consideration is inspired by Donella Meadows, the author of Thinking in Systems: A Primer [6]. She notes that the higher level of a hierarchy is designed to serve those in the lower levels. Quite simply, an architect's general availability to discuss alternatives or just answer a question adds a sense of confidence to the general working atmosphere. The architect’s availability should not be seen as a crutch for developers. Instead, it is the foundational scaffolding to nurture the craft of software development in others.

Finally, architects encourage the heart by bringing a passion for technology into the group. Others will sense that level of energy and often respond in kind.

If you consider yourself an architect, I have no doubt that there is a sincere pride manifested in your intentional efforts to hone the skills of your craft. I believe intentionally considering Kouzes and Posner’s five practices with each architectural decision you make will take you to the next level.

REFERENCES:
1] Bass, Len; Pal Clements, and Rick Kazman. Software Architecture in Practice . Addison-Wesley, 2003.

2] Kouzes, James and Barry Posner. The Leadership Challenge . Jossey-Bass, 2008.

3] Fairbanks, George H. Just Enough Software Architecture: A Risk-Driven Approach . Marshall & Brainerd, 2010.

4] Goleman, Daniel. Working with Emotional Intelligence . Bantam, 2000.

5] Brooks, Frederick, P. The Mythical Man Month. Addison-Wesley Professional, 1995.

6] Meadows, Donella H. Thinking in Systems: A Primer . Chelsea Green Publishing, 2008.