drEAmtime – summary

Link: http://socialea.chickenbrain.de/2013/02/dreamtime-summary.html

This is my final post in a long series of posts where I used the great post from Ivo Velitchkov as a red line to explain my thinking. Following posts did I create so far:

So it is time to summarize the whole series and once again I like to use a quote from Ivo:

In summary, more often than not, when contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it. When trying to bridge the silos, it creates new silos instead. When trying reduce the IT spending, it in fact makes no change or increases them. When trying to deal with complexity, it’s just pathetic

I completely share Ivos line of thinking here. The first observation (“When contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it”) is actually the main reason that started my work on GLUE. I was facing a situation where multiple software supplier and various integrators including a fairly diversified internal IT process structure had to deliver towards 4 releases every year without sharing any common knowledge and understanding, but all of them tried to teach introduce their approaches. So, I have to confess, in my first line of thinking, GLUE was just another stupid approach to create a common language to try to bring them all on the same page.

After working some weeks on the concepts I proudly presented it and was astonished that my brightness (GLUE) was not obvious to everyone. What I faced (and most of the feedback I collected over several years afterwards) was (of course) full misunderstanding. Everyone was all in for the idea of aligning to language to a single common one, as long as it is the one already used to protect the own way of thinking (tribe). So I totally failed and out of frustration I parked GLUE for a couple of years. Looking back the main problem was that I was so full of being right that I did not listen to those I wanted to follow my line of thinking.

Since then I have my changed my focus and live more up to the concept of being a ChickenBrain. I changed the focus from GLUE being the ultimate truth which everyone has to obey towards a pure mapping tool to identify GLUE diseases. Whatever approach or framework in an engineering context I face I immediately map it into GLUE to double check my understanding of the framework at hand (and to ask sense making questions if needed).

Ivos second observation (“When trying to bridge the silos, it creates new silos instead.”) is also something I observed more than once, most inside corporations where the Head of Enterprise Architecture tried to create or defend his very own Empire. That empire (or tribe) thinking is of course typically creating or defending an Enterprise Architecture silo. It can easily go worse if the Architecture Domains are split into several teams which have to argue their existence and easily spend more time on defending their existence than in providing real value. And it typically it does not matter how they are split, as long as they are split roles and responsibilities will be defined and some sort of open or hidden fighting is typically the result.

Ivos third observation (“When trying reduce the IT spending, it in fact makes no change or increases them.”) and fourth observation (“When trying to deal with complexity, it’s just pathetic.”) are connected and has typically many root causes. For example information flow problems or how I name them a GLUE disease, lack of analyzing the To-Be Architecture where the WISE SCAN of the GLUE Division Destination helps and quite often just bad implementations, where the PACE SCAN of the GL UE Division Discovery helps. The various root causes of unneeded complexity can be analyzed with the help of the EPIC SCAN.

I like to thank Ivo for his great inspirational post and I am happy that I finished to follow that red line. Comments and feedback is as always more than welcome (and new inspirational posts as well).