Month: April 2014

I’ve talked about the fortunes of the service providers and the network equipment vendors in past blogs, and so it’s logical now to talk about the IT giants who are players in the networking space.  None of these firms are likely to be targets of M&A in at least the traditional sense, and Dell has already gone private.  Others in the space aren’t likely to follow suit, so the question is really not one of survival as much as of prospering, and perhaps acquiring some other players.  Even network guys?  We’ll see.

Let’s start with the obvious giant, IBM.  There is no technology company I respect more, because there’s no other technology company that has shown it can weather major shifts in the market and technology.  I learned programming on an IBM computer, worked with the first true IBM mainframe.  They launched the mainframe and the PC in a very real sense.  Their Systems Network Architecture (SNA) was the foundation of enterprise networking.  They have patents and R&D in every area of IT.  You have to take these guys seriously.

The problem IBM has is that old guys like me don’t make up the market.  There was a time when IBM as a brand was solid gold, but IBM doesn’t have the brand they used to because their stuff is hardly populist.  Selling off the PC (laptop, desktop) business to Lenovo made financial sense but not brand sense.  But the big problem is marketing.  If you sell to the Fortune 500 you don’t normally need it, but if you want to shift your focus and image you certainly do.  I

BM has to become a cloud company, and in the networking space it has to become an SDN and NFV company.  I was at a European networking show where IBM had a booth, consisting of a sad little flag, two bored people, and nothing else.  It was worse than not being there, and yet OpenDaylight had a nice booth.  And in NFV, I don’t see IBM having a real story at all even though they have virtually all the assets.  I could build NFV from the ground up more easily using IBM products than from the products of any other vendor, but you’d never know it unless you dug in more than anyone is likely to.

Might they do some M&A to fix their problem?  No, not because the M&A part isn’t likely but because you can’t fix a problem with the choir director by hiring more singers.  IBM needs to orchestrate in more ways than one.

HP is in a much better place in the singing sense.  In the cloud space, HP is a player with servers and software and even a public cloud offering.  They also have an SDN story and one of the better (maybe even the best) NFV story.  The problem HP has is not that they don’t have a story but that they may still be a tad short on substance.  In the cloud, SDN, and NFV space HP is still following a roadmap instead of sitting happily at the destination.

NFV is IMHO the critical test for HP.  NFV is the near-term application for a level of orchestration and management that will eventually touch everything in the networking and IT space.  It used to be that HP OpenView was almost the household word of network management, and HP needs to have HP Open-something the household word of orchestration down the line.  The only way to insure that happens is for them to be a player in NFV as soon as possible.  They are working on it, working better than any other IT player is, but they might still do some canny M&A to get there faster.  It’s hard to say what would be best for them to pick up because I can’t read their technology trend line with management and orchestration yet.  Watch these guys though, because if any IT player moves in this space HP is one who might.

My next name is Intel and that may surprise you.  Intel is known as a chip player, but they’ve been quietly looking more and more into software.  The Wind River Carrier Grade Communications Server is impressive; arguably the best open-source platform for carrier cloud, SDN, and NFV.  If you were to add orchestration and management to it, the combination might be so powerful it would establish Intel as the kingpin in that space, giving them a completely killer NFV approach.

The challenge for Intel in management and orchestration is that they don’t have anything going there in an open-source sense.  They’ve had a relationship with Tail-f but I’m not convinced that’s going to provide them what they need, and the relationship might actually discourage both Intel and other partners from cohabiting to create a better solution.  If Intel does any relevant M&A I think that the management and orchestration space is where it would make sense.

Dell is another potential network-market server/IT vendor.  Like HP, Dell has a pretty decent portfolio of stuff for the networking space, and like HP it’s largely based on open source (Dell/Red Hat for example).  The challenge is that open source is inherently non-differentiating, and Dell needs to have a differentiated strategy if they want to compete in the space with the likes of HP or Cisco (who we covered among the network vendors).

HP has management distractions, and so obviously does Dell, who needs to figure out how to run as a private company so they can do a re-IPO later on and make everyone who participated in the privatization rich.  That means doing a lot better than expected, which means doing more than push servers and PCs the same way as always.  The carrier market could be huge for Dell, and it could be that Dell has to pull partner Red Hat’s carrier train against Intel/Wind River too.  A big order, one that Dell may have to do a lot of M&A to fill, but they have no stock currency to buy with.  We’ll see what happens.

So there we have it.  The IT giants are safe in their core markets for now.  They have some M&A incentive, but not to buy network equipment players.  This is all about software now.  Open source software in areas where you can’t differentiate yourself easily, to poison the well for others who might try.  Special sauce where something special is possible.  That’s what to look for.

When I did my review of the Street’s view of consolidation in the service provider space, some of you wondered about the network equipment vendors.  After all, it’s hard to imagine how a buyer industry so pressed for profits it has to collapse into itself via consolidation could avoid putting some price pressure on its vendors.  If that happens (which clearly it is already) then the vendors come under consolidation pressure as well, as a target or as someone looking to acquire to bulk up or build up.  But some more than others.

Who is “safe?”  Obviously Huawei doesn’t have anything to worry about.  It’s not going to be bought and it’s unlikely it would go out and grab up one of the other network names as long as there are issues in Congress with selling to the big US operators.  They could do M&A in the enterprise space or in software, and I think that’s likely.  The equipment guys really don’t have much that Huawei needs; they need ammunition in the NMS, OSS/BSS, and orchestration spaces.  This is where I think Huawei should focus their own M&A telescopes.

Cisco is similarly immune from being acquired, but they do have a risk.  For a long time activist investors have considered jumping into Cisco (as they have with rival Juniper), but this time to force a breakup.  Cisco has a bunch of fast-growing but small product areas and a behemoth legacy switch/routing business that has nowhere to go, profit-wise, but down.  They could do some more M&A, but the fact is that Cisco is torn right now between “buying revenue” and “buying R&D” (an issue for a lot of vendors).  They may wait a bit to see which would do them more good.  They really have a good asset set; I think their challenge is just one of priorities.

Another player I think is unlikely to be bought is Ericsson.  The company has a good thing going right now, reducing its exposure to commoditizing hardware and focusing more on professional services.  The open-source pressure in the network space is likely to help Ericsson, since most operators see themselves either buying integrated packages from open source vendors like Red Hat or Wind River, or integrating with a partner.  I think Ericsson may stand back on acquiring something in the near term, though.  Their primary assets are in the OSS/BSS space and other than picking up some software players to add technology value in orchestration or other network-related areas, I think they’ll ride the fence.

The “well…maybe” players start (alphabetically) with Alcatel-Lucent.  I think Alcatel-Lucent has a strong product portfolio, but they have a pretty high level of expense and they are also a bit too monolithic and glacial to contend with a fast-moving market.  I don’t think that they are at imminent risk, but they would be vulnerable to a major shift in technology like SDN or NFV if they couldn’t harness it to their benefit.  Their positioning is particularly vapid, and that’s been an ongoing problem for them.  It’s simply too early to say whether they can track trends or look exciting.  If they’re looking for M&A I’d suggest that management/orchestration might be the place to focus.  That would give them more opportunity per invested dollar I think.

Next in the “maybe” group is NSN.  They have a good but narrow product portfolio, something that can create some very significant risks.  Mobile infrastructure has been a kind of “stay-the-course-fools-paradise” because margins there have circled the drain closer to the rim than the rest of networking.  That doesn’t end the downward slurp, though.  Not only that, Huawei clearly sees mobile as its own big priority and there’s nobody you want less in a competitive situation than them.  NSN’s question is whether it takes a risk by holding to current product boundaries or takes a risk in expanding them.  As long as they’re on the fence there, they won’t acquire anything big, I think.  If they make a big move, watch to see if it steps outside the mobile box.  If it doesn’t then NSN may be looking to be adopted instead of having a single parent.

In the “could-be-acquired-or-worse” category we’ll again go in alphabetical order and start with Brocade.  While the company had a significant blip in strategic traction last year because of the Vyatta deal and some semi-good-if-perhaps-accidental NFV positioning, they lost all of it by the fall survey because they just couldn’t seem to follow up with a cohesive story.  The problem Brocade has is that they are really a data-center player without much of a cloud or NFV strategy and those are what will drive data center networking.  Their spring 2013 success showed that being stridently different will get you attention, so they need to do that again, but also follow up by doing something stridently useful.

Next on the list is obvious; Juniper.  The company just announced staff cuts as their new CEO tries to make friends with activist investors.  The problem is that, as a US company, you can’t sustain yourself in a commoditizing market by trying to fight Huawei on price and if you cut costs you can’t ramp up R&D or M&A like you need to.  The problem Juniper has is its price/sales ratio and P/E.  The former is about 2.8 and the latter about 31 as of yesterday; Brocade’s is 2.14 and about 16.  That would suggest to most that Juniper’s stock is pricy, discouraging M&A.  And if you buy back stock and cut costs, your near-term ratios are probably going to move even higher.  The worst problem is that while the company has many strong things it could do, it’s too preoccupied with cost management to do them.

For anyone who’s a potential acquisition target, the big question is who would take the buyer role.  I don’t think there would be much value in any of the network vendors buying another network vendor.  The computer vendors are the obvious play, and here we have Dell, HP, IBM, Microsoft, and Oracle.  But I don’t think any of these companies would move to acquire one of the network players.  HP and Dell already have some networking gear.  IBM is selling off x86 server business because the margins stink, and networking would truly suck for them.  OEM is better.  Oracle is I think smart enough to see that they don’t want to be in the commodity hardware business.  So…I think all of the possible acquisition targets are likely stuck in 2014, which means they’d better be buffing themselves up for either a rosier life as an independent or a more attractive tidbit for a bigger player to acquire.

Cisco has never been shy about taking a different (and often frankly opportunistic) path with respect to “revolutions” like the cloud, SDN, and NFV.  I’d be the last guy to say that Cisco was all for an open-happy-band-of-brothers approach to competition but I’d also be last to expect that they would be.  We’re all in business to make money, and if Cisco takes a position in a key market like SDN that seems to favor…well…doing nothing much different, you have to assume they have good reason to believe that their approach will resonate with buyers.  Even if their story is confusing.  So it is with OpFlex.

Classical OpenFlow SDN uses a central controller to manage the routes in a network.  This controller uses OpenFlow to communicate forwarding rules to the network devices, and this process can be supported either in “reactive” or “proactive” mode.  In the reactive model, a switch tries to find a rule for something and if it fails, kicks the “something” back to the controller to get a rule.  In the proactive mode the controller is expected to pre-load the devices with complete and consistent forwarding tables.

So how aout OpFlex?  OpFlex isn’t “an alternative” to OpenFlow as some have suggested; it has nothing to do with the forwarding tables in a direct sense.  It’s my view that you could still use OpenFlow inside a network that was controlled by OpFlex at a high level.  You could also use traditional devices.  Like other Cisco initiatives, OpFlex appears to be aiming higher, working to translate application needs into policies and then communicate those policies to the places in the network where traffic control is applied.

Policies, and policy exchanges, are what OpFlex is about.  It’s convenient to visualize OpFlex as creating a kind of “policy network” that exists in parallel with the real network.  This network has three tiers—a Policy Controller/Repository, Policy Elements, and Managed Objects, which are “objects” more in the abstract or software sense.  The goal of OpFlex is to create a tree of policy distribution that ends with Policy Elements that can “resolve” a policy.  It’s the resolution of policies that control the devices.  Policy Elements are linked to one or more MOs, and these MOs are representations of (abstractions of) real/virtual network elements.

Where this connects with user reality is in the notion of “Endpoints”.  Endpoints are devices, virtual or real, and when they “connect” they are registered and assigned a policy.  It’s that policy and the handling it represents that is distributed using OpFlex.  It appears that you can also define “roles” or application structures within an Endpoint, giving them separate policies.  All that adds up to a way of doing application-based handling in an open and distributed way, presuming that everyone implements OpFlex consistently.

If I’m reading the draft RFC right (Cisco, feel free to send me a correction if I’m not) then this whole process has the effect of creating a kind of policy-domain set that overlays on a normal IP or Ethernet network.  This means that the topology management and basic device forwarding stays as it is except to the extent that a Managed Object behavior is applied to the device and that MO responds to a policy.  If there were no policies, the network would presumably function as it is today.  If central policy control is lost it would appear that a default policy could be applied within the policy tree, even down to the device level.

The OpFlex concept is consistent with Cisco’s larger vision of SDN, which has been that it’s about application or software control, starting with APIs and going down to whatever you put in the data path.  That doesn’t have to be anything much different, though it can be.  Cisco seems to imply that there will be an OpFlex link to OpenDaylight; certainly they’re not trashing OpenDaylight or Insieme.  I see OpFlex as being an intermediary layer in the Cisco approach, a means of allowing an API-driven SDN vision that’s always been kind of about policy into an “open” approach.  Is it open?  Yes; Cisco is going to do a reference open-source policy controller and the protocol is being submitted as an IETF standard.

You can now see why I say this isn’t really much related to OpenFlow, though Cisco positions it as being an example of a “declarative” versus OpenFlow’s “imperative” model.  Actually Cisco is describing the “reactive” OpenFlow model I described earlier when it says “imperative”, and I’m not convinced that model is ever a good idea outside the lab.  Most SDN users would want precomputed routes and failure modes.  A better comparison would be to say that OpFlex as an architecture would allow policy-based application control with current devices.  In that regard, it’s really not that different from an OpenDaylight controller with a legacy ACI plugin on the bottom.

Part of Cisco’s approach appears to be applicable to real current problems.  MOs can have statistics and state indicators that can be observed, and it appears to me that an MO hierarchy might be able to support “derived state” accumulated up an MO chain from the individual devices (real or virtual).  It also appears that you could view OpFlex as a kind of SDN federation approach since it seems that a Policy Element could “represent” a complete SDN/OpenFlow network and thus OpFlex and the policy tree could mediate traffic handling across multiple SDN domains.  But the big problem here is my need to continually use qualifiers like “cloud” or “appears”.  By presenting such an obvious OpenFlow counterpunch as the centerpiece of OpFlex PR material, Cisco has hidden any real mission statement and we’re left trying to dredge it out.

One thing I don’t like about this, at least as I’m interpreting it, is that what we’re doing here is establishing application networking policies that are distributed down to the lower network layers.  It appears to me that you could establish policy hierarchies where lower-level networking recognized three or four classes of service and then map application policies to transport policies, but I’m not sure why you’d want to define higher-level policies that wouldn’t be implemented granularly.  I favor the notion of an SDN network that’s layered, with the top level a pure overlay structure (like Nicira) and the bottom level a pure-policy transport-grade-of-service structure.  This I think would be a simpler model because connectivity and grade of service consumption are mapped only at one place—the boundary between the layers.

There’s nothing in the announcement that makes it clear how things like orchestration and management would work in a policy-driven world, though as I indicated you could infer some hooks in OpFlex if you look closely.  I think this is the biggest technical downside for Cisco and the biggest business downside too.  You can’t create network value with protocols, and at the end of the day that’s what OpFlex is.  Since I can easily map a concept like this into the broad “structured intelligence and derived operations” model I’ve been talking about, I have to believe Cisco could have done that too.

I see a bit of a rush-job positioning here, too.  “OpFlex” is a term that’s widely used in other industries so if you search on it you get a bunch of extraneous hits.  The OpenFlow jabs seem furiously defensive, and the state of the material is deficient even for a company like Cisco who values inspiration way more than buyer education.  I think Cisco is seeing the handwriting on the wall (and it’s Chinese), and they’re leaping to the attack here.  Maybe they should have waited a bit.

One of the inevitable results of commoditization is consolidation, and Wall Street (Oppenheimer in particular) has started predicting who among the “providers” in telecom might be acquired by somebody else.  It’s worth looking at their list of eaters and “eatees” to see what we can learn about industry direction.

Top of everyone’s list is T-Mobile, and most realize the challenges that the company faces—mostly competitive but also challenges in marketing and churn.  The problem for mobile operators is less that of roaming (as some have suggested) and the need to build giant service areas as it is about advertising scope.  Mobile services are promoted and sustained by brand recognition and that’s achieved largely through TV ads.  If you buy ad space on a primo show and half or more of the audience can’t get service from you because you don’t have towers in their area, you’re wasting your time.

That makes the cost of running an aspiring mobile telco about the same as that of running an established one, and obviously the revenue is a lot less if you’re trying to fight your way up.  But I’m not sure that T-Mobile is an easy grab for somebody for that same reason—return on investment for the buying company is going to be harder to achieve.  T-Mobile can’t likely be acquired by Verizon or AT&T, so if there’s going to be any action, look for it to come from a cable company who wants to leverage mobile services for quad-play.  I’m skeptical even there.

Level 3 is another company that gets an acquisition target nod, and here I think the thesis is better though still complicated.  From a profit and ROI perspective the company isn’t exactly sterling, and I don’t see that changing at this point.  What Level 3 could offer is national backbone capacity and peering with the major access ISPs.  That could be valuable for either 1) mobile backhaul if somebody like T-Mobile really wanted to push their cells into everyone’s territory or 2) if the overturning of neutrality sticks or if a new rule permits inter-provider settlement, provider-pays content delivery, or QoS peering.  I don’t think that Verizon or AT&T need Level 3, though, so again we’re left looking at either offshore players or a cable MSO to be the acquirer.  If the FCC and Congress cooperate on neutrality and settlement, this could happen.

DirecTV is second on Oppenheimer’s list and third overall among the broader Street players.  I think there’s value in video delivery for sure—it’s actually about the only thing that can be truly profitable in terms of consumer network services.  The problem with M&A here is less value than “valuable to whom?”  A company with a video franchise already has little reason to pick up DirecTV because they already have content services so that rules out the cable companies and AT&T and Verizon.  The only thing that DirecTV could add is fringe coverage, where customer density and opportunity were too thin in a geography to make any wireline delivery of content pay.  I think that’s a marginal game, so I think DirecTV is on the block only for an offshore player.

Probably the most “interesting” speculation on provider M&A is somebody buying Rackspace.  The thesis here ranges from the sublimely stupid (“Telcos have to get into the cloud”) to the semi-sensible (“Operators could wring a lot better margins out of Rackspace’s infrastructure, and quickly become players in the cloud”).  This is actually a tough call, because it is true that as former public utilities the telcos could surely deliver better results and also tolerate low ROIs better.  However, it’s not clear how much a telco would have to pay for Rackspace, and unless the telco has specific technical options to reduce costs and specific service objectives beyond IaaS, it’s hard for me to see how this works. Still, Rackspace was the impetus behind OpenStack, which is the favored telco cloud.  Cable companies might be a better bet since they typically have less invested in the cloud than the telcos do (both AT&T and Verizon already have cloud services).  They’d also need to have some specific technical strategy to raise service agility and drive down costs, though.

I think this last point is the most interesting, because in truth the M&A prospects for all the companies I’ve named would be better if we assumed that the prospective buyer had a good idea of how to raise revenue and lower cost that goes beyond consolidative economies, which are always potential drivers for M&A.  Here I’d point to AT&T and their Domain 2.0 strategy, which promises to create a new and more agile/efficient telecom.  If that could be done, then AT&T could benefit from any of these acquisitions except that of Level 3, and it’s possible they could use Level 3 CDN capability to deliver content from U-verse out of area.

The key point about consolidation driven by commoditization is that it can be both promoted by and defended against using measures that drive up margins.  If the buying player can wrestle better profits from what they acquire, then they are more likely to take the plunge.  If the target company can create better margins internally, they can perhaps sustain themselves independently or make the price of acquisition unattractive.  SDN and NFV are both shifts that could boost efficiency and agility.  The cloud could improve revenues.  At the technology level we have path toward better profitability, if we can harness these trends.

Necessity is the mother of invention.  The same forces that encourage consolidation also promote the need for operational efficiency and service agility, those two common buzzwords of our time.  As we’re considering whether the industry will commoditize and consolidate, we need to consider whether it could fight its way out of both painful consequences by simply doing a better and more efficient job.  I think that’s very possible, and referencing again AT&T’s initiatives, I think people are really trying to do that right now.

It’s probably no surprise to anyone that Huawei turned in record earnings in the last quarter, and I’m sure that the other network vendors have even more to worry about now than before.  So do network operators, whose own revenue and profit pressures have been driving them to reduce costs.  Nobody in the whole of the network equipment market can possibly have missed the drive for “transformation” by operators.  You can transform by radically cutting capex, radically cutting opex, radically raising revenue, or a combination of these factors.  With three choices to work with, why is it that Huawei’s competitors have been unable to frame a challenge to the Chinese giant?

SDN and NFV have been driven by capex considerations, by the simple notion that if you want to lower your cost, spend less on equipment.  The problem is that operators know in their hearts that capex reduction is the worst of the three transformation approaches.  One of the thought-leader giants of NFV, in an open meeting, made the comment that capex wasn’t the real driver for NFV; “If we want 20% capex reduction we’ll just beat up Huawei on price.”  That’s a telling comment because it shows both the high hurdle that capex-driven transformation would have to clear, and also why Huawei is winning.

Could either SDN or NFV realize a greater-than-20% capex reduction?  Overall, meaning network-wide, I think the answer is clearly “No!”  Both technologies have strong capex benefits but in relatively specialized missions.  Service Chaining, the poster-child application for both SDN and NFV, is actually a very difficult application to justify at all, given that the profitable applications are limited to business services and could likely be supported by simple cloud-hosted multi-tenant elements because the services themselves are sold on long-term contracts.  It would be possible to redo networking completely to optimize both SDN and NFV, but to build a totally new networking model and evolve to it successfully from where we are is a very big problem.  Too big for vendors to bother with, and so they present narrow and half-hearted solutions, which Huawei can trump on price alone.

How about opex reduction?  Well, there we have a similar issue.  Right now we have operators investing in cloud computing, where the cloud community has a growing list of orchestration/DevOps tools available.  They invest in SDN, which has yet to settle on a true management model, and they’re starting to deploy NFV even though there’s no indication that its own MANO processes will fully address even local management needs (how do you represent a service chain as a MIB when the user wants to see only a virtual device and the operator needs to see all the hosted elements and connections?)  Opex reduction is, in my view, very feasible but it’s not going to happen unless everyone accepts that you can’t gain anything from managing opex in ten percent or less of your infrastructure.  However far you think SDN or NFV or the cloud might go, it’s darn sure going to start off at less than 10% of infrastructure, so early benefits will never be significant.  That means it’s back to pressing Huawei in price, and they win.

Increasing revenue is the last element, and that can in turn be divided into two categories—improving time-to-revenue on current services and offering new services.  “Service agility” (meaning the time from conceptualizing a service to making it available to deploy and then the time from order to deployment) is one of the operator hot buttons.  But again a “service” is more than a cloud- or NFV-hosted element or an SDN data center.  How agile are we going to be if we tie the Road Runner of SDN/NFV to one of those big rocks that keep falling on our coyote friend?

New services is also problematic.  The majority of “new services” people talk about are things like social networking, which are ad funded.  The total ad spending worldwide is less than the revenues of one big carrier so even if operators got all of that (which they won’t because less than half is likely to be even addressable online) they don’t really do much.  What operators need is new services that people will pay for, and that means either for-fee content services (like Netflix) or business services that drive major productivity gains and so can justify paying a nice fee for the service itself.  But equipment vendors settle for saying “Internet traffic is exploding” or touting the “Internet of Everything” and don’t do anything to prepare operators for what for-fee new services might look like.  Huawei’s price-leader approach gives operators at least an assured path to higher profit, so Huawei wins again.

This is a big complicated industry, but you can take comfort in statistics at the high level.  Right now, operators worldwide spend about 18 cents of every revenue dollar on capex.  We can transform them only by making that 18% number smaller by increasing revenue or by reducing the 18% to something like 14% (our hypothetical 20% price reduction by “beating up Huawei”.  Operators would love to do better than that in cost and increase revenue too, but they need solutions and not market platitudes.  They need, as they’ve said in my surveys for 8 years or so, for vendors to step up and support their transformation needs.

Vendors need that too, because our carrier’s 20% push on pricing to Huawei is working.  And because Huawei is at least as likely to See the Light in terms of opex and service revenue increases as other network vendors are.  Huawei eight years ago when operators were signaling their distaste for their vendors’ transformation support, was nothing in software, nothing in management.  They were simple box-pushers, and now they are becoming not only competitive but dominant in things like mobile infrastructure where there’s a big software element.  They’re jumping into OSS/BSS (their Fastwire acquisition just this year proves that).  They’re active in NFV.  These guys mean business, and business beyond being that player who’s beat up for the extra 20% price concession.  Imagine how well they’ll do if their competitors hunker down on legacy technology and vapid positioning.  We may see, and soon.