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.