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).

drEAmtime - PACE SCAN

I continue to explore the red line laid out by 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

Ivo has now fixed some typos in his post to cleanup. I decided (for the moment) to keep my posts as they are, at least as long as the flow goes.

To quote Ivo 

The part related to complexity certainly deserves a separate post and may be more than one. As this one got pretty long already, for my standards that is, let me just finish with the following: dealing with complexity is not reduced to finding ways to reduce it. It requires much different understanding of what happens when interactions are not linear. When there is dynamics, adaptation, self-organisation, irrational behaviour, politics and power.
 

Here Ivo touches the concept of transorming from As-Is to To-Be. Here he doesn't rant, but points at some specific points which need attention to execute successful on the transformation. Here I apply the PACE SCAN to secure the information flow through the GLUE Discovery and the transformation from one stable state to anohter stable state.

• People - to transform people will make the difference between success and failure.
• Adaption - to transform the complete solution must be adapted to reach fit to purpose.
• Communication - to transform communication is key to secure that the targets will be reached.
• Emphatic - to transform it is required to sense also the unspoken which enables to deliver and help that people and solution form a perfect fit-to-purpose environment.

The typical complexity to be found after executing in a poor way (not doing the PACE SCAN right) is contrived complexity, where a subset of the stakeholders was handled, but not the holistic complete set. By that highly biased solutions are created which unbalance the whole system. Sometimes is worth to unbalance though, because it allows to find innovation which will not be found if you always stay in a balanced world. But before the innovation can be found there is normally a time of tension and pain. Ivo doesn't touch this in his post, because he is very much focussing on efficiency, but sometimes his statement "And indeed they shoot inefficiencies and get all the glory and the money to shoot more." with a slight twist is also a good outcome, when something is done effectice: "And indeed they create innovative solutions and get all the glory and the money to create more."

Which leads to another root cause of complexity: Perverse Complexity, where the intention has been good (WISE SCAN), but the execution was not done with all the needed resources and skills in place. On top my observation is that in many transformations there is quite some theoretical effort on showing the importance of the change management, but quite often (a pity) the execution does not follow the theory or the scope and money to do change management gets downscoped. Here Enterprise Architects with a focus on people can help.

 

With respect to Ivos post I have the impression that he has mostly seen Enterprise IT Architects with a strong skillset on IT but no real awareness of people. So my advice to Ivo: Look for Real Enterprise Architecture and you will find great solutions and even greater people.

drEAmtime - WISE SCAN

Time for post number 6 in exploring the great post from Ivo Velitchkov step-by-step. Here is what I have created so far:

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

To quote Ivo:

Some attempts to achieve IT rationalisation fail spectacularly. I’m not going to list out the reasons for that. But it is may be sad that such failures discredit EA as a management discipline as whole. But sometimes Enterprise Architect are really able to find ways to discover what’s not needed and how to remove it, or what is underutilised and how to achieve better ROI for it. After all  most of them are smart people using good tools. And indeed they shoot inefficiencies and get all the glory and the money to shoot more. But as they rarely get to the cause of the inefficiencies or are in the position to influence the bigger system that produces these inefficiencies, the overall result is an oscillation or even increase in overall IT spending. The increase is because the success of the EA justifies bigger EA budget which is almost without exception a part of the IT budget.

Here Ivo points at one of the most common pitfalls of Enterprise Architecture applied: fighting symptoms instead of the root cause. This has several reasons. First of all external Enterprise Architects coming with a consulting company might not have the needed inside or full pain awareness to truly fight the root cause (some might even look for future business, and a permanent broken information flow is a permanent revenue stream). Internal Enterprise Architects might have a huge reputation problem which quite often is based on Ivos observation. So as mentioned in the other posts a clear focus on fixing the information flow is a good start to shoot at the root cause and get it eliminated or at least plant some seeds to eliminate the root cause later.

But this is clearly not enough. So with respect to fixing the content I apply the WISE SCAN approach, which looks into the future (GLUE Destination):

• Worth - The future capability must be worthwhile to trigger a transformation. (Ivo:  But sometimes Enterprise Architect are really able to find ways to discover what’s not needed and how to remove it, or what is underutilised and how to achieve better ROI for it.)
• Informed - The future capability must contain all the relevant information as much as needed containing the necessary facts. (Ivo: After all  most of them are smart people using good tools.)
• Simple - The  future capability must be the most simple solution which fits the purpose. (Here Ivo seems to have lost trust and is pointing to Perverse Complexity: "Some attempts to achieve IT rationalisation fail spectacularly.")
• Environment - The future capability must be embedded in the greater context. (Here Ivo also seems to have lost trust: "But as they rarely get to the cause of the inefficiencies or are in the position to influence the bigger system that produces these inefficiencies, the overall result is an oscillation or even increase in overall IT spending.")

I share the observation with Ivo that in many cases so called Enterprise Architects do indeed promote decisions which are not following the WISE approach but are focusing to much on some aspects and therefore add to the EPIC complexity. After all the core reason  why emergent complexity exists.

The next post will most likely be about the PACE SCAN. Feedback as always more than welcome to help me improve (or get another red line through my own thoughts. Only some posts to go till Ivos input has done its job for me).

drEAmtime - Archetypes

I am still not done with exploring the great post from Ivo Velitchkov in which many gems are to be found. My posts so far:

1. drEAmtime - Communication
2. drEAmtime - Bridging the Silo
3. drEAmtime - Capability Cemetery 
4. drEAmtime - EPIC SCAN

To quote Ivo:

But just when the situations seems really critical, the door opens with a kick and EA cowboys enter. They pull out frameworks and architecture tools from their holsters and in slow motion (a very slow motion), they shoot inefficiency after inefficiency until all of them lie dead on the floor. Then they walk out and go to shoot inefficiencies in some other town and when new inefficiencies appear in this town they come back again to kill them out.

Today it is a rather short reflection, but Ivo reminds me of a series I wanted to start and promised some time ago in my post May I Introduce The Enterprise Architect. The EA cowboy is indeed one of the archeypes I was thinking of, even though the title I have in mind is more the Enterprise Hero Architect. A very short prethinking here: The Enterprise Hero Architect is sometimes needed to fight the really big problems when it is actually already to late. And as Ivo describes he walks away when the enemy is defeated. There is some problems though, in most cases the hero is only capable of fighting the symptoms, but not the real root cause of the problem.

I (hopefully) will explore the various archetypes soon, at least I plan to. I have touched that concept in the EA Summerschool 2012, Copenhagen  and want to renew my promise here. So stay tuned. :)

drEAmtime - EPIC SCAN

I continue to explore the great post from Ivo Velitchkov step-by-step, because his posts allow my thoughts to follow a red line. He pretty much eliminated a GLUE Disease in my very own head. Once again (and I will continue to say that till I reach the end of the red line) thank you for unplugging me.

So here again a quote from Ivo:

Big organizations in all sectors, especially in the service industries, tend to gather huge number of applications until they find themselves in a situation where there are far too many to manage. A good number of them are not used at all. Some other part is underutilized. Most of the critical applications have high maintenance or high replacement cost or both. Inevitably there are many which automate different parts of the same process but they don’t talk to each other. And this justifies new spending on building interfaces, or buying application integration packages first and then replacing them with BPMS and then probably with something better than BPMS. As a result – more spending and more applications to manage.

Ivo keeps continuing exploring that with some more statements, which all point to one specific problem: Unneeded complexity as the root cause of too high costs. Once again  a great observation and a situation I have also faced more than once (and most likely will face each and every day as long as I stay in Enterprise Architecture drEAmland. So what am I doing? Actually I am applying the EPIC SCAN approach to analyze the past (GLUE Defence).

• Emergent Complexity - consequence of many small and unrelated decisions. (Ivo: "Inevitably there are many which automate different parts of the same process but don't talk to each other")
• Perverse Complexity - consequence of clumsy attempts to reduce complexity. (Ivo: "And this justifies new spending on building interfaces, or buying application integration packages first and then replacing them with BPMS and then probably with something better than BPMS.")
• Irreducible Complexity - consequence of the real complexity of the demand environment. (Ivo touches this only between the lines: "Big organizations in all sectors [...] tend to gather huge number of applications [...]")
• Contrived Complexity - consequence of deliberately creation to benefit some stakeholders. (Ivo: "But as they rarely get to the cause of the inefficiencies or are in the position to influence the bigger system that produces these inefficiencies, the overall result is an oscillation or even increase in overall IT spending.")

By analyzing the problem at hand with the EPIC SCAN approach I am able to create transparency and visibility on the root cause of the problem. And then it is (once again) all about communication and people to optimize the information flow and by that find the best fit-to-purpose solution.

It does help quite a lot, if you don't panic and stop thinking to be an Enterprise Architect but start knowing that you are one. Remember, in the Enterprise Architecture Matrix you just have to let it all go, fear, doubt and disbelief. Free your mind.

As always over to you for commenting to help me improving my thinking and share as much knowledge as possible.

drEAmtime - Capability Cemetery

Thanks to a great post from Ivo Velitchkov which unplugged some thinking of mine I was able to put some words around a couple of ideas and approaches I use. One post about Communication rather than creating an aligned (meaningless) language and a second post about truly Bridging the Silos instead of creating a new Enterprise Architecture silo. 

So here another quote from Ivo:

EA is often in the position to attract some serious budgets for reasons we’ll see in another dream, and this way the new island becomes a safe territory for people that have either failed or lost interest in the pure IT. This as a result further decreases the credibility of EA which slowly, in some organisations, gets the image of a place for people that are not good enough for IT and prefer to hide under EA labels where things are vague enough and much more difficult to measure. The lost credibility either undermines the work of the really good EA practitioners or pushes them out of the organisation or both.

 This immediately reminded me of an Enterprise Modelling Anti Pattern from Scott Ambler the so called Enterprise Parking Lot. Here a quote from Scott:

Your enterprise modelling group is composed of a lot of very smart people who don't fit in well anywhere else within IT but you don't want to lose their knowledge.

I personally have often observed a combination of both and therefore I phrase it the Capability Cemetery. So how to fix or handle this? First of all I am typically looking at each individuals capability. It is fairly seldom the case that there is people who try to avoid working under all circumstances, even thought that happens now and then. In most cases there is a deficit or GLUE Disease somewhere, a conflict between the organization setup (be it structural, process, project or any other organization) and the way the individual person is willing to operate. Typically, via investing in the interesting to reveal the relevant, it is possible to dig out the real root cause of the problem. Knowing the root cause then allows to optimize the information flow through the circulatory GLUE Cube.

 

Showing the people in the Capability Cemetery a clear path how they can utilize their knowledge and bring the highest possible value to the success of the company typically creates a buy-in situation of the members in the Capability Cemetery, especially if the value becomes visible and is recognized by the relevant people (which might be decision makers). Moving that overall Capability Cemetery now step-by-step into a well respected (Enterprise) Architecture Community will generate also organizational buy-in on the go towards a situation where no-one will ever question the value of the Enterprise Architecture. Communication is (once more) the absolute key element for success here.

As always, I need your input to improve and I do love knowledge exchange, so please forward your comments and thoughts.

drEAmtime - Bridging the Silos

As I have written in my last post "drEAmtime - Communication" a a great post from Ivo Velitchkov caught my attention and triggered me to think which is now resulting in the second post of a series of yet unknown length.

To quote Ivo:

The EA people instead of building a bridge between the two silos, create a new one. And at certain point they find themselves in the position where neither Business nor IT regards them as a bridge any more. The Business people trust EA people even less than IT because they see them as cross-dressed IT. IT people loose trust to EA as well because they are not sure they understand the Business and if they still remember what was IT. Further, IT managers need support which EA does not have the authority to ensure.

Again well observed. Here is actually way more than one observation. First of all the additional Enterprise Architecture silo. It is emerging when the desire to differentiate is higher than the desire to solve problems. Due to the typical way organizations measure success and failure it is in most situation inevitable happening. The real business people push back the Enterprise Architecture people, because they do not know enough (or the right things) about the business and the IT people push back the Enterprise Architecture people, because they don't know enough (or the right things) about the IT. So literally it is again about communication, in this case collisions between ideas.

As I have put it in my post "Real Enterprise Architecture", there is typically more than one organizational unit doing the conceptual work of Enterprise Architecture. In Ivos example it is business against EA, therefore there is a natural conflict between the (green) business domain and the Enterprise Architecture (blue) domain with a natural overlap (orange).

Conceptually the same conflict exists between IT (white) and Enterprise Architecture (blue), therefore indeed in most situations the emerging new (and scary?) function of Enterprise Architecture does create a new silo with new interfaces (or without).

Another example is the potential deviations inside one domain as I have explained in my post "Tailoring Domains". Here Enterprise Architecture is also supposed to bridge silos, but has a huge potential to be seen as an intruder and therefore being ignored or fought. (What does the (stupid) Enterprise Architect know about my Application?).

For both cases my answer is (once again) the same. I focus on people and try to optimize the information flow. This is (once again) not based on a specific EA framework or method but centered around communication and working with people.

 

Comments as always more than welcome so that I am able to improve my thinking and writing.