Architecture Team ★

Architects and engineers studying plans for Greenhills project, Ohio. 1936

...you have a project direction defined, and now you need to come up with a structure for the system.

✥ ✥ ✥

You need to create an architecture that is simple and cohesive, but which accommodates a variety of constituencies.

Most systems are too large for a single mind to analyze and resolve. Not only is the system to complex for a single person but the architecture must accommodate multiple viewpoints to be successful. You can solve this with a team of architects who bring diverse views, but the collision of diverse views brings difficulties of its own.

A design by committee usually looks that way. It tends to result in everything being added, even the kitchen sink! (Try to get a picture of the Denver Public Library here.)

Committees are inherently less efficient than individuals (see SoloVirtuoso for example.) Yet there is safety in a team; it makes it possible to keep a ModerateTruckNumber.

The entire organization will need to accept the architecture. The more people that are involved in the architecture, the better chance one has of "selling" the results. But the more constituencies involved, the more difficult it is to come to agreement in the first place.

Therefore:

Create a small team of resonating minds to define the initial architecture, in such a way that the team covers the expected partitioning of the system. The key idea is that most or all the team members should come away with a piece of the system for which they have architectural responsibility. While this may appear to be trying to predict the future, one can usually easily identify the areas of grossest partitioning beforehand. For example, it is probably easy to guess a system might have a user interface, back-end storage, and internet communication areas. The careful selection of the team is aimed at preventing the "designed by committee" look.

Other representatives may be needed to round out the team. Luke Hohmann notes the difference between the technical architecture and the marketing architecture; the marketing viewpoint may be very valuable in this team.

The ArchitectureTeam's task is to create a high level partitioning. There remains much architectural work to be completed at lower levels. Charles Weir designates the high level architecture team as the "Master", while "Journeyman architects" take on the design of the smaller pieces. The Master-Journeyman pattern also suggests typical partitioning of core architecture, architectural vision, interfaces, and specification control [BibRef-Weir1998].

✥ ✥ ✥

Legitimizing this activity as a team, with organizational structure, lends support to the social interaction necessary to forming and sustaining the shared vision (see UnityOfPurpose).

The team should have a periodic StandUpMeeting to maintain the architectural integrity of the system. Early in the project, these meetings can take place daily.

Note that an architecture team focuses on the initial architecture. The result should be a gross partitioning of the system, allowing members of the architecture team to be architects of their own subsystems (see also ConwaysLaw.)

The best way to accomplish a shared architectural vision is probably through the use of LockEmUpTogether.

HolisticDiversity is a pattern that ties together the multiple teams such as infrastructure teams and other teams relating to individual domains and technologies. The ArchitectureTeam may either be such a team or contribute to a cross-disciplinary team that goes beyond architectural issues into issues of business and implementation.

This pattern is a refinement of Harrison's "Diversity of Membership" [BibRef-Harrison1996].

This pattern draws heavily on Gerard Meszaros' ArchitectureDefinitionTeam. Gerard further suggests that there be a separate ArchitectureOrganization that owns the architecture. Here, we propose that ownership and function be tied together. This pattern also arises in Alistair Cockburn's analysis of the interaction between HolisticDiversity and SubsystemBySkill. See also ArchitectControlsProduct and ArchitectAlsoImplements.