Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
“If you don’t know where you’re going, you’ll probably end up somewhere else”. This is a powerful statement, because in a few words it paints a mental picture of the combination of a trip and a lack of knowledge, and then foreshadows a future that appears too uncertain to be desirable. There are several books of this title, for self-realization, parenting, career help… But I haven’t been able to find a reference to infrastructure architecture. Yet. But do infrastructure architects know where they’re going?
It seems to me that most architects, when confronted with the assignment to create an architecture for an infrastructure facility, take one of two routes:
they create a more or less detailed outline of the final construction of the facility, usually without any reference to how they got to that particular construction;
or they forego any reference to the actual infrastructure world altogether, instead limiting their architecture to lists of principles, visions, cartoons, or other less-than-substantial contributions.
As I originate from the world of servers , networks and other tangible pieces of infrastructure (professionally, not biologically), I felt most comfortable with the first route – until I encountered infrastructure facilities that were simply too vast and complicated to meaningful map them with conventional network diagrams, IP tables and server listings. Fortunately, by that time I was already involved in an initiative that aims to rescue the infrastructure architecture from that particular morass – the initiative now known as OIAm, the Open Infrastructure Architecture method.
A better way…
The OIAm developers took a long hard look at infrastructure, attempted to reduce it to what really matters at an architecture level, and then put the focus on the infrastructure behaviour, in the process stripping almost all construction details from the architecture models. This works excellently, as the aspect that makes infrastructure useful to the organization is not its endless range of configuration parameters, topographies, devices, software and firmware versions, IP number plans et cetera – regardless how proud engineers and designers are of their great efforts in this area. Infrastructure architecture is useful because of the service it delivers its consumers; the functionality it provides. In other words: infrastructure is useful to the organization because of what it does, not how it does it.
The OIAm developers set out to create a vocabulary for functionality that described the behaviour that the infrastructure performed for its clients. It turns out that such a vocabulary needn’t be particularly bulky: with some sixty functions, one can describe most (if not all) infrastructure facilities. Now couple this vocabulary with a powerful grammar such as ArchiMate 2.0, and we’re capable of telling compelling “stories” about infrastructure. It’s remarkably easy to dress up these stories with (infrastructure specific) quality attributes – although that’s a topic on its own, that deserves a separate blog. Likewise, attaching guidelines and prescriptions in the form of (architecture) requirements is simple once the “how” has been modelled – again, a topic worthy of its own blog. But the resulting stories are very accessible. relatively easy to understand and convey, and still powerful enough to reveal all issues that the infrastructure architect is supposed to tackle.
First the “what”, then the “how”!
By now we have arrived at the main point of this blog: once you can describe the “what” of your infrastructure with sufficient detail, thinking about the “how” becomes much easier. That’s why I’d like to propose a third route to come to infrastructure architecture:
create a functional model of the infrastructure, adorned with relevant quality requirements and architecture requirements, and leave the construction details in the capable hands of the infrastructure designers.
Taking this approach effectively lets you determine where you are going with your infrastructure landscape. And if you can identify your destination with sufficient accuracy, it’s much easier to check and adjust your course under way. Furthermore, stakeholders are easier to involve if they get to talk about an easy to understand functional destination, not the nitty-gritty complex details of some constructional journey. So isn’t it about time you took control of your infrastructure destination?
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: