drEAmtime – summary

by

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


 

Categories Uncategorized

Complexity is not a problem

by

There is a common view in the enterprise architecture world that complexity is a big problem, perhaps the biggest problem, and that the primary task of enterprise architecture is to deal with this complexity.

  • “Enterprises are instances of complex adaptive systems having many interacting subcomponents whose interactions yield complex behaviors.  Enterprise Architecture is a way of understanding and managing such complexity.” (Beryl Bellman Managing Organizational Complexity pdf FEAC Oct 2009)

Indeed, I’m sure I’ve said things like this myself. But if complexity is a problem, whose problem is it? I am not seeing a huge rush of businessmen hiring enterprise architects just to deal with The Complexity Problem. Usually they have much more practical problems that they want addressing.

Read more »

Agility and Fear

by

Frank Furedi argues that human thought and action are being stifled by a regime of uncertainty. The only thing we have to fear is the ‘culture of fear’ itself (April 2007),

McGregor introduced the distinction between Theory X and Theory Y, referring to different beliefs about the behaviour and motivation of workers, which may be embedded in management practices and organization culture. Ouchi argued that McGregor’s distinction doesn’t work for all cultures, and identified a third theory, Theory Z, which he used to explain the behaviour of most Japanese companies and some Western companies.

Theory X refers to a set of beliefs in which workers are lazy, require constant supervision, and are motivated only by financial rewards and penalties.

Theory Y refers to a set of beliefs in which workers can be trusted to pursue the interests of the firm without constant supervision, and respond to a range of motivators.

Theory Z refers to a set of beliefs about lifetime commitment between employers and employees.

If we frame fear in terms of Theory-X, then it becomes fear-and-blame and we can all go tut-tut. But isn’t there also a way of framing fear in terms of Theory-Y, without yoking it to blame? Performing artists may experience some stage-fright prior to producing an outstanding performance, and while excessive stage-fright may be debilitating, some degree of anxiety may be a positive stimulus. Are we to ban all forms of anxiety and uncertainty from the organization, so that everyone can feel cosy and safe?

And what about Theory-Z? If an organization is under existential threat, then the members collectively need to focus all their energy and creativity on restoring the viability of the organization, and it would be perfectly normal for them to be emotionally as well as intellectually engaged in this task. Necessity, as they say, is the mother of invention.

All I’m saying is that there are different types of fear, which may have different effects on organizational behaviour. Fear-and-blame is one particular type of fear, but there are other types.

Many workers rightly feel responsible for their work. In most organizations, employees or contractors are ultimately vulnerable to loss of status or loss of earnings if they fail to perform satisfactorily. A completely fear-free organization would be disengaged from its customers and environment, and therefore ethically problematic.

However, a caring organization may be able to attenuate some of this feeling of vulnerability, and provide some kind of safety net that allows people to take reasonable risks without too much fear of failure. Whereas an uncaring organization either fails to provide proper boundaries, or amplifies the sense of vulnerability by capricious and unjust management practices.

Agility and Fear

by

Frank Furedi argues that human thought and action are being stifled by a regime of uncertainty. The only thing we have to fear is the ‘culture of fear’ itself (April 2007),

McGregor introduced the distinction between Theory X and Theory Y, referring to different beliefs about the behaviour and motivation of workers, which may be embedded in management practices and organization culture. Ouchi argued that McGregor’s distinction doesn’t work for all cultures, and identified a third theory, Theory Z, which he used to explain the behaviour of most Japanese companies and some Western companies.

Theory X refers to a set of beliefs in which workers are lazy, require constant supervision, and are motivated only by financial rewards and penalties.

Theory Y refers to a set of beliefs in which workers can be trusted to pursue the interests of the firm without constant supervision, and respond to a range of motivators.

Theory Z refers to a set of beliefs about lifetime commitment between employers and employees.

If we frame fear in terms of Theory-X, then it becomes fear-and-blame and we can all go tut-tut. But isn’t there also a way of framing fear in terms of Theory-Y, without yoking it to blame? Performing artists may experience some stage-fright prior to producing an outstanding performance, and while excessive stage-fright may be debilitating, some degree of anxiety may be a positive stimulus. Are we to ban all forms of anxiety and uncertainty from the organization, so that everyone can feel cosy and safe?

And what about Theory-Z? If an organization is under existential threat, then the members collectively need to focus all their energy and creativity on restoring the viability of the organization, and it would be perfectly normal for them to be emotionally as well as intellectually engaged in this task. Necessity, as they say, is the mother of invention.

All I’m saying is that there are different types of fear, which may have different effects on organizational behaviour. Fear-and-blame is one particular type of fear, but there are other types.

Many workers rightly feel responsible for their work. In most organizations, employees or contractors are ultimately vulnerable to loss of status or loss of earnings if they fail to perform satisfactorily. A completely fear-free organization would be disengaged from its customers and environment, and therefore ethically problematic.

However, a caring organization may be able to attenuate some of this feeling of vulnerability, and provide some kind of safety net that allows people to take reasonable risks without too much fear of failure. Whereas an uncaring organization either fails to provide proper boundaries, or amplifies the sense of vulnerability by capricious and unjust management practices.

How Offices Make People Stupid

by

@benhammersley at #RSAwork talks about the future of office work, and identifies some of the ways that organizations make themselves stupid. The irony is that a lot of these mechanisms were supposed to make offices more productive and efficient, and to promote collaboration and creativity. As Ben puts it


“We have optimized being on top of things rather than getting to the bottom of things.”

Let’s start with open plan offices. As Ben tells the story, these were introduced in an ideological attempt (supposedly originating in North California) to flatten the office hierarchy, to remove barriers between people, and to encourage people and technology to work together in perfect harmony. There are various dysfunctional versions of this Californian Ideology – see my post All Chewed Over By Machines (May 2011).

In practice, various interesting forms of behaviour emerge in open plan offices. Ben notes the widespread practice of more powerful workers grabbing the desks near to the wall, leaving juniors huddled in the middle in a state of permanent anxiety, as if they were antelope anticipating the lion’s pounce.

Many offices are designed as semi-open plan, with people huddled in cubicles, but with the constant chance of someone popping a head over the partition.

In some offices, there is a deliberate policy to move people around – sometimes called hot-desking. One of the supposed benefits of this policy is that it encourages workers to constantly develop new relationships with their transient neighbours. For companies whose workers don’t spend all their time in the office, this policy also reduces the amount of office space required. However, the uncertainty and anxiety of getting any desk, let alone a decent desk near the wall and away from the more irritating co-workers, might be regarded as a negative factor.

Putting aside the economics and culture and psychological impact of open plan offices, the essential justification is that they promote communication and collaboration. These elements are necessary but not sufficient for productivity and innovation in a knowledge-based organization. Not sufficient because productivity and innovation also depend on concentrated hard work.

Read more »

How Offices Make People Stupid

by

@benhammersley at #RSAwork talks about the future of office work, and identifies some of the ways that organizations make themselves stupid. The irony is that a lot of these mechanisms were supposed to make offices more productive and efficient, and to promote collaboration and creativity. As Ben puts it


“We have optimized being on top of things rather than getting to the bottom of things.”

Let’s start with open plan offices. As Ben tells the story, these were introduced in an ideological attempt (supposedly originating in North California) to flatten the office hierarchy, to remove barriers between people, and to encourage people and technology to work together in perfect harmony. There are various dysfunctional versions of this Californian Ideology – see my post All Chewed Over By Machines (May 2011).

In practice, various interesting forms of behaviour emerge in open plan offices. Ben notes the widespread practice of more powerful workers grabbing the desks near to the wall, leaving juniors huddled in the middle in a state of permanent anxiety, as if they were antelope anticipating the lion’s pounce.

Many offices are designed as semi-open plan, with people huddled in cubicles, but with the constant chance of someone popping a head over the partition.

In some offices, there is a deliberate policy to move people around – sometimes called hot-desking. One of the supposed benefits of this policy is that it encourages workers to constantly develop new relationships with their transient neighbours. For companies whose workers don’t spend all their time in the office, this policy also reduces the amount of office space required. However, the uncertainty and anxiety of getting any desk, let alone a decent desk near the wall and away from the more irritating co-workers, might be regarded as a negative factor.

Putting aside the economics and culture and psychological impact of open plan offices, the essential justification is that they promote communication and collaboration. These elements are necessary but not sufficient for productivity and innovation in a knowledge-based organization. Not sufficient because productivity and innovation also depend on concentrated hard work.

Read more »

Culture Mapping Tool

by

Dave Gray posted on his blog that he has created a tool to help understand corporate cultures. This looks very interesting… I could see lots of uses for this tool as an Enterprise Architect. The typical stakeholder management only gets…

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

Three Best Practices for Successful Implementation of Enterprise Architecture Using the TOGAF® Framework and the ArchiMate® Modeling Language

by

How should we organize ourselves in order to be successful? An architecture framework is a foundational structure for developing a broad range of architectures and consists of a process and a modeling component. The TOGAF® framework and the ArchiMate® modeling language are two leading and widely adopted standards in this field. Continue reading →