EA Voices

<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>

How many of us can say that we are aware of insurance on a daily basis?  Not many. Of course, we become acutely aware of it when we need it, don’t we? In order to promote a more positive awareness of the insurance industry, an anonymous group (most likely insurance companies) created National Insurance Awareness Day.

At Troux, we’re very aware of the insurance industry. Every day, our solutions help customers such as MetLife, Liberty Mutual and Travelers Insurance make better business decisions. We’re providing them with insights to help them understand how IT can support the goals and strategies set forth by company leaders and change the reputation of the IT department within the organization.  With help from Troux, USAA’s enterprise architecture team has evolved from a technology centric group to one that successfully incorporates business goals into their practice—and they’re talking about it.

As you can imagine, our insurance customers are a pretty risk-averse group. And we love it because we are all about taking the risk out of decision making. When it comes down to it, we ensure that our insurance customers are able to answer critical business questions, reduce risk to business operations and increase satisfaction amongst business partners and internal clients. And we do this by helping them turn EA into an enabler for better decision-making.

Troux customers are even receiving industry recognition for their EA programs.  Northwestern Mutual won a coveted 2012 Enterprise Architecture Award from Forrester and InfoWorld after it successfully changed its organization’s perception of IT by managing technology as a company asset.

We’re proud to partner with insurance providers around the world, including Achmea, Blue Cross Blue Shield of Minnesota, Marsh, Talanx, Farm Bureau Life Insurance Company and Aspen Insurance.  So on this National Insurance Awareness Day don’t just think about revisiting your policies and coverage limits take a moment and give a nod to the great companies that have you covered!

To find out how your company can take the risk out of decision making, click here.