#eavoices

Power, Process, Project, People

by

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:

RT @davidsprott: The shape of the next generation EA framework. t.co/dolaKQtb #CIO #ecosystem #services #entarch
— Tom Graves (@tetradian) 18. Februar 2013

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.

Lessons from Lance – the future and Digital Doping

by

Recently several of us Gartner analysts were discussing the future of digitally enhanced humans. This covers a wide range from drugs that enhance cognition to prosthetics that enhance our physicality. With Lance Armstrong’s public fall from grace it is easy to see how artificial enhancement has infiltrated and tarnished professional sports. But I’m wondering about […]

The post Lessons from Lance – the future and Digital Doping appeared first on Mike Rollings.

Deep Thinking on The Architecture of Architecture: Meta-Architecture

by

As many of you have already have known, Enterprise Architecture and Architecture within the context of sociotechnical organization is going through what I believe a renaissance period.   The architecture field is moving to more of an interdisciplinary art and science.    Also many architects, myself included, have been trained on producing goal oriented systems.  This teleological approach based…

Cybernetic Entropy

by

The pioneers of cybernetics borrowed the concept of entropy from thermodynamics, the tendency of systems to become less organized over time.They regarded structure and information as ways of halting or reversing entropy, and information is sometime…

Enterprise Life Forms

by

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

Details vs Context

by

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

Walk the Talk

by

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:

I suspect that the primary job role of Enterprise Architects is to argue with other EAs about what #entarch is. Prove me wrong, people.
— Kevin Brennan (@bakevin) 7. Februar 2013

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.

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


 

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 »