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

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.

given up on balance

A blog post of Amanda Fenton about balance reminded me about a core concept I use in the space of GLUE and the change introduced via GLUE. In my post Fixing Flows I wrote about the joy of getting something to work and therefore eliminating a GLUE Disease. Maximizing the throughput in the GLUE Space in each and every domain is what I am aiming for and unfortunately the slowest domain decided upon the speed of the whole GLUE Space.

So what is my key to success here? I try to achieve balance (all domains do have almost the same throughput) by giving up on balance myself. Now that seems to be counter intuitive, but it is exactly what I do:

 

To achive balance I give up on balance!

 



The key aspect behind this thinking can be found in my way of tackling complexity:

1. In the simple domain there is no need to give up balance.
2. In the complicated domain there is limited need to give up on balance, but in a very controlled way.
3. In the ambiguous domain there is permanent need to give up on balance, but action can be done one by one.
4. In the Not-Known domain balance does not exist.

I like to use the analogy of walking:

1. Standing on both feet in balance
2. Decide where to go ("automatic" after the initial decision where to go)
3. During the step out-of-balance
4. continue with 1

Therefore to move the Architecture from one state to the other (As-Is -> Transition Architectures -> To-Be Architecture) the whole system gets out of balance all the time, because it is the only way to move. The whole GLUE Division Discovery is completely dedicated to out-of-balance behaviour, so the same flow as walking with GLUE terminology:

1. GLUE Division Defence (As-Is)
2. GLUE Division Destination (To-Be)
3. GLUE Division Discovery (Transition, get to the target)
4. continue with 1

In a perfectly running GLUE the next To-Be is close to automatic (or at least very fast), which translates into a system where the change between balance and non-balance is done so fast and automatic that everything is perfectly in flow. In most cases I find (or throw myself at) systems where the flow is out of balance, but the system stable (and unwilling to change). Here I give up my own balance (entering willingly Not-Known) to create a momentum to change.

And I do not know why, but this flow of events is kind of a Zen feeling for me: things happen unpredictable and real time around, with and due to me while I try to categorize (EPIC SCAN) them, set a direction (WISE SCAN) and support the execution (PACE SCAN). In most cases this require to be very flexible with the methods and tools and therefore I apply most of the time (80%) agile techniques. And here the technical tool I use is a whiteboard and markers.

Complexity SCANs in GLUE

In my lasts posts I was exploring complexity and how I tackle the problem of complexity by applying my GLUE thinking to it. Therefore here a short summary so that my thinking about complexity up to now is collected in one place. I am using the SCAN framework of Tom Graves and connect it with GLUE by applying it to the GLUE Divisions and the GLUE Discipline Detect:

In GLUE Detect on Defence the EPIC SCAN is used to analyze the root and severity of the complexity:

• Emergent Complexity - consequence of many small and unrelated decisions and actions.
• Perverse Complexity - consequence of clumsy attempts to reduce complexity.
• Irreducible Complexity - consequence of real complexity of the demand environment.
• Contrived Complexity - consequence of deliberately creation to benefit some stakeholders.

In GLUE Detect on Destination the WISE SCAN is used to analyze the potential and the desired future state:

• Worth - A future capability must be worth the investment.
• Informed - The decision to invest into the future capability must be fact based.
• Simple - The most simple solution must be selected (to minimize future complexity)
• Environment - The solution must be embedded in the greater contex.

In GLUE Detect on Discovery the PACE SCAN is used to analyze the speed of tranformation:

• People - because one person can (and most likely will) make the difference between success and failure.
• Adaption - because the solution must be adapted to serve the people.
• Communication - because communication is key to ensure that the solution serves the people (and is accepted by them).
• Emphatic - because sensing also the unspoken is needed to be able to deliver and help that people and solution form a perfect fit-to-purpose environment.

All of this is needed to optimize the journeys through the GLUE Space and there is one good advice: Don't Panic.

 

PACE SCAN

In my last posts I explored the world of complexity and started with Don't Panic. An advice which does not only work for GLUE and Enterprise Architecture but is generally a fairly good advice. The some ideas collided in my head (which reminds me of the great Steven Johnson and his Where Good Ideas Come From) and I therefore wrote about EPIC SCAN for the GLUE Division Defence and WISE SCAN for the GLUE Division Destination. Both techniques which i use in my GLUE thinking and therefore my daily work for quite a while but which I could not formalize more yet. Tom Graves SCAN framework allowed me to find a way to formalize it a bit more. I had difficulties with WISE SCAN but finally found a way.

So one GLUE Division is missing: Discovery. Here I use the PACE SCAN:

• People - because one person can (and most likely will) make the difference between success and failure.
• Adaption - because the solution must be adapted to serve the people.
• Communication - because communication is key to ensure that the solution serves the people.
• Emphatic - because sensing also the unspoken is needed to be able to deliver and help that people and solution form a perfect fit-to-purpose environment.

And for those who have not figured yet: Besides enjoying working in the space of chaos, because here the really cool new things (and a lot of stupidity) emerge I also love working in the GLUE PACE SCAN to find a way through the chaos.

WISE SCAN - Revised

In my last post I was writing about EPIC SCAN, a combination of two great sources of knowledge including a reflection on how I use it. Emergent, Perverse, Irreducible and Contrived existing Complexity is SCANned for how complex it really is. According to the result (Simple, Complicated, Ambiguous, Non-of-them) a way of working, mindset, skillset is applied in a holistic way to optimize the flows through GLUE.

There is a challenge left, because the EPIC SCAN only works for sensemaking which I place in the GLUE Division Defence. The question is now how to apply the SCAN in the Division Destination. For that I use the WISE SCAN:
  

• Worth - A capability developed in the GLUE Division Destination must be worth to start the transformation in GLUE Division Discovery..
• Informed - Collect information (if not already at hand) so that a decision is as much as possible and needed based on facts. Just Bareley Good Enough from Scott Ambler might be a source of inspiration here.
• Simple - Select the most simple solution which works. KISS from Michael Vizdos might help here.
• Environment - Ensure that a future complexity is embedded in the greater contex.

Feedback as always more than welcome.

EPIC SCAN in GLUE

In my last post Don't Panic i touched upon complexity, a topic which seems to be pretty hot at the moment by looking at various twitter messages and fairly recent blog posts. Richard Veryard has touched the topic in a quite interesting way in his post On The Causes of Business Complexity. What I particular liked in his post was his four causes of complexity:

• Emergent Complexity - consequence of many small and unrelated decisions and actions.
• Perverse Complexity - consequence of clumsy attempts to reduce complexity.
• Contrived Complexity - consequence of deliberately creation to benefit some stakeholders.
• Irreducible Complexity - consequence of real complexity of the demand environment.

 I like to reorder that slightly without really changing the context, because working in complexity is epic.

• Emergent Complexity
• Perverse Complexity
• Irreducible Complexity
• Contrived Complexity

To tackle the EPIC Complexity I can now use the SCAN Framework. and by that create sense, aim for decisions and look for the right skill and mindset. A topic which is also tackled by Shawn Callahan in his post When Should We Collaborate, where he also refers to Cynefin and links a way of working to complexity:

• coordination for Simple Problems
• cooperation for Complicated Problems
• collaboration for Complex Problems
• Any method for Chaos to shift to one of the other three complexity domains

I agree with his judgement of the first three levels of complexity but I am more willing to follow Tom Graves approach in the fourth domain. In his post Sensemaking - Modes And Disciplines he sees working and acting as an Artist (inner value) as the answer to Chaos. In this one I full agree, because I believe the other three working models (and roles in Toms post) will only find unknown areas of their own domain in the unexplored space of Chaos.

So I call that now the EPIC SCAN.

So how do I link this knowledge to GLUE. First of all I look into optimizing or fixing the flows in the GLUE Space. Here applying the right approach to way of working and finding the right skill and mindset is in most cases more important than finding the perfect answer. The people will find the right answer inevitable if their skills and mindset fit to the complexity domain. If the fit is not given then they will try to shift the complexity into another domain or start being frustrated. A typical statement here is: "If X would just understand me".

And unfortunately there is no Silver Bullet to it. Not even Ken Schwaber markets the methodology SCRUM that way. In a recent post he clearly links SCRUM to the complex domain (where the unknown is greater than the known). In spaces where the known is greater than the unknown SCRUM creates more waste than needed and other methods (if applied correctly) will produce results in a less wastefull way. The challenge is to find the right method to maximize Value Add. And for those who are still unsure: the complexity area where I love the Domain Enterprise Architecture most is in the Chaos, no matter where in GLUE.

Don't Panic

Janne J. Korhonen has written a nice and worth to read blog post: There is not a simple solution to every problem, in which he was bringing me Cynefin back to my mind:

• Simple Problems can best be solved via Sense-Categorize-Respond (Best Practice).
• Complicated Problems can best be solved via Sense-Analyze-Respond (Good Practice).
• Complex Problems can best be solved via Probe-Sense-Respond (Emergent Practice).
• Chaotic Problems can best be solved via Act-Sense-Respond (Novel).

Tom Graves has created his useful SCAN framework and compares SCAN here with Cynefin. SCAN divides the sense-making and decision-making also in 4 different buckets:

• Simple and Straightforward
• Complicated but Controllable
• Ambiguous but Actionable
• Not-known, None-of-the-above

As I have written in People in GLUE the difference between success and failure lies in the success of failure of a person, because a person can make the difference. The key reason why in the GLUE Framework the focus is on people.

"Don't Panic",

Douglas Adams (1952 - 2001)

"Don't Panic" is the cover of "The Hitchhiker's Guide to the Galaxy" and in the novel it is explained that the title has two reasons. The first reason is, because the device looks insanely complicated and the second reason is to keep intergalactic travelers from panicking. I personally believe that most Enterprise Architecture frameworks could use a title like "Don't Panic", because the Frameworks look insanely complicated and to prevent those who travel through Enterprise Architecture either by applying or consuming it to panic.

In my GLUE approach I use the concept of the GLUE Decks to tackle complexity. As a reminder there is always a one-to-many relationship between the decks:

While I observe and support the GLUE Journeys through the GLUE Space I match the complexity of the solution to four levels:

1. Re-Use of an already existing solution without changing the solution itself. Most likely high potential to automate or already automated.
2. Re-Use of an existing Architecture (GLUE Discipline Design) so that real changes happen only in build and therefore potentially also on a lower Deck. Off-the-shelf and cloud solutions belong into this category.
3. Change of the Architecture by adding elements which are not existing at the moment.
4. No Idea how to solve the problem

Important aspect here is that the complexity level on the different decks can vary quite dramatic. Therefore to find out the complexity of a potential solution I apply a simple max() function on all Decks and elements in one Deck. The highest complexity decides about the complexity of the overall solution.

In most cases there is a fairly simple answer (Good or Emerging Practice) to most Desire, which is transforming into an existing standard off-the-shelf solution. That transformation is in most cases as an initial starting point not acceptable ("we are special", "we do not accept that our process is dictated by a software supplier" or "change the process without changing the IT solution and get all imaginable benefits"). Reality is that in most cases an adaption to an existing off-the-shelf-solution is a good fit-to-purpose and fairly easy (complicated, complicated but controllable, Re-Use Architecture) to use solution.

The typical conclusion for me is to go to the persons and work close with them. Helping them in seing the potential of a solution even if it means to give up some of the Intentions and Requirements. Interesting enough this is usually not achieveble by pure facts but requires a quite intense person to person work. So Don't Panic, work with the persons. People are relevant, the problem and the solution is only interesting.