Sunday, February 24, 2013

No Power for Enterprise Architects

Some time ago I have written about The Enterprise Architecture Matrix, where I used a small sequence from the movie Matrix to explain my line of thinking for Enterprise Architecture. This time I use the scene from Lord Of The Ring where Frodo is looking into Galadriels mirror to see the future.But see yourself:

Frodo is the Solution Architect, who is trying to solve a problem at hand and Galadriel is the Enterprise Architect(EA) who provides the Solution Architect (SA) with tools (the mirror) and advice.
The Enterprise sleeps, and when the Enterprise Architect explains, only the Solution Architect listens.

EA : "Will you look into the mirror?"
SA : "What will I see?"
EA : "Not even the wisest can say, for the mirror shows many things. Things that are, things that were, and some things that have not yet come to pass."

SA looks into the mirror, and sees Legolas, Merry and Pippin, then Sam. The Shire as it was, then the Shire ravaged, overrun with orcs, and Sam in chains.

Then the Eye appears, and the Task grows heavier, trying to pull itself down into the mirror. SA snatches it away, falls backward onto the ground.

EA : "I know what it is you have seen, for it is also in my mind. It is what will come to pass if you should fail. The Fellowship is breaking. Already it has begun. He will try to take the ring. You know of whom I speak. One by one, it will destroy them all."

SA : 'If you ask it of me, I will give you the One Task.'

EA : "You offer it to me freely. I do not deny that my heart has greatly desired this."
A dark light comes over her as she touches the power of the Task.
EA : "Instead of a Dark Lord, you would have a queen, not dark but beautiful and terrible as the dawn! Tempestuous as the sea, and stronger than the foundations of the earth! All shall love me and despair!"

EA backs away from the Task, ut for a moment, she looks old, and it seems to bring her no joy to have done the right thing.
EA : "I passed the test. I will diminish, and go into the west, and remain Galadriel."

SA : "I cannot do this alone."

EA : "You are a Ringbearer, Frodo. To bear a architecture task is to be alone. This task was appointed to you, and if you do not find a way, no one will."

Frodo : "Then, I know what I must do. It's just I am afraid to do it."
Galadriel : "Even the smallest person can change the course of the future."

I try to allow all ideas to influence my thinking about Enterprise Architecture. Sometimes it works perfect, sometimes not at all, but I truly hope that I try. I personally believe that an Enterprise Architect should stay away from the power and if he decides to take the power stay away from Enterprise Architecture. There is a high risk that an Enterprise Architect with power abuses that to build just another empire no-one needs. Instead of building this empire focus on repair GLUE Diseases and fix the flows in the GLUE Circulatory System.


Feedback as always more than welcome.

Saturday, February 23, 2013

Power, Process, Project, People - Force One

In my last post I have started a series about Power, Process, Project and People. In this post I like to reflect a bit on power and what I am doing with respect to power in my daily Enterprise Architecture life. Just to repeat the definition from the Oxford Dictionaries: Power is the ability or official capacity to exercise control; authority. There is of course a lot of other definitions or deeper explanations of this concept. As a starter I recommend to read the Manifesto reference-sheet from power and response-ability from Tom Graves. For simplicity reasons I here stick to the very simple above mentioned Oxford Dictionaries definition.

Power is most obviously found in organizations by just looking at the organizational chart. In most cases it is formed like a pyramid with one on the top and some below, which have each some below them again. This can potentially be a very high structure (e.g. CEO > CxO Board > Divisions > Departments > Groups > Employees), even though there is some companies who run a flat hierarchy. In most cases these structures are self defending (GLUE Division Defence). It is very uncommon to see an Employee who has a higher salary than his manager. Also concepts like a technical career path typically only worsen the situation, because now the employees themselves are organized in a pyramid. And it can all be summed up by the concept of Julius Caesar: Divide and Conquer, which I have used to introduce the concept of the GLUE Domains. What I observe most it that it is limiting and framing people into something way smaller than they could be.

The typical advice I hear and read in various Enterprise Architecture Frameworks (e.g. TOGAF 9) is to place Enterprise Architecture in the governance structure close to the CxO level, preferable reporting direct to the CIO (Enterprise IT Architecture) or to the CEO (Enterprise Architecture). There is also the idea to put it below the CMO (?Enterprise Marketing Architecture?). Even though I have seen a lot of value created at that level I also see a fair amount of disconnect to the employee level and Ivory tower behaviour. The balance between strategy, tactics and operational work is not always easy to keep. And if an Enterprise Architect works only in his power structure then the result will be biased towards exactly that structure, heavily influenced and by that imbalanced due to only staying inside the frames given by it.

So what am I doing different? I am actually using the GLUE Domains in the GLUE Space to identify and map the power structures. The amount of GLUE Decks very  much depends on the context. For the blog I use four to explain the concept, but it can easily go way higher (or lower).

Typically these Domains are in conflict with each other with respect to Roles and Responsibilities. For example the responsibility of an Application Owner in the processes of Application Lifecycle Management who owns every aspect of his Application:

And Test Execution, which is typically owned by Test Management. Here two Empires are potentially in conflict.

The (theoretically) simple answer for Enterprise Architecture is now to work close to the decision makers (in this case most likely the CIO) and guide the CIO to take the right decisions. The basic (and I think wrong) assumption behind that is, that the CIO decides and forces it in. Following the basic idea of the power then this is indeed the case and especially and heavy command & control liking environments there is a high likelihood that  this will indeed be forced in, because the managers on those structures want to know everything what their people know. I personally believe that this is in most cases causing more damage than it is repairing, therefore I do work different. (Seth Godin touches this problem in his post destabilizing the bullying power structure.

I do not need only a strong connection to the decision makers, but I do need to be connected also to the lower levels of the organization. Therefore no framework and no formal governance is enabling me to be an enterprise architect, but knowing that I am one helps a lot! So instead of relying on pure power structures I go to the people who have the conflict and challenges at hand, and then I am doing Enterprise Architecture work by helping them to connect to the holistic Enterprise (repairing GLUE Diseases), no matter how deep or high they are on the ladder of power. That of course requires that I have to earn trust first, which is most easily achieved by walking the talking, especially when the advice is beyond the scope of the power structure.

Feedback as always more than welcome.

Thursday, February 21, 2013

Power, Process, Project, People

I keep writing about People, because I strongly believe that in the end the only thing which really matters is people, like in the Agile Manifesto: Individuals and Interactions over Processes and Tools.

In the past days I have seen plenty of interesting posts putting various concepts in the focus. One caught my attention and is very much worth to read:

This post followed some back and forth twittering and it was a very enjoyable discussion. It triggered some thinking I wanted to reflect already for a while, because every now and then I see an interesting tendency to market something as the one and only way on how to look at the world or solutions, be it IT or non IT.

Coming back to people I want to reflect on three forces especially which I observe every day and what I do to work with them or what I see in the typical Enterprise Architecture approaches. The three forces are (for each one definition from Oxford Dictionaries):
  • Power - The ability or official capacity to exercise control; authority.
  • Project - An individual or collaborative enterprise that is carefully planned to achieve a particular aim.
  • Process - A systematic series of mechanized or chemical operations that are performed in order to produce something. 

The definition of process and project is sometimes confusing if compared, so for simplification I typically differentiate by using project in the context of unique deliveries and process if the deliveries are repeatable. These three forces have a different effect on people, and each and every person has a different opinion what type of force he prefers, but in typical organizations all three forces exist in co-existence and influence each other. The key to all these three powers in the end is the People though and interesting enough they get quite often forgotten.

This is only the first post in a series, otherwise it is getting too long. The next post will be about power. If you have any input to give straight away then I am happy to read or hear from you.

Thursday, February 14, 2013

Enterprise Life Forms

In my last post "Details vs Context" I have touched the challenge to find the right balance between getting lost in the details and getting lost in the context. The frequent readers of my blog should by now know that my personal take on Enterprise Architecture is very much focusing on people without blending out the building blocks of the flow:

An interesting and relevant observation of mine is now that each and every company has its very own soul, the true essence of that company. Of course on the surface they all (at least the big ones) seem to have the same functions, same processes, same good practices applied, but if you just manage to see one level deeper it all of a sudden is total different between the companies and has its very own beauty. The soul of a company has some aspects which seem to be generic patterns:
  • It is deeply rooted in the old guard people (GLUE Defence).
  • New people sooner or later tend to adopt to it.
  • It is embedded in the structural, process, project and especially in the informal organization.
  • It can not be easily changed.
  • It has self healing effects which protect the system against damages inflicted by external sources or careless management / leadership attempts and forces the whole environment back into the pre-change attempt.
One of the first things when I work in or with a company for  me is to try to identify the soul of it. Because it seems to be unique and very special. I have not seen two different companies with an identical soul and that is actually something which I personally find very interesting and relevant to create fit-to-purpose architectures, not to mention that the soul of the company has its very own unique beauty which is as far as I see it worth to be protected.

Wednesday, February 13, 2013

Details vs Context

In my last post I was writing about walking the talking, which is based on my experience one of the key elements for success. Some time ago I have written about the need to remember the larger context which is also reflected in my WISE SCAN post (E stands for Environment). So it is essential to connect a solution in the context to secure sustainable success and not rely on random luck. The saying: "To not see the wood for the trees" is also based on that line of thinking.

The interesting challenge now is to not get lost in the greater context and by that forgetting to chop the trees. I have seen many Enterprise Architects loosing contact to reality and connecting literally everything to a problem or solution at hand but totally forgot to deliver the solution. The intellectual discussion with them was actually truly great and I learned a lot (this happened many many times), but pity enough it wasn't very relevant.
I believe it carries the very same danger to not deliver than getting lost in the details, but does contain an additional problem. Those who get lost in the context loose credit due to not delivering, while those who get lost in the details are typically valued for their great knowledge, but questioned about their communication skills.

So my advice (and I try to live up to that every day) is: deliver while connecting, connect while delivering. Don't think something fully through, but connect it good enough. Fail often and fail fast. And secure that the whole environment is setup to support that. If not, then fix the information flow, fix the GLUE Circulatory Flow, so that information flows free, is easy accessible, enriched fast and supports collision of ideas.

And in most cases the answer lies in the people who are operating in the GLUE Circulatory System. They are the elements which needs to be worked on to secure information flow. Technology can be a catalyzer or facilitator but is typically not the key element to secure optimal information flow. Balancing details and context is an ongoing challenging task which mainly operates on people and their ability to connect details with context. Various Enterprise Architecture tools help here a lot, but what is most successful is finding the right words for the right people to connect the details and the context via an emotional holistic story touching all senses. Tough one, but there is moments of perfect flow in life. And those moments are the reason why I deeply love my job.

Tuesday, February 12, 2013

Walk the Talk

My last posts have been very much focused and following a red line, so now I am trying to pick up some loose ends. There is one thing which bugs me quite often when I am doing Enterprise Architecture work. There is way to much focus on talking about Enterprise Architecture. Something which is also reflected by following twitter post:
My personal observation is that Architects actually discuss about Enterprise Architecture, but do in most cases not argue. This is a differentiation I find very important, because an argumentation chain would at least provide a red line why one approach is chosen over the other. By looking at the pure amount of frameworks and tools in the market and the amount of new players entering that space it is quite obvious that Enterprise Architecture is at the moment in a hype or fever situation. This can easily lead to total irrational decisions. On this topic I recommend to take a closer look at the Tulip Mania, some of the behaviours might also be seen in more recent crises.

Here (as mentioned before) I use GLUE as mapping tool for me. The real most interesting (and relevant) question for me always is: Where is a person stuck in the GLUE circulatory system.

And then I try to go into that position, placing myself onto the seat of that particular person to understand where the missing links are. If I manage to understand a portion of it I try to show the traces by using whatever terminology is approbiate for that particular person. Not GLUE, not a specific framework, but whatever language element helps. Sometimes indirect communication by others is the only way to succeed, sometimes I need to play over time. Invest today, harvest in a couple of month when a small trigger has grown into something powerful.

In most cases showing the connections to other information streams (in the circulatory system) allows the person at hand to see some possible answers to concrete problems which have not been solveable before. And there is one thing I know, then it is that I do not know anything, but what I know is that I am an Enterprise Architect. So in most cases I have literally no chance to give a correct concrete answer even though I am fairly often asked to give one, but I am able to help the information flow, to unblock the thinking, to link elements. There is my focus and that enables others to bring their great knowledge to the game and solve problems I would not have dreamt of being solved.

Saturday, February 9, 2013

drEAmtime - summary

This is my final post in a long series of posts where I used the great post from Ivo Velitchkov as a red line to explain my thinking. Following posts did I create so far:
  1. drEAmtime - Communication
  2. drEAmtime - Bridging the Silo
  3. drEAmtime - Capability Cemetery
  4. drEAmtime - EPIC SCAN
  5. drEAmtime - Archetypes
  6. drEAmtime - WISE SCAN
  7. drEAmtime - PACE SCAN 
  8. drEAmtime - Frameworks
  9. drEAmtime - modelling

So it is time to summarize the whole series and once again I like to use a quote from Ivo: 
In summary, more often than not, when contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it. When trying to bridge the silos, it creates new silos instead. When trying reduce the IT spending, it in fact makes no change or increases them. When trying to deal with complexity,  it’s just pathetic
I completely share Ivos line of thinking here. The first observation ("When contemporary mainstream EA is trying to introduce a common language, it creates confusion and additional work to deal with it") is actually the main reason that started my work on GLUE. I was facing a situation where multiple software supplier and various integrators including a fairly diversified internal IT process structure had to deliver towards 4 releases every year without sharing any common knowledge and understanding, but all of them tried to teach introduce their approaches. So, I have to confess, in my first line of thinking, GLUE was just another stupid approach to create a common language to try to bring them all on the same page.

After working some weeks on the concepts I proudly presented it and was astonished that my brightness (GLUE) was not obvious to everyone. What I faced (and most of the feedback I collected over several years afterwards) was (of course) full misunderstanding. Everyone was all in for the idea of aligning to language to a single common one, as long as it is the one already used to protect the own way of thinking (tribe). So I totally failed and out of frustration I parked GLUE for a couple of years. Looking back the main problem was that I was so full of being right that I did not listen to those I wanted to follow my line of thinking.

Since then I have my changed my focus and live more up to the concept of being a ChickenBrain. I changed the focus from GLUE being the ultimate truth which everyone has to obey towards a pure mapping tool to identify GLUE diseases. Whatever approach or framework in an engineering context I face I immediately map it into GLUE to double check my understanding of the framework at hand (and to ask sense making questions if needed).
Ivos second observation ("When trying to bridge the silos, it creates new silos instead.") is also something I observed more than once, most inside corporations where the Head of Enterprise Architecture tried to create or defend his very own Empire. That empire (or tribe) thinking is of course typically creating or defending an Enterprise Architecture silo. It can easily go worse if the Architecture Domains are split into several teams which have to argue their existence and easily spend more time on defending their existence than in providing real value. And it typically it does not matter how they are split, as long as they are split roles and responsibilities will be defined and some sort of open or hidden fighting is typically the result.

Ivos third observation ("When trying reduce the IT spending, it in fact makes no change or increases them.") and fourth observation ("When trying to deal with complexity,  it’s just pathetic.") are connected and has typically many root causes. For example information flow problems or how I name them a GLUE disease, lack of analyzing the To-Be Architecture where the WISE SCAN of the GLUE Division Destination helps and quite often just bad implementations, where the PACE SCAN of the GLUE Division Discovery helps. The various root causes of unneeded complexity can be analyzed with the help of the EPIC SCAN.

I like to thank Ivo for his great inspirational post and I am happy that I finished to follow that red line. Comments and feedback is as always more than welcome (and new inspirational posts as well).


Friday, February 8, 2013

drEAmtime - modelling

Finally I can see the end of the red line created by the great post from Ivo Velitchkov. So far I have created following posts:
  1. drEAmtime - Communication
  2. drEAmtime - Bridging the Silo
  3. drEAmtime - Capability Cemetery
  4. drEAmtime - EPIC SCAN
  5. drEAmtime - Archetypes
  6. drEAmtime - WISE SCAN
  7. drEAmtime - PACE SCAN 
  8. drEAmtime - Frameworks
Two more posts to go, this one and another final one. To quote Ivo: 
Then of course modelling itself is believed to help in dealing with complexity. But what kind of modelling? A very complicated architecture diagram does not show complexity. It just shows a lot of effort spent in denial of it.
Actually I personally believe that modelling is a great tool and support communication quite a lot, if applied correctly. I also have a couple of models here in my blog which help me to explain and visualize what I think. Looking at them isolated they are most likely confusing and difficult to understand, which makes it sometimes indeed difficult to use them alone. But in the support of the whole storyline, be it as part of a blog post or as part of a presentation the model helps to align the thinking. The one I refer to most here in the blog is actually the circulatory GLUE system:

Just a cube with lots of confusing lines. Only by working through my GLUE thinking and GLUE posts it hopefully gets meaningful. Which reminds me that I need to label my posts a bit more organized, otherwise it gets difficult to find information. Or I need to put all of it together, reorganize it and write it again in a more structured way, more like a book? Maybe a project worth to go, maybe not. If you have feedback here you are more than welcome.

Coming back to Ivos post there is jokes circulating around me: "When have you last time had a meeting with Kai without him using the whiteboard?" or "We are trained to sit so that we have free view towards the whiteboard." Scott Ambler has heavily influenced my thinking with his great website about Agile Modeling besides a lot of great colleagues I had over the years who showed skilled approaches in supporting their line of argumentation with the right model at the right moment. I also liked his Whiteboard Warrior concept, but he has put it offline from his website. There is some traces left in the web though.

One of my key approaches is to draw while I speak. Many words (and I say and write a lot) are more often confusing than enlighting, while a single diagram just shows it. Finding those is not always easy, but the more I model the easier it is to create the right drawing at the moment when it is needed. So my advise is: draw to support your line of thinking, explain in pictures, add a story and the whole gets  its own life. Which most likely will return back to you one day, grown over time, transformed and morphed, but beautiful. I try to show Enterprise Architecture and the elements which are delivered via Enterprise Architecture in their full beauty, sometimes I fail, sometimes I succeed.

And a model which is beautiful will carry the story way longer and way more emotional than any dry facts. If Dennis Dutton is right with his assumption than it is rooted in human beeings. I found the success in this approach by try and error. Feedback and comments as always more than welcome.

Thursday, February 7, 2013

drEAmtime - Frameworks

It looks like as if I am getting closer in finishing my exploration of the great post from Ivo Velitchkov. So far I have created following posts:

  1. drEAmtime - Communication
  2. drEAmtime - Bridging the Silo
  3. drEAmtime - Capability Cemetery
  4. drEAmtime - EPIC SCAN
  5. drEAmtime - Archetypes
  6. drEAmtime - WISE SCAN
  7. drEAmtime - PACE SCAN
To quote Ivo once more:

If you are an Enterprise Architect, a popular way to deal with complexity is to arm yourself with a framework. With a good framework, it is believed, you can do two things. First, reduce the variety of the enterprise to just a few things that share the same properties, according to some classification theory and where things doesn’t fit, add more layers of abstraction. And second, reduce the things you can possibly do to just a few but well defined and in a specific order, with well prescribed inputs and outputs, because that was common for so many organisations that did well so that it became a best practice, and the chances are, if you follow this way, it will do you well as well. Now, because of the shared understanding of the beneficial role of the abstract layers, and the boundaryless imagination unconstrained by the reality, there is a serious number of frame-works and on top of them other-works on how to adapt and adopt them.
And once more a lot of truth in it. One of the first things I learned while dealing with complexity actually was that it created panic. Even though it seemed to me quite obvious what the answer is and how to explain it by using an enormous amount of framework knowledge (of course shameless stolen from many) in my explanation I kind of did not really deliver the message. So my current working approach is to remind the audience of one simple short statement of wisdom: "Don't Panic".
I like to use frameworks, but the amount of frameworks is indeed enormous and heavily increasing (and I add one by bringing my GLUE thinking into the game). Pragmatic EA has an overview about frameworks which I personally find very interesting (GLUE is not in that list, because I did not register it so far and obviously no one else did).

So I do exactly what Ivo says: "Reduce the variety of the enterprise to just a few things that share the same properties" and it actually helps me to understand the complexity and trace broken information flows. So I personally find it very useful, but GLUE is of course at this very moment nothing else than an attempt to materialize my very own thinking where there was absolutely no need for any agreements with others. So it is strong for me, but most likely useless for everyone else. If you are interested in applying my thinking please let me know, I will see if I can somehow help you in understanding and applying my thoughts.

With respect to Ivos other statement: "And second, reduce the things you can possibly do to just a few but well defined and in a specific order, with well prescribed inputs and outputs, because that was common for so many organisations that did well so that it became a best practice, and the chances are, if you follow this way, it will do you well as well." I have a different approach. I personally believe that GLUE always happens and is inevitable. So I personally don't focus as a primary task on implementing one (or many if you look at the amount) framework, but instead I primarily look at broken information flows or GLUE diseases.


And those diseases I then try to fix, sometimes by proposing (and implementing) a framework, sometimes by inventing something new, sometimes by just talking to the people. It all depends on the context, but I try to guide the energy in the system in a way that it allows to emerge an solution.. It is of course very interesting (but not always relevant) to get hung up in discussion about frameworks or become really religious in applying some technique in one or the other way, but try to avoid that discussion, even though it is sometimes needed to cultivate collisions and by that look for something new (if lucky innovative).

Tuesday, February 5, 2013

drEAmtime - PACE SCAN

I continue to explore the red line laid out by the great post from Ivo Velitchkov. So far I have created following posts:
  1. drEAmtime - Communication
  2. drEAmtime - Bridging the Silo
  3. drEAmtime - Capability Cemetery
  4. drEAmtime - EPIC SCAN
  5. drEAmtime - Archetypes
  6. drEAmtime - WISE SCAN
Ivo has now fixed some typos in his post to cleanup. I decided (for the moment) to keep my posts as they are, at least as long as the flow goes.

To quote Ivo 

The part related to complexity certainly deserves a separate post and may be more than one. As this one got pretty long already, for my standards that is, let me just finish with the following: dealing with complexity is not reduced to finding ways to reduce it. It requires much different understanding of what happens when interactions are not linear. When there is dynamics, adaptation, self-organisation, irrational behaviour, politics and power.
Here Ivo touches the concept of transorming from As-Is to To-Be. Here he doesn't rant, but points at some specific points which need attention to execute successful on the transformation. Here I apply the PACE SCAN to secure the information flow through the GLUE Discovery and the transformation from one stable state to anohter stable state.

  • People - to transform people will make the difference between success and failure.
  • Adaption - to transform the complete solution must be adapted to reach fit to purpose.
  • Communication - to transform communication is key to secure that the targets will be reached.
  • Emphatic - to transform it is required to sense also the unspoken which enables to deliver and help that people and solution form a perfect fit-to-purpose environment.
The typical complexity to be found after executing in a poor way (not doing the PACE SCAN right) is contrived complexity, where a subset of the stakeholders was handled, but not the holistic complete set. By that highly biased solutions are created which unbalance the whole system. Sometimes is worth to unbalance though, because it allows to find innovation which will not be found if you always stay in a balanced world. But before the innovation can be found there is normally a time of tension and pain. Ivo doesn't touch this in his post, because he is very much focussing on efficiency, but sometimes his statement "And indeed they shoot inefficiencies and get all the glory and the money to shoot more." with a slight twist is also a good outcome, when something is done effectice: "And indeed they create innovative solutions and get all the glory and the money to create more."

Which leads to another root cause of complexity: Perverse Complexity, where the intention has been good (WISE SCAN), but the execution was not done with all the needed resources and skills in place. On top my observation is that in many transformations there is quite some theoretical effort on showing the importance of the change management, but quite often (a pity) the execution does not follow the theory or the scope and money to do change management gets downscoped. Here Enterprise Architects with a focus on people can help.


With respect to Ivos post I have the impression that he has mostly seen Enterprise IT Architects with a strong skillset on IT but no real awareness of people. So my advice to Ivo: Look for Real Enterprise Architecture and you will find great solutions and even greater people.

Monday, February 4, 2013

drEAmtime - WISE SCAN

Time for post number 6 in exploring the great post from Ivo Velitchkov step-by-step. Here is what I have created so far:
  1. drEAmtime - Communication
  2. drEAmtime - Bridging the Silo
  3. drEAmtime - Capability Cemetery 
  4. drEAmtime - EPIC SCAN
  5. drEAmtime - Archetypes 
To quote Ivo:
Some attempts to achieve IT rationalisation fail spectacularly. I’m not going to list out the reasons for that. But it is may be sad that such failures discredit EA as a management discipline as whole. But sometimes Enterprise Architect are really able to find ways to discover what’s not needed and how to remove it, or what is underutilised and how to achieve better ROI for it. After all  most of them are smart people using good tools. And indeed they shoot inefficiencies and get all the glory and the money to shoot more. But as they rarely get to the cause of the inefficiencies or are in the position to influence the bigger system that produces these inefficiencies, the overall result is an oscillation or even increase in overall IT spending. The increase is because the success of the EA justifies bigger EA budget which is almost without exception a part of the IT budget.
Here Ivo points at one of the most common pitfalls of Enterprise Architecture applied: fighting symptoms instead of the root cause. This has several reasons. First of all external Enterprise Architects coming with a consulting company might not have the needed inside or full pain awareness to truly fight the root cause (some might even look for future business, and a permanent broken information flow is a permanent revenue stream). Internal Enterprise Architects might have a huge reputation problem which quite often is based on Ivos observation. So as mentioned in the other posts a clear focus on fixing the information flow is a good start to shoot at the root cause and get it eliminated or at least plant some seeds to eliminate the root cause later.

But this is clearly not enough. So with respect to fixing the content I apply the WISE SCAN approach, which looks into the future (GLUE Destination):
  • Worth - The future capability must be worthwhile to trigger a transformation. (Ivo:  But sometimes Enterprise Architect are really able to find ways to discover what’s not needed and how to remove it, or what is underutilised and how to achieve better ROI for it.)
  • Informed - The future capability must contain all the relevant information as much as needed containing the necessary facts. (Ivo: After all  most of them are smart people using good tools.)
  • Simple - The  future capability must be the most simple solution which fits the purpose. (Here Ivo seems to have lost trust and is pointing to Perverse Complexity: "Some attempts to achieve IT rationalisation fail spectacularly.")
  • Environment - The future capability must be embedded in the greater context. (Here Ivo also seems to have lost trust: "But as they rarely get to the cause of the inefficiencies or are in the position to influence the bigger system that produces these inefficiencies, the overall result is an oscillation or even increase in overall IT spending.")
I share the observation with Ivo that in many cases so called Enterprise Architects do indeed promote decisions which are not following the WISE approach but are focusing to much on some aspects and therefore add to the EPIC complexity. After all the core reason  why emergent complexity exists.

The next post will most likely be about the PACE SCAN. Feedback as always more than welcome to help me improve (or get another red line through my own thoughts. Only some posts to go till Ivos input has done its job for me).

Sunday, February 3, 2013

drEAmtime - Archetypes

I am still not done with exploring the great post from Ivo Velitchkov in which many gems are to be found. My posts so far:

  1. drEAmtime - Communication
  2. drEAmtime - Bridging the Silo
  3. drEAmtime - Capability Cemetery 
  4. drEAmtime - EPIC SCAN
To quote Ivo:
But just when the situations seems really critical, the door opens with a kick and EA cowboys enter. They pull out frameworks and architecture tools from their holsters and in slow motion (a very slow motion), they shoot inefficiency after inefficiency until all of them lie dead on the floor. Then they walk out and go to shoot inefficiencies in some other town and when new inefficiencies appear in this town they come back again to kill them out.
Today it is a rather short reflection, but Ivo reminds me of a series I wanted to start and promised some time ago in my post May I Introduce The Enterprise Architect. The EA cowboy is indeed one of the archeypes I was thinking of, even though the title I have in mind is more the Enterprise Hero Architect. A very short prethinking here: The Enterprise Hero Architect is sometimes needed to fight the really big problems when it is actually already to late. And as Ivo describes he walks away when the enemy is defeated. There is some problems though, in most cases the hero is only capable of fighting the symptoms, but not the real root cause of the problem.

I (hopefully) will explore the various archetypes soon, at least I plan to. I have touched that concept in the EA Summerschool 2012, Copenhagen  and want to renew my promise here. So stay tuned. :)

Saturday, February 2, 2013

drEAmtime - EPIC SCAN

I continue to explore the great post from Ivo Velitchkov step-by-step, because his posts allow my thoughts to follow a red line. He pretty much eliminated a GLUE Disease in my very own head. Once again (and I will continue to say that till I reach the end of the red line) thank you for unplugging me.

So here again a quote from Ivo:
Big organizations in all sectors, especially in the service industries, tend to gather huge number of applications until they find themselves in a situation where there are far too many to manage. A good number of them are not used at all. Some other part is underutilized. Most of the critical applications have high maintenance or high replacement cost or both. Inevitably there are many which automate different parts of the same process but they don’t talk to each other. And this justifies new spending on building interfaces, or buying application integration packages first and then replacing them with BPMS and then probably with something better than BPMS. As a result – more spending and more applications to manage.
Ivo keeps continuing exploring that with some more statements, which all point to one specific problem: Unneeded complexity as the root cause of too high costs. Once again  a great observation and a situation I have also faced more than once (and most likely will face each and every day as long as I stay in Enterprise Architecture drEAmland. So what am I doing? Actually I am applying the EPIC SCAN approach to analyze the past (GLUE Defence).
  • Emergent Complexity - consequence of many small and unrelated decisions. (Ivo: "Inevitably there are many which automate different parts of the same process but don't talk to each other")
  • Perverse Complexity - consequence of clumsy attempts to reduce complexity. (Ivo: "And this justifies new spending on building interfaces, or buying application integration packages first and then replacing them with BPMS and then probably with something better than BPMS.")
  • Irreducible Complexity - consequence of the real complexity of the demand environment. (Ivo touches this only between the lines: "Big organizations in all sectors [...] tend to gather huge number of applications [...]")
  • Contrived Complexity - consequence of deliberately creation to benefit some stakeholders. (Ivo: "But as they rarely get to the cause of the inefficiencies or are in the position to influence the bigger system that produces these inefficiencies, the overall result is an oscillation or even increase in overall IT spending.")
By analyzing the problem at hand with the EPIC SCAN approach I am able to create transparency and visibility on the root cause of the problem. And then it is (once again) all about communication and people to optimize the information flow and by that find the best fit-to-purpose solution.

It does help quite a lot, if you don't panic and stop thinking to be an Enterprise Architect but start knowing that you are one. Remember, in the Enterprise Architecture Matrix you just have to let it all go, fear, doubt and disbelief. Free your mind.

As always over to you for commenting to help me improving my thinking and share as much knowledge as possible.

Friday, February 1, 2013

drEAmtime - Capability Cemetery

Thanks to a great post from Ivo Velitchkov which unplugged some thinking of mine I was able to put some words around a couple of ideas and approaches I use. One post about Communication rather than creating an aligned (meaningless) language and a second post about truly Bridging the Silos instead of creating a new Enterprise Architecture silo. 

So here another quote from Ivo:
EA is often in the position to attract some serious budgets for reasons we’ll see in another dream, and this way the new island becomes a safe territory for people that have either failed or lost interest in the pure IT. This as a result further decreases the credibility of EA which slowly, in some organisations, gets the image of a place for people that are not good enough for IT and prefer to hide under EA labels where things are vague enough and much more difficult to measure. The lost credibility either undermines the work of the really good EA practitioners or pushes them out of the organisation or both.
 This immediately reminded me of an Enterprise Modelling Anti Pattern from Scott Ambler the so called Enterprise Parking Lot. Here a quote from Scott:
Your enterprise modelling group is composed of a lot of very smart people who don't fit in well anywhere else within IT but you don't want to lose their knowledge.

I personally have often observed a combination of both and therefore I phrase it the Capability Cemetery. So how to fix or handle this? First of all I am typically looking at each individuals capability. It is fairly seldom the case that there is people who try to avoid working under all circumstances, even thought that happens now and then. In most cases there is a deficit or GLUE Disease somewhere, a conflict between the organization setup (be it structural, process, project or any other organization) and the way the individual person is willing to operate. Typically, via investing in the interesting to reveal the relevant, it is possible to dig out the real root cause of the problem. Knowing the root cause then allows to optimize the information flow through the circulatory GLUE Cube.

Showing the people in the Capability Cemetery a clear path how they can utilize their knowledge and bring the highest possible value to the success of the company typically creates a buy-in situation of the members in the Capability Cemetery, especially if the value becomes visible and is recognized by the relevant people (which might be decision makers). Moving that overall Capability Cemetery now step-by-step into a well respected (Enterprise) Architecture Community will generate also organizational buy-in on the go towards a situation where no-one will ever question the value of the Enterprise Architecture. Communication is (once more) the absolute key element for success here.

As always, I need your input to improve and I do love knowledge exchange, so please forward your comments and thoughts.

drEAmtime - Bridging the Silos

As I have written in my last post "drEAmtime - Communication" a a great post from Ivo Velitchkov caught my attention and triggered me to think which is now resulting in the second post of a series of yet unknown length.

To quote Ivo:
The EA people instead of building a bridge between the two silos, create a new one. And at certain point they find themselves in the position where neither Business nor IT regards them as a bridge any more. The Business people trust EA people even less than IT because they see them as cross-dressed IT. IT people loose trust to EA as well because they are not sure they understand the Business and if they still remember what was IT. Further, IT managers need support which EA does not have the authority to ensure.
Again well observed. Here is actually way more than one observation. First of all the additional Enterprise Architecture silo. It is emerging when the desire to differentiate is higher than the desire to solve problems. Due to the typical way organizations measure success and failure it is in most situation inevitable happening. The real business people push back the Enterprise Architecture people, because they do not know enough (or the right things) about the business and the IT people push back the Enterprise Architecture people, because they don't know enough (or the right things) about the IT. So literally it is again about communication, in this case collisions between ideas.

As I have put it in my post "Real Enterprise Architecture", there is typically more than one organizational unit doing the conceptual work of Enterprise Architecture. In Ivos example it is business against EA, therefore there is a natural conflict between the (green) business domain and the Enterprise Architecture (blue) domain with a natural overlap (orange).

Conceptually the same conflict exists between IT (white) and Enterprise Architecture (blue), therefore indeed in most situations the emerging new (and scary?) function of Enterprise Architecture does create a new silo with new interfaces (or without).

Another example is the potential deviations inside one domain as I have explained in my post "Tailoring Domains". Here Enterprise Architecture is also supposed to bridge silos, but has a huge potential to be seen as an intruder and therefore being ignored or fought. (What does the (stupid) Enterprise Architect know about my Application?).

For both cases my answer is (once again) the same. I focus on people and try to optimize the information flow. This is (once again) not based on a specific EA framework or method but centered around communication and working with people.


Comments as always more than welcome so that I am able to improve my thinking and writing.