Aggregated enterprise architecture wisdom
For the second post in the TOGAF Demystification series, let’s tackle the common topic of TOGAF to other frameworks. Over the years I’ve heard the debates between passionate EA’s and seen the seemingly endless posts on LinkedIn and blogs on…
I’m currently looking at international identity standards and thought that I might post some thoughts about them as I look at them. The first that I have looked at is ISO/IEC FDIS 24760-1:2011(E) “A framework for identity management – Part 1: Terminology and concepts”. This standard is supposed to define key terms for identity management […]
“TOGAF is not complex”. Its content is not, in fact it is rather bland, the form is though. It’s simply too large, consisting of sections that are not specific to architecture but overlap, unnecessarily, with other methodologies.
We wrote up a technical whitepaper that summarizes TOGAF and how you can build, maintain, and gain return on investment on an enterprise architecture with our tooling — System Architect, Focal Point, RAM, and other IBM tools. The technical whitepaper – Building Enterprise Architectures with TOGAF 9 — is available for download for free, here: http://public.dhe.ibm.com/common/ssi/ecm/en/raw14241usen/RAW14241USEN.PDF […]
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:
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).
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:
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).
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.
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.
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.
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.
@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.
@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.
Reblogged from Ian Carroll: After reading Dean Leffingwell’s awesome books on scaling Agile I was left wondering how to apply the principles in practice. Here’s a practical example – with a few extras courtesy of Kanban thinking. The above system … Continue reading →