Architect Consulting

Consulting Services overview

Architect Training

Architectural Leadership Class

Software Architecture Class:

Enterprise Architecture Seminar:

Software Architecture and UML Class

An essential attribute of good architecture is conceptual integrity. This is the easiest to achieve when the system is architected by one person.  However, architectures are typically created by teams of architects who:

• bring different expertise to bear. In complex systems, no one person covers the full breadth of technical expertise required to properly inform the architectural decisions, and lend credibility to the architecture. 
• represent the interest of different organizations. This is especially the case for product family (a.k.a. product line) architectures. The architects on the team represent knowledge of the products of their organizational group (project, division, etc.) as well as the relative priorities of their system requirements (organizational goals, and product functionality and qualities).

The challenge for the architecture team is not just to create an architecture that is "as if of one mind"--that is, it has the quality of integrity--but to create one at all!

Common Organizational Pitfalls

Lack of Leadership

Architecture teams that have no (recognized) leader, typically flounder without direction. In consensus-oriented organizational cultures, there is often resistance to leadership. Managers resist appointing someone to lead,  leaders do not step forward, and team-members do not accept leadership if it does emerge. Even when such teams are urged to name a leader, they resist in subtle ways. One team elected as leader the person least likely to lead. That person was the most adept at facilitating the group, reducing confrontations and appeasing team members when they did arise. But the team never made any of the tough decisions it was faced with, and eventually was dissolved.

If the problem is routine, good managers are needed to facilitate the work that needs to be done, efficiently applying resources and getting results. For problems that require change, where there is lack of acceptance, or novelty, leadership is essential. Inspired vision, passion, and a willingness to take decisive action in the face of uncertainty, are the hallmarks of leaders. Architecture projects are, by their very nature, ventures into unchartered territory and especially fraught with competing ideas on which direction to take. Without leadership, indecision reigns:

“INDECISION, n. The chief element of success; “for whereas,” saith Sir Thomas Brewold, “there is but one way to do nothing and divers ways to do something, whereof, to a surety, only one is the right way, it followeth that he who from indecision standeth still hath not so many chances of going astray as he who pusheth forwards...”  Ambrose Bierce, The Devil’s Dictionary

Individual Agendas

Architecture teams are pulled in too many directions at once when everyone on the team tries to dominate, each regarding their own agenda as foremost. Meetings are fractious, with endless "discussion:" 

“DISCUSSION, n. A method of confirming others in their errors.” Ambrose Bierce, The Devil’s Dictionary

This often happens in teams of very experienced architects, who have strong opinions about directions to take to best meet the needs of the business segment or technical domain they represent. It is just as well to remember that:

"the practice of architecture is a long and rapid succession of sub-optimal decisions, mostly made in partial light." Philippe Kruchten, 1999

and

"Good enough for each part is usually best for the whole system. When one part is maximized then there are inevitable losses for other parts."  (Principles of Systems Thinking, http://www.lambent.com/systems/sysprin.htm)

Divided Attention

Architecture teams made up of part-timers, typically fail to gain traction on the problem. Faced with competing short-term product pressures, the architecture effort stalls:  meetings are too hard to schedule; critical viewpoints are not represented when a decision is made, resulting in lack of buy-in to the decision; management becomes impatient with slow progress, and the effort folds.

True, an initial-cut Architecture Diagram (boxes and lines showing architectural components and the relationships among them) may reasonably be produced by an architecture working group. However, it is a non-trivial task to create an architecture that meets its architecturally significant requirements. Doing so requires focused work, both in architecture team meetings and off-line. It also takes commitment on the part of the architecture team members to "hang in there" when tough compromises have to be made. 

When we talk about gaining management sponsorship in the Init/Commit phase, we are often told: "We have management sponsorship. They chartered this architecture effort, after all!" But of course management chartered the effort. Architecture seems like a really good deal when its strategic benefits are touted and the perceived cost is low. The true test of commitment comes when management has to make hard investments of their best people's time. If management expects the architecture team to create an architecture while simultaneously holding its members largely responsible for current product releases, they are not adequately committed.

Ivory Tower

Architecture teams that cut themselves off from the rest of the organization may produce an architecture, but it will be in great danger of being rejected. It is tempting to try to reduce distractions, putting up a "wall" around the team so that they can make rapid and efficient progress.  This isolation is the source of serious misunderstandings. Firstly, the architecture team may come to be resented as a "select" group off doing interesting stuff that is disconnected from everyday product pressures. In an atmosphere of resentment, the developer community will be looking for opportunities to find weakness in the architecture. Secondly, there is a tendency to lose track of product priorities and developer concerns unless there is strong communication between the architecture team and developers and project managers on the one hand, and strategic managers on the other.  Direct contact with leading edge customers is also important to keep the architecture effort informed of market directions.  

Critical Success Factors for Architecture Teams

From the above discussion, it may appear that there is a stalemate: architecture teams are likely to find themselves mired in indecision when there is no leader or when there are too many leaders. When everyone's primary job responsibility is to do something else the team is likely to go nowhere, but they can head off-track when the team is on permanent assignment to architecture. Catch-22? No. 

We recommend a small team of architects dedicated full-time to the creation and deployment of the architecture. The team should be made up of the smallest number of representatives of the technical and organizational perspectives essential to the architecture. Typically, however, organizational constraints mean that compromises have to be made. Here is a short list of success factors:

• The team needs a leader. 
• At least that person should be devoted full-time to the architecture effort. 
• The team needs to operate as a team: "a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable" (Katzenbach and Smith, 1993) 
• The team needs to "communicate! communicate! communicate!" (Rechtin, 1991) with stakeholders.
• The team needs to establish and maintain goodwill 

With experience working with dozens of architecture projects and reuse programs, we have come to realize that goodwill is the real silver bullet. Without it, a collection of architects are not a team. And, without goodwill from the developer and management community, the architecture is rejected in overt opposition or covertly ignored in favor of local design tuning and tinkering.

Some Strategies of Successful Architecture Teams

Architectural Leadership

Architect with a Baseball Bat: Appoint or elect a leader and grant that person authority. One architecture team had three of the most senior, most talented architects at HP. They knew that to be successful, all three could not try to lead. This would cause too much division in the team. They appointed a leader, and as Joe Sventek puts it, they allowed him to be a "benevolent dictator with a baseball bat". That is, they allowed him to set direction, make difficult decisions to break logjams, and generally lead the team.

Architecture Crying Towel: Management supports the architecture team in making their decisions stick. Another HP architect, Holt Mebane, hung a "crying towel" outside his office.  While you could freely discuss your concerns about some aspect of the architecture with him, if he decided the architecture should not be changed his decision reigned and you could use the crying towel to console yourself. Of course, this worked because Holt is a very affable guy who is much liked and respected in the development community--he had tremendous goodwill among developers and the strong support of management. If these things, and a good sense of humor, were not in place in good measure, this symbol of the loss of developer freedom would have raised much resentment.

Add Your Strategies for Success 

Please share your successful architecture team practices or pitfalls with the community by posting them here.

References

Bredemeyer, Dana and Ruth Malan. "Role of the Software Architect", http://www.bredemeyer.com/role.pdf, 1999.

Katzenbach, Jon and Douglas Smith, The Wisdom of Teams, Harper Business, 1993.

Kruchten, Philippe, "The Architects: The Software Architecture Team", Proceedings of the First Working IFIP Conference on Software Architecture, February 1999.

Malan, Ruth and Dana Bredemeyer, "Architecture Teams",  http://www.bredemeyer.com/pdf_files/ArchitectureTeams.pdf, March 2001.

Malan, Ruth and Dana Bredemeyer, " Architecture Team Charter Action Guide",  http://www.bredemeyer.com/pdf_files/ArchitectureTeamCharterTemplate.pdf, March 2001.

Malan, Ruth, and Dana Bredemeyer,  "Enterprise Architecture: Balancing Centralization and Decentralization", published the Resources for Software Architects web site at http://www.bredemeyer.com/ArchitectingProcess/VAPColumns/MAPandBCA.htm.

Muller, Gerrit, "The Role and Task of the System Architect", published on the Philips Gaudi project site, http://www.extra.research.philips.com/natlab/sysarch/index.html, October 2000.

Muller, Gerrit, "The Arisal of a System Architect", published on the Philips Gaudi project site, http://www.extra.research.philips.com/natlab/sysarch/index.html, October 1999.

Rechtin, E. Systems Architecting: Creating and Building Complex Systems. Prentice-Hall, 1991. (especially Ch. 14).

Other Resources

• Role of the Architect Workshop from Bredemeyer Consulting. This unique class explores the role of the architect and associated skills, and participants work through series of exercises to practice new skills and techniques that will help them in the architect role. San Diego, April 2001.
• How to Lead, How to Follow and How to Get Out of the Way, Tutorial at the Enterprise Architecture Conference by Dana Bredemeyer and Bill Branson, Boston, March, 2001.  Also available as a one day seminar.