Kai Schlüter

drEAmtime – modelling

by

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.

Categories Uncategorized

drEAmtime – modelling

by

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.

drEAmtime – Frameworks

by

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

Categories Uncategorized

drEAmtime – Frameworks

by

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

drEAmtime – PACE SCAN

by

I continue to explore the red line laid out by the great post from Ivo Velitchkov. So far I have created following posts:drEAmtime – Communication drEAmtime – Bridging the Silo drEAmtime – Capability Cemetery drEAmtime – EPIC SCANd…

drEAmtime – PACE SCAN

by

I continue to explore the red line laid out by the great post from Ivo Velitchkov. So far I have created following posts:drEAmtime – Communication drEAmtime – Bridging the Silo drEAmtime – Capability Cemetery drEAmtime – EPIC SCANd…

drEAmtime – WISE SCAN

by

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

drEAmtime – WISE SCAN

by

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

drEAmtime – Archetypes

by

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:drEAmtime – CommunicationdrEAmtime – Bridging the SilodrEAmtime – Capability Cemetery drEAmtime – EPIC SCAN To quote Ivo: But…

drEAmtime – Archetypes

by

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:drEAmtime – CommunicationdrEAmtime – Bridging the SilodrEAmtime – Capability Cemetery drEAmtime – EPIC SCAN To quote Ivo: But…

Categories Uncategorized

drEAmtime – EPIC SCAN

by

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.

drEAmtime – EPIC SCAN

by

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.