Tuesday, November 27, 2012

Enterprise Architecture Asset Failure and Flow

I have read an interesting Blog Post from Paul Wallis about Asset failure and flow wich focusses on the physical elements. I really enjoyed reading the post and I can only encourage you to also read it with care. It furthermore triggered me to think and write again about the flow of events through an Enterprise. I will pick up quotes from the mentioned blog post and reflect on them by creating a collision of ideas to my social EA thinking.
 
When key flows – water, electricity, natural gas or sewage – are interrupted in an urban area, our lives become very difficult, very quickly. Interruptions to these critical flows will often cause knock-on interruptions to dependent secondary flows, impacting things like flows of people, flows of vehicles, or flows of goods through supply chains. Flows of data are no less vulnerable to interruption caused by unexpected interactions with other types of flow.
As I have written in GLUE Disease one of my main approaches is to look at the key flow (of knowledge) and especially into dysfunctions of that flow. If I find a dysfunctions I try to optimize the flow of knowledge direct or indirect depending on the given situation. If I am successful the achieved better flow of knowledge through the Enterprise will lead to better decisions.
 
 

 
But in today’s digital world, risk lies not only in the failure of IT assets that directly enable data to flow, but also in the failure of other less obvious business assets: a leaky door, a de-pressurised cable, a failed valve or a broken pump.
 
As I have written in People in GLUE what really matters are the people. They make the difference and they in the end form the real flow of events. Processes and Methods do help, but what really makes the difference are the people.
 

 
If the people fail there is no process and method available (at least for EA not) to secure the success and an optimal information flow. Therefore I personally focus on the people first. Of course there is a certain amount of processes and methods needed (to help the people working better), but as written in the agile manifesto:  Individuals and interactions over processes and tools. Of all the assets available, people are the biggest and therefore should be threated according to that.

Sunday, November 18, 2012

Embrace Empathy - Observed the start of a Paradigm Shift

In my last post I have written about embracing emotions to induct innovation. This was triggered by a good conversation on the Sapphire Now around Enterprise Architecture. Even though my approach to Enterprise Architecture is somewhat different than the approach presented on the Sapphire Now I enjoyed it to speak to Enterprise IT Architecture experts.

The most interesting session on the Sapphire for me was a small 30 minute session with the promising title "Practising Empathy in Design Thinking". Surprisingly a fair amount of interested people showed up, even though the Sapphire Now especially in combination with the SAP TechEd is more dedicated to embracing technology and focusing around that, which is absolutely understandable given the nature of the business of SAP.

When Marilyn Pratt entered the stage it was very obvious that she has a story to tell. A story about empathy, thinking different and approaching people. For sure not a story about a specific method or technical tools and answers to a problem, but a story about people collaborating to achieve something. And that surprised me in a very positive way. The second speaker Hester Hilbrecht focused a lot on explaining Design Thinking. I think that this method is a valid technique for sense making and problem solving in the Ambiguous, but Actionable space of the SCAN framework from Tom Graves, but does not truly work in the Simple, Complicated or Not-Known space. I might come back to that topic in a later post.


The first very promising thing is that a paradigm shift seems to start now. Even though compared to the pure amount of sessions and the overall themes the Empathy and Design Thinking portion was very small it was clearly visible that the approach is shifting from "SAP Knows Better" towards "What does the Customer (or User) truly need", including the techniques to achieve that in a structured way. The approach might be debatable, but the start of that paradigm shift is very great to see. Finally I have some hope that the whole User and Customer Concept of SAP is changing to something more warm and useful and less effective and efficiency driven.

On top of that Marilyn Pratt opened up the space for a discussion in the audience and facilitated that in a great way, which allowed me to listen to other great sources of knowledge and gave me the opportunity to talk to some of them after the session. Especially the short discussion with Paula Rosenblum and Mrinal Wadhwa about Design and Art and how to achieve it was a pleasure and my personal highlight of the Sapphire 2012. There was other truly great moments, but this one was special, because it was intense with a lot of passion and an absolute desire to change something to the better while there was zero to no intention to make a business out of it. It added to my knowledge and touched me emotional and that is what I personally like most.

I felt this great moment of feeling the emotions of the others as Jermey Rifkin has put it so nicely in his statement: "We are soft wired to experience an others plight as if we are experiencing it ourselves" shown in this RSA Animation. And this is part of the core of my thinking in my post Don't Think You Are, Know You Are!


Tuesday, November 13, 2012

Embrace Emotions to Induct Innovation

Today I had some great discussions at Sapphire TechEd in Madrid. Despite all the very interesting content driven discussions I really enjoyed a discussion around Enterprise Architecture. Even though I heard mostly Enterprise IT Architecture, there was some great value propositions in the way it was presented. A fairly pragmatic approach to tools and processes combined with a strong sense for people excellence. Even though I personally find the whole setup fairly IT centric there is still the emphasis on the most important thing. People.





Furthermore there was a two focus areas mentioned specific: Efficiency and Innovation. There was not much details shared on those two spaces, but the typical buzzwords where used: KPIs, Management Buy-In, Independence of Enterprise Architecture, no decisions by Enterprise Architects to stay unbiased and a lot of other statements. All of the statements are worth to be analyzed and blogged about, but I will focus on "No Decisions by Enterprise Architects to stay unbiased".

I have a different approach here, because of several reasons:
  1. I believe that every person in the world is biased --> Self-Serving Bias.
  2. To support decisions from others some form of facts must be provided, because a recommendation is nothing else than a hidden decision, where the formal decision is given to someone else, but the interpretation of the facts is already done. So focusing on the facts:
    1. I believe that internal facts support the current approach and style, this belongs to the GLUE Division Defence. That typically allows to change a portion, but most likely only in very small steps, because the status is protected by good internal facts.
    2. I believe that external facts support a follow-up strategy. Here it depends on the level of trust to the external facts. Quite often there is some level of trust between decision maker and fact provider based on former relationships, this belongs to the  GLUE Division Discovery.
    3. The combination of internal and external facts often lead to an interesting situation in which some conflicts between internal and external facts need to be managed. Cultivate those Collisions, they most likely allow to breed some new ideas and solutions. And these new ideas have the potential to become true innovations.
I believe that Innovation is the unified selling proposition for every company. The one (or many if a company is great) thing which makes them truly different in the market also allows them to stay in the market. For innovations risks must be taken, decisions must be made, the decisions must be justified and that is to my believe not fact based. Fact based decisions follow the classical game of efficiency and effectiveness. And that is the good old story of process management. The way to Induct Innovations is to Embrace Emotions.

Don't think you are an Enterprise Architect, know you are.

Thursday, November 8, 2012

May I introduce the Enterprise Architect

It was a long time since my last post and I am sorry for that, but I am very busy these weeks and therefore the blog lost some of my attention. I will try to put more time and energy into it in the next weeks, but I do not know for sure yet if I truly find the time.

Anyways, as part of a (hopefully long) series I like to introduce you to the Enterprise Architect on the left. I kind of use the theme from a post from Forrester, even though I do not agree with the post itself (Tom Graves haswritten about this in his post broken) the idea of using an image or a photo to show what an Enterprise Architect is and how he has to behave is very interesting as a concept. The Forrester image shows a specific business man like approach to Enterprise Architecture.

To start the fun right now I use a drawing my wonderful wife has created for me. The (almost) naked Enterprise Architect without any specifics. As part of my GLUE concept where the people are the most important aspect of Enterprise Architecture an (almost) naked Enterprise Architect has only one tool he can use, and that is himself. In the next posts (whenever I find the time) I will explore the capabilities of that Enterprise Architect deeper.

Sunday, October 28, 2012

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.

Social EA Logo

It is time to brand my blog Social Enterprise Architecture a little. Therefore I have created a small and simple logo (with huge help of my wife who is way better in logo work than I am). From now on I will use this logo also as the favicon.

That actually reminds me that I also have to create a logo for GLUE. A lot of things on my backlog for this blog and my ideas around social enterprise architecture. I hope I get it delivered step-by-step next to all the other activities I have to do.

Friday, October 19, 2012

Cultivate Collisions

A couple of days ago a tweet flew by which deserved closer attention:
Questions to ask about any method or approach: Who invented it? What problem one tried to solve? Do I have that problem?
In the interaction with the author it became (once again) obvious that I have a different approach to look at methods and tools than just looking at for what specific problem space it was created. Steven Johnson has put this in a great way in his speech Where Good Ideas Come From. The immediate question I ask myself is:

Can I use this for any problem I face at the moment?

I try to cultivate collisions. I try to see behind the core idea and why it was created. Even though there is a lot of value in understanding why and how a method was created I personally believe there is one flaw in understanding the thoughts of others: it constrains the creation of new ideas.

"Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who read too much and uses his own brain too little falls into lazy habits of thinking.",
Albert Einstein (1879 - 1955)

So learning from others is key for me to understand and learn, but also to develop new ideas. And I am not only trying to learn from other Enterprise Architects, but I try to learn from everything what I experience. And then I try to create and add that new piece of puzzle based on that experience. It is a journey, and honestly it is a tough one, but not panicking helps me here.

I will label all posts in which I try to with collision, and there is already one example on this blog: The Enterprise Architecture Matrix. Cultivate collisions and embrace the change coming through that collisions. What are you waiting for?

Wednesday, October 17, 2012

Don't Think You Are, Know You Are!

Today Tom Graves has neatly described Two Enterprise Architectures and by that explored the difference between Enterprise IT Architecture and Enterprise Architecture. I have touched that topic shortly in my post about Real Enterprise Architecture. I am using my standard example here with following Decks:

Based on those Decks in the 3-dimensional representation Architecture is covered by the GLUE Discipline Design. Enterprise IT Architecture covers all EITA Activities and Deliveries in the context of IT:


While Enterprise Architecture must include Enterprise IT Architecture, but shall not be limited to it, because Enterprise Architects have to look at everything in a holistic way not biased towards anything.


Reality of course is often different and therefore difficult. Enterprise report in most cases direct (or via management structures) to the CIO or CTO. On top of that there is the demand of typical Enterprise IT Architects to be seen as holistic Enterprise Architects spanning the whole Enterprise. And that is a difficult concept for the audience to understand, because of the reporting structure.

What I do not understand though is: What are Enterprise Architects waiting for? If you are hired as Enterprise IT Architect and have something to add to the whole Enterprise Architecture, why don't you just provide it then? Use hte EITA recruiting as the entry to provide the true value. So far I am still waiting for a company to turn that knowledge down. It is usually unexpected, but nevertheless pretty much needed, and therefore also very willingly accepted and used. Asking for governance or an official mandate is calling for trouble if you ask me, because in typical organisations there is no real place for real holistic Enterprise Architects.

The closest could be reporting to the CEO, but everyone is seeking for a position close to CEO. So what is the unified selling proposition Enterprise Architects can make to the CEO compared to all the others who want air time? So any other C-Level reporting structure will normally have to do the trick. That will lead to a somewhat biased situation (the C-Level to report to is the one who drives the potential on how to use and evolve the role).

But if we truly believe in Enterprise Architecture to be a fully holistic non biased function (difficult concept at the moment in time when human beings are involved) then why not just give it a try? Just offer that holistic service to the audience at hand. Provide the knowledge and utilize the existing structures as much as needed, but apply the concepts of the Enterprise Architecture Matrix. And the most important one is, if you believe in being a holistic Enterprise Architect:

Don't think you are, know you are!

Guide the Energy

As I have written in my last post Less is More reducing complexity to the absolute needed minimum is key to not add unneeded clutter and blurriness. I also touched shortly on the energy created if two (or more) ideas compete for the limited attention available. In my post GLUE Disease I wrote about diseases which cause unbalanced system and that is unhealthy and potentially very risky for the whole GLUE Circulatory System.

To explain the mechanics here I use the concept of the GLUE Divisions:




  • Destination to set the target
  • Discovery to do the transition
  • Defence to protect the existing




As I have put in my post Given Up On Balance I kind of feel in balance when I give up the balance. I have not found better words for this yet, so if you have some bring them forward to allow me to learn (and find a better balance). When I find competing ideas I look closely at them. In many cases it is somehow related to (the lack of clear) ownership (a topic which I want to touch soon as well) and the derived complexity.
  • If the system tips towards defence nothing moves, the whole become rock solid or frozen like ice, which prevents any improvement or complexity reduction.
  • If the system tips towards destination the whole adds complexity (emergent complexity).
  • If the system tips towards discovery reinventions of the system occurs either without the needed input (destination) or the capability to adapt (defence). That can spawn any kind of complexity and behaves quite random (Not-Known Domain in Tom Graves' SCAN framework)
So how do I imbalance:
  • In a frozen system I try to add energy by planting several small ideas like written so great in the post of Harold Jarche about Trojan Mice. Small little ideas and changes which create a small but significant imbalance in the system potentially leading to massive tension and friction. As written in the Trojan Mice post the ideas and their result has to be watched closely and if in doubt removed, because they can grow massive and by that create severe impact.
  • In a high energy system (destination) I try to remove energy by bridging between the conflicting parties. In most cases the commonalities are larger than seen (hoped for) by the disputants. The destination conflict though is the most interesting to watch for a fairly long time to see where it goes. It can be like tectonic plates which create volcanic eruptions who are very destructive. That energy might be needed though to break up the power of defence. Furthermore it has the potential to create something truly new. Guiding this energy is one of the most important challenges for Enterprise Architecture to be successful.
  • In a system which is constantly trying to adapt without input or capabilities to adapt the mission is twofold. Creating tension and friction (to a certain degree) to find the next (volcanic) eruption which does feed the system with the needed ideas. But the key aspect is to guide the energy, bring people together, help them understand each other and translate between the (potential already engaged in tribal wars) involved. Diplomatic skills are fairly important here and being able to handle and maneuver in the Not-Known space.
As I have put in my post the Enterprise Architecture Matrix: Stop trying to solve it, but start solving it.




Friday, October 12, 2012

Less Is More

In my last post I have written about the concept to compare Enterprise Architecture with the Matrix. In short: free your mind and open up for all the possibilities. There is no reason to stay inside the boundaries provided by the various frameworks and models. They are helping, but not the answer. The real change happens by working with the people and there is the place where the real Enterprise Architecture is happening. With and through the people.


Today I have read an interesting post of Tom Graves where he brought Ric Philipps and his definition of Enterprise Architecture being an antipattern to my awareness. The result is that I follow (just another) Enterprise Architect, which is great. The concept in that particular post is interesting, because Enterprise Architecture adds another level of complexity which might easily outweight its benefit. I personally see Enterprise Architecture (as any other form of Architecture) as waste.


There is a particular element I really like about Ric Philipps' post. And that is the underlying principle minimalism. Ludwig Mies van der Rohe has used that principle greatly (very subjective) for his approach to architecture. By reducing the definitions (frameworks, models, you name it) to the absolute minimum the Observer Effect is minimized as well. Highly complex models (amount of definitions and relationships) have indeed based on my own observation a high tendency to disturb and create more noise than sense. (e.g. the discussion about UML extend and include, or the various complexity models).


If you ask me the model of the world could be flat, like in discworld (despite the turtle and the elephants, that is not needed to explain it). It does work for my daily life. And even though I know that the world is a globe my senses tell me something different, because they are more sharp on experience which is directly connected to my physical experience, and almost all things I need work for that model. (Actually a map is nothing else than a 2-dimensional model of the world). But of course I am not very religious on that 2D model, most likely because I just use it and did not invent it. On GLUE i might think different, the future will tell.

Nevertheless the boxing and framing is also very useful, as Seth Godin has put it so great in his post "I want to put you in a category". The interesting thing for me is not only the boxing itself, or being trapped in the Overconfidence Effect, but especially the friction and tension created by two (or more) tribes defending their own believe and thinking (almost) to death. Of course there is a short term negative effect (and there was some very destructive examples of that in the past), but all that energy usually also creates something new, something which has not existed before. So it is very interesting to observe the heavy (and very emotional) discussion in the complexity models around Enterprise Architecture at the moment. Even though there is a lot of bad feelings on all sides I personally believe that all this negative energy has a good chance to create something new which the world has not seen before.

Thursday, October 11, 2012

The Enterprise Architecture Matrix

In my last post I have tried to express that I have given up on balance and I like it pretty much to be out of balance. It is kind of balance for me to be out of balance. No idea why, no idea where that leads to, no idea how long it lasts, but I accept the fact that I like it and that it gives me this perfect moment of being once with the flow. The flow I try to optimize with my daily work and which I tried to describe (fairly weak description so far) in my posts about GLUE Disease and Fixing Flows:


In this post I try to describe the way I approach Enterprise Architecture with my GLUE thinking in a different way. For that I will use a sequence from the movie Matrix and translate it into a dialogue between a Real Enterprise Architect and a Wannabe Enterprise Architect. For simplicity I use Wannabe and Real to point out who is speaking.


Wannabe: I know Enterprise Architecture.
Real: Show me.
Real: This is an Enterprise Architecture Activity. It follows the same basic rules than the Enterprise, rules like governance. What you must learn is that these rules are no different that the rules of a framework. Some of them can be bent. Others can be broken. Understand? Then solve it, if you can.

[Wannabe tries to solve the problem]

Senior: Good. Adaptation, improvisation. But your weakness is not your technique.Project Manager: The Junior tries to solve an Enterprise Architecture problem.

Real: How did I solve it?
Wannabe: Your knowing more than I do.
Real: Do you believe that my being more experieced or knowing more has anything to do with my Enterprise Architecture framework technique in this place? You think that's air you're breathing now? Hah. Again.
[Wannabe really tries to solve it]
Project Manager: Jesus Christ, he's fast. Take a look at his neural kinetics, they're way above normal.
[Wannabe is close to solving it]
Real: What are you waiting for? You're faster than this. Don't think you are, know you are. Come on. Stop trying to solve and start solving it.

Project Manager: I don't believe it.

Wannabe: I know what you're trying to do.
Real: I'm trying to free your mind, Wannabe, but I can only show you the door, you're the one that has to walk through it. You have to let it all go, Wannabe, fear, doubt, and disbelief. Free your mind.



I truly hope that Enterprise Architects are waking up and walking through that door. The more the better. If you ask me then there is more to solve out there than we are ever able to sort, so if possible free your mind and enter the real Enterprise Architects leaving all the rules and boundaries behind you, but use them where reasonable.


Wednesday, October 10, 2012

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.

I am a ChickenBrain

After trying out blogging for a bit more than a month I decided to invest a little time into using my own domain now for the blog. It is still hosted with Google Blogger, but now to be found under http://socialea.chickenbrain.de.
 
"We know nothing at all. All our knowledge is but the knowledge of schoolchildren. The real nature of things we shall never know."
Albert Einstein (1879 - 1955)
 
 
The interesting (for me at least) thing about that domain is, that I found the name ChickenBrain at the age of 17 as a Character name for a Roleplay game (quite some years ago), before I explored the Internet. I quit roleplaying some years ago, but that nick kind of sticked to me. At that age I had a very good teacher for philosophy (looking back my school was really cool to offer that course, at that age I did not recognize the school to be cool). That (wise) man teached us in a good way that we do not know anything, so ChickenBrain became my pattern (and still is my main pattern).
 
I know that I know nothing and therefore I seek for answers (and will hopefully continue seeking for answers). Funny enough in one job interview (with a headhunting consultancy) I was told to not use my primary email adress kai@chickenbrain.de for sending the resume, but shall use something more professional. I was listening to the headhunting clerk and told him that I will not (and hopefully never) will be working for a company who does not value people who openly confess that they know nothing.
 
So, if there is one thing I know, than this is the message:
I am a ChickenBrain

Sunday, October 7, 2012

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.
 


Saturday, October 6, 2012

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:
  
Feedback as always more than welcome.

Friday, October 5, 2012

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.





Sunday, September 30, 2012

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.


Thursday, September 27, 2012

A matter of perspective

It has been a while since my last post about Value Creation and GLUE. Interesting enough this created some discussions via twitter about what is a real value add and what not. I still stick to my statements that the only value add is located in the GLUE Discipline Develop and methods and tools to be able to deliver real value are not value in itself (despite the moment when they are created and/or added to an environment).


"The world is given to me only once, not one existing and one perceived. Subject and object are only one.",
Erwin Schrödinger (1887 - 1961)

The interesting challenge I personally observe in Enterprise Architecture each and every day is to ensure that the existing and perceived world are synchronized to be recognized as the same. On top of that the IT world has created another challenge which now requires that the existing world, the artificial reflection of the world, the perceived existing world and the perceived artificial reflection of hte world needs to be synchronized. As I have written in "Always remember the next larger context" the challenge is to find the one-to-many mapping in the GLUE Space to ensure an accurate artificial reflection of the world and therefore synchronize the real world with the artificial world.

Imagine a company which is multinational and organized with a global, regional and local organizational setup. To keep it simple the artificial reflection of the world could be done by harmonizing all processes in the world and deliver a one size fits all approach:


In most situations this is a fairly good marketing statement and looks very good to justify huge initiatives to align processes around the world. The pushback of the real world is most likely enormeous and depending on the size of the company and the diversity of the markets there is literally no chance to squeeze the whole into the same concept. But maybe a regionalized approach does work where there is one process fits all for one region approach:



This will give a fairly large amount of alignment but at the same moment in time neglects the necissity for local deviations and specialities of single elements in a corporation. This can be fairly simple reasons like local legal law or more complex reasons like a different approach to the market, because the market situation is different in that specific country and legal entity. Therefore the answer can easily look fairly diversified:







So in many cases the final architecture will be federated. No matter if it was a structured educated approach to reach a federated architecture or evolution over time due to created necessity by restructuring the organization and therefore creating the implicit demand for a federated architecture (Conway's Law). The end result (from a conceptual point of view) is the same. A mixture of Global, Regional and Local elements:






The interesting thing from an Enterprise Architecture point of view to me now is the perspective in such an architecture. It might be very interesting to find the right federated architecture, but I believe it is not really relevant. Relevant is to help the people who must live and work in such a federated architecture to see the whole holistic view. So in the discussion between a global and a local owner the tension between the two perspectives is fairly easy to observe. From the global point of view the local part of the architecture is just another Customer which of course has to follow all rules and boundaries of the global architecture:





From a Local point of view the Global System is just another part of the architecture in the complete holistic local architecture. The business case for success for the local part of the corporation is in most cases motivated by local demand and conflicting with global demand.




The interesting discussion now is to find the right federated architecture. Unfortunately that is a moving target and does change as fast as the business changes. The discussion about the right To-Be Architecture (even though it indeed is interesting) can easily be an endless ivory tower discussion never coming to a final conclusion. The relevant discussion in my mind is helping all involved stakeholders (and that includes of course the regional elements as well in this example) to see the holistic picture. The real joy of Enterprise Architecture to me is that Enterprise Architects should apply the concept of Schrödinger's Cat in the Architecture all the time: The Cat is alive and Dead at the same moment in time.

And here (once again) it is more relevant to help the people than to apply a specific method or tool to come to a final recommendation, which I tried to picture in my GLUE framework:


 

As always questions and comments more than welcome, but I am already happy if you continue to read my blog posts. :)

Thursday, September 20, 2012

GLUE Value Add

By looking at the GLUE Disciplines and how to GLUE Disseases one of my main goals is always to optimize the flow of information and reduce waste. Which brought the idea behind this post onto the surface of my thinking.

“Short as life is, we make it still shorter by the careless waste of time”,
Victor Hugo (1802 - 1885)

So what is waste in GLUE. How to find waste and how to eliminate or at least minimize it. The GLUE Disciplines play a major role here, because they are motivating the action to deliver a solution.

  • Describe Intention does not add value. The pure description of the intention does not give any further value to the existing solution. It might guide towards a future state of the solution. The interesting thing about Describe Intention to me is that many investments are made based on a fuzzy statement about a potential To-Be future. As stated in Enterprise Architecting Past, Future or Present I do not believe that the future is really truly predicable, so good luck with your investment bet.

  • Define Requirements does not add value. The definition of the requirements does not give any further value to the existing solution. It might give a fairly good picture on how a potential future of the solution can look like. The interesting thing about Define Requirements to me is that many decisions are made based on requirements as if they are facts.

  • Design Architecture does not add value. The organization of requirements into elements does not give any further value to the existing solution. It might provide a reasonable split between the elements and might order and organize them. The interesting thing about Design Architecture to me is that many architecture To-Be documents are treated as if the problem is already solved.

  • Develop Solution adds value. Here something is added to an existing solution and therefore adds value to the existing. (under the assumption that it was done in an educated and careful way).

  • Do Operation does not add value. Running any solution does not add value, but only supports in keeping the existing value alive. The interesting thing about Do Operate to me is that there is quite often the believe that execution excellence (Do Operate) adds value, even though it only maintains the current.

  • Detect on Solution does not add value. Inspecting if an solution is fit for purpose does not add value, but only checks if value was delivered or the execution is still done in the right way. The interesting thing about Detect to me is that quite often a high maturity assessment results leads to the believe that a solution is excellent.
So the real value add inside the GLUE model is only on the Develop Discipline:

So why are we doing all these activities. Reality is that we have to take into account the persons who do the activities and in most cases people can not (or are not allowed to) see the full holistic picture of the solution.

 
 

But in a total idealistic world or an GLUE Utopia the only really needed deliverable would be based on Development activities. In this case no waste would be generated and all time spend would be dedicated to the development of the existing solution. So when I look at any given method or tool at hand I try to find one which is minimizing on waste and I try to only generate the waste I absolutely must generate. Being an Enterprise Architect myself there is quite some waste I could generate for the only real value add which is Development:


I am happy to hear about your thoughts and comments.