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.

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