The infrastructure architect versus the other architects
As I was asked to speak at the Enterprise Architecture forum in London, I got to think about what I could tell the other people attending the forum about the work of us infrastructure architects. I realized that while the infrastructure architect has an important yet subservient job to play in the enterprise architecture team, the other architects may not always realize this; or if they do, they might not always know how to make good use of the infrastructure architects services.
So what exactly is the infrastructure architects role in the architecture team? Since architects are to translate vision into architecture (which should be considered overarching design), this surely implicates that infrastructure architects create overarching infrastructure design. That must mean that the other architects can simply discuss with their infrastructure colleagues what they require from the infrastructure, and then they get what they need, right? Well, not quite. Because more often than not, the work performed by the infrastructure architect is not very accessible to people outside the infrastructure field.
Infrastructure and the gap with the rest of the world
The infrastructure field itself is quite inaccessible for outsiders, as its dominated by intricate and complex technology, as well as a plethora of products from specialized vendors. Furthermore, the people working in this field have a penchant for thinking in solutions and constructions, while continuously considering all those technical and technological intricacies. For people outside the field, this makes it quite hard to have a constructive conversation with the infrastructure people, because they dont speak the lingo of bits & bytes, protocols and ports, threads and heaps.
However, infrastructure itself is indispensable as the foundation of a modern IT landscape, and therefore it is indispensable for todays enterprise as a whole. What application does NOT make use of infrastructure such as the network and the security devices guarding it? What data is NOT stored on centralized storage facilities, be it in databases or files? And then there are even more facilities operating behind the scenes that make it possible for the people in the enterprise to do their jobs: identity stores, portal services, the workspace itself, and the facilities that provide access to the new generation of workspace devices such as smartphones and tablets.
This means infrastructure has great relevance to the organization, making it all the more important that the organization conducts clear and effective discussions with the infrastructure department when infrastructure is to be created or changed. So if theres a gap between the infrastructure architects and the people that are supposed to make good use of his services: what can be done to bridge this gap?
Let your infrastructure architect help you on your terms
Ive blogged before on the virtues of working with infrastructure functionality instead of its construction. I would in this blog like to point out that the advantages of this approach stretch beyond the infrastructure architects themselves: the approach also serves the other enterprise architects quite well (maybe even more so than the infrastructure architect!). Once the infrastructure architect starts formulating the infrastructure architecture as a set of services with a clear, unambiguous and non-technical set of functionalities and qualities, it is much easier for colleagues, such as application architects, to assess and discuss the available and planned facilities, allowing for a much clearer and better fit between application and infrastructure, and promoting an increase in the sharing or reusing of existing infrastructure facilities. Being able to do more with less, which organization wouldnt want that!
So Id like to plea for using infrastructure functionality as the key to mutual understanding between infrastructure architects and the other enterprise architects. You dont really need to be an infrastructure architect to be able to understand the basic functions that infrastructure facilities perform. And once the (often complex) construction details are removed from the conversation, it should be much easier to have meaningful discussions on the choices available, and the impact each choice brings. Sure, as a non-infrastructure architect you may still need a little studying or guidance to learn to use this functional vocabulary. But the improved quality and effectiveness of your consultations with your infrastructure architecture colleagues will be well worth it.
Of course this plea presupposes that the infrastructure architects of your organization use a method for conducting functional architecture, such as the Open Infrastructure Architecture method. Should this not yet be the case, then you are more than welcome to contact me or my colleagues at BiZZdesign to help you implement it.
If youre interested to learn more on this topic, come visit me at the Enterprise Architecture forum in London on September 19th 2013!