No Power for Enterprise Architects

Some time ago I have written about The Enterprise Architecture Matrix, where I used a small sequence from the movie Matrix to explain my line of thinking for Enterprise Architecture. This time I use the scene from Lord Of The Ring where Frodo is looking into Galadriels mirror to see the future.But see yourself:



Frodo is the Solution Architect, who is trying to solve a problem at hand and Galadriel is the Enterprise Architect(EA) who provides the Solution Architect (SA) with tools (the mirror) and advice.
 
The Enterprise sleeps, and when the Enterprise Architect explains, only the Solution Architect listens.

EA : "Will you look into the mirror?"
SA : "What will I see?"
EA : "Not even the wisest can say, for the mirror shows many things. Things that are, things that were, and some things that have not yet come to pass."

SA looks into the mirror, and sees Legolas, Merry and Pippin, then Sam. The Shire as it was, then the Shire ravaged, overrun with orcs, and Sam in chains.



Then the Eye appears, and the Task grows heavier, trying to pull itself down into the mirror. SA snatches it away, falls backward onto the ground.

EA : "I know what it is you have seen, for it is also in my mind. It is what will come to pass if you should fail. The Fellowship is breaking. Already it has begun. He will try to take the ring. You know of whom I speak. One by one, it will destroy them all."

SA : 'If you ask it of me, I will give you the One Task.'



EA : "You offer it to me freely. I do not deny that my heart has greatly desired this."
A dark light comes over her as she touches the power of the Task.
EA : "Instead of a Dark Lord, you would have a queen, not dark but beautiful and terrible as the dawn! Tempestuous as the sea, and stronger than the foundations of the earth! All shall love me and despair!"




EA backs away from the Task, ut for a moment, she looks old, and it seems to bring her no joy to have done the right thing.
EA : "I passed the test. I will diminish, and go into the west, and remain Galadriel."




SA : "I cannot do this alone."




EA : "You are a Ringbearer, Frodo. To bear a architecture task is to be alone. This task was appointed to you, and if you do not find a way, no one will."




Frodo : "Then, I know what I must do. It's just I am afraid to do it."
Galadriel : "Even the smallest person can change the course of the future."

I try to allow all ideas to influence my thinking about Enterprise Architecture. Sometimes it works perfect, sometimes not at all, but I truly hope that I try. I personally believe that an Enterprise Architect should stay away from the power and if he decides to take the power stay away from Enterprise Architecture. There is a high risk that an Enterprise Architect with power abuses that to build just another empire no-one needs. Instead of building this empire focus on repair GLUE Diseases and fix the flows in the GLUE Circulatory System.

 

Feedback as always more than welcome.

Power, Process, Project, People - Force One

In my last post I have started a series about Power, Process, Project and People. In this post I like to reflect a bit on power and what I am doing with respect to power in my daily Enterprise Architecture life. Just to repeat the definition from the Oxford Dictionaries: Power is the ability or official capacity to exercise control; authority. There is of course a lot of other definitions or deeper explanations of this concept. As a starter I recommend to read the Manifesto reference-sheet from power and response-ability from Tom Graves. For simplicity reasons I here stick to the very simple above mentioned Oxford Dictionaries definition.

Power is most obviously found in organizations by just looking at the organizational chart. In most cases it is formed like a pyramid with one on the top and some below, which have each some below them again. This can potentially be a very high structure (e.g. CEO > CxO Board > Divisions > Departments > Groups > Employees), even though there is some companies who run a flat hierarchy. In most cases these structures are self defending (GLUE Division Defence). It is very uncommon to see an Employee who has a higher salary than his manager. Also concepts like a technical career path typically only worsen the situation, because now the employees themselves are organized in a pyramid. And it can all be summed up by the concept of Julius Caesar: Divide and Conquer, which I have used to introduce the concept of the GLUE Domains. What I observe most it that it is limiting and framing people into something way smaller than they could be.

The typical advice I hear and read in various Enterprise Architecture Frameworks (e.g. TOGAF 9) is to place Enterprise Architecture in the governance structure close to the CxO level, preferable reporting direct to the CIO (Enterprise IT Architecture) or to the CEO (Enterprise Architecture). There is also the idea to put it below the CMO (?Enterprise Marketing Architecture?). Even though I have seen a lot of value created at that level I also see a fair amount of disconnect to the employee level and Ivory tower behaviour. The balance between strategy, tactics and operational work is not always easy to keep. And if an Enterprise Architect works only in his power structure then the result will be biased towards exactly that structure, heavily influenced and by that imbalanced due to only staying inside the frames given by it.

So what am I doing different? I am actually using the GLUE Domains in the GLUE Space to identify and map the power structures. The amount of GLUE Decks very  much depends on the context. For the blog I use four to explain the concept, but it can easily go way higher (or lower).

Typically these Domains are in conflict with each other with respect to Roles and Responsibilities. For example the responsibility of an Application Owner in the processes of Application Lifecycle Management who owns every aspect of his Application:

And Test Execution, which is typically owned by Test Management. Here two Empires are potentially in conflict.

The (theoretically) simple answer for Enterprise Architecture is now to work close to the decision makers (in this case most likely the CIO) and guide the CIO to take the right decisions. The basic (and I think wrong) assumption behind that is, that the CIO decides and forces it in. Following the basic idea of the power then this is indeed the case and especially and heavy command & control liking environments there is a high likelihood that  this will indeed be forced in, because the managers on those structures want to know everything what their people know. I personally believe that this is in most cases causing more damage than it is repairing, therefore I do work different. (Seth Godin touches this problem in his post destabilizing the bullying power structure.

I do not need only a strong connection to the decision makers, but I do need to be connected also to the lower levels of the organization. Therefore no framework and no formal governance is enabling me to be an enterprise architect, but knowing that I am one helps a lot! So instead of relying on pure power structures I go to the people who have the conflict and challenges at hand, and then I am doing Enterprise Architecture work by helping them to connect to the holistic Enterprise (repairing GLUE Diseases), no matter how deep or high they are on the ladder of power. That of course requires that I have to earn trust first, which is most easily achieved by walking the talking, especially when the advice is beyond the scope of the power structure.

Feedback as always more than welcome.

Power, Process, Project, People

I keep writing about People, because I strongly believe that in the end the only thing which really matters is people, like in the Agile Manifesto: Individuals and Interactions over Processes and Tools.

In the past days I have seen plenty of interesting posts putting various concepts in the focus. One caught my attention and is very much worth to read:

RT @davidsprott: The shape of the next generation EA framework. t.co/dolaKQtb #CIO #ecosystem #services #entarch
— Tom Graves (@tetradian) 18. Februar 2013

This post followed some back and forth twittering and it was a very enjoyable discussion. It triggered some thinking I wanted to reflect already for a while, because every now and then I see an interesting tendency to market something as the one and only way on how to look at the world or solutions, be it IT or non IT.

Coming back to people I want to reflect on three forces especially which I observe every day and what I do to work with them or what I see in the typical Enterprise Architecture approaches. The three forces are (for each one definition from Oxford Dictionaries):

• Power - The ability or official capacity to exercise control; authority.
• Project - An individual or collaborative enterprise that is carefully planned to achieve a particular aim.
• Process - A systematic series of mechanized or chemical operations that are performed in order to produce something. 

The definition of process and project is sometimes confusing if compared, so for simplification I typically differentiate by using project in the context of unique deliveries and process if the deliveries are repeatable. These three forces have a different effect on people, and each and every person has a different opinion what type of force he prefers, but in typical organizations all three forces exist in co-existence and influence each other. The key to all these three powers in the end is the People though and interesting enough they get quite often forgotten.

This is only the first post in a series, otherwise it is getting too long. The next post will be about power. If you have any input to give straight away then I am happy to read or hear from you.