Architectures Are Self Reinforcing Metaphors

What is architecture? Many people talk about technology infrastructure, others talk about high-level design. There are as many answers as people, it seems.

I've come to believe that an architecture is a frame: a set of rules which tell you whether a solution is an acceptable addition to your application. There are many ways to solve any problem, but some make more sense than others given the code that you already have.

Why are some solutions better than others? Well, sometimes there are technology limitations. If you are making a distributed system, you may have constraints which force you to distribute some things and not others. If a developer breaks those constraints, they break the architecture.

Other cases are more interesting. Suppose, hypothetically, you are writing a payroll system and you already have a large body of code with a metaphor in place. The corporation comes along with a new requirement. External consultants are to be paid through the system and each is to get $100,000 a month, base pay. You have a choice. You can reuse the metaphor of the system and its code base, or you can just add the names of the consultants to a map. When their names hit the system, they are intercepted and they go through a parallel path that does not use any of the classes described in the metaphor.

Why wouldn't you do this? The corporation recognizes the value of its consultants and wants to pay each of them this way, and it could be the simplest thing that could possibly work. But is it? It may be easier to use the metaphor that is there. In C3's case this would be the lines, stations, bins, and parts. There should be a progressive benefit to falling in line with the metaphor of a system... emergent value. When the value is there, the architecture becomes self-reinforcing. The developers care for the architecture because they know that it makes work easier, and new solutions, whether consciously or not, are judged against adherence to this architecture. As the architecture grows, new additions become simpler. It becomes easier to add value as you DoTheSimplestThingThatCouldPossiblyWork.-- MichaelFeathers

This is exactly right I think. What is often lost is the inherently metaphorical nature of all programming. Software Design is entirely metaphorical since the entities that are produced are writings. The analogy between software and building is far weaker than the analogy between software and writing more generally. Indeed, it seems to me that the reason that software people are so often called "gurus" "wizards" and the like, is because software is the closest thing to magic that actually exists -- words of power in the Forth sense. A program is an incantation that actually works -- it produces action in its limited domain. All software is metaphor, and that is an essential insight I think. RaySchneider

I like this... we don't do work... we cast spells... no wonder this is so much fun! RamonLeon

But not all metaphors are useful. How can we tell which ones work well, and which ones do not? Brian Marick is exploring that question on his Visible Workings web site at http://www.visibleworkings.com

I find it helpful to remember that "architecture" derives from the Greek word "architectonike," which refers to the structure of knowledge apart from the content of knowledge. As such, it comes closest to finding a parallel in the modern word, "epistemology" and not the modern meaning of "architecture." Remembering that its orgin is more about ontology than urban planning helps me avoid some of the crasser reductions of concept that have become popular in modern Western subjects face with the prospect of hyperreality. Greg Bredbeck

CategoryMetaphor