With cloud a hot topic here at Think Gig, and the merger still bringing up questions, we wanted to share what our EVP, Chris Ancell, had to say about our future plans for cloud. The talented Jessica Scarpati of SearchTelecom recently sat down with Chris to get his perspective about the cloud hype, on-demand services and the evolution of customer needs. Here’s a section from the interview we thought was particularly insightful:
SearchTelecom.com: It seems you can’t be selling IT services these days without a cloud strategy. Qwest was selling cloud services prior to the merger, but what about CenturyLink? What does the completion of the CenturyLink-Qwest merger mean for the combined company’s cloud strategy going forward?
Ancell: CenturyLink was absolutely doing work on reviewing customer requirements and awareness of what was going on in the market. They didn’t have any products in the market as of the time that we closed the merger, but it’s absolutely an area of focus and there’s a recognition that real opportunity exists there.
I’m not a big fan of ‘the cloud’ term only because it seems overused. One of the things we have been very focused on—unlike some others, and we don’t have to name any names—is that we’re not going to go out and rebrand our entire portfolio as cloud all of a sudden. We’re focused on introducing services that meet customer demands.
You will see information from us … as we put those things into the market, but [the cloud] is an area of focus. What we refer to it more as is “on-demand services.” If you want to go back and rebrand everything, I guess technically you could call Centrex a cloud service because it’s delivered over the network. But [our strategy for] on-demand services encompasses everything from the network itself to compute cycles, storage, applications—all provided on an on-demand basis. Then you get into specifics under each [service]. You have backup and recovery in that storage space; you have just raw storage in that storage space. You have all different kinds of permutations in computing cycles in how you turn those up and turn those down.
In the end, it’s about providing all of those infrastructure components in an on-demand basis. We’re very focused on that and particularly in understanding what customers are really looking for because despite all the hype, there still is a lot of evolution that’s going on in [terms of] what customers are really looking for.
You can read the whole interview at SearchTelecom’s site here.
What do you think – is “cloud” overused? Is the evolution to “on-demand” services more meaningful to businesses?
Tags: cloud




I tend to agree with your assessment — the names used matter less than the type of services being offered, and more importantly what they can do to solve customer problems or meet business needs. Application services, network outsourcing or out-tasking and managed services have all contributed to the path that led us all to this point.
I kind of like the “on-demand” approach rather than “the cloud”. On-demand is more end user focused (I assume it is service at the demand of the customer….not the utility). It is also more encompasing, addressing the network/transport that gets you to “the cloud” to begin with. I imagine business greatly prefering a carrier who also offered “on-demand” networking services and bandwidth than just a carrier who offered you cloud services. As a matter of fact, I think you could sell “on-demand” services today and make a killing off the carriers who only offer the legacy, “you place an order with me and I’ll tell you if and when you can have it” approach. I am willing to bet the “on-demand” near term (like in today or yesterday) market opportunity is many times that for “the cloud” services. First to market with the “on-demand” approach to network serivce offerings is going to kill their competition in the high end business market where dynamic business needs change from week to week and they can no longer wait for the old phone company utility to get around to provisioning their service on their old, snail pace utility time frame.