Being an enterprise architect I am not insensitive to the skyward gazes that project managers or developers make when being “assigned” an architect. The architect is frequently perceived as living in an ivory tower of abstraction in perfect disjunction from the real world. At best he is a distraction, at worst a liability
The architect frequently lives in a completely idealized world and he is tasked with implementing these ideals. However often this fails precisely because the ideals rarely conform to the reality. The architect fails to appreciate, what in military parlance is sometimes referred to as “the facts on the ground”. He is too often the desktop general.
Symptoms of an idealist regime is
- There is a guideline for that
- Templates for any occasion
- We have it documented in our Enterprise Architecture tool, any other questions?
- More than 3% of the IT organization are Architects
- CMMi level 5 is viewed as the minimum requirement for doing any kind of serious work
Now consider the architect’s counterparts: project managers, developers or sys admins that just want to get the job done in a predictable way. These guys live “the facts on the ground”. They know all the peculiarities of the environment or system being worked on.
Symptoms of a pragmatist regime is the following
- If something breaks we fix it and get back to our coffee break
- Upgrade what is already in place when it runs out of support (urgency promotes action)
- Enhance existing functionality, it already works
- New technology is like the flu, it will pass, no need to get it
- A big pot of Status Quo (not the band) with a dash of Not-invented-here
The pragmatist will never really fundamentally transform the situation because he always wanders from compromise to compromise. He is wandering from battle to battle. Now this will rarely win the war.
It seems that we are left between a rock and a hard place. One, the idealist, will never move anything but has the sense of direction. The other, the pragmatist, will move plenty but has no sense of direction so it will mainly be in circles. Let us turn our attention to a possible way out of this conundrum. The answer is a philosophical stance first attributed to John Dewey at the start of the previous century: Pragmatic Idealism. Well, duh. Was that obvious?
It is just as obvious as it is rare in my experience. Pragmatic Idealism is a term often used in international policy, but is enterprise architecture not often similar to just that? It posits that it is imperative to implement ideals of virtue (think perfect TOGAF governance and templates for any and all possible architectural artifact), but also that it is wrong not to discard these ideals and compromise at times in the name of expediency.
What does this mean in practice? Here are a number of principles to help you live by the ideals of pragmatic idealism (if that makes sense)
Have ideals and communicate them frequently. If we become too pragmatic we lose the purpose of being an architect. We have to remember that the direction has to be set by us and we need everyone to know about it. Even if it is not immediately clear how we will get there. We need to provide input on whether we should go all in on open source or whether Microsoft is a preferred vendor. Here one caveat is that we have to be very sure about the ideal, because if we first have started to communicate it there is no way back. You will lose all credibility as a visionary if you stand up one day and say open source is the way forward and the next you sign an enterprise license agreement with Oracle.
This means that you have to bring a very good knowledge of where your organization is and where it wants to go. Without a solid understanding of both, you are better off playing it safe and going with the flow. That said it should quickly be possible to pick up one or two key ideals.
Ideals are ideally expressed as architecture principles. I often use TOGAFs formula of Name, Statement, Rationale and Implications:
- Name – Should be easy to remember and represent the essence of the rule
- Statement – Should clearly and precisely state the rule. It should also be non trivial (“don’t be evil” does not pass the test)
- Rationale – Provides a reason for the rule and highlights the benefits of it
- Implications – Spells out the real world consequences of this
The first thing you should do then is to flesh out these ideals and create a process through which you can create buy in to them. Chances are that the organization already has some that you can work from, but make sure that they also align with what you feel they should be going forward.
Oh, and also, don’t have too many ideals, that is, don’t have too many principles. We are shooting for something around the “magical number 7 plus or minus 2” as the title of George Miller’s groundbreaking article had it. In this article Miller demonstrated that the number of different items of information optimal for being remembered was 7 plus or minus 2. While later research has shown that it is probably even lower, this is still a good rule of thumb. Ideally you would want to be able to remember it your self but, more importantly, you want everyone else to remember your principles as well.
Approach every problem with the minimum amount of energy and structure necessary
Say what? Now is he advertising laziness or what? Not quite, there is actually hard science behind this. We know from the second law of thermo dynamics that disorder is the only thing in the universe that comes for free and automatically. Conversely order requires energy. Any person or organization only has a limited amount of energy. What this means is that the net effect of your architecture endeavors will be maximized with the minimum amount of order necessary. Consequently the more thoughtfully you can use that energy the more effective you will be.
In practical terms this means that you should not develop 25 item templates for 9 different types of meeting minutes if you are the sole architect in a 9 man start up. You are clearly spending too much energy. It may be your ideal to have a template for every purpose but maybe it can wait until the purpose actually arises. Similarly you should not do all your architectural documentation in your code if you are building an application with 100 million lines of code. Even if you your ideal is Lightweight Architecture Decision Records as Thoughtworks advocates as the highest ideal.
Every problem is different. The architectural skill you have to develop is to find out how important it is. The more important a problem is the more structure and energy it deserves. This is why documentation is higher in regulated industries like pharma and banking; it is simply a necessity to stay in business.
There are different ways to gauge importance. First of all, if something is recurring frequently, chances are that it is important. At least from the perspective of efficiency it is worthwhile to bring structure to frequently recurring events. This is why many people took the time to structure an email signature with their name and phone number. That way they do not have to write it every time someone needs it.
Secondly, important stuff is tied to the business model. If you are in banking, data management, access control and auditing is important. In this case you might want to bring as much structure and predictability to that as possible.
Make every compromise count. You have to make sure that the ideals you are following are known and that every compromise you make is registered as such by the people on the ground. If no one knows the direction, then we are just back to basic pragmatism where everything is just another step in a random direction. You have to make sure that every compromise somehow leads to a larger goal.
If you want to move to a cloud first strategy and a given project has reservations about the cloud and wants to implement the solution on a local VM. Don’t just say ok, even if you think it is ok for this project. Make sure that you make clear what the advantages are and agree on non-trivial reasons why this particular project does not have to go to Azure or AWS. Sometimes a compromise can also be used as leverage for other architectural decisions, since people know you are there to implement ideals. This can even work doubly to your advantage in that you are seen to be pragmatic and possible to work with and they will feel like they owe you, or at least be on friendly terms. But beware, because it may just as well be perceived as weakness if there isn’t a good reason for the compromise.
The path forward
The world is divided into idealists in ivory towers watching and shouting and pragmatists scurrying about in their trenches as rats in mazes, but only the pragmatic idealists can effect real change towards the better. If we lean toward one we should try to be aware of the merits of the other. I have given a couple of principles I have found helpful: Have ideals and communicate them, approach every problem with the minimum amount of energy and structure and make every compromise count. There are many more ways to affect change since it all starts with having a pragmatic idealist spirit.
Danish 
English