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.

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!

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.

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.

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.

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?