Aggregated enterprise architecture wisdom
@danlockton is doing a survey How do actual designers use academic literature?What are the barriers you’ve experienced?What service would you like to see?What would be useful to you?Could academics make their work more easily applicable?Here’s my ans…
@danlockton is doing a survey How do actual designers use academic literature?What are the barriers you’ve experienced?What service would you like to see?What would be useful to you?Could academics make their work more easily applicable?Here’s my ans…
Last week I had the pleasure of attending and presenting at the Open Group conference in Newport Beach, California. I find these conferences enlightening as I enjoyed the dialog with fellow professions who share similar point of views on the discipline of Enterprise Architecture. I have made the following observations: We have a huge challenge in…
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).
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.
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).
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.
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.
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.
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…
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,…
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 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 unexpe…
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
