Gartner keynote transcript: Conquering complexity

The following transcript is from the keynote presentation, entitled "Conquering Complexity: Operational Excellence in IT," at the Gartner Symposium ITxpo  in San Francisco on May 16:

RAY:
And you thought IT was complicated!

Just remember that
when you open your car door.

So, good morning, I’m Ray Paquet.

I'm an IT Ops guy.

We worry about keeping the systems up and running.

COLLEEN:
And I'm Colleen Young.

I'm a former IT Exec, and I worry about responding to constantly changing business demands.

RAY:
And that's exactly where the problem starts.

The business change is what makes IT Ops a never ending battle.

COLLEEN:
Yes, it's a challenge...
but we have to deal with it.

So we can start by really thinking about where does the complexity come from, and why does it worry us so?

RAY:
Well, one of the reasons it worries me is because it leads to the Ops people being over worked and underpaid.

COLLEEN:
Ray, most CIOs would say the same thing.

But how do the people you speak with see complexity arising?

RAY:
How much time do we have?

COLLEEN:
Net it out!

RAY:
To start with... there’s the constant search for a silver bullet – the one great new thing that will solve all our problems.

Then there’s the implementation of point solutions without looking at the bigger picture.

More generally, there’s a project focus versus a more architectural approach...
which is really all about short term metrics driving short term behaviors.

Of course, this is not a unique challenge for the IT Ops world – we hear the same thing at every level, from the CEO satisfying quarterly earning expectations, on down.

But there is a sense that IT Ops is the end of the chain – the place all the complexity gets pushed to.

One of our colleagues referred to managing complexity as being akin to playing the whack a mole game –
you hit it down in one place, and it just pops up somewhere else.

And then there’s the issue I think Colleen will certainly relate to as well    poor change management discipline.

COLLEEN:
... Or none at all!

You know...
with all this change and resulting chaos...
IT can be a pretty tough job.

ROLL VIDEO 1 http://www.jsquaredinc.net/ gartner/1cutdown.mov

COLLEEN:
Obviously this is an extreme example...
clearly not a situation which would apply to anyone here.

But I do think there are some lessons we can point out.

RAY:
I’m with you.

One of the basic issues we all face is that the nature of complexity keeps changing – it’s not like we have a
"fixed problem" that we’re able to just chip away at.

COLLEEN:
One of the reasons complexity produces so much anxiety is that it’s cyclical...
technological and societal change are constantly acting upon one another.

As one aspect of our lives gets easier, another gets harder.

Inevitably, just when we’ve gotten used to “the new normal”, it changes again.

RAY:
Right... typically we go through a cycle of growing complexity followed by simplification, and repeat.

And we may enter that cycle at the high point, or the low –

We might see the introduction of something simple and it gradually gets more complex
... until eventually it’s got too complex, and someone has to go through some re design step function to shift back to greater simplicity.

Many IT departments have inherited a skunk works project, home developed application that found its way into full blown production and became unsustainable, because it was never architected for production scale.

It all seemed so simple when it started out.

COLLEEN:
And we also see the opposite case – the first introduction of a leading edge technology which then gets refined over time, becoming simpler and easier to use.

Computers themselves are an obvious example of that pattern.

I don’t think my 73 year old father could have achieved much with ENIAC, but he’s quite at home with a PC.

So complexity isn't static –
over time we see it going back up again – even if it is somehow “under the covers”.

RAY:
And of course, what is under the covers too often breaks through the covers.

While everything is working...
life is fine.

But when something breaks, it gets a whole lot more difficult to figure out where the problem is...
and what has gone wrong.

This is the reality that IT Ops people are facing every day because complexity keeps on increasing.

COLLEEN:
But it’s not enough to consider complexity as part of some great “circle of life” and become pessimistically fatalistic.

If we really want to get a handle on complexity, we have to see that complexity is not simply a bad thing, to be reduced wherever possible.

There’s no question that complexity has its downsides.

It slows us down,
introduces the opportunity for mistakes, costs more,
and generally makes it harder to see the forest for the trees.

But it also provides benefits.

It can enhance functionality, increase personal control, and... maybe somewhat paradoxically ... it can even improve reliability, quality and reaction time.

RAY:
There’s a good way to express one angle on this that comes from the study of systems at a very general level.

It’s known as the Law of Requisite Variety.

Basically, it says that if we want to control a system, we can’t simplify the control mechanism beyond some point.

Think of simple mechanical systems, this is obvious...

We need enough levers to control the various independent features of the machine...
and that's why the intro video is so much fun.

Because it illustrates exactly this point by exaggeration.

***
But this principle is very general...
it applies to many different kinds of systems.

So let’s turn this into something a little more specific and practical.

In IT Ops, when we are going to make a change to address a business requirement, the issue of complexity has to be at the forefront of our thoughts.

We can consider that the value of complexity is roughly a bell curve.

The part we normally recognize is the right side – as complexity increases, value declines –
therefore complexity is bad.

But there is also the left side.

The situations where we add complexity to gain value –
and at some level much of technology lies on that side of the curve.

***
So... we might put this together and consider a metric we could call “value of complexity”.

We can get value by making our systems more complex... up to a point – but then diminishing returns set it.

In fact, not just diminishing returns but negative returns – now we’re into bad complexity.

Consequently, the first challenge is to recognize where we are on this curve – can I get value from making things more complex?

Is the value of complexity positive... or... negative?

Keeping in mind that as complexity increases, our risks and costs increase.

Now, of course... life is not really this simple!

The curve is not a simple bell curve, and there is no absolute level at which the value of complexity tops out.

It’s really a matter of considering each potential change, in respect to the relationship between complexity and value –
obviously, avoid changes with negative value of complexity.

COLLEEN:
So this gives us a framework for considering good vs. bad complexity.

What does it take to put that into practice?

First, we have to develop the discipline to consider whether a change will have a net positive or net negative effect relative to what we’re trying to accomplish, and we have to examine it over its entire lifecycle.

This means evaluating every proposed complication or added element to determine whether it has a positive return on complexity...
if not, reject it.

But remember – evaluate over a lifecycle, not just at a point in time.

Consider adding complexity to increase target benefits when current levels of things like Availability, Agility, and so on fall below par.

Second, we need to think about using complexity as a remediation strategy.

This may seem crazy in the abstract... instinct tells us simpler is better.

But step back and think for a minute... sometimes we add complexities to fix a problem.

Operating Systems, for example, have clearly got more complex – and the result, for the most part, is improved availability, functionality and quality.

The bottom line is that a mantra of “keep it simple” is inadequate for the realities of life.

And much of this issue revolves around complexity which is “inside” versus that which appears on the “outside”.

RAY:
But even this is a dangerous over simplification.

What is inside in terms of one type of interaction –
say for an end user –
can definitely be on the outside for another...
and of course, that other person may well be the IT Ops guy,
for whom that greater “internal” complexity is anything but hidden.

COLLEEN:
One of the reasons complexity is so hard to deal with is that it has many faces, each with different perspectives, needs and tradeoffs.

There isn’t one isolated dimension we can tackle –
we have to address it from many different directions at once.

RAY:
So, Colleen, you’re saying that complexity is complex because it’s complex!

COLLEEN:
No...!  The point we’re making is that one’s perspective on complexity will vary depending on where one sits.

That is, one person’s complexity is another person’s simplicity.

It’s all in the eye of the beholder.

In our own realm of IT, we can look at the end user, or the world of application development, or the infrastructure domain –
Ray’s stomping ground.

Those are three focus points where there may be value in shifting complexity around from one to another.

And this isn’t just playing that whack a mole game!

It really may be that having the complexity in one place rather than another gives overall benefits.

But finding that optimum is often not easy – it’s not some abstract idealized debate –
(VIDEO CUE)
it can all get pretty emotional between the different interests involved.

ROLL Video 2  http://www.jsquaredinc.net/ gartner/2cutdown.mov

RAY:
We all want to have our cake and eat it, too...
but the story illustrates the point about potentially adding complexity to create greater overall simplicity –
but only if it’s done right.

So what does it mean to do it right?

IT has to realize that they are in the manufacturing business, it's just that they are delivering services instead of building goods.

Manufacturing is managed via the Mft processes.

IT must... must, do the same thing.

This will cause IT to be more repeatable while moving from a Technology view to a Process Based approach.

This is a fundamental shift.

Otherwise, we’re back to the problem I mentioned at the beginning – the technology
fix de jour.

COLLEEN:
Absolutely... and the video also implies the issue of tradeoffs...
not just good complexity vs. bad complexity...
but whose complexity.

RAY:
So let’s tackle this issue of trade offs head on.

First, there’s the issue of trade offs between different interested parties and the value of sticking with the single product for all users versus different products for different users.

The complexity introduced by multiple products can make sense if each matches the needs of a particular group
so well that the value is greater than the increase in complexity.

The trouble is that in practice, it can be very difficult to figure out what the total picture looks like, and what the actual value is.

Second, all constituents are not equal – and some certainly have a lot more clout than others – so sometimes we have to accept a less than perfect solution, because of the political realities.

Which is a large part of why this can all get so uncomfortable.

COLLEEN:
So what can we do about all this?

Complexity analysis must be embedded in our architecture, portfolio management and service delivery decisions.

That may not remove the politics, but at least it gives a better framework for consistent management decisions.

Next, examine complexity from multiple dimensions – its overall net increases or decrease...
its costs versus its benefits... and its specific affects on various constituent groups.

When considering where to place or shift complexity, work backwards from the external customer’s experience, to the internal end users, and lastly on IT.

In other words, don’t make IT’s life easier at the expense of the business or its customers.

And although we all know that you wouldn’t set out with that objective in mind, it’s such an easy jibe to make that being very explicit is the best defense.

More generally I’d say:
Spend more time on the process and less on the technology.

RAY:
Specifically, in the context of IT Ops...
put complexity in the place where it makes sense from a process point of view...
not from a functional point of view.

For example, security patches might get done by the software distribution process in IT Ops or AD, rather than by the security group, where you'd expect it to be done.

As a more extreme example, maybe patch management gets shifted completely outside of your organization to a vendor,
to reduce complexity.

And here we see the implications in terms of control and trust very clearly.

COLLEEN:
OK, Ray, I can buy that these are all good ideas, but it starts to sound suspiciously like we’re saying conquering complexity is just an engineering or an outsourcing challenge.

I’m still thinking we need to re examine the way people actually deal with complexity.

After all, people differ greatly in what they see as being complex vs. simple.

Unless we take that into account, I think we’ll continue to operate in a very sub optimal way.

RAY:
Sub optimal... that sounds like one of my words.

But I can’t disagree.

It’s not just that people have different tolerances for complexity, but that what makes sense in the balance between the technology and the need and capabilities of the individual changes over time.

I can give you a current hot example.

For a long time it’s been obvious and incontrovertible that the way to control the costs of providing PC power across an enterprise is to standardize, and control from the center what equipment and configuration each employee uses.

We’re now seeing a few companies challenging this conventional wisdom, and actually starting to implement policies to allow much greater individual control and discretion in personal computer configuration and use, by putting control at the system interface...
that is, server access rather than the client.

(VIDEO CUE)
But in many cases IT and the users are not communicating.

ROLL Video 3  http://www.jsquaredinc.net/ gartner/3cutdown.mov

RAY:
Now I can assure you that this topic of IT control versus user empowerment has generated ferocious discussion inside our own research communities.

We are certainly not yet at the point where we would advise you to take off the controls and let freedom rein.

But the world changes all the time, and what made for good sense in a world of one desktop computer for dedicated white collar staff who learned computing at work, may not be the right balance for the GameBoy generation with laptops and multiple home computers, PDAs and the rest, who learned to use a computer before they could write.

And this is just one topical example of where we are at the leading edge of a transition.

We can see many examples in the history of IT where innovation has added complexity and, in doing so, allowed the constraints on the organization to change.

E-mail proliferation has changed the way corporations communicate and people collaborate.

It is the primary enabler of the virtual organization.

It appears simple from the user's perspective...
but from the IT Operations view, managing hundreds of thousands or millions of emails is non-trivial.

And e-mail is now a tier one mission critical app.

In fact, the number one applications management inquiry that we get by far is on managing email.

COLLEEN:
It’s pretty easy to relate to the issues of complexity trade offs and moving complexity around at the level of the individual, but we can also observe similar issues at a structural level within the business.

There are a number of good examples coming from supply chain management –
and these can involve substantial changes in business models.

These changes shift complexity between business partners in a way that improves overall supply chain performance, and thus, eventual customer satisfaction.

RAY:
One good example comes from Pepsi USA.

They've restructured their sales and delivery model so that they take orders and then ship...
rather than shipping and asking outlets how much they want – which was of course the traditional approach in sales of many beverages and grocery goods.

Now that certainly shifts complexity around in a big way – but the net is a more effective delivery process.

COLLEEN:
And interestingly, if we look at the example of Cemex, a major international supplier of pre mixed concrete, we see the exact opposite in terms of the shift in business model.

Not surprisingly, the traditional model for concrete delivery is that you order, then it is delivered – you can’t have it hanging around.

But Cemex has managed to develop their understanding of aggregate customer requirements sufficiently that they can essentially load trucks, put them on the road, and know that someone, somewhere, will be able to use the product within the very short timeframe of setting concrete.

It's more complex...
but as far as both Cemex plants and customers are concerned,
it looks a whole lot simpler because of the predictability.

RAY:
So the point is there is no “right” answer in terms of relating complexity to business choices.

But it definitely brings us to the point where we have to pick up on this issue of the relationship between complexity and change management.

I mentioned this right at the beginning as something that comes up even in the very specific context of IT Operations.

But once we see complexity in this broad context of business processes, change management moves front and center.

Managing complexity really means managing change.

COLLEEN:
The relationship between complexity and change is very deep.

As a change occurs, it may simplify or increase complexity, both by its impacts and by the previously unimaginable opportunities it creates.

Those opportunities, then, potentially drive further change.

This spinning vortex of cause and effect inevitably means that conventional wisdom will eventually become outdated and be replaced by new conventions.

Suddenly, previously excluded strategies become viable.

Old assumptions about what is “manageable” or “cost effective” or “best practice” become outdated.

This can lead to a situation where the optimal solution in terms of managing complexity may shift...
and not just shift in an incremental fashion, but radically.

RAY:
So putting that in terms that appeal to the engineer in me... (and I think that goes for most of you, too)...
I’d say change has n order consequences – first order, second order and so on.

COLLEEN:
Yes, quite literally.

We can actually lay out what these n order things are.

There's a framework that can help us think about and predict the impacts of n order change.

Three professors by the name of O’Hara, Watson and Kavan studied the total impact of IT projects on organizations, and they developed a mechanism for classifying IT projects to better predict their scope.

RAY:
In that work, they begin by defining organizations as a collection of two systems:
a cultural system, comprised of organizational structure and people...
and a technology system, comprised of technology and tasks.

It is the relationship between these four variables of structure, people, technology and tasks that define the scope of technology driven change.

Within this context, there are distinct levels of change...
that is the n-order change.

COLLEEN:
Let's go through them...

First order change affects only tasks.

This is the kind of technology driven change we experienced in the early days of IT, where we were primarily automating repetitive tasks, without changing underlying processes.

An example of this would be moving from paper document archival to records management systems.

In this case, our impacts are confined to the technology systems of the organization.

Second order change crosses over into cultural boundaries by affecting not only tasks, but also the people performing them.

An example would be the introduction of word processing, which changed aspects of both management and administrative jobs.

Managers ended up doing more of their own document preparation, causing the displacement of many administrative workers.

And both managers and the remaining administrative staff were forced to learn vastly different skills in order to adapt from typewriters to application software.

Third order change affects every variable in both cultural and technological systems, so it’s exponentially more complex.

ERP is an excellent example of this.

It broke down organizational barriers between different internal departments, forcing them to work in an integrated manner.

It pushed management level decisions, such as what customer orders to fill in a backlog situation, down to line workers in the warehouse.

When organizational hierarchies, business models, communication channels, authority, or workflow patterns are altered, that is third order change.

Now, we at Gartner believe we’re in an environment of Fourth order change.

IT projects are affecting not just our employees, but our partners, our customers, our communities and so on.

So the cycle continues.

Soon, we may be even looking at fifth order change, where individuals' experience with consumer-focused technology will drive their expectations and demands for IT products and services in the workplace.

RAY:
So the implications and advice from this multi level change model are as follows:

* The more uncertain your business domain...
the more you need an architecture...
and the fewer constraints we will build into it.

Architecture is a best practice.

The higher the order of the change...
the harder it will be to successfully apply...
so the slower we must go.

Therefore, build mechanisms to shield the impact of change from higher orders, to minimize complexity.

And shift complexity away from people, organization, and external interactions to reduce both rigidness and consequences.

COLLEEN:
But there’s a further step.

If people put management of complexity in the context of general change management, there’s a basic decision framework that can help address the big issues in a more coherent way.

The basic question is,
“How do you assess your organization’s preparedness for its next IT change initiative or assess the health of an initiative currently underway?”

Well, you examine your maturity and performance in four basic categories:
Strategic Objectives,
Business Case,
Management Commitment,
and Capacity for change.

We have a decision framework with a series of questions that help structure the due diligence effort in each of these areas.

If you explicitly know the answer to these questions, and periodically review your performance in each category against your assumptions, you are in good shape.

If you realized the questions needed to be asked and are in the process of answering them, you’re doing appropriate due diligence, but should proceed with caution.

If the answer to any one of these questions is unknown, your project is at risk.

RAY:
So if we go back to my very first comment about the sources of complexity arising from my discussions with IT Ops people, I included change management.

So here the IT Ops perspective and the general business management perspective do coincide.

It’s very easy for us – certainly as IT folks –
to focus on the impact of technology in relation to complexity – whether as a force for good, or for evil.

But complexity is ultimately about people, therefore in dealing with complexity we always need to return to understanding people, their needs, capacity and capabilities.

There are important human characteristics that we must always keep in mind when we consider complexity and the ways to deal with it.

Just think of the basic issue of visualizing even relatively small numbers – just think how hard it is to think of a list of more than 7 items.

And these sorts of limitations extend very much to issues like understanding how a complex assembly of inter related parts works.

Think back to the opening video again as an example.

Difficulty is a human concept, not a measurement of technology.

And standardization as a response brings benefits mainly to people –
or at least some people.

The technology you standardize on may be more complex.

But the value is that there is less work to integrate or test...

fewer choices to consider...

less variance, so increased repeatability, and decresed learning effort.

The consequence is lower cost and greater effectiveness.

COLLEEN:
Every standardization implies change, but every person and organization has a set change absorption capacity...
exceed that capacity and the changes get de-railed.

These limits are not absolutes.

Improvements such as effective change management processes can increase capacity.

If the capacity of the organization or of individuals is below what is necessary to serve the needs of that organization, it must be increased.

RAY:
And we should note that conquering complexity isn’t...
in fact can’t be, seen as just a matter of reducing it, or managing it away.

We also have to confront the challenge of increasing our capacity – as individuals and businesses –
to accommodate complexity.

Here is at least a basic checklist of approaches and best practices.

Standardization – whether you think of this as a way of reducing complexity or increasing your capacity for complexity doesn’t matter...
it is still central.

Specifically, look to reduce:
The numbers of ways you do things
The number of products you have
The number of vendors you have

COLLEEN:
But be careful with that one.

Reducing the number of vendors can have clear advantages in terms of reducing complexity.

But it can have unattractive side effects also – like leading to higher cost and vendor lock in.

RAY:
So the trade offs we mentioned many times are still very much in play here.

Alongside standardization comes consideration of automation.

And automation may come in many forms...

Starting with what you might consider “traditional” automation – using IT systems to replace human tasks...

To the implementation of particular types of tools, such as middleware products or systems management tools which enable more complex tasks to be accomplished more easily – whether in terms of time or skills required.

Then there are things like expert systems – which can be considered as tools to augment human capabilities rather than replace human activity.

The net is that automation hides the complexity...
(although not for everyone – and too often, not for IT Ops).

And it creates an environment with fewer but more highly trained and expensive people.

COLLEEN:
Which, again, in your particular organization might be considered a good thing or a bad thing.

There are also some pretty basic best practices – but ones that are easy to overlook.

Don’t do too much at once – that creates implementation complexity and risk.

Buy what you need – not what you might need!

Buying the deluxe product with functions you will never use, costs money and adds complexity.

RAY:
Spoken like a true IT Ops person!

And basic though it might sound, it requires a great deal of discipline and rigorous analysis to follow through on such "simple" prescriptions.

But Colleen, I think it’s appropriate that you should get the last word.

COLLEEN:
What a gentleman!

So, let me encapsulate the management perspective in a few words...

Centralized control and management can definitely move you in the direction of reduced complexity.

It minimizes the points of control, and may likely minimize the costs of expensive expertise.

But, pretty obviously, there are contrary factors at play here as well.

Over centralization can get you to that point where you become a bottleneck for handling the complexity that exists in your environment.

Remember process.

If you don't have your processes under control, your technology is out of control.

Perhaps a better way to consider this is to think in terms of adjusting the organization to manage the complexity you have to deal with – the point being that the response to complexity is as likely to lie in organizational and human change as it is in the application of technology.

RAY:
We’re agreed.

And I think you’ll find that our many colleagues at this Symposium will give you as much drill down as you could possibly want...
whether it be in regards to the technology,
or the management practices, or business processes.

Thank you, and enjoy this Symposium.