Setting speed limits for IT transformation

There’s been plenty of talk about business disruption and IT-driven transformation. The speed at which technologies are moving through the Gartner hype cycle is also newsworthy. Innovation has never been so competitive and for some companies never so critical to success. One result has been a significantly increased rate of IT change – supporting the so-called “speed of business.”

A recent example is the “distributed ledger” technology called Blockchain (which is only 8 years old). Blockchain is the basis for cryptocurrencies such as Bitcoin and is expanding into other areas where trust is needed (such as smart contracts). Blockchain is even being heralded as Internet 2.0 – it promises to change life as we know it today!

Technologies of all types are being adopted and deployed at a faster and faster pace.

A recent Forbes article on DevOps, for example, states that “by fostering an environment of teamwork and collaboration, companies can significantly increase their development velocity—the speed at which they update their software and fix performance issues that arise. Instead of deploying software updates every few weeks or months like was the norm only several years ago, tech firms who are evolving to a DevOps methodology are able to deploy new functionality at lightning speed; some companies are deploying hundreds of updates per day.”

But, do we always need “lightning speeds” and hundreds of updates per day, and, if so, why? Perhaps more importantly, is there a downside to such hyperactive IT transformation?

Defining change

A change can be thought of as anything that alters the state of a process, system or ecosystem.

Changes can be planned or unplanned, user- or provider-sponsored, scheduled or unscheduled, permanent or temporary. A change can be physical or virtual, technical or operational, discretionary or mandated. IT change management is a discipline in the IT Service Management best practices.

Some change is generally unavoidable – it includes everything from hardware failures, security breaches and capacity scaling to new applications and business disruption.

Motivations for change

With “traditional” on-premises IT, the only things done rapidly were fixing bugs and plugging security holes. Large applications could take years to develop; hardware replacements would follow a 3 to 5-year cycle.

Today, being able to react both quickly and flexibly when the situation warrants it has become critical to success. It seems that a business can be disrupted almost overnight.

Many of today’s leading companies are less than ten years old; Google, for example, was only incorporated in 1998. Unicorns simply cannot measure the rate of change in terms of years!

Changes in technology often provide the incentive for innovative applications. The reasons for change may include the need to:

  • Reduce the cost of doing business, creating products or delivering services;
  • Deliver capabilities “as a service” or creating better user experiences;
  • Increase access to customers via the Internet; and
  • Monetize the data collected via IoT sensors or derived from transactions and conversations.

Corporations are looking for the next big thing that is useful, enjoyable or otherwise desirable to large numbers of potential customers. These customers expect change to be rapid, safe and purposeful.

The real question is whether it is the technology itself, the information derived from its use, or the speed of deployment that provides the greatest advantage.

Types of change

Not all changes are the same. For example, one classification could be:

  • Fixes that are needed to recover from faults or failures; fixes should be relatively small changes and should be transparent to users; they should be implemented quickly to avoid service degradation;
  • Updates that change the functions or features of a product or service; updates may be a response to a competitor’s move; deployment speed may not be the major success factor;
  • Modernization is an application replacement or major infrastructure update; modernization programs are not meant to change the business but to sustain it and possibly to improve it; speed is not normally the primary concern especially if life cycle management practices are being used;
  • Transformations may include new business processes, new user experiences and new systems; speed may be important for competitive reasons but may also be limited by organizational maturity, cultural resistance, training requirements and customer acceptance.

Business transformations are arguably the most important type of change and have the greatest impact on the future of the company. Uber, AirBnb and Bitcoin are popular examples of disruptive changes at the industry level. If Pokémon GO (augmented reality) and Bitcoin (fintech services) are any indication, the next waves of change are just around the corner.

The pace of change

To ask the question again – is change at “lightning speed” desirable and what are the downsides of hyperactive IT development?

In my opinion, all changes need to be well-orchestrated and well-managed to avoid “change for the sake of change.” Not everything, except perhaps in a start-up entrepreneurial company, needs to be done as quickly as humanly possible.

Modern managers must recognize that the pace of IT is increasing but not let it lead to shortcuts and a lack of planning (with enterprise architecture, for example). Information assets should also be front and centre in thinking about change – we will soon have more information available to be collected, processed and stored.

Some of the downsides of speed may include:

  • Inability to develop stable plans and make reasonable technology decisions;
  • Additional complexity and increasing development delays;
  • Lack of good documentation;
  • Trade-offs of quality versus speed; and
  • Additional costs if assets are replaced before their end of life.

This is what I’ve been thinking. Are you concerned about how fast things are changing? Or are you happy with the challenges of keeping up-to-date?

Would you recommend this article?


Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.

Jim Love, Chief Content Officer, IT World Canada
Don Sheppard
Don Sheppard
I'm a IT management consultant. I began my career in railways and banks after which I took up the consulting challenge! I try to keep in touch with a lot of different I&IT topics but I'm usually working in areas that involve service management and procurement. I'm into developing ISO standards, current in the area of cloud computing (ISO JTC1/SC38). I'm also starting to get more interested in networking history, so I guess I'm starting to look backwards as well as forwards! My homepage is but I am found more here.

Featured Download

IT World Canada in your inbox

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Latest Blogs

Senior Contributor Spotlight