One size never fits all.
(This article was originally published on MSDN in the Architecture Center in April, 2004. With its relevance to discussions about simplicity, I felt it worthwhile to dig it up. - Hess.)
One Size Never Fits All
Before a wide selection of inexpensive, off-the-shelf clothing was available in the marketplace, most of a family’s clothing was made at home. My mom made much of my wardrobe when I was younger. Frequently, I would accompany her to purchase material and choose patterns. Later, she would pin the finely marked tissue to the fabric, cut the components, and stitch them together. Whatever the occasion, style, or article of clothing needed, a pattern existed that was specific enough for the task, yet versatile enough for variation and adaptation. She always found what was required, and was able to execute no matter the scale or material.
What was so magical about those patterns? How was it possible for my mom to cope with the seemingly infinite variations in material, size, proportion, and style; yet consistently deliver a quality finished product? While she is one of the most creative people you could meet, why wouldn’t she just craft her own patterns? You would think that she had plenty of experience. And what does this have to do with software architecture?
For software architects, the pattern has emerged as a valued, and widely discussed, component in our toolkits. Because patterns evoke a sense of predictability, even in complex problem spaces, they increase confidence in our ability to deliver the software needed to solve these problems. The Gang of Four, and subsequent pattern community contributors, created a language for cataloguing and describing these concepts. Then they refined this communication in the context of accepted modeling semantics, communication mechanisms, and solid system engineering practices. Yet, how many of us actually leverage patterns as deep foundations for our projects?
|
The diagram at the right is a detail from an early 20th century Russian clothing pattern. It represents a small piece of an overwhelmingly complex model. However, for the tailor this complexity is actually freedom: a form of documentation for an expert practitioner. Subtle variations in scale and implementation style are interlaced in an approach acceptable to like professionals. There is a tremendous amount of information encoded into this pattern. While this detailed information fosters adaptability, it limits broad usability across a range of experience levels.
|
Figure 1: Clothing pattern (detail)
"Neva" Magazine, St. Petersburg, 1906
|
|
Figure 2: MVC pattern, object relationships
|
This diagram is a typical representation of one of the patterns that I believe nearly anyone can grasp: Model-View-Controller. If you have even the most basic understanding of separation of concerns, OOAD principles, and the “box and line” modeling semantics, you can get an understanding of how this pattern works. However, it leaves many of the details up to the implementer. By design, it furnishes no scale or style dimension, letting the system’s requirements determine the instance variations in communication protocol, object interaction and presentation variation.
|
In the software architecture world, which of the above diagram styles has more value? Which diagram is closer to the mechanisms that we use to communicate our architectural thinking to those actually implementing the work? It is my belief that, while we often use the latter diagram model, it falls short in describing the myriad details comprising a real system. There are two challenges that need to be considered when we consider this gap in effectiveness: Our quest for simplicity, and our thirst for creativity.
The architecture of any system today is inherently complex. As architects, we strive to decompose problems into manageable chunks, into understandable models that attempt to simplify the communication of complex challenges. In fact, this is not unique to software architecture. As Stephen J. Gould writes, “From its late-seventeenth-century inception in modern form, science has strongly privileged the reductionist mode of thought that breaks overt complexity into constituent parts and then tries to explain the totality by the properties of those parts…”[1] He wrote this in an article commenting on the discovery that predicted 1,400 genes of the human genome, as calculated from endpoints observed in the human system. In reality, there are more than 30,000 to 40,000 genes. Clearly the quest for simplification and reduction led geneticists to erroneous conclusions. Software architects today often err in the opposite fashion. Rather than encoding additional detail, we highly refactor our models; thereby, leaving much to interpretation. To effectively leverage patterns we should find ways to instantiate patterns in very specific forms. We should use the platform, language, problem space and practitioner experience available to us as influencers to work in an appropriate level of detail.
Architecture is an inherently creative task. We have a multitude of options available to us. Much of our work is not guided by physical principles, but rather by instinct and feeling. Consequently, we are suspicious of “silver bullets:” those predictable, packaged solutions that ultimately fail at some critical juncture. Also, our creativity is challenged by an ever changing landscape of platform technologies, standards, capabilities and tools. Pity our colleagues who are faced with the daunting task of implementing our grand architectures. An abundance of choice hinders our ability to effectively leverage patterns, or even to provide a basic platform for training and understanding. Finally, we each categorize our system thinking differently, creating misunderstanding even when discussing the same fundamental pattern.
Totally reinventing and re-categorizing our architectural patterns is not required. Nevertheless, to make the best use of patterns we should address architectural ambiguity by introducing more context into our pattern usage. As my mom said, “You can’t just make a shirt; you need to be specific about cut, style, and fabric.” What’s more, you can’t simply reclassify “shirt” to “sweater” without forming a clear tie back to a common starting point. As architects, we need to leverage the strengths of our expert practitioners, and furnish them with the tools and resources that provide the correct balance of boundary and adaptability. Only then can we consistently deliver the perfect garment. In this way our pattern catalogues become useful, effective, and can actually be used by our developers.