Design and Architecture

This is a modern nail clipper. It was invented, it appears, by Chapel Carter in 1896. Ask yourself, which elements of this object reflect design, and which elements represent architecture. I am going to offer a fairly clean distinction for you to ponder, but I'd like you to make up your own mind first. You don't have to be a mechanical engineer or any sort of engineer, architect, artist or designer to answer. Just go with your intuitive sense of those terms, and apply them. These ideas also apply to organizational and social design and architecture. This piece grew out of an interesting bit of crossfire on Twitter a few days ago. It began when I said:

"Am realizing I enjoy design, but not architecture. Design is the 'play' subset of 'architecture.'"

This provoked an instant response from @jrdotcom, a  software guy I know:

@vgr In software, there is no difference between design & architecture. They are just words that non-programmers have invented.

After a bit of back and forth thesis-antithesis, another guy I know, @jbsil01, also a software guy, offered a partial synthesis:

@vgr as a programmer, design can mean the same thing as architecture. as a user, architecture should be irrelevant to design.

Reflecting on the exchange, I realized that all three positions bother me. My own remark is too flippant, clearly. But @jrdotcom's position, that there is no substantive distinction, that this is all pointy-haired-boss-speak, at least in software (and I have heard similar views from other sorts of engineers) is too dismissive of the importance of language. And finally, @jbsil01's reliance on subjective user experience as a fundamental filter to tease the two apart is too pragmatic and operational. So let's dig deeper. I'll frame my discussion in terms of engineering, but this applies, mutatis mutandis to other synthesis fields which mix utilitarian intents with aesthetic ones. The Distinction Here's the distinction.

1. Packet switching is a design. For non-techies, this is the idea of a network-of-networks that moves things around after chopping them up into standardized pieces that may travel different routes between the same end points.
2. TCP/IP (the basic set of protocols that run the Internet) is an architecture that realizes that design in the domain of inter-networking software
3. Containerization is an architecture that realizes that design in the domain of multi-modal cargo transport (sea, rail and road)

In other words, architecture is not about UML diagrams or stack cartoons in software, or CAD drawings in mechanical engineering. Design -- at least not design with some utilitarian element in its intent -- is not about aesthetics (though there is a relationship that I will get to). This example-based distinction will do for now. Finally, both design and architecture are part of the engineering artifact itself, and do not depend on the opinions of an individual in a specific role like 'user' or 'engineer.' Since I am not a software developer (though I manage software projects), and since this distinction applies in any field of synthesis where the end result is "stuff gets built," let's work the nail clipper example, since it is familiar and simple enough for anyone to understand. The Nail Clipper I don't know the actual story of the nail clipper, and whether the design occured to Chapel Carter in a flash of insight or through evolutionary refinement, but let's do a counterfactual story. It is 1890, and everybody is sick of trimming their nails with barbers' razors (as a kid I used to go to a barber who'd trim my nails after my haircut) or nail scissors. The one is unsafe, and the other involves sore knuckles. Both require some skill to avoid rough edges. The basic problem can be framed quite easily in mechanical engineering terms: you want a device that is safer than the razor, eliminates the uncomfortable ring handles of the nail scissors, requires less skill to use than either, and requires no maintenance (unlike razors, which require periodic sharpening). Our hypothetical, uncreative 1890s engineer thinks a little and decides he likes the twin cutting edges of the scissors for safety. To function at less-than-razor sharpness, this approach requires leverage (the ratio of delivered to applied force) of more than one, so a small force can be amplified. So looking up his engineering textbook, he realizes that only Class 1 (scissor) and Class 2 (nutcracker) levers work. Class 3 (sugar tong) levers won't work because they provide leverage of less than one. So his two basic classes of  design are: The first is basically a complication of the scissor idea: turn the blades ninety degrees and shape them to conform to human nails, and add a spring-action return to eliminate the need for the rings. The second needs cutting surfaces oriented like scissors, since you can't shove your finger through the coil spring at the other end. If you are a mechanical engineer, and work through the details, you will realize that both textbook designs are ugly as hell: once you add all the joints and linkages, there are more parts and more failure modes than either the razor or the scissors (I recall a machine design textbook, I forget which one, which used the same nail-clipper example and had a sketch of a ridiculous "full" textbook design to make the point that design involves more than blindly applying the theory of simple machines). They also display low symmetry, a point that is significant. Now we turn to our fictionalized version of Chapel Carter. Let's pretend he got an Aha! insight. He too, starts down the path of basic Class 1 and Class 2 lever designs, but then he gives up on seeing the ugliness. He then follows this right-brained process:

1. Out on a walk, he watches a cat catch and bite a mouse, and marvels at the compactness of the cat's head. Suddenly, he realizes that the cat's jaws are a two-cutting-edge class 3 lever, which he had eliminated. The muscles providing the forces operate between the fulcrum (the jaw hinge) and the cutting points.
2. He ponders more, and realizes that by using pull forces from muscles, animal jaws achieve great compactness, and the Class 3 structure achieves high symmetry and an open-mouth design. But the design wouldn't work for nail-clippers because there is no easy way for a human to exert forces that way, and the leverage would be less than one (which doesn't matter for jaws, since jaw muscles are strong, teeth are sharp, and food is softer than nails).
3. He lets the problem simmer in his mind, and then one night, he leaps out of bed shouting "Eureka!" He has thought of a curious way to combine a class 1 lever with a class 3 lever which might apply to his problem. The idea is clever, but now has lots more moving parts and two levers where other designs have one.
4. Still, he is so enamoured of his clever insight that he continues thinking about it, even though it seems too complicated on the surface.
5. And again, in a flash of insight, he figures out how the whole thing can be done with only 3 parts, so long as he is willing to make some odd-shaped parts. His leap of faith that two levers would in the end lead to a more compact design is validated.
6. Some weeks of trial-and-error later, he has the design we use today.

Now, he has a design that not only hits the customer specs, but thanks to his elegant swivel-and-fold design for the pressure lever, is unbelievably compact. For an encore, he has replaced a return action requiring a separate spring with one that just uses the bending stresses of a couple of welded strips. Permanent joints replacing moving joints mean one less point of failure. Architecture vs. Design The first, uncreative engineer's approach is strong architecture with very weak design. The second approach is strong design followed by strong architecture. You can also have strong design with weak architecture, and I can't think of a nail-clipper example, but here is a sketch of a design I came up with for a design challenge way back in 1996, when I was a mechanical engineering junior. The challenge was simple: come up with a device that, through the turning of a crank (input), lifts up a pencil 15 cm and drops it (output). My design was inspired by a mechanism I saw in a steel plant, designed to move heavy iron bars up a slope (something similar can be seen in certain toys that lift up toy cars to the top of a slide using a "moving staircase," and let them roll down): The dimensions and distances are not accurate, but the rough idea is that the pair of outer, orange plates moves in circles on the blue arms, staying parallel and aligned with respect to the fixed, yellow inner plates. As you turn the outer plates using the black handle, the pencil moves up one level at a time, until it hits the top level, which is sloped, allowing the pencil to fall down.  I was rather pleased with myself, and my team-mate and I produced a prototype out of some spare perspex we found in the shop, using glue and wooden dowels to put the whole thing together. If you can't visualize roughly how the thing works, never mind. It was flimsy, but it worked. We won a "special mention," but the design that won first place was a much more robust and straightforward application of a pulley and a four-bar mechanism (I forget the details), and a neat gripper that could pick a pencil off the floor, rather than requiring it to be in a special location like our design. It worked beautifully. A lot of people looked at our design and were intrigued by the cleverness of the basic idea, but didn't take the design seriously. The winner though, had both clean design and great architecture, and unlike our design, did not make the idea too simple and subservient to a single clever "trick." We were so happy with our clever idea, that we missed thinking through some basic features that would be useful in the solution, like being able to pick up a pencil from any surface, and other things that would matter in practice, like putting a pair of heavy and large plates on two rotor arms. We also jumped too quickly to "insight" rather than doing enough preparatory thinking with basic machine design principles, and evaluating the full "vocabulary" of elements like pulleys, belts, four-bar mechanisms and so forth. We got simplicity and elegance, yes, but at the cost of a fully-functional solution. Design and Architecture Defined Design is the process of seeing an ambiguous problem through the lens of a specific organizing insight and a set of self-imposed design principles both of which can be domain-independent. Each element in the 'design' definition is critical:

1. Domain Indepedence: Design ideas come from novel ways of seeing, and rely on similarity of sensory patterns. These can clearly transcend specific domains. From where we stand, a set of seven stars happens to look like a "Big Dipper." Design is conceptually pretty much always visual. Design arising out of ways of hearing or touching are rarer.
2. Organizing Insight: At the heart of every great engineering artifact, there is usually at least one powerful organizing insight, often borrowed from an unrelated domain via a metaphor (jaws for nail clippers) or abstraction ("packet" in networks). This organizing insight plucks out a small and fertile region of a large design space to explore. If the insight is validated, it usually buys you a lot of simplification (in an absolute, information-theoretic sense in fact, but I won't belabor that point; just think of it as "elegance"). A familiar example: the "organizing insight" of Southwest is "compete with driving and buses, not other airlines."
3. Design Principles: The laws of physics, customer requirements and engineering best practices are a basic set of constraints. But design usually involves imposing further constraints on yourself. These are not those vague ideas like "simplicity" or "elegance." These are more specific commitments like "fewest possible moving parts." Design principles can also be domain-independent. For example Southwest Airlines applies the idea of "fleet homogeneity" (only fly 737 aircraft). This is derived from the general principle: "use identical parts to serve identical functions." This principle has a lot of benefits, but also some problems: an entire country devoting its agricultural land to one crop leaves itself vulnerable to disease (think potatoes and Ireland).  Heterogeneity and diversity, the other end of the spectrum, present different benefits and costs. The point is, design principles commit to tradeoff points as a matter of principle, not out of an intent to optimize something. Optimization is in the realm of architecture. Trade-off points chosen as design principles represent leaps of faith.

Architecture is the application of a codified set of  domain-specific laws and a mature vocabulary of components, to realize and finish a design, and providing it with an intrinsic logic that allows it to break away from the organizing design insight. The elements of the definition architecture are also essential.

1. Domain-specificity:You cannot go from the abstract idea of "packet" to a communication network, or from a clever observation about cat's jaws to a nail clipper, without knowing a good deal about how things are built in the domain. Architecture is a domain-specific skill.
2. Laws and Components: Every domain has hard and soft laws (you shouldn't attempt to build a perpetual motion machine for instance (hard) or leave sharp edges exposed (soft)), and a vocabulary that evolves organically from reusable pieces of previous successful designs: fragments of design DNA that are known to work. The four-bar mechanism in machine design, the model-view-controller pattern in software architecture, and the RLC oscillator circuit in electrical engineering are all examples. Many design-oriented thinkers have great ideas but a very poor vocabulary, which leads to clumsy architecture. In more self-contained artistic domains like graphic design, the 'architecture' element can be found in principles of color matching and layering, specific painting techniques and so forth.
3. Finishing: Architecture must also finish a design, because design only makes some of the commitments required for a completed artifact. For the completion, the design principles guide the architecture part of the way (so the "elegance" of the insight is extrapolated to other aspects of the artifact). But there are always parts of the architecture about which the organizing design insight has nothing to say. Many clever ideas for Websites, for instance, ignore security concerns. Designers usually have nothing to say about it, but architects do. This part of "finishing" is provided by best practice principles from the domain itself. Securing TCP/IP and securing containers in shipping are likely not similar in any way (except by accident).
4. Intrinsic logic: Design insights impose a very powerful organizing force on an engineering artifact, usually from outside the domain. For example, the desktop metaphor for computer screen GUIs is very powerful. Left unchecked, it could lead to all sorts of bad architectural commitments. Similarly domain best practices create a powerful opposed force from within the domain. A critical function of architecture is to contain the greed of the design, and limit the influence of the domain, and create enough harmony in the whole artifact that it acquires an intrinsic logic. In the end product, architecture should rule, not design or domain. This is what allows artifacts to become unique. So TCP/IP and container shipping, despite sharing an organizing insight, are architecturally coherent in very different ways.

Design DNA, Symbols and Aesthetics Design, in the sense of Bauhaus and other design "schools" often seems to be about pure art. There is a lot that can be said about this, but I suspect that in truly successful functional design, there are no 'non-functional' elements. Everything ties into the whole. So we should ask, what functions do the color of paint and the design of a logo or car grille serve? I believe they serve two functions. First, the visible part of an artifact reveals only a very few elements of design. Only a handful of the thousands of decisions involved is obvious at first glance. In examples like TCP/IP, the organizing insight may even be invisible functionally. So the design must, within its ecosystem, signal its DNA. Something of the unique aspects of the organizing design insights and the intrinsic logic of the architecture must be made visible, because the test of the design's success is a Darwinian one: survivability. The signalling needs to reach those parts of the ecosystem that ensure survival. Internet users do not need to understand packet switching, but in the ecosystem of network architectures, communications engineers had better become very familiar with the packet switching idea (or meme)  if it is to survive. They are the ones who will reuse it in future designs. For signalling the design part of the DNA, this means exaggerating the organizing design insight on the surface, and downplaying neutral elements. If it cannot be signalled, it must be symbolized, preferably in very elemental or iconic ways. Mercedes-Benz and BMW still convey "luxury" and "power" respectively, thanks to their effective grill designs and body-styling principles. For signalling the intrinsic logic part of the architecture, we need the same outward signs that nature employs: symmetry. In an information-theoretic sense, symmetry of any sort represents low entropy. Low entropy is terribly expensive to maintain in any ecosystem, natural or artificial. A survivable architecture is one that has enough coherence in its intrinsic logic to leave some design variables free to display various sorts of surface symmetry. Symmetry not only carries a specific interpretation, it is easy to pick out as a pattern against a backdrop of low symmetry. So in short, visible "design DNA" and symbols signify the uniqueness of a design, while symmetry-driven aesthetics signal the intrinsic logic and low entropy of the architecture. When these are hard to convey in surface terms, symbols become important, to provide easy focal points. The idea of a brand is an extension of the idea of design DNA to organizations. Design, Architecture and User Experience Sometimes, due to the nature of the problem, the organizing insight that drives design primarily organizes the part of the artifact that a user interacts with. Almost all of Apple's design DNA is related to the single organizing insight that human-computer interactions should revolve around the sense of touch. The drag-drop GUI, the click wheel of the iPod and the  two-finger interface of the iPhone all derive from this insight. Even 'negative space' decisions fit this model: the focus on hiding away unpleasant tactile elements like dealing with multiple pieces or a mess of wires fits the organizing insight. But this does not mean all design should be as visible as that of Apple, or as concerned with user-experience coherence. In fact Apple is a good example of design overwhelming architecture. The organizing insight of Unix is programmatic composability, particularly at the level of piping and redirection at the shell, little shell scripts and other features that make the inside of a Unix machine a self-organized bazaar. Curiously, Microsoft, while a weak-design-strong-architecture combo at the level of the operating system, is not actually weak in design. Microsoft's organizing design insights are not at the level of technology, but at the level of market timing. If 'touch' is the sign of Apple, then 'get it right by Version 3' is Microsoft's signature. The point of this little sidebar is this: it doesn't matter where in your scheme of things you have an organizing insight, but you need one somewhere. Around that, your architecture will be efficient, even if others complain about other parts. User experience, internal design and business model architecture are all legitimate targets. You don't have to win them all. There is a lot more that can be said here, especially about how design and architecture represent different personality strengths. But let's leave it at that. Design and architecture are different and substantive ideas. Language matters.