Embrace Emergent Complexity or Hail the Hairball Architecture

In the last days a great blog post of Gerben Wierda was brought via various channels to my attention which contains a very good video about Enterprise (IT) Architecture:


I do not want to add much to the tribal war between Enterprise Architecture and Enterprise IT Architecture here, because I believe knowing that you are an Enterprise Architect allows you to be one, no matter of the organizational setup, but what I like to look at is the beauty of the Hairball Architecture.

The Hairball Architecture is the consequence of many small and unrelated decisions and actions, or in the terminology of the EPIC SCAN Hairball Architecture is a reflection of emergent complexity. The video touches this topic in a nice way promoting the idea of Enterprise (IT) Architecture as a complexity reduction approach. I believe that this is a valid utilization of Enterprise Architecture, but it does not utilize the beauty of the Hairball Architecture. Instead it prevents emergent complexity by connecting a decision to the greater context.

A standard approach is to utilize standards as much as possible and by that shifting the complexity problem more towards the linear solvable space.  Even though there is a lot of beauty in solving problems that way it is quite often short jumping and it does for sure not use the beauty of the Hairball Architecture, but it does use the beauty of standards, best (or good) practices and by that easy access to skilled (at least in that context) people.

As I have pointed out in GLUE Disease I am looking for broken flows of information in the GLUE Space and try to fix them. A Hairball Architecture based on Emergent Complexity is typical a signal that the various decisions have not been brought into greater context (higher deck). Therefore the answer to utilize Enterprise IT Architecture, standards and best practices is a valid one. This is usually achieved by comparing As-Is Hairball Architecture with To-Be Best Practice Architecture and by creating the needed migration projects from As-Is to To-Be. To repeat the message again, this is not utilizing the beauty of the Hairball Architecture, but is at least fixing the circulatory system:

 

Another more interesting answer is true utilization of the emergent complexity by allowing the emergent complexity in the Hairball Architecture to conflict in a structured way. The various ideas implemented in the solutions will most likely collide and by that creating new ideas which did not exist before the conflict and the attempt to find answers. I compare this also with an abiogenesis. There is a pretty good chance to find true innovation in Hairball Architecture and Emergent Complexity but it is a very hard job to find the jewels in all the complexity. And to my knowledge till now it requires an artist approach to Enterprise Architecture more than any other skill set.

Social EA Logo

It is time to brand my blog Social Enterprise Architecture a little. Therefore I have created a small and simple logo (with huge help of my wife who is way better in logo work than I am). From now on I will use this logo also as the favicon.

That actually reminds me that I also have to create a logo for GLUE. A lot of things on my backlog for this blog and my ideas around social enterprise architecture. I hope I get it delivered step-by-step next to all the other activities I have to do.

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?

Don't Think You Are, Know You Are!

Today Tom Graves has neatly described Two Enterprise Architectures and by that explored the difference between Enterprise IT Architecture and Enterprise Architecture. I have touched that topic shortly in my post about Real Enterprise Architecture. I am using my standard example here with following Decks:

Based on those Decks in the 3-dimensional representation Architecture is covered by the GLUE Discipline Design. Enterprise IT Architecture covers all EITA Activities and Deliveries in the context of IT:

While Enterprise Architecture must include Enterprise IT Architecture, but shall not be limited to it, because Enterprise Architects have to look at everything in a holistic way not biased towards anything.

Reality of course is often different and therefore difficult. Enterprise report in most cases direct (or via management structures) to the CIO or CTO. On top of that there is the demand of typical Enterprise IT Architects to be seen as holistic Enterprise Architects spanning the whole Enterprise. And that is a difficult concept for the audience to understand, because of the reporting structure.

What I do not understand though is: What are Enterprise Architects waiting for? If you are hired as Enterprise IT Architect and have something to add to the whole Enterprise Architecture, why don't you just provide it then? Use hte EITA recruiting as the entry to provide the true value. So far I am still waiting for a company to turn that knowledge down. It is usually unexpected, but nevertheless pretty much needed, and therefore also very willingly accepted and used. Asking for governance or an official mandate is calling for trouble if you ask me, because in typical organisations there is no real place for real holistic Enterprise Architects.

The closest could be reporting to the CEO, but everyone is seeking for a position close to CEO. So what is the unified selling proposition Enterprise Architects can make to the CEO compared to all the others who want air time? So any other C-Level reporting structure will normally have to do the trick. That will lead to a somewhat biased situation (the C-Level to report to is the one who drives the potential on how to use and evolve the role).

But if we truly believe in Enterprise Architecture to be a fully holistic non biased function (difficult concept at the moment in time when human beings are involved) then why not just give it a try? Just offer that holistic service to the audience at hand. Provide the knowledge and utilize the existing structures as much as needed, but apply the concepts of the Enterprise Architecture Matrix. And the most important one is, if you believe in being a holistic Enterprise Architect:

Don't think you are, know you are!

Guide the Energy

As I have written in my last post Less is More reducing complexity to the absolute needed minimum is key to not add unneeded clutter and blurriness. I also touched shortly on the energy created if two (or more) ideas compete for the limited attention available. In my post GLUE Disease I wrote about diseases which cause unbalanced system and that is unhealthy and potentially very risky for the whole GLUE Circulatory System.

To explain the mechanics here I use the concept of the GLUE Divisions:

• Destination to set the target
• Discovery to do the transition
• Defence to protect the existing

As I have put in my post Given Up On Balance I kind of feel in balance when I give up the balance. I have not found better words for this yet, so if you have some bring them forward to allow me to learn (and find a better balance). When I find competing ideas I look closely at them. In many cases it is somehow related to (the lack of clear) ownership (a topic which I want to touch soon as well) and the derived complexity.

• If the system tips towards defence nothing moves, the whole become rock solid or frozen like ice, which prevents any improvement or complexity reduction.
• If the system tips towards destination the whole adds complexity (emergent complexity).
• If the system tips towards discovery reinventions of the system occurs either without the needed input (destination) or the capability to adapt (defence). That can spawn any kind of complexity and behaves quite random (Not-Known Domain in Tom Graves' SCAN framework)

So how do I imbalance:

• In a frozen system I try to add energy by planting several small ideas like written so great in the post of Harold Jarche about Trojan Mice. Small little ideas and changes which create a small but significant imbalance in the system potentially leading to massive tension and friction. As written in the Trojan Mice post the ideas and their result has to be watched closely and if in doubt removed, because they can grow massive and by that create severe impact.
• In a high energy system (destination) I try to remove energy by bridging between the conflicting parties. In most cases the commonalities are larger than seen (hoped for) by the disputants. The destination conflict though is the most interesting to watch for a fairly long time to see where it goes. It can be like tectonic plates which create volcanic eruptions who are very destructive. That energy might be needed though to break up the power of defence. Furthermore it has the potential to create something truly new. Guiding this energy is one of the most important challenges for Enterprise Architecture to be successful.
• In a system which is constantly trying to adapt without input or capabilities to adapt the mission is twofold. Creating tension and friction (to a certain degree) to find the next (volcanic) eruption which does feed the system with the needed ideas. But the key aspect is to guide the energy, bring people together, help them understand each other and translate between the (potential already engaged in tribal wars) involved. Diplomatic skills are fairly important here and being able to handle and maneuver in the Not-Known space.

As I have put in my post the Enterprise Architecture Matrix: Stop trying to solve it, but start solving it.

Less Is More

In my last post I have written about the concept to compare Enterprise Architecture with the Matrix. In short: free your mind and open up for all the possibilities. There is no reason to stay inside the boundaries provided by the various frameworks and models. They are helping, but not the answer. The real change happens by working with the people and there is the place where the real Enterprise Architecture is happening. With and through the people.

Today I have read an interesting post of Tom Graves where he brought Ric Philipps and his definition of Enterprise Architecture being an antipattern to my awareness. The result is that I follow (just another) Enterprise Architect, which is great. The concept in that particular post is interesting, because Enterprise Architecture adds another level of complexity which might easily outweight its benefit. I personally see Enterprise Architecture (as any other form of Architecture) as waste.


There is a particular element I really like about Ric Philipps' post. And that is the underlying principle minimalism. Ludwig Mies van der Rohe has used that principle greatly (very subjective) for his approach to architecture. By reducing the definitions (frameworks, models, you name it) to the absolute minimum the Observer Effect is minimized as well. Highly complex models (amount of definitions and relationships) have indeed based on my own observation a high tendency to disturb and create more noise than sense. (e.g. the discussion about UML extend and include, or the various complexity models).


If you ask me the model of the world could be flat, like in discworld (despite the turtle and the elephants, that is not needed to explain it). It does work for my daily life. And even though I know that the world is a globe my senses tell me something different, because they are more sharp on experience which is directly connected to my physical experience, and almost all things I need work for that model. (Actually a map is nothing else than a 2-dimensional model of the world). But of course I am not very religious on that 2D model, most likely because I just use it and did not invent it. On GLUE i might think different, the future will tell.

Nevertheless the boxing and framing is also very useful, as Seth Godin has put it so great in his post "I want to put you in a category". The interesting thing for me is not only the boxing itself, or being trapped in the Overconfidence Effect, but especially the friction and tension created by two (or more) tribes defending their own believe and thinking (almost) to death. Of course there is a short term negative effect (and there was some very destructive examples of that in the past), but all that energy usually also creates something new, something which has not existed before. So it is very interesting to observe the heavy (and very emotional) discussion in the complexity models around Enterprise Architecture at the moment. Even though there is a lot of bad feelings on all sides I personally believe that all this negative energy has a good chance to create something new which the world has not seen before.

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.