Change Management – Kurt Lewin

March 31, 2008

In Enterprise Architecture we often talk about models, patterns, best practices, technology and the like. Given that EA is fundamentally about change, it’s interesting that change management doesn’t get a lot of coverage in EA circles. In this post I’ll introduce a very simple model of change management that has been around for over 50years.


The term “change management” is a daunting one. Conceptually we know what it is and we know that we need it – but we often don’t know where to start. One of my favourite models of change management was devised by Kurt Lewin. I like it because it is insightful – yet extremely simple. And it shows us exactly where to start.In essence, the model proposes that “change” is a 3 step process:Change Management

Step 1: Unfreezing
This step deals with determining what needs to change and why it needs to change. It’s about overcoming organisation inertia, breaking down the status quo and changing mindsets. This step is often characterised by fear, uncertainty and anxiety. People’s doubts and concerns must be understood and managed.

Step 2: Change
Once people understand the need for change, new ideas are developed and introduced (usually through a collaborative and inclusive effort). Once the future state is agreed on, the organisation begins the transition from the old to the new. During the transition people will be out of their comfort zone so to allay their fears you need continually reinforce how the change will benefit THEM (not everyone will fall into line because something is good for the company).

Step 3: Freezing
Once the transition is complete and everyone has found their feet again you need to institutionalise the changes – make them the new status quo. Policies, procedures, reward systems and organisational values are all changed to reflect the new reality. This helps the change ‘sink in’ and provides some closure. Eventually, people’s comfort levels begin to return to previous levels.

This key insight from this model is that the process of “change management” has 3 distinct steps. To maximise chances of success you we need to start at the beginning and work your way through.

You could start at Step 3. You can attempt to freeze change by introducing new policies and procedures and then expect people to follow them. The trouble is – they won’t. At best they will obey the letter of the law but not the spirit and at worst they’ll just ignore everything and keep doing what they’ve always done. Sure, you could spend a lot of time on monitoring and enforcing compliance but this is wasted time, money and effort. If you manage change correctly people will voluntarily move with you – without any oversight or coercion.

Unfortunately you see a lot of enterprise architecture groups starting at Step 3. Endless documents, models, policies and procedures are produced and disseminated throughout the organisation. The architecture group expects people to comply. But they never do. And they never will. It is really easy for various groups to come up with arguments why they are special and why the rules shouldn’t apply to them. Typically, those arguments are hard to refute. Even if the architecture group had ‘friends in high places’ which could mandate compliance, such an adversarial spirit between the central architecture group and other groups is counter productive.

You could start at Step 2. Starting here is an improvement over starting at Step 3 because you’re at least consulting various stakeholders throughout the organisation, rather than just forcing change down their throats. This collaborative and inclusive process means you can come up with a better and more complete vision of the future and it also means that people will be less resistant to change because they’ve had a say in what the change will be. The problem with starting at this step is that ‘less resistance to change’ is not the same as ‘support for change’. And you need the latter.

Again, you see a lot of architecture groups starting at this step. Often you see a new lead architect come in and try and change things to suit their personal preference. Or a new technology comes out and the architecture group incorporates it into their vision. The problem is that various project teams are likely to be cynical of the proposed changes and dismiss them as “change for change sake”. Even if the end state is better than the status quo people won’t change, largely because change is hard work. You need to show people that the difference between the future state and the status quo is big enough to make it worthwhile moving.

But you should be starting at Step 1. By process of elimination we’ve arrived at Step 1. The logical place to start. Obviously, there’s never any guarantees when it comes to something like ‘change management’ but as with everything, if you take the time to think it through, you at least give yourself a fighting chance of success.


OASIS Reference Model for SOA. Part 9: Core Concepts – Execution Context

March 28, 2008

This post is part of a series. Click here for the ‘home page’


According to OASIS, the execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interactionThe execution context is the foundation of any successful service interaction because:

  • It is a collection of all the agreements in place for a given service interaction (e.g. semantics, protocols, policies etc).
  • It allows the consumers and providers to distinguish between different instances of the same service.
  • It allows providers and consumers to identify each other.
  • It provides a mechanism for policy enforcement.
  • It provides a mechanism for managing state (yes I know the theory says that services should be stateless but as with everything in technology – compromises sometimes have to be made)
  • It provides a context for interpreting data. For example, Amazon provides a ‘recommended books’ feature. A list of recommended books is meaningless unless you log in and tell Amazon who you are. Only then, does the data have meaning to you, the consumer.

It’s also noteworthy that:

An execution context often evolves during a service interaction. The set of infrastructure elements, the policies and agreements that apply to the interaction, may well change during a given service interaction. For example, at an initial point in an interaction, it may be decided by the parties that future communication should be encrypted. As a result the execution context also changes – to incorporate the necessary infrastructure to support the encryption and continue the interaction.”


OASIS Reference Model for SOA. Part 8: Core Concepts – Contract and Policy

March 25, 2008

This post is part of a series. Click here for the ‘home page’


According to OASIS:

  • A policy represents some constraint or condition on the use, deployment or description of an owned entity as defined by any participant.
  • A contract, on the other hand, represents an agreement by two or more parties.

Service Policy
In order to write effective service policies you need to keep just two things in mind:

  • Policies are based on assertions and assertions must be measurable.
  • An assertion can only be adopted as a policy if it is enforceable.

These examples will help clarify these two points.

Example 1: Valid and Invalid Assertions

An example of a valid (i.e. measurable) assertion is “all messages are encrypted.” This assertion is measurable because the message is either encrypted or it is not.

An example of an invalid assertion is “only small orders will be accepted electronically”. This assertion is not measurable because there is no way of knowing what ‘small’ means. A better assertion would be “only orders valued under $50,000 will be accepted electronically.”

Invalid assertions can never be policies.

Example 2: Valid Assertion and Valid Policy
A valid (i.e. measurable) assertion can be adopted as a policy only if it enforceable.

Continuing on from the above example, we know that “all messages are encrypted” is a valid assertion. It would also make a valid policy because:

  • We can measure the assertion: ether the message is encrypted or it is not
  • We can adopt the assertion as a policy because we can enforce it: if it is not encrypted the message will be rejected

Example 3: Valid Assertion but Invalid Policy
Just because an assertion is measurable does not mean that it will automatically make a good policy. To make a good policy the assertion must be enforceable.

Here is an example of a valid assertion:
“The value of the orders placed in any given day must not exceed $50000 unless prior arrangements have been made with the sales manager in charge of your account.”

This assertion is valid because:

  • We can easily measure the value of orders placed in a given day
  • We can measure whether ‘prior arrangements’ have been made – either they have or they haven’t.

Would this assertion make a good policy? It depends. If the service can find out whether ‘prior arrangements’ have been made in real time when an order is placed then it would make a valid policy. However, if the ‘prior arrangement’ takes the form of a phone call between a sales manager and a client and no record of it is made in a repository accessible to the service then clearly the policy is not enforceable.

When developing your service policy you may also want to consider these points:

  • Define policies in terms of ‘real world effects’. For example, your policies should:
    • prevent unauthorised actions to be performed
    • invalid states to be entered into
    • business rules to be violated
  • Explain the consequences of attempting to violate the policy (e.g. if a client tries to place an order over $50,000 it may be rejected and no harm done, or the account may be disabled)
  • Consider whether any ‘compensatory actions’ may be appropriate when policy violations are detected further down the chain (if the service the consumer is interacting with calls other services). It is not always possible to check all applicable policies ‘at the gate’ (the first service). For example:
    • the consumer calls Service A, which in turn calls Services B, C and D.
    • Services B/C alter shared stated used by D.
    • When D is called the request may violate D’s policies, but the violation may not have been foreseeable when A was called.
  • Policies should cover BOTH of these areas:
    • Infrastructure (e.g. security, privacy, Quality of Service etc)
    • Business rules

Service Contract
A service contract is an agreement between two parties. A contract is basically a collection of policies. The policies in a contract may be:

  • Generic policies that apply to all
  • Specific policies that relate only to the agreement/relationship between the parties in a contract.

A contract may be arrived at through:

  • Out-of-band process – outside of the SOA environment (e.g. lawyers in a boardroom)
  • In-band process – during the course of service interaction (e.g. a service may have a policy that when you interact with it for the first time, you are implicitly ‘signing up’ for a 6 month contract at a set monthly fee)

OASIS Reference Model for SOA. Part 7: Core Concepts – Service Description

March 23, 2008

This post is part of a series. Click here for the ‘home page’


The service description represents all the information needed in order to use a service. There is no one “right” way of describing a service, rather the elements of description required will depend on the context and the needs of the parties using the service.In essence, the service description is an amalgamation of information the other core concepts in the OASIS Reference Model:

Interaction

As discussed earlier, interaction is composed of:

  • Behaviour Model, which is made up of:
    • Action Model
    • Process Model
  • Information Model, which contains information about:
    • Semantics
    • Structure

All of these elements should probably be included in your service description.

Visibility
As discussed earlier, visibility is composed of:

  • Awareness
  • Reachability
  • Willingness

The documentation from OASIS suggests that you only need to include the ‘reachability’ components in your service but I disagree. I think all three elements need to be there. For example:

  • Awareness – location of the service (and maybe alternate/backup locations)
  • Reachability – protocols used
  • Willingness – fair use policies

Real World Effect
Clearly the whole point of interacting with a service is to “get something done”. The service description needs to include sufficient information to allow the consumer to clearly understand the real world effects of invoking a service.

For more information about real world effect click here.

Contract and Policy
A service description may include information about the policies (i.e. constraints or conditions of use) that govern the use of the service.

For more information about contract and policy click here.


Blue Ocean Strategy

March 21, 2008

How to Create Uncontested Market Space and Make Competition Irrelevant
Author: W. Chan Kim, Renée Mauborgne
ISBN: 1591396190


The basic premise of the book is that there are two types of markets:

  • Red oceans which are markets which are known today – the mainstream where companies try to outperform their rivals to get a greater share of existing demand.
  • Blue oceans which are markets that are unknown (yet to be created). While red oceans are characterised by competition for existing demand, companies that create blue oceans are creating demand and new markets – making competition irrelevant.

Traditionally, business books have focussed on how to compete in red oceans. Michael Porter is the undisputed thought leader in that space and he proposed that companies can either choose to be a cost leader or to differentiate. This book on the other hand proposes that companies that seek to create blue oceans pursue low cost and differentiation – simultaneously. The authors dubbed this approach “value innovation”. The book does provide a number of tools and techniques that help you formulate a compelling value proposition and thus create a blue ocean.

The book is an easy read and it will help build your “innovation” and “thinking outside the box” skills, and for those reasons it is well worth a read.

The target audience for this book is obviously company managers but even so, I like to take at least one thing away from each book I read and try and apply it to enterprise architecture. One of the tools in the book is called the “Eliminate-Reduce-Raise-Create Grid”. Essentially it involves analysing your industry and looking for ways to:

  • Eliminate factors that the industry takes for granted even though customers no longer use them for making buying decisions.
  • Reduce factors that have been overdesigned or overcomplicated in the race to beat competitors, resulting in ‘overserving’ customers. Customers may not want these things and wouldn’t pay for them but since they’re ‘free’ they’ll take them.
  • Raise factors well above the industry standard where they create new value for customers. Or put another way – eliminate the compromises that the industry forces customers to make.
  • Create entirely new sources of value for buyers, thus creating new demand, and allowing you to set prices without reference to the industry as a whole.

So how can you apply this to EA? When we’re building solutions, the concept of “value” should be foremost in our minds. But how often do you see this: the solution team meets with the client. They listen intently and studiously write down everything the client says. Then they label the result a “Requirements Document”. All too often, no effort is made to assess the “value” of what the client is asking for. The “Eliminate – Reduce – Raise – Create” tool is a really simple tool for quickly assessing the underlying value of each requirement. Here’s a simple example of how you can use this tool:

  • Eliminate any requirements that do not have a hard, traceable link to business value. (e.g. “we’d like to be able to change the fonts and colours in the application and reorder the fields on the form”)
  • Reduce any requirements that are “nice to have” or been put in just in case (e.g. “we need to be able to export reports to Excel. It would also be nice to be able to export to PDF, Word and HTML)
  • Raise any requirements that don’t offer a level of future proofing for reasonably foreseeable events (e.g. “the application only needs to support 50 concurrent users”).
  • Create requirements that have not been explicitly asked for (or have been explicitly excluded) but are generally accepted as important (e.g. “we don’t need any security built into the system because it will be hosted on a secure intranet”).

Pretty simple stuff – and we all do it subconsciously- but sometimes it’s good to apply a bit of rigour or structure to our subconscious – particularly when you need to communicate your thought process to clients.


The Red Queen Principle

March 18, 2008

The Red Queen Principle (or Red Queen Hypothesis) was proposed Leigh Van Valen who based his theory on a quote in Lewis Carroll’s Through the Looking Glass. In the book, the Red Queen tells Alice that “in this place, it takes all the running you can do, to keep in the same place.” The Read Queen Principle is usually applied in the context of evolutionary biology, but it can also be applied to business and IT.


The Red Queen Principle states that:

“For an evolutionary system, continuing development is needed just in order to maintain its fitness relative to the systems it is co-evolving with”

In essence what this means is that when a species evolves, it gains a competitive advantage and allows it to capture a larger share of the resources available. Consequently, other, competing, species must also evolve so they can regain their share of resources. When one improves, the other also quickly improves, and so neither is better off relative to the other. This is a classic “arms race.” Another word for this phenomenon is “non-progressive evolution”.

What has this got to do with IT?

I like to bang my “IT should be a source of competitive advantage” drum, but if the Red Queen Principle holds true then it seems my crusade is futile. As soon as you attain some competitive advantage, everyone else will follow suit, and despite all the hard work we end up no better off. Furthermore, if there is no significant first mover advantage then it is bordering on negligence to accept the risks associated with being a trailblazer, when the rewards of doing so clearly don’t justify it.

The Red Queen Principle seems to be alive and well in IT today. Each year increasing amounts of money are spent on IT but no one seems to gain any advantage. We’re caught on a treadmill and it seems we’ve only got two options: slow down and fall behind or run ever faster just to stay in the same place (relative to everyone else).

We need to get off the treadmill. Thankfully the Red Queen Principle itself gives us two ways of doing it:

  • make it difficult to co-evolve.
  • change the ecosystem.

Option 1: Make it difficult to co-evolve.
When deciding between various options for achieving a competitive advantage, be sure to consider the “reproducibility” of your idea. If you pursue initiatives that can’t easily be copied by competitors then you’re preventing them from “co-evolving”. One way of doing this is through legal means such as patents, but in reality this will rarely be an option. However, every organisation has a unique set of strengths. Find out what yours are and then look for ways to amplify them through technology. Even if your competitors copy your technology strategy, they wont get the same bottom-line results as you. YOUR investment will be aligned with YOUR unique strengths. Their investment will be reactive and aligned with your strategy, not their business.

Option 2: Change the ecosystem.
In business, the ‘ecosystem’ is the market you operate in. The book Innovators Dilemma provides empirical evidence that there is no significant first mover advantage in mature, mainstream markets BUT there is considerable advantage in emerging/niche markets. Look for innovative ways to redefine your ecosystem. Technology is an excellent way of moving the goal posts.

A large part of the Enterprise Architecture efforts in your organisation should be oriented towards the pursuit of these options. This is what strategic IT is all about.


OASIS Reference Model for SOA. Part 6: Core Concepts – Real World Effects

March 16, 2008

This post is part of a series. Click here for the ‘home page’


The consequence of invoking a service is the realization of one or more real world effects. These effects may include:

  • Returning information in response to a request for that information
  • A change in the shared state of defined entities
  • A combination of both

Note that the shared state does not necessarily refer to specific state variables being saved in physical storage but it is really a “mutual understanding” between the provider and consumer. For example, if I make an airline reservation, the airline and I have a mutual understanding that I will be travelling on a specified date. There is no “physical” data source that is shared between us.When thinking about real world effects in your architecture, consider such things as:

  • Does the consumer need to know ANYTHING about the internal (private) workings of a service? Does the provider need to know anything about the consumer? Each party should not have any knowledge of the internal workings of the other.
  • If the interaction between a provider and consumer is a sequence of events, how do you manage ‘incomplete’ state (i.e. when the sequence is not yet complete)?
  • Is there sufficient auditing/logging of real world effects?
  • Are ALL real world effects clearly understood by the consumer? Or is there any side effects of the interaction that the consumer may not be aware of?
  • Are the real-world effects clearly understood by consumers? For example, if you call a “BookFlight” service and no seats are available, the service may notify the consumer of that fact OR it may automatically put the person on a waiting list – this is also a real world effect but unless the consumer knows that this will happen it is not the real world effect intended by the consumer.