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