Do you have werewolves in your technology architecture?

What was that eerie, babbling, howling sound? It sounded like a group of people yelling or fighting, but without any words that we could make out.

My wife and I were visiting a wildlife park in the Pyrenees. We were standing in front of the large enclosure that held a pack of wolves. At first, they were hidden amongst the rocks and trees of the mountainside. Then we saw one furry head and a pair of sharp ears, then another, then another. Then the whole pack emerged, about a dozen of them. And they all started howling at once.

But it wasn’t the ‘how-oo-oo-oo’ sound we associate with wolves in films and TV programmes. It was a discordant babble that sounded like overlapping voices. It was strange and disconcerting, even though we knew that we were safe, and could see where the noise was coming from. Later, I learnt that Iberian wolves make this sounds to disorient their prey.

I could imagine hearing this sound back in medieval times, when these mountains were sparsely populated, and help might be far away. It would have been terrifying, and it was easy to see how the legend of the werewolf might have been born: an animal that looks like a wolf but howls with a wordless human voice.

Back then, the forests would have been full of monsters. I expect it has always been the same: the fringes of the human world, the edges of our control, are populated with myths and legends, creatures that loom large in our imagination and often prevent us from straying too far from what is familiar.

We may think that, these days, we have dispelled the monsters. We know that we don’t really live in a world of werewolves and other such beasts, and our technology lets us go wherever we want without fear.

Yet I think that myth and folklore still clings to us: we just give it different names. And we find that myth and folklore everywhere, including in the brightly lit world of enterprise computing and technology architecture.

If you disagree, if you believe that your use of enterprise technology is entirely rational and free of myth, consider your change management process, or your service introduction process, or whatever you call the process that determines how you get a new system into production. If you are particularly lucky, skilled or advanced, this is a fully automated process which applies a comprehensive set of automated tests, gives you objective signals about whether it is safe to deploy - and fails the deployment if it is not.

If you are more typical of an established enterprise then, even if you have such a process, you also have a complex set of manual checks and approvals, change boards and review panels that supplement the automated steps. And, if you ask why all those checks and approvals are necessary, then you will often get answers that sound as if they come from myth and folklore: it has always been done this way; it has been thus since before our time, and who are we to change it?; once, someone failed to perform this ritual, and suffered dire consequences.

Once you notice the accumulation of myth and folklore in your change processes, you may start to spot it all around you. Why are your technical standards set that way? Are they genuinely rational and objective, or do they represent the preferences of a ruler from a bygone age? In particular, what are the things that you consider to be forbidden? Are you allowed to step onto public cloud, or is that considered to be the domain of wolves and other terrors? Are you allowed to use Open Source software, or does that open the door to unknown forces? Why is it that some things are permitted and others are not? Reason or legend?

I exaggerate. But not too much. In theory, enterprise technology is the domain of logic and rational decision making. In practice, those decisions are taken by humans, and humans are subject to cognitive biases, to organisational inertia, and to the perpetuation of myth and folklore.

I believe that one of the key roles of technology architects is to challenge this myth and folklore, to be the people who keep asking why until they find the answer. Architects should be the people who investigate the babble of voices in the forest, find that it is the sound of wolves, and figure out whether they are a genuine threat.

Unfortunately, this is not always the case. Technology architects are usually the guardians of standards, and standards are often the repository of myth and folklore. I know that, when I have filled an architecture role, I have sometimes felt that I was perpetuating standards that I didn’t understand the reasons for, that may have outlived their value. I wish that I could say that I always had the clarity and courage to challenge them, but I am not sure that is true.

Perhaps those of us who profess to be technology architects should make a resolution: that we will only perpetuate those standards (and patterns, and policies and guidance - and all the other things we call rules that we set for ourselves and others) that we can explain clearly to ourselves and others. Where we encounter myths and folklore, we will investigate them and discover the truth - even when we find them within our own existing beliefs.

(Views in this article are my own.)