Evolution of IT - Stage 1 - The Developer

I failed to write the book (actually two) which I planned to do as mentioned in an old blog post. It almost killed my blogging, because I put my writing energy into the book, but never really managed to get something to paper (or leanpub to be more precise). In fact it pretty much felt like Gerhard Polts "Der Gedanke". If you are interested a link to a audio file on youtube (in german).
 

 

 

So instead of continue to failing with the book I plan to write more blog posts again and I will use some of the thoughts I had for the book in a series of posts. I will try to share my mental model (inspired by Tom Graves and his great and interesting post "How do you think?"). My conclusion is total different than his, but that is something I reserve for another post. You might have read about my thoughts behind GLUE, and this is what I will try to re-explain in a total different way. My working title for the moment is Evolution of IT and I will start with Stage 1 - The Developer.

 

Unce upon a time a person was facing a a truly challenging problem. This person had an idea how to overcome the problem, an idea which was most likely based on collision of other ideas, as Steven Johnson puts it so great in his book Where Good Ideas Come From. To solve the challenge this person developed a solution and was therefore the first Developer of a new tribe.

As I have put in an old post of mine, this is the only value adding activity of IT (the new tribe) and therefore it is brilliant that the developer is all alone and can therefore contribute with 100% of his time to value adding activities. The other good news is that there is plenty of new tribes founded all over the place. Many of them are rooted in so called shadow IT or based on hairball architecture. As I have put in an older post of mine hail the hairball architecture, because there innovation is born. (There is of course also quite some negative aspects in hairball architecture (e.g. the loss of transparency and the wasteful approach to resources), but I will come to that aspect in later posts of this series.

In my next post I will write about the first contact between the Developer and another person from another tribe and how that has changed the life of the developer.

GLUE Journeys - Obvious missed take 2

It is a while ago since I was exploring the GLUE Journeys and found a diagram and explanation mistake and fixed it in my post GLUE Journeys - Obvious Missed. And of course, there is more mistakes and in the very same diagram I made another mistake.

Only the flow in the Division Destination is correctly displayed. The other two Divisions Discovery and Defence are missing a flow between the Discipline Describe and Define. So here is the new updated diagram covering the idea now more complete. If you find any mistake in my thinking or like to discuss my thoughts and the way I represent them please feel free to contact me.

Update: And then I made another mistake a couple of weeks later by deleting the wrong files. :)

Enterprise Architecture Domains

It has been a while since I posted last time, because I was pretty much occupied in my job to deliver some interesting projects on the edge between 2012 and 2013. Lucky enough I was able to deliver. :) On top of that there was a portion of Christmas preparation and a new private project with a Iceland Dog.

So now it is time for the first post in 2013. I was triggered today by a tweet from Keith Flanagan: "Enterprise Architecture is about people. Not domains!". I do not know what triggered the statement for him, but I am sure that he is right as tried to put it more than once in my own blog here, e.g. People in GLUE. My primary focus in my Enterprise Architecture work is clearly the people.

Nevertheless, I do believe that people and Domains (could be GLUE Domains, could be other Domains) are pretty much related. I believe most if not all Domains (and the resulting Domain Models) do exist to somehow create an area of responsibility or an empire. The thinking behind the GLUE Decks is also based on Domain thinking.

The Deck System of Systems can easily be split into several Domains for grouping purposes or to create a silo or an (as much as possible) area of responsibility. I think the Domains exist in the typical Enterprise and should therefore be identified, named and analyzed. I furthermore believe that in most cases there is a fairly clear hierarchy between the Domain and the Applications in that Domain. And quite often conflicts exist exactly where that hierarchy is not clear, where an Application belongs or should belong to more than one Domain. And I think what can be observed here is once again Conway’s Law.

I therefore have to explore Nick Maliks tweet deeper: "Autonomy is a necessary intrinsic motivator. EA must replace "empire building" with different autonomous goals." I am not sure if that is correct or not. I personally typically accept the given domains and work more as a mediator (or GLUE) between the various domains by looking for GLUE Diseases and trying to fix them. And as far as I remember it was always about people and always about communication, but maybe I have done it wrong or not used the full potential. Therefore I am happy to hear comments and ideas how to shift away from the standard empire building or tribe thinking towards something more holistic. I am not sure if that is truly possible.

Comments are more than welcome.

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

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.

Less Is More

In my last post I have written about the concept to compare Enterprise Architecture with the Matrix. In short: free your mind and open up for all the possibilities. There is no reason to stay inside the boundaries provided by the various frameworks and models. They are helping, but not the answer. The real change happens by working with the people and there is the place where the real Enterprise Architecture is happening. With and through the people.

Today I have read an interesting post of Tom Graves where he brought Ric Philipps and his definition of Enterprise Architecture being an antipattern to my awareness. The result is that I follow (just another) Enterprise Architect, which is great. The concept in that particular post is interesting, because Enterprise Architecture adds another level of complexity which might easily outweight its benefit. I personally see Enterprise Architecture (as any other form of Architecture) as waste.


There is a particular element I really like about Ric Philipps' post. And that is the underlying principle minimalism. Ludwig Mies van der Rohe has used that principle greatly (very subjective) for his approach to architecture. By reducing the definitions (frameworks, models, you name it) to the absolute minimum the Observer Effect is minimized as well. Highly complex models (amount of definitions and relationships) have indeed based on my own observation a high tendency to disturb and create more noise than sense. (e.g. the discussion about UML extend and include, or the various complexity models).


If you ask me the model of the world could be flat, like in discworld (despite the turtle and the elephants, that is not needed to explain it). It does work for my daily life. And even though I know that the world is a globe my senses tell me something different, because they are more sharp on experience which is directly connected to my physical experience, and almost all things I need work for that model. (Actually a map is nothing else than a 2-dimensional model of the world). But of course I am not very religious on that 2D model, most likely because I just use it and did not invent it. On GLUE i might think different, the future will tell.

Nevertheless the boxing and framing is also very useful, as Seth Godin has put it so great in his post "I want to put you in a category". The interesting thing for me is not only the boxing itself, or being trapped in the Overconfidence Effect, but especially the friction and tension created by two (or more) tribes defending their own believe and thinking (almost) to death. Of course there is a short term negative effect (and there was some very destructive examples of that in the past), but all that energy usually also creates something new, something which has not existed before. So it is very interesting to observe the heavy (and very emotional) discussion in the complexity models around Enterprise Architecture at the moment. Even though there is a lot of bad feelings on all sides I personally believe that all this negative energy has a good chance to create something new which the world has not seen before.

given up on balance

A blog post of Amanda Fenton about balance reminded me about a core concept I use in the space of GLUE and the change introduced via GLUE. In my post Fixing Flows I wrote about the joy of getting something to work and therefore eliminating a GLUE Disease. Maximizing the throughput in the GLUE Space in each and every domain is what I am aiming for and unfortunately the slowest domain decided upon the speed of the whole GLUE Space.

So what is my key to success here? I try to achieve balance (all domains do have almost the same throughput) by giving up on balance myself. Now that seems to be counter intuitive, but it is exactly what I do:

 

To achive balance I give up on balance!

 



The key aspect behind this thinking can be found in my way of tackling complexity:

1. In the simple domain there is no need to give up balance.
2. In the complicated domain there is limited need to give up on balance, but in a very controlled way.
3. In the ambiguous domain there is permanent need to give up on balance, but action can be done one by one.
4. In the Not-Known domain balance does not exist.

I like to use the analogy of walking:

1. Standing on both feet in balance
2. Decide where to go ("automatic" after the initial decision where to go)
3. During the step out-of-balance
4. continue with 1

Therefore to move the Architecture from one state to the other (As-Is -> Transition Architectures -> To-Be Architecture) the whole system gets out of balance all the time, because it is the only way to move. The whole GLUE Division Discovery is completely dedicated to out-of-balance behaviour, so the same flow as walking with GLUE terminology:

1. GLUE Division Defence (As-Is)
2. GLUE Division Destination (To-Be)
3. GLUE Division Discovery (Transition, get to the target)
4. continue with 1

In a perfectly running GLUE the next To-Be is close to automatic (or at least very fast), which translates into a system where the change between balance and non-balance is done so fast and automatic that everything is perfectly in flow. In most cases I find (or throw myself at) systems where the flow is out of balance, but the system stable (and unwilling to change). Here I give up my own balance (entering willingly Not-Known) to create a momentum to change.

And I do not know why, but this flow of events is kind of a Zen feeling for me: things happen unpredictable and real time around, with and due to me while I try to categorize (EPIC SCAN) them, set a direction (WISE SCAN) and support the execution (PACE SCAN). In most cases this require to be very flexible with the methods and tools and therefore I apply most of the time (80%) agile techniques. And here the technical tool I use is a whiteboard and markers.

Complexity SCANs in GLUE

In my lasts posts I was exploring complexity and how I tackle the problem of complexity by applying my GLUE thinking to it. Therefore here a short summary so that my thinking about complexity up to now is collected in one place. I am using the SCAN framework of Tom Graves and connect it with GLUE by applying it to the GLUE Divisions and the GLUE Discipline Detect:

In GLUE Detect on Defence the EPIC SCAN is used to analyze the root and severity of the complexity:

• Emergent Complexity - consequence of many small and unrelated decisions and actions.
• Perverse Complexity - consequence of clumsy attempts to reduce complexity.
• Irreducible Complexity - consequence of real complexity of the demand environment.
• Contrived Complexity - consequence of deliberately creation to benefit some stakeholders.

In GLUE Detect on Destination the WISE SCAN is used to analyze the potential and the desired future state:

• Worth - A future capability must be worth the investment.
• Informed - The decision to invest into the future capability must be fact based.
• Simple - The most simple solution must be selected (to minimize future complexity)
• Environment - The solution must be embedded in the greater contex.

In GLUE Detect on Discovery the PACE SCAN is used to analyze the speed of tranformation:

• People - because one person can (and most likely will) make the difference between success and failure.
• Adaption - because the solution must be adapted to serve the people.
• Communication - because communication is key to ensure that the solution serves the people (and is accepted by them).
• Emphatic - because sensing also the unspoken is needed to be able to deliver and help that people and solution form a perfect fit-to-purpose environment.

All of this is needed to optimize the journeys through the GLUE Space and there is one good advice: Don't Panic.

 

PACE SCAN

In my last posts I explored the world of complexity and started with Don't Panic. An advice which does not only work for GLUE and Enterprise Architecture but is generally a fairly good advice. The some ideas collided in my head (which reminds me of the great Steven Johnson and his Where Good Ideas Come From) and I therefore wrote about EPIC SCAN for the GLUE Division Defence and WISE SCAN for the GLUE Division Destination. Both techniques which i use in my GLUE thinking and therefore my daily work for quite a while but which I could not formalize more yet. Tom Graves SCAN framework allowed me to find a way to formalize it a bit more. I had difficulties with WISE SCAN but finally found a way.

So one GLUE Division is missing: Discovery. Here I use the PACE SCAN:

• People - because one person can (and most likely will) make the difference between success and failure.
• Adaption - because the solution must be adapted to serve the people.
• Communication - because communication is key to ensure that the solution serves the people.
• Emphatic - because sensing also the unspoken is needed to be able to deliver and help that people and solution form a perfect fit-to-purpose environment.

And for those who have not figured yet: Besides enjoying working in the space of chaos, because here the really cool new things (and a lot of stupidity) emerge I also love working in the GLUE PACE SCAN to find a way through the chaos.

WISE SCAN - Revised

In my last post I was writing about EPIC SCAN, a combination of two great sources of knowledge including a reflection on how I use it. Emergent, Perverse, Irreducible and Contrived existing Complexity is SCANned for how complex it really is. According to the result (Simple, Complicated, Ambiguous, Non-of-them) a way of working, mindset, skillset is applied in a holistic way to optimize the flows through GLUE.

There is a challenge left, because the EPIC SCAN only works for sensemaking which I place in the GLUE Division Defence. The question is now how to apply the SCAN in the Division Destination. For that I use the WISE SCAN:
  

• Worth - A capability developed in the GLUE Division Destination must be worth to start the transformation in GLUE Division Discovery..
• Informed - Collect information (if not already at hand) so that a decision is as much as possible and needed based on facts. Just Bareley Good Enough from Scott Ambler might be a source of inspiration here.
• Simple - Select the most simple solution which works. KISS from Michael Vizdos might help here.
• Environment - Ensure that a future complexity is embedded in the greater contex.

Feedback as always more than welcome.

EPIC SCAN in GLUE

In my last post Don't Panic i touched upon complexity, a topic which seems to be pretty hot at the moment by looking at various twitter messages and fairly recent blog posts. Richard Veryard has touched the topic in a quite interesting way in his post On The Causes of Business Complexity. What I particular liked in his post was his four causes of complexity:

• Emergent Complexity - consequence of many small and unrelated decisions and actions.
• Perverse Complexity - consequence of clumsy attempts to reduce complexity.
• Contrived Complexity - consequence of deliberately creation to benefit some stakeholders.
• Irreducible Complexity - consequence of real complexity of the demand environment.

 I like to reorder that slightly without really changing the context, because working in complexity is epic.

• Emergent Complexity
• Perverse Complexity
• Irreducible Complexity
• Contrived Complexity

To tackle the EPIC Complexity I can now use the SCAN Framework. and by that create sense, aim for decisions and look for the right skill and mindset. A topic which is also tackled by Shawn Callahan in his post When Should We Collaborate, where he also refers to Cynefin and links a way of working to complexity:

• coordination for Simple Problems
• cooperation for Complicated Problems
• collaboration for Complex Problems
• Any method for Chaos to shift to one of the other three complexity domains

I agree with his judgement of the first three levels of complexity but I am more willing to follow Tom Graves approach in the fourth domain. In his post Sensemaking - Modes And Disciplines he sees working and acting as an Artist (inner value) as the answer to Chaos. In this one I full agree, because I believe the other three working models (and roles in Toms post) will only find unknown areas of their own domain in the unexplored space of Chaos.

So I call that now the EPIC SCAN.

So how do I link this knowledge to GLUE. First of all I look into optimizing or fixing the flows in the GLUE Space. Here applying the right approach to way of working and finding the right skill and mindset is in most cases more important than finding the perfect answer. The people will find the right answer inevitable if their skills and mindset fit to the complexity domain. If the fit is not given then they will try to shift the complexity into another domain or start being frustrated. A typical statement here is: "If X would just understand me".

And unfortunately there is no Silver Bullet to it. Not even Ken Schwaber markets the methodology SCRUM that way. In a recent post he clearly links SCRUM to the complex domain (where the unknown is greater than the known). In spaces where the known is greater than the unknown SCRUM creates more waste than needed and other methods (if applied correctly) will produce results in a less wastefull way. The challenge is to find the right method to maximize Value Add. And for those who are still unsure: the complexity area where I love the Domain Enterprise Architecture most is in the Chaos, no matter where in GLUE.

Don't Panic

Janne J. Korhonen has written a nice and worth to read blog post: There is not a simple solution to every problem, in which he was bringing me Cynefin back to my mind:

• Simple Problems can best be solved via Sense-Categorize-Respond (Best Practice).
• Complicated Problems can best be solved via Sense-Analyze-Respond (Good Practice).
• Complex Problems can best be solved via Probe-Sense-Respond (Emergent Practice).
• Chaotic Problems can best be solved via Act-Sense-Respond (Novel).

Tom Graves has created his useful SCAN framework and compares SCAN here with Cynefin. SCAN divides the sense-making and decision-making also in 4 different buckets:

• Simple and Straightforward
• Complicated but Controllable
• Ambiguous but Actionable
• Not-known, None-of-the-above

As I have written in People in GLUE the difference between success and failure lies in the success of failure of a person, because a person can make the difference. The key reason why in the GLUE Framework the focus is on people.

"Don't Panic",

Douglas Adams (1952 - 2001)

"Don't Panic" is the cover of "The Hitchhiker's Guide to the Galaxy" and in the novel it is explained that the title has two reasons. The first reason is, because the device looks insanely complicated and the second reason is to keep intergalactic travelers from panicking. I personally believe that most Enterprise Architecture frameworks could use a title like "Don't Panic", because the Frameworks look insanely complicated and to prevent those who travel through Enterprise Architecture either by applying or consuming it to panic.

In my GLUE approach I use the concept of the GLUE Decks to tackle complexity. As a reminder there is always a one-to-many relationship between the decks:

While I observe and support the GLUE Journeys through the GLUE Space I match the complexity of the solution to four levels:

1. Re-Use of an already existing solution without changing the solution itself. Most likely high potential to automate or already automated.
2. Re-Use of an existing Architecture (GLUE Discipline Design) so that real changes happen only in build and therefore potentially also on a lower Deck. Off-the-shelf and cloud solutions belong into this category.
3. Change of the Architecture by adding elements which are not existing at the moment.
4. No Idea how to solve the problem

Important aspect here is that the complexity level on the different decks can vary quite dramatic. Therefore to find out the complexity of a potential solution I apply a simple max() function on all Decks and elements in one Deck. The highest complexity decides about the complexity of the overall solution.

In most cases there is a fairly simple answer (Good or Emerging Practice) to most Desire, which is transforming into an existing standard off-the-shelf solution. That transformation is in most cases as an initial starting point not acceptable ("we are special", "we do not accept that our process is dictated by a software supplier" or "change the process without changing the IT solution and get all imaginable benefits"). Reality is that in most cases an adaption to an existing off-the-shelf-solution is a good fit-to-purpose and fairly easy (complicated, complicated but controllable, Re-Use Architecture) to use solution.

The typical conclusion for me is to go to the persons and work close with them. Helping them in seing the potential of a solution even if it means to give up some of the Intentions and Requirements. Interesting enough this is usually not achieveble by pure facts but requires a quite intense person to person work. So Don't Panic, work with the persons. People are relevant, the problem and the solution is only interesting.

A matter of perspective

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

"The world is given to me only once, not one existing and one perceived. Subject and object are only one.",

Erwin Schrödinger (1887 - 1961)

The interesting challenge I personally observe in Enterprise Architecture each and every day is to ensure that the existing and perceived world are synchronized to be recognized as the same. On top of that the IT world has created another challenge which now requires that the existing world, the artificial reflection of the world, the perceived existing world and the perceived artificial reflection of hte world needs to be synchronized. As I have written in "Always remember the next larger context" the challenge is to find the one-to-many mapping in the GLUE Space to ensure an accurate artificial reflection of the world and therefore synchronize the real world with the artificial world.

Imagine a company which is multinational and organized with a global, regional and local organizational setup. To keep it simple the artificial reflection of the world could be done by harmonizing all processes in the world and deliver a one size fits all approach:

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

GLUE Value Add

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.

“Short as life is, we make it still shorter by the careless waste of time”,

Victor Hugo (1802 - 1885)

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.

Glue Decks - Represented Different

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.",

Jack Welch, former CEO, GE

I do not really believe that the end is in sight, but what I believe is that the next larger context will fix the problem at hand and that indeed can mean that the inside comes to an end. To translate that into GLUE I use the concept of the GLUE Decks, where one Deck relies on the other Deck:

Another way to represent this is to model one Deck inside the other according to the above statement, but the message as such stays the same.

If something is dysfunctional in the inner element then the feedback flow through the outer element will fix it by either forcing the inner part to adapt or by eliminating the dysfunctional element. The circulatory system takes care of the solution, if not inside then via outside elements:

Agile GLUE

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 tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

 

The first line is a key concept of GLUE. I put the individual person and the interaction with people in the center of GLUE. A person makes the difference, not the process or tool at hand.

 

 

What really wonders me sometimes is the obsession (or tribal wars) between different so called agilists which method is the best. I am not a native speaker, but I believe that the sentence "Individuals and interactions over processes and tools" translate into that a discussion about the method or tool set is the wrong discussion if in doubt. So talking about SCRUM or Kanban (both processes or tools) is just the wrong discussion. Talking with the individual person and interact with the person is more the right thing to do. Applying SCRUM and Kanban is therefore a good thing to do (as many other concepts), but talking about it is a complete different story.

 

The second line is a concept which I personally find to narrow minded, so I have enhanced it in my own thinking towards "Working solution over comprehensive documentation". The whole focus of GLUE is to get things delivered. This is reflected in two dimensions. First of all the GLUE Disciplines and then the GLUE Divisions.

 

Customer Collaboration over contract negotiation is a concept which is only briefly covered in GLUE. The Roles and Responsibilities describe how the (artificial) roles are in their deliverables dependent upon each other. But what really matters here (again) is the customer or better the person behind the customer. Contract negotiation is in my mind just a tool to get an agreement in place. Therefore the third line seems to be pretty much the same statement to me as line one and therefore I apply the people centric thining and working with the customer as much as with anyone else.

 

Responding to change over following a plan is the last change and I try to tackle that by looking at the GLUE Space as a circulatory system. The faster the flow is circling through the system the higher the capability is to react to change.

 

 

To keep it simple I do not try to press in a specific method or tool which claims to be agile into the concept, but just apply the agile manifesto itself. Comments are more than welcome.