In Enterprise Architecture, we spend a lot of time caring (strongly) about agility.  How do we reform IT (people, process, portfolio) so that the business can more rapidly adapt to strategic change?

From a process perspective, one way to approach the problem of agility is to make it more likely that a project, once chartered, will actually deliver business value, and not just rearrange the deck chairs.  That means, of course, that we need to ask the business to put a measurable value on the things that they do.  The result is scorecards and dashboards and BI reporting.  All excellent stuff.

But there is an underlying capability that is directly stated in the problem statement, but frequently lost in the wave of operational data: system agility.  In other words, what people, process, and portfolio measurements are needed as part of our IT scorecard, so that the systems themselves become more adaptable, configurable, and user-self-service-empowered?

And here is where we can inadvertently fail to measure important things.  Here is where scorecards need to be carefully composed to address the problem.  Measurables drive process improvement efforts like Six Sigma, so failing to measure a key measurable means two things: improvement in agility will be inadvertent, and decisions that reduce agility will not receive proper scrutiny.

Bottom Line: We must be able to measure agility. 

To measure it, we must define it. 

What is agility?

Is agility measured by the time it takes to change a business rule?  How come it takes longer to change some rules than others?  What can we do to find and reduce the root causes of delay in the ability to change a business rule?  Heck… how do you define a business rule?

Is agility measured by the time it takes to deliver a new business capability?  Why can I deliver some capabilities quickly, and others take years? 

Are some capabilities ‘bigger’ than others?  Does the relative size of a capability factor in to the time needed to change?  How do we measure the size of a capability? 

These are hard questions.  Have you answered them in your scorecard?

Some may say: you cannot define change because you cannot predict it.  Therefore, preparation for a specific change is pointless.  It creates bloated designs and expensive software. 

I agree.  But I am not trying to predict a specific change.  I’m simply observing that change, as a force in and of itself, is a normal part of business life.  It is not constant: some years we change more than others.  Change is driven by many things, both internal and external. 

Agility is our ability to respond to change gracefully and with few flaws.  If we, as IT, build processes and solutions that don’t take change into account, the cost of avoiding agility will vastly exceed the cost of embracing it.

I say that we can define agility, measure it, and improve it.  In fact, we must.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

2 thoughts on “Can we measure agility? Can we afford not to?”
  1. I think business agility can learn a lot from the concept of cohesion in OOP: the more components of your enterprise know about each other, the less open the system is to adaptability. I also think quantifying agility in terms of its historic performance is misleading – as unpredictable as change is, you may feel that your system is agile simply because it has kept up with change in the business over the past several years, only to realize, in hindsight 10 years later, that those were really stable years and not truly indicative of the nature of the business. IMO agility must be measured by the system’s ability to isolate and contain change, to minimize its impact on seemingly unrelated aspects of the system. The metrics we use to analyze the cohesion, coupling and complexity of objects in software, metrics central to measuring agility, could probably be applied to enterprise architecture to come up with something similarly meaningful.

Leave a Reply

Your email address will not be published. Required fields are marked *

5 − one =

This site uses Akismet to reduce spam. Learn how your comment data is processed.