- drEAmtime - Communication
- drEAmtime - Bridging the Silo
- drEAmtime - Capability Cemetery
- drEAmtime - EPIC SCAN
- drEAmtime - Archetypes
- drEAmtime - WISE SCAN
- drEAmtime - PACE SCAN
- drEAmtime - Frameworks
- drEAmtime - modelling
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 patheticI 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 GLUE 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).
Hi Kai,
ReplyDeleteA couple of general comments related to your exploration of Ivo Velitchkov's post drEAmtime . Firstly, I find the topic communication (and information flows) really interesting, please keep up the good work and continue exploring this topic.
Your blogging made me reflect about what I have learned regarding communication and broken information flows. Hence, two independent thoughts were created in my head: 1) simultaneous translation and 2) the Bullwhip Effect.
1) Simultaneous translation would be a powerful method to avoid misunderstanding caused by different mother tongues. By mother tongues I refer to professional languages and abbreviations used by different professions, companies or within a company (Sales, Production, R&D, etc.). Simultaneous translation is most-likely only theoretically possible, although it’s applied in other sectors e.g. Television, the European parliament / European commissions. Based on my experience working with people with different mother tongues conflicts are often caused by the differences in languages. A project dictionary is often developed to help the different parties understand what the other part means, useful but also a reactive approach.
2) From Supply Chain theory we know an issue called the Bullwhip effect. The Bullwhip effect is a result of lack sharing of accurate and relevant (raw) information. The information sent from one participant—down through the chain—to another participant is distorted. Take an example, Participant X sells 2 items to a Customer, but orders 3 items to be able to meet future demand. Participant Y receives the order of 3 items, but is not aware of the actual (Customer) demand is two (2) items. Now Participant Y sends an order to Participant Z, and once again the order is most-likely adjusted, so let’s say Participant Y orders 4 items (the distortion can result in both too optimistic and pessimistic expectations, it depends on the demand history). The interesting is, what would Participant Y do, if he knew the Customer only had bought 2 items? Your guess is as good as mine, but I would say he would order based on the sold items (facts) and not an adjusted number. It’s not directly a broken information flow, but similar information flow issues are often observed inside an organization.