EA Voices

In part 7 of “Memoirs of an Enterprise Architect” I tested your knowledge on data classification and compliance.  Well, I have good news for this week.  There will not be another quiz so you can just sit back, relax and maybe learn a thing or two…

<h2>I can’t tell you what the box does…</h2><p>In my <a href=”http://www.bizzdesign.com/blog/infrastructure-architecture-function-before-construction/”>previous blog</a>, I outlined <a href=”http://www.bizzdesign.com/blog/infrastructure-architecture-function-before-construction/”>how infrastructure architects are better off focusing on behaviour instead of construction</a>. This, however, immediately leads to a curious problem: most folks in infrastructure are familiar with the offerings of the big vendors (at least up to a point), but very few can accurately describe what the products actually do. It’s typical for technical people: ask them what a product does, and they’ll tell you how it works.</p><p><img alt=”” class=”right” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Infrastructure-Architecture-OIAm-box.jpg” style=”width: 250px; height: 204px; float: right;”/>As a little self-test: what does the engine in your car actually do? Can you accurately describe its function? If you know something of automotive technology, you may find you’re tempted to explain the engine to me as an internal combustion device that burns fuel and thus converts the energy into motion; pistons, cylinders, valves or injection, all that stuff. But “burning fuel” is not actually the goal of having the engine in your car, is it?</p><p>The same applies to infrastructure facilities: if you point to a box, its administrators can tell you how it is connected, how it is configured, and what cool features the vendor has created that they were able to use. But the language the admins use will likely be rife with buzzwords and proprietary terms that the vendor has made up, or has twisted in a <a href=”http://www.authorama.com/through-the-looking-glass-6.html”>Humpty-Dumpty</a> way (“When I use a word, it means just what I choose it to mean – neither more, nor less”). This serves the vendor well, because to retain these proprietary features, the best product to augment or replace his box will almost automatically be another one of his own boxes. But infrastructure architects shouldn’t want to limit their choices this way.</p><h2><br/>… but I can tell you how it works.</h2><p>If we look again at your car’s engine, its function is to <a href=”http://en.wikipedia.org/wiki/Propulsion”>propel</a> the car. Other functions that are performed by different car parts: breaking, steering, signalling, lighting, offer seating, protection against impact, protection against the climate, et cetera. As our culture has had over a century of experience with automobiles, these different functions are easily recognized. (And you therefor probably already gave the proper answer in the previous self-test).</p><p><br/>Now if we look at infrastructure facilities, we find there are many words that describe the construction and its components (router, firewall, CMS, server, hypervisor, database), but we seem to lack the proper functional vocabulary. One could wonder if we could simply put “ing” behind a construction items name  to describe its function. When we try that, we find that “Routing” and “firewalling” seem OK. But “Content Managing”, “serving” and “data basing” are too generic, and “hypervisoring”… well that doesn’t seem to mean anything. And by the way, doesn’t your firewall also do other things, like routing and logging?</p><p><br/>It’s clear we need to look at infrastructure in a different, more fundamental way. At the most basic level, we could say that infrastructure transports, stores, and/or processes a customer’s data. But using a vocabulary of only three verbs won’t get us very far, so we need more specific words to describe infrastructure functionality.</p><h2><br/>The OIAm functional vocabulary</h2><p>Fortunately we don’t have to make up these infrastructure functions from scratch. There’s a community surrounding the Open Infrastructure Architecture method (OIAm), that has been working on this problem of recognizing and naming infrastructure functionality since 2008. This has resulted in a list of some <a href=”http://www.infra-repository.org/oiar/index.php/Building_Block_Type_Overview”>fifty-plus infrastructure functions</a>, ranging from “distribution” (what a router does) and “filtering” (what a firewall does) to “interconnection” (long range network connection), from “Application Engine” to “Identity Validation”, et cetera. Tested in practice, the set of infrastructure function covers just about everything that the infrastructure architects need to describe.</p><p><br/>One thing that remains difficult, however, is how to come to acceptable names for the functions. We’ve found cases where a function was named with a seemingly fitting, industry accepted term, only to find that architectures containing this function were misunderstood by some, precisely because of that familiar term. Examples are Authentication (now named Identity Validation) and “Basic Storage” (now Raw Retention). It turns out that many recognizable terms can be interpreted in many different ways, some narrow in interpretation, others quite sweeping.<br/>On the other hand, if functions are named with seemingly abstract, obscure, or otherwise unknown terms, then some stakeholders may regard the whole architecture built on those functions as a fairly useless academic exercise.</p><p><br/>So in naming generic infrastructure functions, we need to maintain a precarious balance between terms that are too familiar, and terms that are too alien. Have the community succeeded in this? Maybe you can <a href=”http://www.infra-repository.org/oiar/index.php/Building_Block_Type_Overview”>have a look</a> for yourself, and if you think you can help us improve, feel free to <a href=”mailto:j.schoonderbeek@bizzdesign.nl”>drop me a line</a>. And since the vocabulary is published under a Creative Commons license, you are free to use it as you see fit.</p>