Conceptual Integrity

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.

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