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

Categories Uncategorized

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

Categories Uncategorized

Fellow Enterprise Architects, Avoid the EA Buzzword Bingo!

Another another big Enterprise Architecture conference has now wrapped up. Now you have been updated on all the new buzzwords, -isms and great new visuals. I know it’s exciting to take advantage of these cool new expressions and fancy words,…

Categories Uncategorized

Enterprise Architecture and abstraction layers

I recently read John Gotze’s thoughts on the updated national enterprise architecture framework and its underlying meta-model published by the Danish Government Agency for Digitisation. The framework is named ‘OIO EA’ and has evolved over a number of years into the official national government architecture approach. In his critique, John highlights that the updated meta-model …read more

The chance that your car might be washed away is not the only…

The chance that your car might be washed away is not the only reason to avoid driving across a flooded road.

The greater danger is that the road under the flood waters has already been washed away.

How many large system projects fail because of unexpected dependencies or unknown conditions?

Visibility is a clear and immediate benefit of a mature EA practice. 

And remember, just because the road is going in the right direction – i.e., is aligned with your business – does not mean it’s at all safe.

Photo By Brian Stansberry (Own work) [CC-BY-3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia Commons

What is Information Architecture?

I want to continue to build on the theme of Information Architecture which is being talked about a great deal at the Open Group Conference in Newport Beach. In my post, "A Quick Look At The Importance Of Information Architecture"…

Categories Uncategorized

drEAmtime – Communication

I read a great post from Ivo Velitchkov about drEAmtime which i recommend to read. I will try to pickup Ivos observations and explore how I handle the things he mentioned. He put in a great way what I am also observing and where I therefore use a different approach, even though I am in the end just another Enterprise Architect.

To quote Ivo:

The strong IT smell of the EA language decreases the chance of the Business to believe that they would benefit from learning it and that explains the low motivation and buy-in. Even though the cognitive load for IT is much lower, seeing the willingness of the Business to ‘improve’ its literacy, IT people find better things to be busy with. And another funny point. When there is some buy-in by the Business, EA is put under IT, not between business and IT. Then EA people complain they can’t do much from there. But may be they are put there just because they can’t do much.

Well observed if you ask me. So what am I doing to handle this? First of all I focus on people:

That is easy to say and write, but what does it actually mean? Well, I invest in the interesting to reveal the relevant. And I do that by using the “normal” language, so no special words, no special approach and for sure nothing based on any given EA framework. Just nothing, plain talking in a well proven language. (This does of course work only if it is one of the two languages I mastered good enough so far. I am trying hard to add a third one, but it seems to be a long and difficult journey to success).

From an communication point of view I indeed believe that I should operate between IT and Business, but this is not based on having the title Enterprise Architect, but based on my interest in operating in two domains at the same moment in time. That allows me actually to love to talk IT talk and business talk. I have literally no demand to force IT and business into speaking the same language or force them through a very rigid process, because I stopped thinking to be an Enterprise Architect and started to know that I am. Therefore I operate between business and IT, even though from an organizational point of view I am at the moment located in IT.

So I just focus on repairing the information flow, which then allows to find better solutions, some of them supported by IT solutions, some of them not supported. Reality is though that most EA approaches (frameworks as much as people owning the title Enterprise Architect) I have seen so far are indeed not aiding and simplifying the communication but do add an enormous amount of cognitive load, which is literally impossible to understand for anyone not fully familiar with the various methods. I might find the time to explore the benefit of acting like that later, but for the moment the key message is: optimize the information flow by utilizing communication.

Comments as always more than welcome. It helps me to improve my thinking and understanding.
Categories Uncategorized

Free TOGAF 9 Exam Simulator and Sample Questions

Manuel Di Toma has created a great resource for Enterprise Architects looking for TOGAF 9 certification. He built a set of TOGAF 9 simulation tests to help prepare you for the big test. Manuel ensures that all the resources in…

Fuzzy Point of Failure

Apple, Oracle, the Danish banks and the Danish government, today demonstrates how vulnerable we digital citizens are. I went to my online bank today. It told me I need to update Java, so I did (even if it is just a week ago I last did that, but hey, it’s Java so…). After doing so, …read more

Should Business Architects use the Business Model Canvas at the Program level?

In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture.  In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business initiative) is started.  He felt that the canvas is useful for creating a clear picture of the business impacts on a program.  There are problems with this method, which I’d like to share in this post. 

Let me lay out the context for the sake of this post since there is no business architecture “standard vocabulary.” 

A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.”  This business program has a management structure and is ultimately provided funding for a series of “projects.”  The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs. 

For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model.  I’m using the term “program” for this post because the Open Group presenter used the word “program.”  Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.

The practice presented by this talk is troubling to me.  As described, the practice that this presenter provided goes like this: Within the context of the program, the business architect would pull up a blank copy of the business model canvas and sit with his or her executive sponsor or steering committee to fill it out.  By doing so, he or she would understand “the” business model that impacts the program. 

During the Q&A period I asked about a scenario that I would expect to be quite commonplace: what if the initiative serves and supports multiple business models?  The presenter said, in effect, “we only create one canvas.”  My jaw dropped.

A screwdriver makes a lousy hammer but it can sometimes work.  The wrong tool for the job doesn’t always fail, but it will fail often enough to indicate, to the wise, that a better tool should be found.

The Osterwalder’s business model canvas makes a very poor tool for capturing business forces from the perspective of a program.  First off, programs are transitory, while business models are not.  The notion of a business model is a mechanism for capturing how a LINE OF BUSINESS makes money independent of other concerns and other lines of business.  Long before there is a program, and long after the program is over, there are business models, and the canvas is a reasonable mechanism for capturing one such model at a time.  It is completely inappropriate for capturing two different models on a single canvas.  Every example of a business model, as described both in Osterwalder’s book and on his web site, specifically describe a single business model within an enterprise.

I have no problem with using business models (although my canvas is different from Osterwalder’s).  That said,  I recommend a different practice: If the business initiative is doing work that will impact MULTIPLE business models, it is imperative that ALL of those business models are captured in their own canvas.  The session speaker specifically rejected this idea.  I don’t think he is a bad person.  I think he has been hammering nails with a screwdriver.  (He was young).

Here’s where he made his mistake:

multistream value chain

In the oversimplified value stream model above, Contoso airlines has three business models.  The business owners for these three businesses are on the left: Bradley, Janet, and Franklin.  Each are primarily concerned with their own business flows.  In this oversimplified situation, there are only two programs, each with one project.  If the session speaker were working on the Plantheon program, his idea works.  there is only one business model to create.  That nail can be hammered in with a screwdriver.  Lucky speaker.  Showing Franklin his own business model is a good thing.

But if we are working on the Flitrack program, what do we show Franklin?  if we create a “generic” canvas that includes cargo, he will not recognize the model as being applicable to his concerns.  He will not benefit and neither will the program.  In fact, Franklin will think us fools because he had a presentation from Plantheon yesterday showing him an accurate model… don’t you people talk?

Program Flitrack should have one-on-one conversations with Bradley and Janet to develop their business models.  The business model that Franklin cares about does not need to be created again.  It can come out of the repository.  The Flitrack program would consider all three models as independent inputs to the business architecture of the organization impacting the program. 

Anything less is business analysis, not business architecture.