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.
|
