drEAmtime - Frameworks

It looks like as if I am getting closer in finishing my exploration of the great post from Ivo Velitchkov. So far I have created following posts:

1. drEAmtime - Communication
2. drEAmtime - Bridging the Silo
3. drEAmtime - Capability Cemetery
4. drEAmtime - EPIC SCAN
5. drEAmtime - Archetypes
6. drEAmtime - WISE SCAN
7. drEAmtime - PACE SCAN

To quote Ivo once more:

If you are an Enterprise Architect, a popular way to deal with complexity is to arm yourself with a framework. With a good framework, it is believed, you can do two things. First, reduce the variety of the enterprise to just a few things that share the same properties, according to some classification theory and where things doesn’t fit, add more layers of abstraction. And second, reduce the things you can possibly do to just a few but well defined and in a specific order, with well prescribed inputs and outputs, because that was common for so many organisations that did well so that it became a best practice, and the chances are, if you follow this way, it will do you well as well. Now, because of the shared understanding of the beneficial role of the abstract layers, and the boundaryless imagination unconstrained by the reality, there is a serious number of frame-works and on top of them other-works on how to adapt and adopt them.

And once more a lot of truth in it. One of the first things I learned while dealing with complexity actually was that it created panic. Even though it seemed to me quite obvious what the answer is and how to explain it by using an enormous amount of framework knowledge (of course shameless stolen from many) in my explanation I kind of did not really deliver the message. So my current working approach is to remind the audience of one simple short statement of wisdom: "Don't Panic".
I like to use frameworks, but the amount of frameworks is indeed enormous and heavily increasing (and I add one by bringing my GLUE thinking into the game). Pragmatic EA has an overview about frameworks which I personally find very interesting (GLUE is not in that list, because I did not register it so far and obviously no one else did).

So I do exactly what Ivo says: "Reduce the variety of the enterprise to just a few things that share the same properties" and it actually helps me to understand the complexity and trace broken information flows. So I personally find it very useful, but GLUE is of course at this very moment nothing else than an attempt to materialize my very own thinking where there was absolutely no need for any agreements with others. So it is strong for me, but most likely useless for everyone else. If you are interested in applying my thinking please let me know, I will see if I can somehow help you in understanding and applying my thoughts.

With respect to Ivos other statement: "And second, reduce the things you can possibly do to just a few but well defined and in a specific order, with well prescribed inputs and outputs, because that was common for so many organisations that did well so that it became a best practice, and the chances are, if you follow this way, it will do you well as well." I have a different approach. I personally believe that GLUE always happens and is inevitable. So I personally don't focus as a primary task on implementing one (or many if you look at the amount) framework, but instead I primarily look at broken information flows or GLUE diseases.

 

And those diseases I then try to fix, sometimes by proposing (and implementing) a framework, sometimes by inventing something new, sometimes by just talking to the people. It all depends on the context, but I try to guide the energy in the system in a way that it allows to emerge an solution.. It is of course very interesting (but not always relevant) to get hung up in discussion about frameworks or become really religious in applying some technique in one or the other way, but try to avoid that discussion, even though it is sometimes needed to cultivate collisions and by that look for something new (if lucky innovative).