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.



given up on balance

A blog post of Amanda Fenton about balance reminded me about a core concept I use in the space of GLUE and the change introduced via GLUE. In my post Fixing Flows I wrote about the joy of getting something to work and therefore eliminating a GLUE Disease. Maximizing the throughput in the GLUE Space in each and every domain is what I am aiming for and unfortunately the slowest domain decided upon the speed of the whole GLUE Space.

So what is my key to success here? I try to achieve balance (all domains do have almost the same throughput) by giving up on balance myself. Now that seems to be counter intuitive, but it is exactly what I do:

 

To achive balance I give up on balance!

 



The key aspect behind this thinking can be found in my way of tackling complexity:

1. In the simple domain there is no need to give up balance.
2. In the complicated domain there is limited need to give up on balance, but in a very controlled way.
3. In the ambiguous domain there is permanent need to give up on balance, but action can be done one by one.
4. In the Not-Known domain balance does not exist.

I like to use the analogy of walking:

1. Standing on both feet in balance
2. Decide where to go ("automatic" after the initial decision where to go)
3. During the step out-of-balance
4. continue with 1

Therefore to move the Architecture from one state to the other (As-Is -> Transition Architectures -> To-Be Architecture) the whole system gets out of balance all the time, because it is the only way to move. The whole GLUE Division Discovery is completely dedicated to out-of-balance behaviour, so the same flow as walking with GLUE terminology:

1. GLUE Division Defence (As-Is)
2. GLUE Division Destination (To-Be)
3. GLUE Division Discovery (Transition, get to the target)
4. continue with 1

In a perfectly running GLUE the next To-Be is close to automatic (or at least very fast), which translates into a system where the change between balance and non-balance is done so fast and automatic that everything is perfectly in flow. In most cases I find (or throw myself at) systems where the flow is out of balance, but the system stable (and unwilling to change). Here I give up my own balance (entering willingly Not-Known) to create a momentum to change.

And I do not know why, but this flow of events is kind of a Zen feeling for me: things happen unpredictable and real time around, with and due to me while I try to categorize (EPIC SCAN) them, set a direction (WISE SCAN) and support the execution (PACE SCAN). In most cases this require to be very flexible with the methods and tools and therefore I apply most of the time (80%) agile techniques. And here the technical tool I use is a whiteboard and markers.

I am a ChickenBrain

After trying out blogging for a bit more than a month I decided to invest a little time into using my own domain now for the blog. It is still hosted with Google Blogger, but now to be found under http://socialea.chickenbrain.de.

 

"We know nothing at all. All our knowledge is but the knowledge of schoolchildren. The real nature of things we shall never know."

Albert Einstein (1879 - 1955)

 

 

The interesting (for me at least) thing about that domain is, that I found the name ChickenBrain at the age of 17 as a Character name for a Roleplay game (quite some years ago), before I explored the Internet. I quit roleplaying some years ago, but that nick kind of sticked to me. At that age I had a very good teacher for philosophy (looking back my school was really cool to offer that course, at that age I did not recognize the school to be cool). That (wise) man teached us in a good way that we do not know anything, so ChickenBrain became my pattern (and still is my main pattern).

 

I know that I know nothing and therefore I seek for answers (and will hopefully continue seeking for answers). Funny enough in one job interview (with a headhunting consultancy) I was told to not use my primary email adress kai@chickenbrain.de for sending the resume, but shall use something more professional. I was listening to the headhunting clerk and told him that I will not (and hopefully never) will be working for a company who does not value people who openly confess that they know nothing.

 

So, if there is one thing I know, than this is the message:

I am a ChickenBrain

Complexity SCANs in GLUE

In my lasts posts I was exploring complexity and how I tackle the problem of complexity by applying my GLUE thinking to it. Therefore here a short summary so that my thinking about complexity up to now is collected in one place. I am using the SCAN framework of Tom Graves and connect it with GLUE by applying it to the GLUE Divisions and the GLUE Discipline Detect:

In GLUE Detect on Defence the EPIC SCAN is used to analyze the root and severity of the complexity:

• Emergent Complexity - consequence of many small and unrelated decisions and actions.
• Perverse Complexity - consequence of clumsy attempts to reduce complexity.
• Irreducible Complexity - consequence of real complexity of the demand environment.
• Contrived Complexity - consequence of deliberately creation to benefit some stakeholders.

In GLUE Detect on Destination the WISE SCAN is used to analyze the potential and the desired future state:

• Worth - A future capability must be worth the investment.
• Informed - The decision to invest into the future capability must be fact based.
• Simple - The most simple solution must be selected (to minimize future complexity)
• Environment - The solution must be embedded in the greater contex.

In GLUE Detect on Discovery the PACE SCAN is used to analyze the speed of tranformation:

• People - because one person can (and most likely will) make the difference between success and failure.
• Adaption - because the solution must be adapted to serve the people.
• Communication - because communication is key to ensure that the solution serves the people (and is accepted by them).
• Emphatic - because sensing also the unspoken is needed to be able to deliver and help that people and solution form a perfect fit-to-purpose environment.

All of this is needed to optimize the journeys through the GLUE Space and there is one good advice: Don't Panic.

 

PACE SCAN

In my last posts I explored the world of complexity and started with Don't Panic. An advice which does not only work for GLUE and Enterprise Architecture but is generally a fairly good advice. The some ideas collided in my head (which reminds me of the great Steven Johnson and his Where Good Ideas Come From) and I therefore wrote about EPIC SCAN for the GLUE Division Defence and WISE SCAN for the GLUE Division Destination. Both techniques which i use in my GLUE thinking and therefore my daily work for quite a while but which I could not formalize more yet. Tom Graves SCAN framework allowed me to find a way to formalize it a bit more. I had difficulties with WISE SCAN but finally found a way.

So one GLUE Division is missing: Discovery. Here I use the PACE SCAN:

• People - because one person can (and most likely will) make the difference between success and failure.
• Adaption - because the solution must be adapted to serve the people.
• Communication - because communication is key to ensure that the solution serves the people.
• Emphatic - because sensing also the unspoken is needed to be able to deliver and help that people and solution form a perfect fit-to-purpose environment.

And for those who have not figured yet: Besides enjoying working in the space of chaos, because here the really cool new things (and a lot of stupidity) emerge I also love working in the GLUE PACE SCAN to find a way through the chaos.

WISE SCAN - Revised

In my last post I was writing about EPIC SCAN, a combination of two great sources of knowledge including a reflection on how I use it. Emergent, Perverse, Irreducible and Contrived existing Complexity is SCANned for how complex it really is. According to the result (Simple, Complicated, Ambiguous, Non-of-them) a way of working, mindset, skillset is applied in a holistic way to optimize the flows through GLUE.

There is a challenge left, because the EPIC SCAN only works for sensemaking which I place in the GLUE Division Defence. The question is now how to apply the SCAN in the Division Destination. For that I use the WISE SCAN:
  

• Worth - A capability developed in the GLUE Division Destination must be worth to start the transformation in GLUE Division Discovery..
• Informed - Collect information (if not already at hand) so that a decision is as much as possible and needed based on facts. Just Bareley Good Enough from Scott Ambler might be a source of inspiration here.
• Simple - Select the most simple solution which works. KISS from Michael Vizdos might help here.
• Environment - Ensure that a future complexity is embedded in the greater contex.

Feedback as always more than welcome.

EPIC SCAN in GLUE

In my last post Don't Panic i touched upon complexity, a topic which seems to be pretty hot at the moment by looking at various twitter messages and fairly recent blog posts. Richard Veryard has touched the topic in a quite interesting way in his post On The Causes of Business Complexity. What I particular liked in his post was his four causes of complexity:

• Emergent Complexity - consequence of many small and unrelated decisions and actions.
• Perverse Complexity - consequence of clumsy attempts to reduce complexity.
• Contrived Complexity - consequence of deliberately creation to benefit some stakeholders.
• Irreducible Complexity - consequence of real complexity of the demand environment.

 I like to reorder that slightly without really changing the context, because working in complexity is epic.

• Emergent Complexity
• Perverse Complexity
• Irreducible Complexity
• Contrived Complexity

To tackle the EPIC Complexity I can now use the SCAN Framework. and by that create sense, aim for decisions and look for the right skill and mindset. A topic which is also tackled by Shawn Callahan in his post When Should We Collaborate, where he also refers to Cynefin and links a way of working to complexity:

• coordination for Simple Problems
• cooperation for Complicated Problems
• collaboration for Complex Problems
• Any method for Chaos to shift to one of the other three complexity domains

I agree with his judgement of the first three levels of complexity but I am more willing to follow Tom Graves approach in the fourth domain. In his post Sensemaking - Modes And Disciplines he sees working and acting as an Artist (inner value) as the answer to Chaos. In this one I full agree, because I believe the other three working models (and roles in Toms post) will only find unknown areas of their own domain in the unexplored space of Chaos.

So I call that now the EPIC SCAN.

So how do I link this knowledge to GLUE. First of all I look into optimizing or fixing the flows in the GLUE Space. Here applying the right approach to way of working and finding the right skill and mindset is in most cases more important than finding the perfect answer. The people will find the right answer inevitable if their skills and mindset fit to the complexity domain. If the fit is not given then they will try to shift the complexity into another domain or start being frustrated. A typical statement here is: "If X would just understand me".

And unfortunately there is no Silver Bullet to it. Not even Ken Schwaber markets the methodology SCRUM that way. In a recent post he clearly links SCRUM to the complex domain (where the unknown is greater than the known). In spaces where the known is greater than the unknown SCRUM creates more waste than needed and other methods (if applied correctly) will produce results in a less wastefull way. The challenge is to find the right method to maximize Value Add. And for those who are still unsure: the complexity area where I love the Domain Enterprise Architecture most is in the Chaos, no matter where in GLUE.