Sunday, September 30, 2012

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.

Thursday, September 27, 2012

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

Thursday, September 20, 2012

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.

Tuesday, September 18, 2012

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:

Monday, September 17, 2012

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.

Friday, September 14, 2012

Fixing Flows

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 how to tackle it in the specific context. With respect to GLUE and especially the GLUE Decks we have been looking at the two lower Decks of my example:

For two sessions in a row we couldn't get a good drawing, because the (many) existing process drawings in the market are mainly tool specific, but for sure not fitting directly into the context of my current assignment. (which is a very typical problem and lead me to creating GLUE).

So i used my GLUE thinking to stay focused to the problem at hand and not getting distracted by all the specialities you always find. Furthermore it helped me once again to stay vendor agnostic, so that no existing tool in the market confuses the discussion about the wanted To-Be Architecture. Having said that I of course know, that the reality will look different than what we have created, but a certain investment into the future is needed to ensure that an adoption can take place.
The really interesting thing though was, that it did not work out in the beginning. The solution emerged by utilizing the knowledge of people inside the Application and Software Deck and by combining a presentation with the power of the whiteboard. By sending the presentation to apear on the whiteboard we have been able to draw our process ideas directly into existing process models in an fast and agile way and a new way to represent the idea emerged. Once more it was obvious that strictly following one way to represent a process as typically enforced by the various tools (and there is many in the market) would not have brought us to our desired target.
So fixing the flow and ensure that the GLUE Journey can continue was the key here to be able to get to a solution and I did not use many Architecture skills, but mainly communication approaches. I highly recommend that you spend some time on Agile Modeling from Scott Ambler.

Wednesday, September 12, 2012

GLUE Disease

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 talk about the concept GLUE Disease and it is related to learn from others.

"He who conceals his disease cannot expect to be cured",
Ethiopian Proverb

So a quote from Wiki: "A disease is an abnormal condition affecting the body of an organism." So how do I translate that into GLUE and Real Enterprise Architecture? By looking at the GLUE Framework and particularly the Circulatory System the analogy is between the body and the GLUE Space.

So what is a GLUE disease then. Actually any dysfunction which causes the whole system at hand to start working unbalanced. The flow of information between in the circulatory system is the key for me to find out if something is going wrong and how wrong something is going.

Some examples (and the list is for sure not complete):
  • New audit finding are found faster than solutions to the findings are build (GLUE Disciplines)
  • New solutions are build and pushed in before the effect of a former solution has been checked (GLUE Disciplines)
  • New solutions are pushed back and enforce changes in destination and discovery (GLUE Divisions)
  • New solutions are build and pushed in before the organisation has adopted to it (GLUE Divisions)
  • Integration into a higher Deck enforces changes on the higher Deck (GLUE Decks)
  • New requests for one Deck are faster created than the lower Deck can integrate into the upper Deck (GLUE Decks)
By observing the flow of logical information , no matter who in the organisation does the particular delivery, I am able to find dysfunctions or diseases. These diseases are usually giving good signals where to focus to sort out architecture obstacles. My believe is that a steady flow of information in a balanced way is a signal of health. At the moment in time when that flow is unsteady or even worse completely blocked the GLUE Space becomes unhealthy. One area can easily spread to other areas and put the whole at risk. These areas I usually focus on and try to fix to let the flow be steady again.

In my next posts I like to explore the different techniques deeper on how to optimize the flow and what techniques to use. On top of that the what to learn from others series is under preparation. Feel free to comment or ask whatever you want via any channel you want to utilize.

Monday, September 10, 2012

When Tomorrow is Today

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:

"When Tomorrow is Today",
Kalle Friedrich Schlüter (*2008)
That was just straight put where the focus should be: right now, this very moment. For him the concept of future does not exist yet. So he has to use the present to explain the future, and reality is, believe it or not, we all use that same concept, even though our grammar rules (for the languages I know) pretend that future can be expressed. As written in "Enterprise Architecting Past, Future or Present" I believe the absolute focus should be on the present, because it is the result of the Past and Leads to one out of many Futures. There is also a song from the young Billy Joel, even though is focus was not Enterprise Architecture, about the challenges of the time.

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.

Saturday, September 8, 2012

GLUE - Updated Framework

In my last post I have updated and corrected the GLUE Journeys to put my thinking in the model after some reflection on my own writing triggered by reading my own thoughts and especially by some comments I received. This of course has an effect on the GLUE Framework in the context of Social Enterprise Architecture which I now have to reflect.
Having written this the interesting question is: what makes the circulatory system work. The answer is very simple: It always works and it always creates the result based on communication between the people as it was put in Conway's Law. And communication between people is not a stable construct but something which is very flexible and undergoing a permanent change.

So how are people organized?
  1. The first dimension is the organizational structure, where people are clearly assigned in elements in pyramidal structures.
  2. The second dimension is the process organization, where people from different elements of the organizational structure work together in the same process towards a repeatable goal.
  3. The third dimension is the project organization, where people from the different elements of the organizational structure work towards a one time goal.
So what is the effect of these three organizations on the GLUE Framework and especially the GLUE Space and the circulatory system?
The answer is fairly simple:
  • All three determine who delivers what in the GLUE Space. The GLUE Space itself and even the circulatory system is not affected.
in many frameworks I observe an argumentation chain which is along the line: If you follow this, then it will work. If something does not work out the argumentation chain is easily: But you have not followed framework x, therefore it couldn't work. Given the fact that none of the frameworks is complete (only reality is) this is a self fulfilling prophecy. With GLUE i try to be different (and I might be biased in believing so and totally wrong. I believe there is no way to break out of GLUE, we are all bound to it, no matter if we try to be different or now.

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

Thursday, September 6, 2012

GLUE Journeys - Obvious missed

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

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

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

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

The full Circulatory GLUE System looks therefore like this:


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

GLUE Decks - Journey between the Decks

In my last post i have finally come to an explanation of the GLUE Journeys I like myself, which is a circulatory system with the GLUE Space as the structure giving element. I shortly touched on the flows:
  • The GLUE Disciplines is a circle, where Detect feeds back into Describe
  • The GLUE Decks are constructed based on the elements from a lower level
  • The GLUE Divisions reflect the diffusion of To-Be into As-Is

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

What is not so clearly explained is the back-and-upwards link from level n, discipline m, to level n+1, discipline m-1
The flow of information between two decks has two connection points:
  • Each requirement from Define will be assigned by Design to an element of the lower Deck (or can be handled in the very same Deck as explained in GLUE Disciplines).
  • After Development of the solution Do is needed to use the solution on the upper Deck.

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

By just looking at the two lower levels
  • If you want to furnish your living room you will place the elements you want to put into your living room on the right place (maybe you even have a plan for that). It can also be the case that you want to buy new elements (e.g. a table and chairs).
  • Room Describe: I want this room to be a living room
  • Room Define: It must contain a chair (I fear that is more an one chair exibition approach than a real living room, but I stick to the example)
  • Room Design: The chair shall be placed in the middle of the east side of the room.
  • Room Develop (start): Find the chair
    • Chair Describe: I want a chair
    • Chair Define: (Put your favourite chair requirements here)
    • Chair Design: (Put your favourite chair design here)
    • Chair Develop: Reuse/Buy/Build the Chair
    • Chair Do: Use the Chair
  • Room Develop (continue): Place the Chair on the east side of the room.
  • Room Detect: Check if everything is done as requested
This is of course an artificial example, but I hope it explains it better why a lower level "Do" leads to an upper level "Develop". You can not finalize a development on the upper level if you do not start to use the elements. I have the same reasoning behind putting Detect after Do, because it is not possible to test something, before you start using it.

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

Tuesday, September 4, 2012

GLUE Journeys - next attempt

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

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

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

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

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

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

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


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

GLUE Journey - Do Business Defence

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

“Knowing is not enough; we must apply. Being willing is not enough; we must do.”,
Leonardo da Vinci (1452 - 1519)
So to get it started here a diagram showing how the information flow is between Do Business Defence and the other GLUE deliverables:


  • Do Business Defence follows basically the Nike Process for Business: Just Do It.
  • Do Business Defence checks if Do Business Defence has been done right, e.g. reporting, analysis or audits.
  • Do Business Discovery supports Do Business Defence to adapt to new things, as touched in Innovation and GLUE. Transformation and Test belong here.
  • Develop Business Defence provides Do Business Defence the needed to support and defend As-Is.
  • Do SoS Defence follows also the Nike Process for the System of Systems. It does provide the System of Systems support for the Business Deck.
Very important is that this concept assumes that a specific content can be mapped to one GLUE Deliverable. When I look at Deliverables i usually find them providing content in the whole GLUE Space, actually including people. The whole concept just helps me to understand how information is tied together: Reality is that nothing is certain and information is usually only partially available. It is a pure artificial construct to understand and map information and helps to seek for the right answers.

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

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

Monday, September 3, 2012

Innovation and GLUE

Again I fail to continue writing on the GLUE Journeys as promised but jump into another hot topic: Innovation. Actually I do not really think that it is new knowledge, but for whatever reason it seems to be hot. i personally utilize the knowledge Everett Rogers has provided us in his Diffusion of Innovations.
So why the hype around innovation? Following Rogers definition (innovation is "an idea, practice, or object that is perceived as new by an individual or other unit of adoption") and his model (the first 2.5% to adopt to an innovation are innovators) I wonder what makes it so interesting that everyone wants to be associated to innovation. (The funny thing is, even if all of us want to be innovative only the fastest 2.5% will be innovators).
“Innovation distinguishes between a leader and a follower.”,
Steve Jobs (1955 - 2011)
I believe part of it is tied closely to the success of Apple. Innovation is to me more a brand than something real. But given the fact that it is a real hype I give it also some focus. First of all in the GLUE Space I place Innovation into the GLUE Division Discovery.
Discovery supports the people to adopt innovations, again following Rogers definitions:
  • Innovators
  • Early Adopters
  • Early Majority
  • Late Majority
  • Laggards
Due to the fact that it is so attractive to be innovative I now also observe some weird approaches, like using off-the-shelf-software not as intended but for something very different. In some cases that might be really innovative by bridging from one area of appliance to another, but in most cases this is just lack of common-sense advertised as out-of-the-box-thinking. Preaching for standards is a lost case against innovation evangelists.
By looking at Enterprise Architecture (not real EA) the Division Discovery is a core part to support the transition of the As-Is Architecture to the To-Be Architecture. As I have tried to point out in Enterprise Architecting Past, Future or Present there is no easy straightforward way (thank god, that secures my job), but here I take the more narrow minded approach around the Architecture Core Deliverables:
So what I think is that Enterprise Architects should lead in the transition from As-Is to To-Be and support the change. A Social Enterprise Architect should be equipped with the right tools at hand to support innovation but also the further adoption. Innovation alone is only a very small subset for Enterprise Architecture to support. And different techniques have to be applied for different stages of the solution:

  1. Everything starts as an invention (part of GLUE Develop Destination)
  2. Some inventions are innovative (part of GLUE Develop Discovery)
  3. Optimization is needed to reduce costs on each variant (First Develop Destination to optimize, then Develop Discovery to get it adopted)
  4. Harmonization as the next level of alignment is reducing the variants down to one
  5. Shared Service delivers the functionality for many out of a small amount of people
  6. Outsource delivers the functionality for the cheapest available price from the market
In my definition only one small area in this model is innovative and it is only one level on the solution evolution. All levels need to be supported by Enterprise Architecture and to make it even more complex the people who work in the different solutions must be taken into account. Any thoughts, comments? Feel free to contact me, I am happy to share knowledge, ideas, thoughts.