GLUE - Updated Framework

In my last post I have updated and corrected the GLUE Journeys to put my thinking in the model after some reflection on my own writing triggered by reading my own thoughts and especially by some comments I received. This of course has an effect on the GLUE Framework in the context of Social Enterprise Architecture which I now have to reflect.

• A Person is assigned to 0 to n Roles
• A Role has responsibilities on a Delivery
• A Delivery produces a Deliverable
• A Deliverable is associated to a Domain
• A Domain is a subset of the Space
• The GLUE Space is a Circulatory System

Having written this the interesting question is: what makes the circulatory system work. The answer is very simple: It always works and it always creates the result based on communication between the people as it was put in Conway's Law. And communication between people is not a stable construct but something which is very flexible and undergoing a permanent change.

So how are people organized?

1. The first dimension is the organizational structure, where people are clearly assigned in elements in pyramidal structures.
2. The second dimension is the process organization, where people from different elements of the organizational structure work together in the same process towards a repeatable goal.
3. The third dimension is the project organization, where people from the different elements of the organizational structure work towards a one time goal.

So what is the effect of these three organizations on the GLUE Framework and especially the GLUE Space and the circulatory system?
The answer is fairly simple:

• All three determine who delivers what in the GLUE Space. The GLUE Space itself and even the circulatory system is not affected.

in many frameworks I observe an argumentation chain which is along the line: If you follow this, then it will work. If something does not work out the argumentation chain is easily: But you have not followed framework x, therefore it couldn't work. Given the fact that none of the frameworks is complete (only reality is) this is a self fulfilling prophecy. With GLUE i try to be different (and I might be biased in believing so and totally wrong. I believe there is no way to break out of GLUE, we are all bound to it, no matter if we try to be different or now.

GLUE glues Engineering together, if we want it or not.

GLUE Journeys - Obvious missed

By writing about the GLUE Journeys i missed to clarify one thing which is so obvious to me that I have not put it into the model, yet. My clarification post on the journeys between the GLUE Decks helped me to see that this was just hidden in my head but not put into any post yet.

“The world is full of obvious things which nobody by any chance ever observes.”,
Arthur Conan Doyle Sr. (1859 - 1930)

My initial declaration was, that something new from the GLUE Division Destination has to be adopted by using the GLUE Division Discovery till it is fully adopted in the GLUE Division Defence:

There is of course also a feedback flow in the divisions. Desire Defence can lead to a changed Desire Discovery which can lead to a changed Desire Destination. If that is a very strong flow here it is a reflection of an organization which resists changes:

The full Circulatory GLUE System looks therefore like this:

 

I have now explored the GLUE Journeys and will start to map various frameworks, models, methods and whatever I find on my exploration to GLUE to explain it even further. I hope this brings something to the community. Now I hand over to your comments and will try to answer them, if I have an answer. If not is actually even better, because that forces me to think deeper.

GLUE Decks - Journey between the Decks

In my last post i have finally come to an explanation of the GLUE Journeys I like myself, which is a circulatory system with the GLUE Space as the structure giving element. I shortly touched on the flows:

• The GLUE Disciplines is a circle, where Detect feeds back into Describe
• The GLUE Decks are constructed based on the elements from a lower level
• The GLUE Divisions reflect the diffusion of To-Be into As-Is

I received a comment via email which I will try to answer:

What is not so clearly explained is the back-and-upwards link from level n, discipline m, to level n+1, discipline m-1
 

The flow of information between two decks has two connection points:

• Each requirement from Define will be assigned by Design to an element of the lower Deck (or can be handled in the very same Deck as explained in GLUE Disciplines).
• After Development of the solution Do is needed to use the solution on the upper Deck.

To give an example I use the example from "always remember the next larger context":

By just looking at the two lower levels

• If you want to furnish your living room you will place the elements you want to put into your living room on the right place (maybe you even have a plan for that). It can also be the case that you want to buy new elements (e.g. a table and chairs).
• Room Describe: I want this room to be a living room
• Room Define: It must contain a chair (I fear that is more an one chair exibition approach than a real living room, but I stick to the example)
• Room Design: The chair shall be placed in the middle of the east side of the room.
• Room Develop (start): Find the chair
• Chair Describe: I want a chair
• Chair Define: (Put your favourite chair requirements here)
• Chair Design: (Put your favourite chair design here)
• Chair Develop: Reuse/Buy/Build the Chair
• Chair Do: Use the Chair
• Room Develop (continue): Place the Chair on the east side of the room.
• Room Detect: Check if everything is done as requested

This is of course an artificial example, but I hope it explains it better why a lower level "Do" leads to an upper level "Develop". You can not finalize a development on the upper level if you do not start to use the elements. I have the same reasoning behind putting Detect after Do, because it is not possible to test something, before you start using it.

(So Plan->Build->Test->Run is a myth, which i will discuss in another post.)

GLUE Journeys - next attempt

I fear it is hard for me to live up to my promises made in my initial post about GLUE Journeys. I have kind of avoided to really come to the point, actually I tried, but I did not get to it in my next attempt (and I have not revealed all of my failed approaches).

“All intelligent thoughts have already been thought; what is necessary is only to try to think them again.”,
Johann Wolfgang von Goethe (1749 - 1832)

Well, I will give it another try. By looking at the GLUE Space the flow of information is from left to right (GLUE Disciplines) and from front to back (GLUE Divisions). For the GLUE Decks the flow is from top to bottom.

The flow of the GLUE Disciplines is actually a circle, because Detect Defect feeds back into Describe Intention:

The flow through the GLUE Decks is following the Architecture for the next level, as also described in "Always remember the larger context". The larger context influences Describe Intention of the element contained in it:

To flow through the GLUE Divisions transforms the Destination via Discovery into a fully adopted solution in Defence:

To combine all flows (which is the full GLUE Journey):

 

I hope this clarifies my thoughts better than my lousy other attempts on GLUE Journeys. I am always happy to learn more, so please comment if you are interested to share knowledge.

GLUE Journey - Do Business Defence

I promised to start exploring GLUE Journeys on the Island of Do Business Defence, and tried to apply a story like construct. I underestimated the difficulties I have to write that story like, so I decided to change the concept. Total dry approach now I fear, but at least started. The first step in the GLUE Journey in the GLUE Space of 72 steps be looked at.

“Knowing is not enough; we must apply. Being willing is not enough; we must do.”,
Leonardo da Vinci (1452 - 1519)

 
So to get it started here a diagram showing how the information flow is between Do Business Defence and the other GLUE deliverables:

 

• Do Business Defence follows basically the Nike Process for Business: Just Do It.
• Do Business Defence checks if Do Business Defence has been done right, e.g. reporting, analysis or audits.
• Do Business Discovery supports Do Business Defence to adapt to new things, as touched in Innovation and GLUE. Transformation and Test belong here.
• Develop Business Defence provides Do Business Defence the needed to support and defend As-Is.
• Do SoS Defence follows also the Nike Process for the System of Systems. It does provide the System of Systems support for the Business Deck.

Very important is that this concept assumes that a specific content can be mapped to one GLUE Deliverable. When I look at Deliverables i usually find them providing content in the whole GLUE Space, actually including people. The whole concept just helps me to understand how information is tied together: Reality is that nothing is certain and information is usually only partially available. It is a pure artificial construct to understand and map information and helps to seek for the right answers.

If I do not understand the current way of working in Do Business Defence I look in my mental GLUE model into the places where the current way of working in business was created (Develop), is supported (SoS), was transformed (Discovery) or how it is looked at (Detect).

On this area I know that I need input, because it is only clear to me, but I have not found a good way to represent it. So I usually keep it to myself, but this blog is about finding out how to express it (if there is any way to express it).

Innovation and GLUE

Again I fail to continue writing on the GLUE Journeys as promised but jump into another hot topic: Innovation. Actually I do not really think that it is new knowledge, but for whatever reason it seems to be hot. i personally utilize the knowledge Everett Rogers has provided us in his Diffusion of Innovations.

 

So why the hype around innovation? Following Rogers definition (innovation is "an idea, practice, or object that is perceived as new by an individual or other unit of adoption") and his model (the first 2.5% to adopt to an innovation are innovators) I wonder what makes it so interesting that everyone wants to be associated to innovation. (The funny thing is, even if all of us want to be innovative only the fastest 2.5% will be innovators).

 

“Innovation distinguishes between a leader and a follower.”,
Steve Jobs (1955 - 2011)

 

I believe part of it is tied closely to the success of Apple. Innovation is to me more a brand than something real. But given the fact that it is a real hype I give it also some focus. First of all in the GLUE Space I place Innovation into the GLUE Division Discovery.

 

Discovery supports the people to adopt innovations, again following Rogers definitions:

• Innovators
• Early Adopters
• Early Majority
• Late Majority
• Laggards

Due to the fact that it is so attractive to be innovative I now also observe some weird approaches, like using off-the-shelf-software not as intended but for something very different. In some cases that might be really innovative by bridging from one area of appliance to another, but in most cases this is just lack of common-sense advertised as out-of-the-box-thinking. Preaching for standards is a lost case against innovation evangelists.

 

By looking at Enterprise Architecture (not real EA) the Division Discovery is a core part to support the transition of the As-Is Architecture to the To-Be Architecture. As I have tried to point out in Enterprise Architecting Past, Future or Present there is no easy straightforward way (thank god, that secures my job), but here I take the more narrow minded approach around the Architecture Core Deliverables:

 

 

So what I think is that Enterprise Architects should lead in the transition from As-Is to To-Be and support the change. A Social Enterprise Architect should be equipped with the right tools at hand to support innovation but also the further adoption. Innovation alone is only a very small subset for Enterprise Architecture to support. And different techniques have to be applied for different stages of the solution:

 

1. Everything starts as an invention (part of GLUE Develop Destination)
2. Some inventions are innovative (part of GLUE Develop Discovery)
3. Optimization is needed to reduce costs on each variant (First Develop Destination to optimize, then Develop Discovery to get it adopted)
4. Harmonization as the next level of alignment is reducing the variants down to one
5. Shared Service delivers the functionality for many out of a small amount of people
6. Outsource delivers the functionality for the cheapest available price from the market

 

In my definition only one small area in this model is innovative and it is only one level on the solution evolution. All levels need to be supported by Enterprise Architecture and to make it even more complex the people who work in the different solutions must be taken into account. Any thoughts, comments? Feel free to contact me, I am happy to share knowledge, ideas, thoughts.

 

Enterprise Architecting Past, Future or Present

Yesterday I saw a message on Twitter which created an emotional reaction of mine. I tried to answer in 140 letters (the magic of twitter), but failed. I was not able to express what I really felt and did not made my point, which caused (of course) another reaction. The conversation was friendly and nice all the time, but I have an uneasy feeling that I missed my point completly. Very fitting to that problem there was yesterday also a quote:

“If you can't explain it simply, you don't understand it well enough.”,
Albert Einstein (1879 - 1955)

So, where was my problem really located:

Thought for the day: Is #entarch doomed because it wants what's best for the business and everyone else wants what's best for themselves?

By looking at this it is really eye catching for me is that Enterprise Architects are defined altruistic and everyone else egoistic. I personally highly doubt that the job profession has anything to do with being altruistic or egoistic. This is part of the person which fulfills the role, but not in the role itself.

Furthermore I have no evidence that the role Enterprise Architect attracts altruistic people, I instead believe that it attracts egocentric persons. Also the Deliverables of Enterprise Architects in most cases are to my knowledge far away from being the best for business. And that is the second statement which struck me in that one sentence. The superlative best. That would for me translate into: out of all Enterprise Architecture options the ONE best is recommended by an Enterprise Architect.

But my answer wasn't touching my points good enough at that point in time:

I highly doubt that #EntArch knows what's best for anything. Not to be known upfront, only known by looking back!

First sentence fits to my thinking, so point expressed. With the second sentence I tried to express that Enterprise Architects do not know the future, but can only make fact based statements about the past. Both of this needs some explanation. As I have pointed out my definition of Real Enterprise Architecture is kind of a holistic approach, but here I like to focus on the deliverables directly attached to Architecture:

Looking into the future is an interesting (but not always relevant) thing to do. In GLUE it belongs to the Division Destination. As a mathematical exercise the basic assumptions are:

1. Only one business (reality is that in most companies there is way more than one distinct business)
2. Only one System of Systems (In a very IT centristic approach this might exist, but taking shadow IT into account it is quite often still a flat out lie. In most companies there is more than one System of Systems, often reflected in Domain Models)
3. 5 Applications (Amount of known Applications can easily extend 1000, if unknown Applications are also counted it is easily more than 10.000)
4. 5 Software Elements in each Application (that translates into a VERY simple Application)
5. 5 Architecture Options to choose from on each GLUE Deck per year (unrealistic low number, I know)
6. Each of the options on each GLUE Deck is a realistic one.

Given that fact looking just one year ahead to give an architecture recommendation (what architects are typically asked for) there is 5*5*5*1*1 = 125 options to recommend.  Now in most cases Architecture changes need some time, so lets assume that we want to look 5 years ahead. Then the number is slightly bigger: 125*125*125*125*125 ~ 30 billion (each of the options give another 5 options) options. So who really believes that he is able to look forward, despite the thing which happens the next second. And remember the reality is worse, so the calculation for one year ahead is already way higher amount of realistic options. So in most cases I observe heavy simplification and self fulfilling prophecies by people working hardest towards their favourites and to a certain degree against what they do not like.

Ok, so lets try to look back. By looking at the past there is a high chance that someone asks for why did we select one option, even though there was this other brilliant option (a competition has decided for). Reality is, it was the same amount of options to choose from in the past 5 years than for the future 5 years. 30 billion options from the past, but ending up in a very specific one. Especially if the Enterprise Architect was part of the decision process (via recommendation) I often observe explanation variants which protect why the decision was taken as it was taken. (The only one I find acceptable is: Given the knowledge at hand at that time of decision we decided for the best to our knowledge at that time).

So  how to overcome this? For me it is a lot about living now, not in the future (GLUE Division Destination), because that specific future is most likely not coming true and not in the past (GLUE Division Defence), because it is gone. That puts up a lot of challenging questions when I am asked about a potential future and recommendations and a lot of challenges when I am asked to inspect and check for compliance, but I try my best.

Comments as always more than welcome to improve the ideas behind GLUE.