"The Cult of Cloacina" - Why Architecture Matters In the Age of Agility

While reading a Facebook post recently, I followed a link that took me to a link that took me to a link to one of those "weird" places on the web. In this case it was about "unusual Roman gods and goddesses." Apparently the Romans had a goddess of drains and sewers. How weird.

The Roman "Cloaca Maxima" (The Greatest Sewer) was an engineering marvel for its time. In the ancient world, germ theory wasn't understood obviously, and so in most cities garbage, refuse, human and animal waste, rotten food, and all other manner of effluence was simply "tossed out the window". (Humorously, the Britishism "loo," used to refer to the toilet, is a shortening of an old Scottish colloquialism "gardyloo", which was a word yelled by servants before they engaged in this "tossing of 'rubbish' out the window" -- to warn passers by that they needed to get out of the way!)

Unlike most other people of the time, the Romans were a bit more fastidious about how they dealt with ummm... waste, and in the 6th century BC constructed The Greatest Sewer to help manage the problem. Writing seven centuries later, the philosopher Pliny the Elder marveled at how sturdy the system still was, commenting on how well it handled the flooding of the River Tiber, completely filling to the ceiling but remaining fully intact and functional. The Greatest Sewer was so important to the Romans that a deity came to represent its.... shall we say... grandeur -- the goddess "Cloacina." There are even coins with her shrine depicted. Over time this goddess merged with the goddess Venus, as Venus was associated with cleanliness and the two goddesses coincidentally shared an association with the myrtle flower.

A colleague and I were reflecting the other day on how "microservice fever" sort of took over our field a few years ago, and doesn't show much sign of abating. We also lamented the emerging antipattern of ignoring system boundaries and packaging concerns in order to "strike it rich" in the "API gold rush" we seem to be in. It seems that in our mad dash to get APIs in front of every system, perhaps we're losing something. There's certainly emerging evidence in places like the hallowed halls of Uber that the emperor might be wearing a thong or something.

Martin Fowler was musing over the common question about "what exactly do architects do?" a couple of years ago. He eventually comes to the conclusion that software architecture means "the stuff that's hard to change." (We'll ignore the fact that the architecture function operates all the way from business development to infrastructure engineering and we'll just focus on systems architecture for right now.) When you couple those two things together (the stuff coming out of Uber, Netflix, and other early adopters of microservices, and Fowler's definition of architecture), the conclusion you basically come to is that microservices, by themselves, are nothing more than drains. Drains and spigots. They're not much more than an endpoint, by themselves.

Let's imagine that I have a system that violates nearly all twelve of the 12-factors that make up good cloud native software. Can I put an API in front of such a system? Of course I can! I can put a drain or spigot at the front of that system, make the API public, and voila, I'm running a digital company! Well... maybe not. You see, that drain/spigot is only as good as the underlying system it's providing to the rest of the world. That underlying system has characteristics and qualities that may not be very cloud app friendly. In reality, that's what those 12-factors are -- they're a subset of the qualities necessary to be a good cloud app. They're not exhaustive, they're just the starting point.

When I was younger, my employer had a training program where all people who aspired to become architects were taught some foundational notions about systems architecture. I participated in those training programs, became a practitioner, eventually taught those classes to others myself, and then promptly abandoned the whole idea when the agility train came to town. We didn't need that "architecture astronaut" stuff. The "architecture" of our systems shall henceforth emerge as we build and integrate our applications. However, even when I moved into the mentoring/consulting roles that I then held as a senior engineer, I remembered some of that stuff I had learned a decade earlier, and taught for a few years -- things like "systems management, operations, application design, integration design, data management, usability and informational design, functional requirement elicitation, and security; things like the Zachman model for focusing on conceptual, logical, and physical views." Each of those had subcomponent "-ilities" (non-functionals) that we needed to worry about as architects. We were taught that almost every decision we made was a trade off. I guess I didn't abandon those things, but rather "shelved them" for our collective delivery mania. After all, many sins can be covered by execution.

And this is where the two stories come together. The Cult of Cloacina wants us to believe that there are no trade offs when we build and integrate systems. We need only (or mostly) focus on customer facing features (they say)! Boundaries and packaging of our systems are minor concerns, and besides we can always change anything, they say. We need only put a drain or a spigot in front of our monolithic system, and we're ready to receive well earned blessings from Our Lady of Troughs. The Cult of Cloacina believes in the opposite extreme as well. We need only fill the world with tiny interconnecting drains and spigots (let the congregation say with due reverence "microservices"), and the Madonna Della Latrium will bestow her overflowing grace upon us. It's all about the use of drains and spigots. The path to salvation is via sweet drains and spigots. So what's the problem? Well, both of these beliefs (superstitions?) ignore something kind of important. At the risk of being branded a heretic, let me posit an alternative view.

The intractable "trade-off axioms" that we were taught to honor and observe as Stoic Philosophers of Architecture never really went anywhere. Like gravity, our misguided belief that they don't exist doesn't keep us from falling. However, as architects we became so enthralled in our reveries that we slowly became irrelevant to our people. Some of us who were more evangelical committed worse crimes. We earned the "ivory tower architect" moniker by blathering on and never pronouncing an actionable direction. We became yet another "department of No." We were neither disciplined enough to be held accountable for delivery, nor were we humble enough to admit that delivery was at least as important as design. For those crimes we have much to repent. (In my case, I can salve my guilt with the palliative that I was at least a project architect in those days.)

It is with great contrition now however, that we must take up our mantles and bring order to the chaos created by the Cult of Cloacina. Systems design and systems thinking matter. Every choice we make in order to provide developer productivity in our ever present quest for faster value throughput has trade offs. We can, and should, look for ways to minimize the long term accretion of those choices (things like TDD, tech debt spikes, and automated regression are certainly useful tools in that regard), but we also must acknowledge (and teach others to acknowledge) that some decisions we make are close to permanent. The languages we use, the app dev frameworks we build on, the choice to use IaaS, opinionated PaaS, unopinionated PaaS, SaaS, or any of the variants along that continuum, how we choose to organize the boundaries of our systems, what type of engineers we hire and promote, and yes, the drains and spigots we provide to and from our systems all have trade offs. We cannot afford to spend ages agonizing over those trade offs, but we also can't afford to pretend like they don't matter and are all equally changeable. They are not.

So, let us usher in a new age of reason. Let us resurrect the pragmatic parts of the Gang of Four, Patterns of Enterprise Architecture, and other old tomes, and mine them for their wisdom. Let us reteach ourselves and others how to quickly assess tradeoffs on architecturally significant things ("the stuff that's hard to change"), and let us channel the enthusiasm of the Cult of Cloacina.

Still unconvinced? I know, it's really hard to believe a guy with "architect" in his title, even (especially?) one who dropped that title and then picked it up again. We must "engineer all the things!" Engineering purity will be our salvation! I know, I get it. So in the spirit of comradeship, please go watch that Uber video I mentioned, or a similar one from Netlix. I think you'll hear many echoes of my sentiments above. The bottom line is that there are emergent properties of every social system (see Conway's Law), and those things affect our solution designs. We can't avoid it. Engineering focus is awesome -- being a good practitioner and engineer is important. There is a vast need to be better at what we do tomorrow than what we do today. Being able to code and debate about code and design choices is so necessary. However, it doesn't eliminate the raw physics of the trade-off axiom, and anybody who offers you a silver bullet that seems to do that probably has a bottle of snake oil in his/her back pocket. To be an engineer is to intentionally hold our animal instincts (like tribalism) at bay, knowing full well that we can't always do that especially well.