Kai Schlüter

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

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. 🙂

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.

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.

Today I saw a statement on twitter which caused some instant reflex of mine and I answered to that post by linking to my post “Always remember the next larger context”.”If change is happening on the outside faster than on the inside the end is in sight…

In my last post I was writing about Fixing Flows, which was just an example answer to GLUE diseases. What I literally always try to apply is the agile manifesto: Individuals and interactions over processes and toolsWorking software ove…

In my last post I was writing about GLUE or Architecture Diseases and apparently one of these diseases hit me recently. I was tasked to work on Application Lifecycle Management and in our Architecture Community we had some really great discussion on ho…

In my last post I was writing about Tomorrow is Today. About working and being right now, this very moment. And I believe that is key, as I tried to point out in other recent posts, e.g. Architecting Past, Future or Present. Today I shortly like to tal…

As I have written in my last post I believe that Enterprise Architecture is inevitable happening, no matter if it is done the one way or the other. I personally sense a lot of tribal thinking in the Enterprise Architecture community where in the heat of the discussion I sometimes wonder why there is so much talk about two sides (e.g. EITA vs EA) or even three (three schools of EA) or towards others (IT vs Business). I personally believe that the whole is a circulatory system which is always happening:

So I believe the right discussion should be along the line: how do we make the flow through the circulatory system (GLUE is just a model to reflect that) optimal instead of focusing on setting up boundaries and controls to ensure that a specific role works in a specific box. So overlaps, as described in an earlier post, is not bad if you ask me, but in fact very healthy, because to succeed not one person can decide on his own limited knowledge, but it forces people into working together, ideally collaborating or at least cooperating.

Non cooperation is a quite common pattern here though, and that is exactly what I sense in the Enterprise Architecture Community way more often than I personally understand, because it leads to nowhere. This is a discussion no one can win, because both argumentation chains (or the three of them) are valid and will be valid forever. The reason is fairly simple: By choosing a leading approach to Enterprise Architecture (be it a framework or a person) which we then follow, we focus on the difference, the unified selling proposition of that specific framework or leader. That ultimately leads to a scattered approach to Enterprise Architecture, which is a joke by itself, given the fact that most Enterprise Architects preach for standardisation across all functions.

My almost 4 year old son was a source of inspiration (once again, as well as his siblings) for me, by making a great quote:

So what is my answer: I focus on the similarities, the common pattern. The things which unite Enterprise Architecture and are indeed the same. I think there is way more in common between the different approaches (and that includes Business Architecture, Project Management, Strategy, Innovation Management and many other things) than we allow ourself to accept and see. We kind of play the game of the three apes, and I wonder why.

Due to that I will focus in my future posts on something different than core Enterprise Architecture: What to learn from others is my leading theme for the next posts. Of course, as always, comments are welcome. So if you want me to look into something else which I only scratched so far then please let me know. Input from the community helps me to get my thinking straigthened.

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 …

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 bu…