Ever tried explaining architecture to a layman? How did you do it? Did you, at some point, refer to the original field of architecture – the one associated with names like Gaudí, Koolhaas and Hundertwasser? Maybe the layman brought it up himself? Did it help the discussion?
Probably it did, actually. While IT and Business architecture isn’t really the same, the original field of architecture works well as a metaphor. It’s such a natural comparison that it doesn’t feel as a metaphor. Plus, it fits kinda neatly – as long as you don’t look too close. And that’s exactly where the metaphor loses its value, both because the layman’s knowledge of brick-and-mortar architecture proves inadequate and because, in the end, the fields are just not the same.
Still, metaphors have value in communicating different aspects of architecture. So I’d like to explore different perspectives on architecture using different metaphors, starting with: navigation!
‘Turn left after the next project, onto new middleware street’
Most of us know what a navigation system is, right? Disregarding the humorous mistakes these things can sometimes cause, they can make our lives a lot easier. Just type in your destination, your preferred type of route, and it will calculate a route for you. Easy as pie, isn’t it?
Well, no not really. There’s a lot going on below the surface which needs to be arranged for a navigation system to function properly. Think about it:
1) How would you like to travel? Shortest distance? Fastest route? Avoiding highways? By pre-set waypoints? Only traveling outside rush hours? There are so many options, all of which affect how ‘good’ a certain route is.
2) The environment isn’t static, but dynamic. Traffic jams grow or dissolve, road work temporarily closes down stretches of road, or 50.000 football fans celebrating their team’s first championship ever bring your progress to a standstill. So, you need to be in touch with the world – to be connected – and to constantly recalculate your route.
3) How do you know you’ve arrived at your destionation? The system will need both a ‘test’ – co-ordinates – and a ‘method’ - GPS – to determine whether or not you’ve reached your destionation.
4) Last but not least, there’s you! Because even if the system gives you a perfect route, with perfect driving instructions, it does not drive the car. That´s what you are for – the driver. And you can choose to do whatever you want, including completely ignoring the instructions and taking a different route.
Comparison to architecture
So, what does this comparison show us about architecture and the process by which it is implemented? Your destination is your business strategy – it’s where your company wants to be. The actual architecture are the co-ordinates, or the manner in which you can test if you have arrived at the destination. The route are the changes you make to your company. It could be implementing new middleware, changing process owners and service-enabling existing applications. I’ll leave the interesting question of who the driver is in this metaphor for later. Let’s first look at those 4 aspects:
1) The preferred route. The same thing exists in IT architecture. Do you want to use current personnel and expertise? Would you prefer to sit out your system lifecycles before updating them? Do culture changes preceed or follow technology changes? Questions that impact not only the timing, but also the architecture itself!
2) The connection. This is so very crucial! An architecture team needs to know what’s going on. Where do projects stall (traffic jams), what projects are going on that should work under architecture (road work), what stakeholders are likely to resist the architecture (the fans blocking the highway), all of that influences the route while driving it.
3) The destination. As said, the business strategy is your destination. The architecture itself, with all of its principles, guidelines and models, is how you test whether or not the company – or rather, its operations – is ‘there’. Far more complicated than in navigation, indeed.
4) The driver. Someone drives the car. That someone can’t be the architect – he’s the algorithm, the heart of the navigation system. So who is? Well, looking at the metaphor, shouldn’t the driver be the one who actually wants to be at the new destination? And, thus, a representative of the organization, such as a board of directors or a ‘business board’ or something?
But most importantly: the car isn’t being controlled by the navigation system, but by the driver. This holds true for architecture as well: the architect isn’t driving the organization, but the business representative is. They have to choose, they are in control of the route.
So, what can we learn from this metaphor? A quick summary…
- An organization will have to do the driving themselves. For which they should be happy.
- You can deviate from a route. A good architect will lead you from your new position to your destionation. Just give him/her time.
- Of course, if they want to do that, architects have to know what’s going on, or they can’t adjust the route to the current conditions. So keep them in the loop.
Any more lessons (or metaphors) that are worthwhile? Please comment!Share and Enjoy: