Conceptual Integrity

In 1975, Fred Brooks said: I will contend that Conceptual Integrity 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. Conceptual Integrity 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 Fred Brooks, "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, Conceptual Integrity is a required ingredient for achieving the principle (I think espoused by Alan Kay?) that "a system must have a powerful metaphor that is uniformly applied throughout a system". While not enough on its own, the System Metaphor used by XP is a step towards achieving Conceptual Integrity in that system.

Conceptual Integrity 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 Team Gel, (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 Design Team must be open to and accept criticism, the architect(s) must be egoless (see Egoless Programming).

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 Conceptual Integrity and the system may run the risk of becoming an Amorphous Blob Of Human Insensitivity (due to Too Many Cooks In The Kitchen). 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 Conceptual Integrity. As is mentioned in much of the Rational Unified Process 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 Conceptual Integrity? 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 Conceptual Integrity as a synonym for Uniform Metaphor? I'm not sure I don't, I'm just curious. I think that I view Conceptual Integrity as a means of achieving (or at least maintaining) a Uniform Metaphor. I'm not sure, though. --Robert Di Falco


Conceptual Integrity and Uniform Metaphor are very closely related... We can consider them, and much of the topic of Architectural Quality, 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

Uniform Metaphor 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. Conceptual Integrity 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 Fred Brooks, he listed the existence of a fan club as a way to distinguish Conceptual Integrity from Design By Committee. Examples he mentioned included the Mac, but I don't remember the others. Another example design mentioned included the Global Positioning System, where the Chief Architect was dividing spare nanoseconds to those software components that turned out to need just a little more time than initially thought. The Chief Architect had the complete system in his head, and exactly knew what he was doing. -- Arie Van Deursen


The Relational Model is a far better example of Conceptual Integrity than SQL. SQL is a mess with regards to orthogonality, parsimony, consistency and even logical correctness. -- Jon Heggland


See original on c2.com