GLUE Governance

Even though I promised to write about GLUE Journeys this is another topic I like to touch shortly.

I was challenged via twitter:

What is Governance, if not "sane and easy to understand rules, roles and responsibilities"?

I personally place Governance in the GLUE Space in Do Discovery, because it is the nature of Governance to inspect and connect and therefore support the transition from As-Is to To-Be and mitigate the friction in that.

I must admit, I have a tendency to stumble over governance proposals I see, which is in most cases just an emotion, a bellybutton feeling. I have learned to trust my emotions and feelings so normally I explore why I am uneasy with the governance at hand. Due to my role as Enterprise Architect I compare the governance with the architecture. And there I normally find the root cause for my feeling:

1. Dysfunctional Do Defence: The governance structure is not aligned with the As-Is Architecture, and therefore not able to defend the existing.
2. Dysfunctional Do Destination: The governance structure is not aligned with the To-Be Architecture and therefore not able to guide towards the future.
3. Dysfunctional Do Discovery: The governance structure is only aligned with As-Is Architecture or To-Be Architecture.
4. Dysfunctional Detect Defence: The governance structure does not have the needed information and facts about the current situation at hand to support an educated decision.
5. Dysfunctional Detect Destination: The governance structure does not have the needed information and facts about the future situation at hand to support an educated decision.
6. Dysfunctional Detect Discovery: The governance structure does not have the needed information and facts about the transition at hand to support an educated decision.

If one of the above statements is true then there is a high likelihood that Governance will lead to an unbalanced decision. And here I usually find the biggest threats and make my predictions about the success of an initiative.

“Good actions give strength to ourselves and inspire good actions in others.”,
Plato (427 BC - 347 BC)

So how to overcome the problem. Given the fact that there is a lot of influence from all sides it is sometimes literally impossible to enlighten towards a sane Governance. Depending on the nature of the influence it usually tips to one of the sides, either supporting As-Is or To-Be stronger. It rarely focuses on the transition which feeds a complete business: External Change Agents. Quite often these Change Agents are sourced via the very same Company which is delivering the new Solution. I believe that is highly risky, because now those who are supposed to support Do Discovery have their loyalty with those who Do Destination. Do Defence all of a sudden is isolated. If in a desperate situation that might be the right way to do it, but I highly doubt the long term success of that.

 

As an Enterprise Architect I try to provide guidance on setting up the right Governance by looking at the As-Is Architecture and owners of the existing Architecture. Furthermore I show the To-Be Architecture and therefore the needed Stakeholders which must own the future Architecture. If that is a different group of Stakeholders the initative will be very interesting in most cases, because friction is usually to come. On top of that I support in providing all facts I have at hand. Shared knowledge is double knowledge and typically the more relevant facts at hand the better the decision process. It is risky though that the relevant facts will be shed with interesting data. Preventing the anti-pattern "Lots of data, no facts" is a challenge in itself, especially because not all players are always interested in a holistic view. Actually in most cases only a very small portion is really interested to look holistic.

 

By providing holistic Enterprise Architecture input based on the relevant facts I believe others are able to hook in and support the overall vision and are also changing towards a more holistic approach. This require way more than good facts actually. I personally have more success if I do not only provide facts and information, but approach the persons behind the roles and statements they make due to their responsibilities.

Real Enterprise Architecture

Today I read a very good blog post (just another) from Tom Graves, which worked as a blockade runner for one thought of mine where I was not really able to put it into words.

“It is amazing what you can accomplish if you do not care who gets the credit.”,
Harry Truman (1884 - 1974)

As I have expressed in the GLUE Domains I observe a conflict between Enterprise Architects and the Business where quite often both the Business and Enterprise Architecture claim to deliver Business Architecture:

As written there is one main assumption behind this. Enterprise Architecture is the complete set of the Discipline Design across all Decks and all Divisions:

So a linear-paradigm Taylorism approach could be literally understood as just follow the Disciplines of GLUE and you know the input to Design (Architecture) and the output of Design:

The conceptual roles and responsibilities in GLUE is something different than what happens in real life. I am in the happy position to have officially the title Enterprise Architect, but if I look at the daily work then I am not only working in the Domain of Architecture as such, but I do work in the complete GLUE Space and actually 80% of my work (rough estimation) is based around working with people, even though my function is part of the IT. I believe a real Enterprise Architect has to work like I do (otherwise I would work different).

Having said this there is of course in all GLUE Domains potential conflicts, but I do not care who gets the credits, as long as the right solution is found and applied. To be able to work in the whole GLUE Space I had to develop myself from a Specialist to a Generalized Specialist. I started as a specialist, because that was all the market asked for (as pointed out also by Tom Graves) and lucky enough (by looking back it was more by luck than by plan) I always got the chance to add some other skills with a different angle allowing me to grow to more breadth.

Always remember the next larger context

Today I stumbled over a Tweet which contained following quote:

 

“Always design a thing by considering it in its next larger context - a chair in a room, a room in a house, a house in an environment, an environment in a city plan.",

Eliel Saarinen (1873 - 1950)

 

This quote perfectly defines how I set up my GLUE Decks. To just directly transform the quote to GLUE Decks it would look like following:
 

 

This is the very same concept behind my setup. If looking from bottom to top it looks like following: A piece of Software belongs to an Application which is part of the System of Systems which belongs to the Business:

 



 

The key challenge on this is to find a clear one-to-many relationship if looking from top to down. By looking from top to bottom look at the next level always as if it is a black box. By opening the black box Business there are System of Systems to be found and their interconnections. Each System of Systems contains Applications and their interconnections. Each Application contains Software elements and the interconnections between them. Getting the structure in a way that is is unambiguous is a challenge in its own, because the lower level elements might be used on more than one of the upper level elements. I usually repeat the work from top to bottom and bottom to top till I have a clear one-to-many mapping from top-to-down.

The elements which I can not map unambiguous give a good hint for a dysfunctional setup, because there is most likely no clear owner. And shared responsibilities are a challenge in itself which I touch in other posts as well.

GLUE Journeys

In my last post I have touched the concept of people in GLUE and where people are connected to the more computable part of GLUE:

As promised I will not touch people in this post, but start writing about GLUE Journeys. But then again as with all my other posts I of course have to take all existing GLUE concepts into consideration to show how it ties together.

“Voyage, travel and change of place impart vigor.”,
Seneca (ca 1 - 65)

So my first challenge is that the journey to write about GLUE journeys is quite a journey. And I had some problems in finding the right entry. My first attempt was to write it as complete posts, but that was already to long after I just put 10% of my journey thoughts into it. So now I am rewriting and restructuring it and I think I will give it another twist, more towards a journey report.
Therefore I will try to explain the concepts via looking at the Primary GLUE Deliveries:

I will start each post by exploring the Island to a certain degree (I have no chance to fully explore a single Island), the people living on the Island, the goods the Island produces and the ships which leave the Island and transport passengers and goods to other Islands. I will follow the ships, where they sail, their goods and their passengers. The first Island I start with is the Island of Do Business Operation. Before that Island I might squeeze one post in writing about the one who is writing the report, to introduce the concept behind. I hope to leave the dry area of GLUE Theory now and enter the GLUE Story Telling by creating a fictional story about travelling through GLUE.

People in GLUE

In my last post I explored GLUE Roles and Responsibilities. Each GLUE Discipline does have a specific Role:

A Role is assigned following the VARISC methodology to a GLUE Delivery which produces a GLUE Deliverable. GLUE Deliveries are organized in GLUE Domains (specialized if needed) and each of the Domains belongs to the GLUE Space:

“Pleasure in the job puts perfection in the work.”,
Aristotle (384 BC - 322 BC)

There is one aspect I have left out so far but is key for my work: People. People matter, actually the next person I talk to matters. And I mean it and try to live up to it. Of course that adds some complexity to GLUE, because People do not act as if they are machines. They have emotion, insight, feelings. They might like you and do therefore things for you which they won't do if they dislike you (and vice verse). They might try to max out on their personal success or live up to serve others. No matter what their motivation is people complicate things, because all of a sudden the result is not computable anymore.

So I personally focus on people. The main reason for me to give this blog the name "Social Enterprise Architecture" actually. Most of the success stories (and failures) I know are actually based on people success or failure. I personally believe that I need to touch people emotional with my Enterprise Architecture work to get it wanted, worked on and done in the end and to a certain degree I do not believe that Governance is the answer to make people work according to the rules, but that sane and easy to understand rules, roles and responsibilities including a high degree of freedom is the key. To explore the concepts behind GLUE a bit more (GLUE Journeys) I will leave out people for the moment but will come back again to that later.

GLUE Roles and Responsibilities

In my last post about GLUE Delivery I have put some focus on the delivery which is from my point the key for everything I do. Deliver, Getting things done, create something, add something. You name it.

“Trifles make perfection, and perfection is no trifle.”,
Michelangelo (1475 - 1564)

As I have tried to explain in my last post the GLUE Deliveries deliver the GLUE Deliverables. Quite obvious including a name generator for deliveries and deliverables. But who delivers, what are the roles and responsibilities? What does the statement "GLUE Deliveries are delivered by Responsible Roles" mean?

For the GLUE Roles I capitalize on the GLUE Disciplines by applying a generic GLUE Role to each Discipline:

1. The Stakeholder does deliver Describe Intention.
2. The Analyst does deliver Define Requirements.
3. The Architect does deliver Design Architecture.
4. The Developer does deliver Develop Solution.
5. The Operator does deliver Do Operation.
6. The Tester does deliver Detect Defect.

Similar as with GLUE Deliveries and Deliverables the full blown name can be constructed by applying a name generator approach: Role Name = Name of Deck + Name of Division + Name of Role for Discipline. By using this mechanic I can look into methodologies and map the corresponding roles into GLUE Roles to understand what basic techniques they must master to be able to deliver. That helps me in judging the CVs and people at hand when a new team member is offered or seeked for. That also supports me in looking into overlaps, because no matter what the official Job Title is, the GLUE Role, Delivery and Deliverable expresses what is done.

In the potential conflict between the Business Organisation and Enterprise Architecture which I explored in the GLUE Domains both, the Business Organisation and Enterprise Architecture do deliver Business Architecture. The challenging question of course is which organisational element does do what part of the delivery.

To support GLUE Journeys which I will touch in a future post I like to remind here short of responsible assignment matrix concept:

• Validating a Deliverable is done by Peers (same Role but not part of the Journey) and/or by those who receive the Deliverable.
• Verifying a Deliverable is done by Testers of the same GLUE Deck.
• Accountable for a Deliverable is the Owner of the GLUE Domain out of which the Deliverable is delivered, and this can of course be a Tailored GLUE Domain.
• Responsible is the corresponding Role as describe in this post.
• Informed is every Role which needs the information.
• Supportive is the Peers (same Role).
• Consulted is some Peers (same Role) who do not actively take part in the Journey.
• The general advice from me is to utilize collaborative approaches over cooperation approaches and try to prevent non-cooperation mode. Sometimes tough to achieve, but advisable to aim for. Most methods actually are only designed around cooperation approaches.

In my next post I like to explore the GLUE Journey concept to show how all of this ties together. As always please comment if you have the desire to do so. If not I will continue following my own path through my own thoughts with some difficulties to understand if I am still on track (understood by anyone) or totally lost in my own ideas. Well, they work for me, so at least that is kind of ok. :)

GLUE Delivery

In my last posts I have explored the GLUE Space and looked into GLUE Domains and how to tailor them.

“Without labour nothing prospers.”,
Sophocles (496 BC - 406 BC)

The GLUE Space in itself is a static construct and allows me to organize and understand. Special attention is needed on the GLUE Deck which I will investigate further with more examples in another post. But that does not deliver anything and therefore I need the concept GLUE Delivery. Getting Things Done is always most important.

• GLUE Deliveries are performed by Reponsible Roles
• GLUE Deliveries produce Deliverables
• GLUE Deliveries are organized in GLUE Domains
• GLUE Primary Deliveries are the Intersection of the GLUE Dimensions: Primary Delivery Name = Name of Discipline + Name of Deck + Name of Division
• Example: Design Application Destination (Architecture), Do Business Defence (Operation), Detect (Defect on) Software Destination
• GLUE Primary Deliverables are the Intersection of the GLUE Dimensions: Primary Deliverable Name = Name of Deck + Name of Division + Noun of Discipline
  
  • Example: Application Destination Design (or Architecture), Business Defence Doing (or Operation), Software Destination Detection (or Test)

The names of the Deliveries are of course artificial process names, but they help me to understand what is really going on, no matter how a methodology is phrasing that. The same applies for the Deliverables where I am able to analyze a given deliverable (no matter what way it is communicated) and map it into the GLUE Space for understanding. Reality is that in most cases information from more than one box is given (and I will not touch upon the motivation here, because there is many good and bad reasons to not be structural sane).

I need to investigate Responsible Roles next and I am awaiting your comments as always. The problem for me sometimes is, that it is crystal clear to me. But that is only in my head and I might be misguided by that. Therefore I need more feedback to understand where I have not given enough information (or made a big mistake by missing something crucial). The more feedback the better actually.

GLUE Tailoring Domains

In my last posts I have explored the GLUE Space.

And looked deeper into GLUE Domains. One example domain is the Application Life Cycle Management:

“Caress the detail, the divine detail.”,
Vladimir Nabokov (1899 - 1977)

By looking closer some problems become visible. One System of Systems can contain a large amount of Applications. The number can easily extend thousand Applications.  So GLUE oversimplifies here. To cover for that a closer look into the domains is needed. Due to the differences there is a high likelihood that the same approach can not be applied. Therefore I prefer to specialize inside a domain:

If looking at Application Life Cycle Management (or any other Domain) even though that the same mechanics are applied (GLUE Disciplines) the specifics make the difference. Something which is often to be heard as "this is special". At the same moment in time suppliers and integrators create their own methodologies and bring them to the market to defend against the others. If inside the GLUE Space in a Corporation the specialities can be captured by mapping them to the right domain and then seek in that domain for the commonalities.

So something like Governance to ensure that one area applies the same rules and follows them belongs into the same domain than the activity. I will touch upon that when I did into Roles & Responsibilities as promised. Important here is that not everything is the same, but can be mapped in the GLUE Space.

GLUE Domains

To find an answer to my GLUE Vision I have developed over my last posts the GLUE Space, which is the intersection of the three GLUE Dimensions.

1. GLUE Disciplines
2. GLUE Decks
3. GLUE Divisions

“Divide and Conquer.”,
Julius Caesar (100BC - 44BC)

I use the GLUE Space myself to map and understand frameworks, methodologies or approaches. To support the mapping I use the concept of the GLUE Domain. Each Domain is a part of the GLUE Space with defined boundaries.

EA - Enterprise Architecture

The basic assumption is that all Architecture Activities are covered by Enterprise Architecture. Therefore the whole Design Discipline in all Decks and all Divisions must be covered.

Business

The assumption is that running the existing organisation, setting the new destination, transforming and finally running the changed organisation is the ownership of the Business Organisation.

Conflict between EA and Business

 

By mapping the responsibilities of EA and Business into the GLUE Space the conflict between EA and Business becomes transparent. Both Enterprise Architecture and Business claim the same responsibility to design or architect the Business. This conflict creates friction which I hope to explore in another post in the future. I think that Conway's Law is one of the best descriptions of what happens there.

 

EITA - Enterprise Information Technology Architecture

To avoid the friction between Enterprise Architecture and Business quite often Enterprise Architecture is only focussing on EITA, the IT part of the Enterprise Architecture. The pushback and the reasoning behind can easily be observed in many forums where evangelists of all methodologies discuss literally endless about the boundaries between the different professions. For me it is quite simple by using GLUE: There is overlaps, so please get over the conflict and start collaborating (work together towards the same vision) if possible or at least cooperate (clear interfaces, roles and responsibilities). Non cooperation (mine, yours, bugger off) is not really helping to solve the situation at hand. Tom Graves was exploring that issue greatly on one of his last posts.

 

Application Life Cycle Management

Application Lifecycle Management is a typical responsibility of an Application Owner. This is a function which can mostly be found inside of IT and some interesting potential conflicts (similar as the example above)  to run departments where definitions of first, second and third level support try to create clarity (and pity enough fail often).

Test Execution

Similar issues exist arround Test Factories. For simplicity I have only shown the domain Test Execution here which covers all activities to execute tests in the whole Enterprise. Here potentially a lot of conflicts exist with some interesting questions to be answered.

In future posts I hope to find the right words to touch Matrix Organisations as well as some specific answers from the market to specific problems. I will try to use GLUE to explain that but most likely the next post is about Roles and Responsibilities.

Feel free to comment and guide me towards topics you like to be explored by GLUE (if there is any). The more input I get the easier it is for me to explore it.

 

GLUE Space

In my last posts I started to explore GLUE to formulate a common approach to all forms of engineering:

General Process Framework with
Loose Coupling of Process Components using a
Unified Approach for
Engineering in all fields.

The GLUE Space is the complete 3-dimensional frame to support all kinds of engineering processes. The first dimension is the GLUE Disciplines which form the generic engineering value stream:

 

The second dimension is the GLUE Decks which depend on the problem space to be looked at. As an example I used a fairly standard (artificial) setup for different engineering layers on top of each other:

The third dimension is the GLUE Divisions which are the different perspectives on engineering:

The intersection of these three dimensions now builds the cuboid:

“Imagination is more important than knowledge.”,
Albert Einstein (1879 - 1955)

If I now face a methodolgy, a framework or an approach I map that against GLUE. Enterprise Architecture for me for example are all architecture activities of one enterprise:

While Enterprise Information Technology Architecture is only containing the IT part of Enterprise Architecture:

So each and every method I face i map into GLUE and know therefore the part of the engineering scope it does deliver. That allows me to know the right process interfaces (if needed also technical implemented) so that any given initative is optimally supported in the GLUE SPACE. To explain that even further I must dig into GLUE Activities, GLUE Domains and GLUE Roles next.

Feel free to comment and contact me. I am more than happy to share knowledge and experience and I will try to answer questions (if there is any), be it public or private.

GLUE Divisions

I started writing about the GLUE Vision:

General Process Framework with
Loose Coupling of Process Components using a
Unified Approach for
Engineering in all fields.

And continued my exploration with an 1-dimensional approach, the GLUE Disciplines:

Then I added the GLUE Decks with following example:

The intersection of Disciplines and Decks form the 2-dimensional approach of GLUE:

I believe that in most cases there is a different perspective on what is needed and therefore a different focus.

“What we see depends mainly on what we look for.”,
John Lubbock (1834 - 1913)

GLUE Divisions is the concept I use here. Each Division delivers to the overall success, but has a different perspective:

1. Destination aims for the future
2. Discovery aims for transformation
3. Defence aims for stability

Typically IT Organisations reflect that by structuring the organisation in a Plan, Build, Test, Run way. There is a different mentality and way of looking at the world attached to the 3 divisions. Having all three mindsets together (and I come to Plan in another post one day hopefully) allows to deliver towards all needs. In many cases one or the other dominates, but that is another topic.

To be able to deliver towards destination, discovery, defence in a good engineered way the now three dimensions of GLUE must be combined and form a cuboid:

So it is now just another boxed approach to put the right activity into the right area (e.g. Define Business Destination Requirements, Design Application Defence Architecture or Do Software Discovery). I will explore some other concepts in this over the next posts, because I fear it is still too simple to describe the full picture.

Glue Decks

I started writing about the GLUE Vision:
 

General Process Framework with

Loose Coupling of Process Components using a

Unified Approach for

Engineering in all fields.

And continued by writing about the GLUE Disciplines:

 

1. Describe Intention
2. Define Requirement
3. Design Architecture
4. Develop Solution
5. Do Operation
6. Detect Defect

I believe that in most cases things build on top of something else and rely on each other to be successful.

“For a tree to become tall it must grow tough roots among the rocks",

Friedrich Nietzsche (1844 - 1900)

GLUE Decks is the concept I use here. Each Deck is supported by the underlying deck and relies on it. For an example company the setup might look like this:

1. The Business is supported by one System of Systems (the whole IT).
2. The System of Systems contains Applications.
3. An Application contains Software Components.

Another example setup could look like this:

1. The Business is organized in Units.
2. Each Unit is supported by its own System of Systems (Domain).
3. Each System of Systems contains Applications.
4. An Application contains Software Components.

To support a combination of global aligned applications and unit dependent applications I would model the shared functions in this example in the unit deck.

To get the decks delivered the intersection between the GLUE Disciplines and the GLUE Decks is needed:

So now it is not that simple anymore, but still following a very simple principle. Each of the decks can follow the same process structure and the disciplines in that process require the same kind of skillset and same approach to look at the problem space. Be it creative (describe), processual (define), structure (design), constructive (develop), safety (do) or destructive (detect).

GLUE is now two dimensional and it is possible to describe many concepts with these two dimensions as I plan to do over the next posts. But I still believe that the reality can not be pressed into two dimensions only so in my next post I will add another dimension to the GLUE Space.