The Team

The architectural creation, maturation , and evolution process cannot be separated from the team associated with each release. In this section I will share some thoughts on the interplay between the architecture and the team. A more complete discussion can be found in my book, Journey of the Software Professional [Hohmann, 1996].

It is natural to first consider the initial development team. Remember that, as the creators of the first system, these people are making design choices based primarily on their experience. While subsequent teams must deal with the choices made by this first team, in some way or another, the first team has no such constraints (this is one powerful reason so many developers are drawn to working on new systems). Because of this, any new architecture, even one based on an architectural pattern, will reflect the idiosyncratic experience of its creators. The number of people involved in creating the architecture, and their relationship with each other, will also profoundly affect the initial architecture. Simply put, there is no way to isolate the team from the architecture.

Experience has shown that creation of the initial architecture should be by as small a team as possible, to minimize communication overhead and to maximize team cohesion. As subsystems are defined, planned, or retrospectively justified, the team will naturally allocate responsibilities to reflect the skills of its members . Suggestions for the initial team range from as few as three to a maximum of ten. My recommendation is three to five, with one identified as the architect, primarily to keep the team moving (see Chapter 3 for a more complete description of the role of the architect).

With the release of a successful initial architecture, the team often grows to accommodate additional requests for features and capabilities. It is natural to grow the team within the initial architecture's boundaries. Perhaps the user interface, which was once handled by one developer, is expanded to need three. Or perhaps the database, which originally could be managed by a single developer, now needs two. In this manner subteams spontaneously emerge in a way that reinforces the initial architecture. The advantage to this model is that the original team member, who is now part of the subteam, can carry over the overall design and share it with new subteam members.

The process of growing the team continues until the team and the architecture have stabilized or until some management-induced limit has been reached. Some companies limit the size of any given team to a specific number of people in order to maintain a fluid, open , and collaborative approach to communication. Other companies allow teams to grow as needed to meet the needs of the system. I consulted on one defense department contract in which the development team consisted of more than 150 C++ developers, organized into about a dozen subsystems. Although this was a fairly large team, it was extremely effective primarily because it allowed the demands of the problem to dictate its size and structure.

The most important thing to remember is that the team and the system architecture are intertwined. They affect, and are affected by, each other.