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.

Enterprise Architecture Asset Failure and Flow

I have read an interesting Blog Post from Paul Wallis about Asset failure and flow wich focusses on the physical elements. I really enjoyed reading the post and I can only encourage you to also read it with care. It furthermore triggered me to think and write again about the flow of events through an Enterprise. I will pick up quotes from the mentioned blog post and reflect on them by creating a collision of ideas to my social EA thinking.
 

When key flows – water, electricity, natural gas or sewage – are interrupted in an urban area, our lives become very difficult, very quickly. Interruptions to these critical flows will often cause knock-on interruptions to dependent secondary flows, impacting things like flows of people, flows of vehicles, or flows of goods through supply chains. Flows of data are no less vulnerable to interruption caused by unexpected interactions with other types of flow.

As I have written in GLUE Disease one of my main approaches is to look at the key flow (of knowledge) and especially into dysfunctions of that flow. If I find a dysfunctions I try to optimize the flow of knowledge direct or indirect depending on the given situation. If I am successful the achieved better flow of knowledge through the Enterprise will lead to better decisions.
 
 

 

But in today’s digital world, risk lies not only in the failure of IT assets that directly enable data to flow, but also in the failure of other less obvious business assets: a leaky door, a de-pressurised cable, a failed valve or a broken pump.

 
As I have written in People in GLUE what really matters are the people. They make the difference and they in the end form the real flow of events. Processes and Methods do help, but what really makes the difference are the people.
 

 
If the people fail there is no process and method available (at least for EA not) to secure the success and an optimal information flow. Therefore I personally focus on the people first. Of course there is a certain amount of processes and methods needed (to help the people working better), but as written in the agile manifesto:  Individuals and interactions over processes and tools. Of all the assets available, people are the biggest and therefore should be threated according to that.

Cultivate Collisions

A couple of days ago a tweet flew by which deserved closer attention:

Questions to ask about any method or approach: Who invented it? What problem one tried to solve? Do I have that problem?

In the interaction with the author it became (once again) obvious that I have a different approach to look at methods and tools than just looking at for what specific problem space it was created. Steven Johnson has put this in a great way in his speech Where Good Ideas Come From. The immediate question I ask myself is:

Can I use this for any problem I face at the moment?

I try to cultivate collisions. I try to see behind the core idea and why it was created. Even though there is a lot of value in understanding why and how a method was created I personally believe there is one flaw in understanding the thoughts of others: it constrains the creation of new ideas.

"Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who read too much and uses his own brain too little falls into lazy habits of thinking.",

Albert Einstein (1879 - 1955)

So learning from others is key for me to understand and learn, but also to develop new ideas. And I am not only trying to learn from other Enterprise Architects, but I try to learn from everything what I experience. And then I try to create and add that new piece of puzzle based on that experience. It is a journey, and honestly it is a tough one, but not panicking helps me here.

I will label all posts in which I try to with collision, and there is already one example on this blog: The Enterprise Architecture Matrix. Cultivate collisions and embrace the change coming through that collisions. What are you waiting for?

The Enterprise Architecture Matrix

In my last post I have tried to express that I have given up on balance and I like it pretty much to be out of balance. It is kind of balance for me to be out of balance. No idea why, no idea where that leads to, no idea how long it lasts, but I accept the fact that I like it and that it gives me this perfect moment of being once with the flow. The flow I try to optimize with my daily work and which I tried to describe (fairly weak description so far) in my posts about GLUE Disease and Fixing Flows:

In this post I try to describe the way I approach Enterprise Architecture with my GLUE thinking in a different way. For that I will use a sequence from the movie Matrix and translate it into a dialogue between a Real Enterprise Architect and a Wannabe Enterprise Architect. For simplicity I use Wannabe and Real to point out who is speaking.

Wannabe: I know Enterprise Architecture.
Real: Show me.
Real: This is an Enterprise Architecture Activity. It follows the same basic rules than the Enterprise, rules like governance. What you must learn is that these rules are no different that the rules of a framework. Some of them can be bent. Others can be broken. Understand? Then solve it, if you can.

[Wannabe tries to solve the problem]

Senior: Good. Adaptation, improvisation. But your weakness is not your technique.Project Manager: The Junior tries to solve an Enterprise Architecture problem.

Real: How did I solve it?
Wannabe: Your knowing more than I do.
Real: Do you believe that my being more experieced or knowing more has anything to do with my Enterprise Architecture framework technique in this place? You think that's air you're breathing now? Hah. Again.
[Wannabe really tries to solve it]
Project Manager: Jesus Christ, he's fast. Take a look at his neural kinetics, they're way above normal.
[Wannabe is close to solving it]
Real: What are you waiting for? You're faster than this. Don't think you are, know you are. Come on. Stop trying to solve and start solving it.

Project Manager: I don't believe it.

Wannabe: I know what you're trying to do.
Real: I'm trying to free your mind, Wannabe, but I can only show you the door, you're the one that has to walk through it. You have to let it all go, Wannabe, fear, doubt, and disbelief. Free your mind.

I truly hope that Enterprise Architects are waking up and walking through that door. The more the better. If you ask me then there is more to solve out there than we are ever able to sort, so if possible free your mind and enter the real Enterprise Architects leaving all the rules and boundaries behind you, but use them where reasonable.