In 1975,
FredBrooks said:
I will contend that ConceptualIntegrity is the
most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.
In 1995, Brooks still hasn't changed his mind:
I am more convinced than ever. ConceptualIntegrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity...after teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as
four people choose a manager, and a separate architect.
See also: ArchitectAsKeeperOfTheFlame,
ChiefArchitect
Discussion:
According to
FredBrooks, "
Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds". To me, a
very small number would only mean the entire team only when that team is a
very small number. In my opinion,
ConceptualIntegrity is a required ingredient for achieving the principle (I think espoused by
AlanKay?) that "
a system must have a powerful metaphor that is uniformly applied throughout a system". While not enough on its own, the
SystemMetaphor used by XP is a step towards achieving
ConceptualIntegrity in that system.
ConceptualIntegrity does
not mean one shouldn't
include many minds (or even the entire team for that matter) in the Analysis & Design process. This is a
very important detail that shouldn't be discounted by those who wish to do away with the role of architect. Team input in Analysis and Design is absolutely
essential for (1) establishing
TeamGel, (2) ensuring the soundness and quality of the analysis, and (3) refactoring the design into something more polished. In fact, the earlier the architect or design-team can include the entire team (or domain-team leads for very large teams), the higher quality the design will be. The
DesignTeam must be open to and accept criticism,
the architect(s) must be egoless (see
EgolessProgramming).
However, if there is
no final word, no one-mind fighting off the democratic compromises that can reduce a vision to its lowest common denominator, then it will be difficult to achieve
ConceptualIntegrity and the system may run the risk of becoming an
AmorphousBlobOfHumanInsensitivity (due to
TooManyCooksInTheKitchen). It is important to realize that you can be
inclusive (or team-oriented) without being
everyone-designs or
anti-architect. Said another way,
it is possible to have an architect and have team collaboration on a design at the same time.
It is also important to note that on a small team, the design-team may in fact be
the whole product team. Another approach would have the architect role and the coach or technical/team lead role (i.e. the
final say or
tie-breaker) be filled by a single individual in order to ensure
ConceptualIntegrity. As is mentioned in much of the
RationalUnifiedProcess literature, there is no requirement for a
1 to 1 or even a
1 to N cardinality between roles and people. A single person could hold
many roles just as a single role could be held by
many people.
Can we identify specific, well-known examples of
ConceptualIntegrity?
I'm starting a list here... please feel free to make additions
- Unix (based on the notion of a "file" (e.g. directories, devices, filesystems, named pipes and sockets are all sort-of files)
- Smalltalk ("everything is an object", and the small set of other accompanying principles)
- SQL ("all data is in tables", with keys and constraints)
- Lisp ("everything is a list")
Do you see
ConceptualIntegrity as a synonym for
UniformMetaphor? I'm not sure I don't, I'm just curious. I
think that I view
ConceptualIntegrity as a means of achieving (or at least maintaining) a
UniformMetaphor. I'm not sure, though. --
RobertDiFalco
ConceptualIntegrity and
UniformMetaphor are very closely related... We can consider them, and much of the topic of
ArchitecturalQuality, as the minimization of design complexity.
- Less complexity = fewer possible combinations of features/ structures
- Fewer possible combinations = more of them work, less to go wrong
- Thus, less complexity = more reliable
UniformMetaphor however is a *single level* of structure, reaching a local minima of complexity by running everything through the same metaphor. Eg, shared memory thru the file system.
ConceptualIntegrity might use multiple levels or layers to form a minimal-complexity functional structure. Eg, presenting shared memory/ inter-process comms with a distinct API.
In one of the keynotes I heard from
FredBrooks, he listed the existence of a
fan club as a way to distinguish
ConceptualIntegrity from
DesignByCommittee. Examples he mentioned included the Mac, but I don't remember the others. Another example design mentioned included the Global Positioning System, where the
ChiefArchitect was dividing
spare nanoseconds to those software components that turned out to need just a little more time than initially thought. The
ChiefArchitect had the complete system in his head, and exactly knew what he was doing. --
ArieVanDeursen
The
RelationalModel is a far better example of
ConceptualIntegrity than SQL. SQL is a mess with regards to orthogonality, parsimony, consistency and even logical correctness. -- Jon Heggland
CategoryPlanning