Blog post

A few things about running, growing, and transforming in the cloud

By Richard Hunter | July 18, 2012 | 2 Comments


I hear a lot lately about cloud as a means to “transformation,” and when I hear that word my personal value-meter kicks in, especially since so many people use the word “transformation” in ways that conflict with its definition in IT portfolio management (from whence the run-grow-transform model emerged in the early 2000s).  In this post, I’m going to lay out what “run”, “grow”, and “transform” mean in this context, and how they relate to value.   

By definition, to “transform” means to enter new markets with new value propositions for new customer segments.  To “grow” means to enhance business performance in established markets serving established customer segments with established value propositions; to “run” means to carry out essential enterprise activities that do not connect directly to a particular customer segment (or, to put it another way, to a particular revenue stream).

When Apple entered the iTunes business, or IBM went full-tilt into the services business, those were transformations.  When Apple brings out the iPhone 5, or IBM brings out a new mainframe, that’s growth, because the market, the customer segment(s), and the value proposition are well-established.  When Apple or IBM add capacity to data centers that support a wide range of enterprise activities, that’s running the business.

Lots of enterprise and vendors use the word “transformation” to mean a big change, but extent of change isn’t what defines a transformation.  It’s not a “transformation” when a supply chain’s costs are dramatically reduced.  That’s “growth” in the run-grow-transform model unless a new market is being addressed with a new value proposition.  So for example, if Wal-Mart goes into the logistics business, taking advantage of its supply chain capabilities to offer supply chain services to other businesses, that’s transformation (new market, new value prop, new customer segment); if Wal-Mart restructures its supply chain to deliver lower cost, even drastically lower cost, that’s growth (lower cost of doing business/higher margins/more capability in established markets).  The value of both growth and transformation investment is ultimately expressed in terms of ROI, which is feasible because we can connect the investment in change to a paying customer (and so have actual returns for the investment).

 The value of run-the-business stuff is expressed in terms of price-for-performance, not ROI, in particular because there is no revenue stream (returns) to which run-the-business services can be connected.  In that sense, email in the cloud, which some enterprises think of as “transformational,” is anything but—it’s simply about achieving competitive price-for-performance for an essential enterprise service that can’t be tied to a particular revenue stream, which is a classic run-the-business value proposition. 

As my colleague Matt Cain has pointed out in his research, the price-for-performance ratio for cloud-based email may not really be all that superior, depending on how “performance” is defined.  Low prices for cloud services currently may reflect low levels of provider investment in security/availability/reliability/upgradeability/etc.   Enterprises pay for that lower performance over time, by supplying mechanisms to fill the gaps in the performance that their own IT team used to provide.  Internal IT organizations have long ago priced the costs of high performance into their services, and cloud providers will sooner or later, meaning that at some point cloud pricing for run-the-business services will approach internal provider unit costs.

Until that happens, remember to focus first on performance in any negotiation on services, because performance drives price–and if performance requirements can’t be met, price is completely irrelevant.

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Leave a Comment


  • They say, “the more things change, the more they stay the same. nowhere is this more true than in IT business buzzwords. Nobody uses the term, Continuous Quality Improvement (CQI or TQI) anymore, but they most certainly use all of the methods they embody. They just have acquired new names and acronyms.

    Here’s the business model: send some high-level execs to Japan. Find out what they are doing in Japanese and then translate it into English.

    Over there, it was called KAIZEN. Over here, they renamed it LEAN and SIX SIGMA, and then decided to build a certification industry around it.

    Clever, but not very original. If Apple started using Kaizen and Samsung started using LEan Six Sigma, Apple would be suing Samsung for copyright infringement.

    I submit that there is nothing really new under the sun and the “run-grow-transform” is the terminology that gives me indigestion. Sorry, but it is shoehorning operations into terms that don’t fit, IMHO.

    What “system” was used to invent the SUV when there was never any need for one and lots of caveats for not making one? Moreover, making the product bigger did not make it better, but far worse.

    It was sheer, brute-force marketing to A-type personalities. The creation of a new need that did not exist before, but using existing parts: a truck bed with a car-like cabin bolted to the top of it.

    Remember “cross-functional teams?” That was the big “to-do” in business until businesses could not find a way to first find people with high-enough levels of functioning in their separate areas to impart some of them to the other areas.

    AGILE is a new idea to return to the software development process of the 1970’s. most of its components came out in the mid ’90’s.

    Yet, over on the educational side of IT, the Instruction Design and Instructional Systems Design contingents, of which I am a member, helped to develop ADDIE in 1978 – the gold standard of ID. It is still being used 35 years later and is still called ADDIE.

    Of course they have found ways of streamlining the process as the technology has improved, which, of course they had to give it a new name, Rapid e-Learning, but it is the same, exact model.

    My motto is, “If it ain’t broke, don’t rename it.”

    Unless, of course, you want to make a name for yourself. 😉

  • Your comments invoke TQI (or TQM–total quality management–as my clients call it), Lean, Six Sigma, Agile, Kaizen, SUVs, and Japanese manufacturing, none of which are referenced in my piece, and contrast these disapprovingly with your 1978 contribution to the ADDIE model. Congratulations on that durable achievement, which I gather should be regarded as the last worthy accomplishment in the management canon since 1978, especially since, as you put it, there’s nothing new under the sun.

    Regarding the rest of your comments, of the 31 lines in your response, exactly two reference run-grow-transform, and those merely note that in your opinion the model doesn’t apply to operations. As noted in my piece, the model is about investment portfolios, not operations per se, so it’s difficult to understand what you’re actually objecting to–perhaps it’s management fads? I don’t like them either. Thanks for reading.