Roadmaps are why you should ditch your architects

Summary

Architects that are not with you along the way are of no use. You should not pay too much attention to them, they're not worth the frustration they cause as nothing good will come from it.
But if you find yourself in the company of an architect that is trying to be with you all the way, you should cherish that architect and consider yourself extremely lucky. Not only because your life will be better, but more importantly because this is a very rare breed.

Classification of Architecture Irritation

In case you're interested in finally getting that excuse to get rid of your architects, you're most likely frustrated with them, their architecture and probably you are not able to see any added value of the architect in your organisation. Therefore, I think you'll most likely fit into one of these groups:

• Your architect is too technical and strict, and that the architecture is too restrictive and technical.
• Your architect is just the right person for the job, and a great job he's doing with that just right architecture.
• Your architect is too high-level and vague to be helpful, and that the architecture is too high-level and vague to be useful

And in case you are an architect, you will fit in one of these three categories and your surroundings classify you as either too strict, awesome or just not helpful at all.

Now think about it really carefully... if you're the just right architect or you're dealing with that architect. Since how long do you feel that way? Has it been forever? Well, then this post isn't for you, but continue reading anyway. In case your answer is something like 'just recently' or 'since not so long', then this post is for you because there's a reason why it's been not since forever and it's bound to change in the near future. Well, it'll be very likely you'll going to move to one of the other groups.

The roadmaps are what make architects roadkill

When your architect already is one of those that you can't really consider useful, and is creating architectures that are not really helping you. Or when you're one of those architects. Well, you're in for a treat, because this is a cause of possibly the main frustration within your IT department. Or even within your whole organisation.

Now why is this?

This is because these architects only add time and costs to your projects and nothing else. They too often behave like auditors, telling you what's wrong and not how to fix it. But other than auditors, the architects refer to something they created themselves in the past, using the RTFM reply.
Auditors are a pain in the buns because they point you at how you're not playing by your own rules. Based on what your own definitions of good and bad are and what is and what's not acceptable, they'll verify to what extent you play by those rules. Architects, too often, will work on a reference architecture, architecture principles or even guidelines and that's it. You use their output to work on your own products. And you'll notice that as soon as you start using their stuff, it's either too restrictive (we develop software in either Java or .Net), too outdated (we develop our software based on JavaEE 5) or too vague (we develop our software based on the multi-tier architecture). Whatever it is, it's not helping and as soon as you ask your architect to do a scan of your products, it will be noticed that you're not using Java or .Net but NodeJS instead, that it's based on Java 8 or that it's an architecture based on SOA principles utilising a serverless infrastructure using Amazon Lamda.
So by either abiding the rules written or checking to what extent your compliant, you're loosing time and wasting money.

In many cases this is because people think architecture is a noun, while it is in fact a verb. Let me repeat that;

Architecture is a verb, and definitely not a noun!

So when you document an architecture, you're documenting a living thing. Something that is changing constantly.  So understand that when you come across a document with an architecture, look at the date of the document, because it's a snapshot of what the architecture looked like at that date. Or rather, it's likely to be the case.

But it doesn't end there, architecture isn't just some thing that changes constantly. It's an opinion of somebody who is mandated to be opinionated. What this means is that the architecture is also showing where you want to go as an organisation with your IT landscape. It's the as-is, the to-be and the route to get there. It's like a sat-nav system, it determines based on GPS coordinates where you are on the map, you enter your destination and it will calculate the route to follow to get at your destination based on your location. This is architecture. Well, part of it. The part that's relevant for this post.

That reference to driving and navigation is something I've done before. Read about it here. It's how I explain to my kids what my job is. I see where my client is, I negotiate with him where he would like to be and then come up with a plan how to get there. Including a clear definition of the impact on his situation along the way. Goods and the bads of the trip.
When you look at how many architects work, it's no surprise that they're so frustrating. The analogy with the SatNav is very clear in this;
There're those that will just hand you a (road)map and you just figure it out. See where you are, find where you need to be, plan your trip and go. And oh, btw, the date on the map is likely not very comforting. Or you'll get a turn-by-turn overview of how to get from A to B, based on the outset of when you started to plan your trip. It's based on some possibly old view of the world and any changes to the roads, terrain or otherwise are hopefully taken into consideration. But any traffic jams or other obstructions along the way are not in scope.
And then there's our trusty connected SatNav system. And the analogy holds. Because this thing is connected to the world. It not only keeps track of where you are during the trip itself, but it will keep an eye out to where you will be shortly. That won't be your final destination, but in case there's some roadwork up ahead, it will guide you past it. You'll be informed about relevant information along the way about gas stations and gas prices, hotels, restaurants etc.
The interesting part here is that those that have ever driven with a map, remember the fights between the driver and the person reading the map. Or those near death experiences when you were driving and reading the map yourself. And in case you printed that yahoo page with the turn-by-turn route to wherever you thought you were going to end up, you'll remember that all of a sudden there's a lot of places with the same name, roads are always under construction and the turn-by-turns are always irrelevant after the 5th turn or so.
These are the architects that think architecture is a noun.

The SatNav is constantly with you, and the better the system the more it anticipates on the road ahead, keeping you informed about your surroundings, distance to destination as well as the arrival time. It will keep in mind that weather conditions might be cause to divert your trip or maybe start the AC to make sure that the climate in the car matches the weather outside. This is when architecture is a verb.

Architects that are not with you along the way are of no use. You should not pay too much attention to them, they're not worth the frustration they cause as nothing good will come from it.
But if you find yourself in the company of an architect that is trying to be with you all the way, you should cherish that architect and consider yourself extremely lucky. Not only because your life will be better, but more importantly because this is a very rare breed.

Conclusion

I did already post about project managers and their demise here. Well, it's not a lot better when it comes to architects. Actually it's worse, because these architects, the ditch-able ones, are useless even in waterfall projects, but more so in agile projects, I give you that.
But where you can still find some use for most of the architects in waterfall projects, because as you know, these projects consider documentation as a key deliverable and are run under the premise that after creating the documentation for the next 12 to 24 months they don't need to change. In Agile projects this is different and this is why many scrum teams have said their goodby's to architects and even organisations have stated that architects are no longer need. And yes, this is the best thing that could have happened to our profession as IT architects. It's a matter of weeding out the turn-by-turn style and map style architects.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link to my blog to all your Whatsapp friends and everybody in your contactlist.
But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Iwan