Despite the fact that I’ve been thinking, talking, and writing about the concept of the hourglass for around twenty years, it was only after my friend and fellow Rortian, Stephen Taylor, asked me to “write up a condensed conveyance of the bowtie/hourglass concept that I can link to from my blog”, that I realized I’d never done so before. I’ve written about spanning layers, and middle-out, and web-oriented architecture (which are all just variations on the hourglass theme); but I’ve never just written a simple, brief summary of the hourglass concept. So here goes…
As you can see from the diagram above, AFAICT, the hourglass concept (by that name) originated in discussions and papers about the architecture of the Internet. Since this is supposed to be a condensed summary, I won’t go into a detailed history of the references to this diagram. Suffice it so say, that in its origin, the hourglass concept was meant to convey a network architecture (such as the Internet) that overlays a diverse set of underlying networks (the bottom of the hourglass), and supports a diverse set of applications (the top of the hourglass), via a simple, general set of protocols (e.g., TCP/IP) in the middle (the waist of the hourglass).
I have generalized this concept as follows: The hourglass concept applies to any kind of simple, general interface that can be realized (implemented) in diverse ways and that can be used for diverse purposes. The opposite of the hourglass concept is the stovepipe or silo concept (aka vertical integration).
Other people have generalized this concept as well, especially a researcher named John Doyle. As with most generalizations, the concept goes by different names: bowtie architecture, spanning layer, bearer service, etc. What’s amazing about the hourglass concept is that once you understand it, you begin to see it everywhere.
For example, early on, when I was trying to find a simple, intuitive analogy for this technology-centric concept (or so I thought at the time), I described it to my wife to see if she could understand my description of it. She thought for a moment, and said, “Oh, you mean something like pasta. You can make noodles from lots of different ingredients, wheat, rice, egg, squid ink, etc., and in lots of different shapes, and you can then make lots of different dishes with them”.
When I say it’s everywhere, I mean everywhere: the electric grid, money, clothing, Legos, intermodal shipping, biology, evolution, etc.
Of course this raises questions such as, “What is the key to such architectures?”, “What design principles ensure successful hourglass interfaces?”, “Why does the hourglass concept spontaneously emerge so widely in nature?”.
The answers to such questions are way beyond the scope of a condensed summary. But there is one principle that is central to the hourglass: generality. Every successful hourglass interface is a general purpose interface. Generality is the key to shareability — the most widely shared interfaces are the most generic. Of course this begs the question of how to design for generality. But that is the topic for another essay.
