Design by Committee
Most large organizations have an architecture committee, platform team,
center of excellence or other forms of review committees that determine
vision and direction of software projects along with technology. It is
generally good idea to have a uniform vision and a fewer set of technologies
used across projects in order to minimize maintenance and learning curve.
One of the things that these committees are responsible is the enterprise
architecture. The enterprise architecture includes hardware platform,
software platform, tools, etc. In addition, it also includes application
architecture that determines how the system will be broken into subsystems.
In some respect these committees work similar to industry standard bodies or
consortium of organizations. Depending on size and diversity of these
committees, often the design process becomes somewhat bureaucratic. The
situation can be worse if you follow strict IT governance practices or ITIL
process.
The disagreement often results in lowest common denominator or low
quality solution.
Another frequest observation is that solution is often overly complexed
and over-engineered for the problem domain. Worse, due to diversity, the
architecture is not uniform and consistent. One of the reason for
such inconsistent or complexed architure is pissing contest. In general,
software architects don’t work well with other architects and the design
meetings turn into show-offs for coming up with most clever solution.
On the other hand, an architecture by a single experienced person is often
simple and consistent. The open source community offers many examples
of creating a simple solutions that works bettern than design
by committee’s. The open source community often uses the term “benevolent
dictator” who is incharge of unified vision and architecture. So,
the software project should probably be only designed by a single architect.
Software architecture is still an art that is learned through apprenticeship.
So, it helps if there is an apprentice who can do the grunt work such as
documenting designs and taking care of details. However, I don’t mean an
architect who does not do hands on work, but rather similar to
James O’ Coplien’s pattern “Architects-Also-Implements”.
March 21, 2006
Design by Committee
No Comments
No comments yet.
RSS feed for comments on this post. TrackBack URL
Sorry, the comment form is closed at this time.