According to a Light Reading article yesterday, Metaswitch’s CEO told an audience at their service provider event that operators needed to start thinking of themselves as software companies. The comment provoked some backlash, on the grounds that it’s been said before. True, but it’s also true to at least to a degree that the comment is valid. Perhaps it’s this “to a degree” thing that’s making it hard for the operators to follow this advice, so let’s look at what “software” means to operators to see inside the “software company” point.
First, let me say that there is zero chance that software will make up even a third of total operator capital spending. While software-based virtualization and feature hosting will impact more than half of all capital projects by the end of next year, the impact will be one of supporting symbiosis and not one of replacement. The biggest impact of software, not surprisingly, will come in higher layers of service. Today, these are subsystems like CDNs and IMS, but in the future they’ll include cloud services. The reason software is important isn’t that it’s universal, it’s because higher-level services are where revenue and profit growth can occur. Transport/connectivity, as a business, isn’t going to get any better.
The second point here is that “thinking of themselves as software companies” is dangerous to take literally. It’s actually rather hard for most of the big operators to be software companies in the sense that we’d normally use the term. In both the US and EU, operators cannot collude even to decide on standards. The NFV activity launched a year and a half ago was hosted in ETSI because it had to be, or operators would have faced regulatory challenges for violation of anti-trust laws. Think of what they’d face were they to cooperate to build software! And building their own software for something of the scale of SDN, NFV, and the cloud is clearly not economical. The fact is that what’s needed is for the operators’ vendors to think of their customers as software consumers rather than as device consumers.
But OK, semantics aside, what kind of thinking are we talking about? Well, a software-centric vision of future infrastructure thinks of all service features not explicitly transport/connection as being hosted software objects and not devices. That doesn’t mean that these hosted software objects don’t need hardware, or that hardware isn’t still the largest component of the budget. It means the flexibility, customer impact, feature content, of a service is created from hosted stuff.
It doesn’t necessarily mean “the cloud” either. The optimum software strategy is not one where traditional devices/appliances are excluded. It’s one where the platform is abstracted in a way similar to that used in the cloud. Not identical, because for quite some time there will be more “hosted stuff” hosted on devices and dedicated platforms than on any virtualized infrastructure. A service is a collection of functions first, and the instantiation of those functions individually in/on optimal platforms. The criteria for optimization will change radically as services deploy because, for first-cost reasons and to limit exposure and risk, operators will initially have to deal with small software-defined commitments that can’t justify mega-data-center deployments. We have to evolve into those deployments based on the success of the business case.
Functional assembly of components to build services isn’t a new thing. We build this kind of application every day in the enterprise space. What makes operators different is both the scale of their operation (complexity increases in proportion to the workflow segments in a task) and the need to be highly efficient to insure optimum margins and prices at the same time. I’ve been arguing for explicit tools to support functional segmentation and composition because of that need for optimization. There’s little value in establishing a highly agile software-driven framework for services if you can’t make it valuable enough to sell at a price users will pay and efficient enough to be profitable to you.
It also makes no sense to fetter your agile future by tying it to current practices, and that’s where I think Metaswitch’s CEO makes his strongest point. One operator already told me that in the future they think they’ll have ten times the number of “service architects” they have today, focused on assembling all this good functional stuff and creating the bridges that build resource commitments for each function when it’s ordered. They’ll have ten times less operations hands on the ball, though, and since there are a heck of a lot more operations types than architects, the net here will be a significant reduction in operations handling, if “handling” is taken to literally mean human touch.
One impact of this is to completely redefine what “service trial” means. Operators have traditionally looked at service introduction as a massive process of progressive trials, needed because it was going to mean a huge investment in technology. Once you have a software hosting and service management framework in place, you don’t even think about that sort of trial. You take something you’ve tested for stability and float it in that great pool of evolving demand—because you don’t care much if the boat sinks and you have to start over. You’ve spent some electrons and a few software bucks, but you can afford to let the market speak for itself. That’s what “service agility” means.
It also redefines “self-service”. We talk today about an NFV revolution that lets an operator move a customer from a physical branch access device with static features into a virtual branch access device. “With static features” could well have been added here because despite the flexibility that NFV promises, most operators are still stuck in order-form mode. What you can buy isn’t limited by what your operator can do, it’s limited by what your operator can sell. We don’t sell virtual, agile, stuff today and we’ll never sell it if we presume that customer service reps are on the phone taking feature orders. They have to let the customer turn things on and off at will. We are already heading there; some operators like AT&T have announced this sort of capability.
“Thinking of themselves as a software company” means thinking of themselves as a company whose future will depend on exploiting the strengths of software and not the limitations of infrastructure. That’s the transformation.