Month: September 2013

Cisco’s announcements on Network Convergence System (NCS) follow their normal pattern that’s fairly characterized as “chicken-little” sales stimulation.  The network sky is falling because everyone and everything is going to be connected and demanding their bits be transported.  Suck it up, operators, and start spending!

Underneath this opportunism is a reality, though, which is that there will be changes to traffic and network facilitation of applications.  I think that Cisco, underneath it all, actually has a handle on what those changes might be and is preparing for them.  The problem is that it’s complicated and it’s coming over a longer cycle than they’d like, so they need to toss some blue pieces of china up into the air and generate some near-term sales momentum.

Networking has always been a layered process, a way of creating connectivity by dividing the overall mission among functional elements in an orderly way.  Data links create reliable box-to-box connection, and then a network layer takes over to offer addressing and open connectivity.  The Internet works that way today.  SDN, which is an element of Cisco’s NCS, offers us an opportunity to do things a little differently.

“Routing” in a functional sense (meaning at any level) means that we make a per-device forwarding decision set that adds up to creating a service model, which is really a connection model.  The presumption behind nearly all of our connection models today is that we have a community of users who expect to communicate.  They may not all talk with each other, but they might.  Therefore we build open models to address and connect.

When you move to Cisco’s “Internet-of-Everything” what changes is that you add a bunch of “things” that aren’t designed for open communication.  The traffic camera or process sensor needs to communicate with a control center, and in fact needs to be protected from other access.  If you add a bunch of these new things to the Internet what you break is less traffic than the model of open connection.  With SDN you could fix it.

SDN (at least in its purist OpenFlow form) says that connection is explicitly controlled by a “central” meaning non-device, non-adaptive, process.  Traffic goes from hither to yon because you explicitly made that happen.  There is no presumption of open connectivity, only “Mother-may-I”.  If you have a traffic camera or a process sensor, you can drive a route between them and everything is fine.

The challenge for this is that it’s clearly not going to scale.  We can’t build routes for every flow on the Internet, not even in a small geography.  The challenge of SDN in a technical sense is addressing this natural trade-off between the explicit control of connectivity that would literally change everything online, and the challenge of scaling central control to manage all the connections.  Right now, for all the hype and crap to the contrary, we’re not meeting that challenge.

I’ve postulated that the solution to the problem of SDN is to break “the network” into two layers.  Up top we have an SDN layer that’s highly agile and based largely on software processes that are largely (but not necessarily entirely) concentrated at the network edge.  This layer runs on top of a transport infrastructure that is fully connective and reliable, offering the same relationship to the higher SDN layer as the data-link layer has with the network layer today.  The goal is to strip requirements for resiliency from the top SDN layer to reduce issues of scalability.  You’d then create “user services” by manipulating only higher-layer SDN paths.

In many cases, we could use this structure without being per-flow in our thinking.  Collect all the workers in a facility by job classification, so that all workers in a given class have the same application access needs.  Make an access subnet out of each class.  Now collect all the application components for each application you run in a data center subnet, per application.  To build a WAN, you now drive an SDN connection between each access subnet and the data center subnet for the applications it needs.

For an Internet of things, we can have an access subnet that contains the process sensors or other telemetry sources associated with a given application, and we can have our data center subnet for applications.  The same concept would then let us connect one to the other.  What we’ve done is to create a new service model using the natural agility of SDN.  If we have carefully placed “facility switches” in our SDN layer, there are only minimal places that have to be made flow-aware, and only minimal scaling of central control processes is needed.

This is what we need to be doing with SDN, people.  We need to think of the ways that controlling forwarding explicitly lets us build service models that better suit present and evolving applications than the permissive connection models we have today.  This is what “Northbound APIs” on OpenFlow controllers should be doing, what Cisco should be (and, I think, sort-of-is) doing with NCS.  I also think other SDN players are seeing some of this same stuff.  We’re just not hearing about it, because as always vendors will expose what sells the most the fastest and not what the future really holds.  It’s up to the media, analysts, bloggers, and people who read the industry news to demand that we get more depth on the future so we can better judge the present.

Service models are in a very real sense the only thing that matters in SDN.  If we can’t generate new and useful service models with it, then the only value SDN might offer is slightly lower capital cost on equipment.  “Slightly lower” because I don’t think that we can replicate an IP or Ethernet network at current scale with both lower capex and opex.  We’re building SDN for a limited future if we don’t think beyond our current service limits.  Looking for something to beat your vendor up on?  Think service models.

In mid-October the SDN World Congress marks the anniversary of the first NFV white paper’s publication.  SDN is far older than that, and the cloud is older still.  I attended a cloud conference last week, and while it was interesting and even insightful in spots, it’s pretty clear that we’re still missing a big part of cloud reality, and even more of SDN and NFV.  Most of what we read on the latter two topics is PR hype.

The problem is one of “mainstreaming”.  If you look at the distribution of humans by height you find most people are clustered around a centerpoint value creating a classic Maxwell curve, but there are very short and tall people.  In IT, most companies have fairly consistent patterns of deployment of technology and standard uses for it, but some companies have unusual applications and issues.  There’s the norm, and there are deviations from it.

Now, imagine someone selling chairs with seats three feet from the floor, or perhaps 18 inches.  There’s a ready market for this sort of thing among people who are unusually tall or short, and if we looked at the early adoption of our chairs we might be tempted to project hockey-stick growth based on the explosive early sales.  What’s missing is Mister Maxwell; the notion of a mainstream market that represents the dominant value proposition and the dominant opportunity.

If all we want to do with the cloud is host applications that are rightfully targets of server consolidation, we’re creating success that doesn’t extend to the center of our distribution of opportunity.  If we add to the “cloud market” by adding in everything that’s remotely hosted, every third-party server relationship, we’ll demonstrate that markets grow if you define them in a bigger way, but we won’t address the way that center-of-the-curve gets empowered.

In the cloud, success comes from a simple truth:  If the cloud is revolutionary for its flexibility and agility, then it will succeed if we have applications that can exploit those properties.  We need a revolution in application design to create mainstream cloud winners, and we’re not talking about what that revolution might look like.

Look now at SDN.  We have, with the OpenFlow model, the ability to create forwarding rules based on centralized policies, so that any arbitrary connection model could be supported.  Suppose we said that all traffic had to transit at least three switches, or move through a state whose name started with the letter “A” or stayed in the same time zone?  Stupid rules to be sure, but illustrative of the fact that with forwarding control you have service model control.  Total agility in building routes.  So what do we do with it?  Nothing that we’re not able to do without it.  Our efforts are almost totally focused on recreating Ethernet and IP, which we already have.

Success in SDN is another simple truth; SDN will succeed if it can deploy and exploit service models that can’t readily be generated with traditional adaptive-behavior network architectures.  This is why I’m all hung up on those “northbound APIs”, but it’s also indicative of a problem with how we look at SDN today.  We’re not talking about service models and they’re the only thing that matters.

Now it’s NFV’s turn.  NFV will succeed if it can frame a model of extemporaneous service generation, a model agile enough to give users what they’ll pay for with minimal explicit service creation and minimal human intervention for management.  The value of moving functionality from current appliances to hosting platforms is limited; it’s a good way to pluck some low apples to fund a real future.  It’s not enough to assure it.

That’s the common denominator here.  The cloud, SDN, and NFV are being framed as cost-savings strategies.  If they succeed in that form, they’ll make our industry smaller and duller.  But do we accept the notion that there’s nothing innovative left to do with connectivity, with features, with applications and productivity?  I don’t, and most of you reading this probably don’t either.  But we’re stuck in a model that not only accepts but embraces that view.  That’s why most CIOs now report to CFOs.  Instead of innovating, they’re sharpening financial pencils.

I read a book on the American Revolution recently, and any objective account makes it clear that it was hard.  I don’t think most revolutions are easy, and our cloud, SDN and NFV ones aren’t going to be an exception to that.  Whether we’re trapped in quarterly-profit obsessions by SOX or have simply surrendered our thinking caps, we’re not being innovative enough with our so-called “innovations”.  A great and revolutionary concept becomes an excuse to raise a few banners and maybe sell hot dogs at the mob scenes.

We can double total investment in software and hardware, in networking and IT over the next five to seven, based on past industry trends, if we can simply recapture our fire, our ability to think not about costing less but about doing more.  It’s growth that won’t last forever; that past history says that we’ll exhaust the potential of the new paradigm and the rate of growth in the industry will slip again—until we find the next revolution.  We can’t rest on our laurels in technology, because people don’t have USB interfaces in their bellybuttons.  We aren’t natural technology consumers, so technology has to be framed to enrich our lives and that enrichment only sets the bar higher for the next wave.

I’m going to be at the SDN World Congress in mid-October to talk about the future—not the pedestrian one that’s unfolding today but the exciting one the industry just may still be capable of driving.  See you there.

AT&T made some news by announcing its latest Supplier Domain Program, based on the goal of developing a transformative SDN/NFV architecture for the network.  The company is pledging to begin to buy under the program late this year and into 2014 but has not issued any capex updates.  That tells me that they expect the program to have only a modest impact on equipment selection in the next year or so, since savings are the goal of SDN/NFV and none are being projected.

I think that Domain 2.0 is more a shot across the bow of vendors than a serious commitment to either SDN or NFV.  The fact is that we don’t have any mature notion of how to build a large-scale SDN/NFV network and in particular how we’d manage one.  The big impediment is that network vendors simply don’t want to cooperate, and that’s what I think AT&T is trying to address.

What is interesting is that AT&T is biasing its justification for the new program toward better service agility and other revenue-side points.  I don’t believe for a minute that this shows a lack of interest in cost savings (despite the fact that capex plans aren’t being changed for 2014),  but I do think that AT&T has like other operators come to realize that the value of SDN and NFV has to come in large part from boosting the “R” in ROI and not just cutting the “I” part.  That also makes the initiative more palatable to vendors, who otherwise might see their own revenues vanish to a point.

And surprise, surprise, just as this is happening, Cisco is introducing its Network Convergence System, a kind of silicon-up approach to SDN and NFV that is aimed at transforming the network in the very way that AT&T says it wants.  NCS is a three-party marriage—custom chip, promised enhancements to control-plane handling and control-to-traffic integration, and improved management coupling down to the chip level.

This sort of vertical integration from the chip to the skies isn’t new; Juniper made the same claim when it announced its new chips a couple years ago.  The problem was that they diluted the benefit claims in their fuzzy and rudderless QFabric launch, the first application of the new chip.  However, I think the lesson—nay, lessons—of both announcements are the same.  First, you have to think about the network of the future very differently, and second that difference is going to be hard to square with our conception of how networks are built.

Let’s start at the top.  Agility in service creation isn’t helpful if the services you’re creating have features invisible to the user.  But service features that are visible have to be either built above the current network connection services, or they have to transform the connection model itself.  NFV is the logical way to do the first, and SDN could be made to do the second.  But NFV so far isn’t claiming to be about creating new features, but rather about hosting old ones that were once part of appliances.  SDN, so far, is either about sticking an OpenFlow pipe up in the air and hoping a service model lands on top of it, or about using software to make an OpenFlow network do Ethernet switching or IP routing.  How fast we stick both feet back into the network quicksand of the past isn’t a good measure of the value of agility.

I’ve tried, in the CloudNFV initiative for which I’m the Chief Architect, to make a clear point that the virtual functions of NFV have to be both network features and cloud application components.  They can’t be things that have to be laboriously written to a new set of standards, nor can they be simply stuff that reluctant vendors have been forced (via things like AT&T’s Domain 2.0) to unbundle into software form.  If we want software to be the king of the network’s future value, then we have to take software architecture for networking seriously.  That means drawing value from current tools, providing a platform for creating new stuff, and supporting the major trends in the market.

One of which is that mobile point-of-activity empowerment I keep talking about.  In agile services, we can build something that the market needs a bit faster than before.  I’m recommending extemporaneous services, services that self-compose around the requests of users.  We are not going to capitalize on the new value of networking by continuing to consider a “service” to be a long-planned evolution of features designed to capitalize on something.  How do we know the “something” is even valuable, and how would a user come to depend on that “something” if nobody offered it?  We have to be able to define software using the same agile principles that we expect to us in designing networks.

That’s the service-model side.  SDN and NFV have to be coupled, in that NFV has to be able to define services it expects SDN to create.  Those services shouldn’t, can’t, be limited to simply IP and Ethernet, because if that’s enough then we don’t have any real new value for SDN to address.  How should connectivity work in an “extemporaneous” service?  How do we secure and manage something that’s here one minute and gone, or different, the next?  That’s the question that AT&T’s Domain 2.0 implies we must answer, and the question that Cisco’s NCS is implied to answer.  But implication isn’t the same as proof, and we have yet to see a single extemporaneous application of the network from Cisco, or an architecture that’s convincingly framed to support such a thing.  Can Cisco do it?  I think so, but I want them to step up and be explicit on the “how” part.  So, I’m sure, does AT&T.

And that’s the hope here.  If AT&T did drive Cisco to claim more agility is at the core of NCS, then can any network vendor ignore the same issues?  I don’t think network vendors will willingly move into the future unless buyers threaten to push them out of the present, which may be what AT&T is doing.  Other operators, I think, will follow.  So will other vendors.

Well, the story now is that Blackberry is following Dell’s example and going private.  Certainly there are simple financial reasons for that, but I also have to wonder whether some of the same “SOX-think” I talked about with Dell be operating here too.  If there’s a turnaround in play for Blackberry it’s going to be a long process, one that’s not going to benefit from having executives pilloried on an earnings call every quarter along the way.  Then there’s the issue of corporate raiders who’d try to grab the company (and, of course, still might).

The question is whether there’s a strategy for Blackberry that’s as clean as that for Dell, and I think that the answer is “Possibly”.  You have to make some assumptions, but here’s an angle that might be followed.

Start with the big assumption, which is that their version 10 OS is a good one.  A number of experts tell me that it is in fact elegant and in some ways superior to both iOS and Android, so I think we can at least say that Blackberry has something it can start with.

The next assumption is that Blackberry has to be thinking along the same lines that a Microsoft executive noted recently, which is that the company has to create a kind of cloud symbiosis.  In Microsoft’s case the goal would be to make a set of cloud services an augmenting point for both the Windows desktop/laptop platform of old and the maybe-emerging appliances.  Blackberry has always had a mail/message service that was credibly a cloud service so this isn’t too much of a stretch either.

Given these two assumptions, I’d suggest that what Blackberry has to do is to morph its current OS into an expanded model in two parallel dimensions.  First, it needs to frame up a microkernel of the current OS, a minimal element that can run on anything and call on “BBcloud” services for functionality.  In effect, it’s Firefox OS.  But second and unlike Firefox OS, Blackberry has to make it possible to pull more than microkernel functionality into devices that have the capability, either permanently to create something like a traditional phone or tablet or as needed.  That means that the appliance becomes an extension of the cloud and not just a portal onto it.  Software features migrate between device and cloud.

The third point is that BBcloud services then have to be expanded considerably.  What Blackberry needs is the ability to make BBcloud into an ecosystem, something that lets developers build mobile and cloud applications not based on “compatible” code but on the same code.  Everything, from apps that are currently nailed to the appliance to stuff that’s not yet written, is designed to be run in BBcloud and hosted wherever convenient.  I’d suggest that Blackberry even provide a mechanism (via a “shell”) to run this stuff on a standard PC.

You probably see where I’m heading with this.  Blackberry has a framework that looks like an extensible mobile environment, one that lets applications and resources spread out from the device into either local user compute resources or into the cloud.  It’s bold enough and powerful enough conceptually to give the company a shot.

The risk, you’ll say, is that whatever Blackberry can do here the other players like Microsoft, Apple, and Google can do as well, and likely better.  Yes, but they have two disadvantages versus Blackberry, two related ones in fact.  The first is that this sort of ecosystem would likely be seen by all the competition as enormously risky to their current business model.  The second is that this risk would be smashed in their face like a pie every quarter, because the competitors are still public companies.

Whether Blackberry (or Dell) sees things this way, it seems pretty clear that “going private” might actually be the way that we get innovation back into our industry.  We have VCs who want to fund social burgers that can be put up for next to nothing, run against a small chance of a buyout, and if they win they pay big.  It’s like the lottery.  We don’t have the kind of financing that builds fundamental tech revolutions out there in VC-land because they see the process as being too lengthy and risky.  But if private equity steps in to take a company like Blackberry private, we could have what’s essentially a giant startup with branding, funding, installed base, and all kinds of other neat stuff.

You also have to wonder whether this sort of thing, promising as it may sound, could actually work.  Many revolutionary approaches have proven to be ineffective, after all.  Australia, who took the bold step of creating a kind of national broadband project with its NBN initiative, is now facing major scaling back, cost issues, and a complete route of the NBN board.  It may be that Telstra (the national carrier who frankly should have been doing this all along) will end up effectively “being” NBN or at least running it.

What the NBN thing proves is that the big disadvantage of revolutionary business mechanisms like the go-private-and-scuttle-SOX approach is that nobody has done it at scale and nobody knows whether it will work financially, much less whether the now-private company can pull something together and make it work.  The private cloak can hide revolutionary development from shareholders wanting instant gratification (like corporate raiders and hedge funds) but it’s not going to make that revolutionary development happen.  Both Dell and Blackberry will have to get their internal R&D processes tuned to a whole new world, where strategy matters a lot, after having lived for decades in a world where it didn’t matter at all.  But isn’t strategy how we got to where we are today?

No less investment maven than Carl Icahn believes that Michael Dell’s successful campaign to stave off his takeover and take Dell private was “just one recent example of a ridiculously dysfunctional system.  Lacking strategic foresight, the Dell board for years presided over the loss of tens of billions of dollars in market value at the hands of CEO Michael Dell. Instead of deposing him, the Dell board froze out shareholders and voted to allow the CEO to buy the company at a bargain price using shareholders’ own cash.”

I agree that the stock system is “ridiculously dysfunctional” but I think Icahn may be more of a contributor to dysfunction than an impartial arbiter of functional-ness.  What Icahn didn’t do, arguably the bubble and SOX did, and it’s just possible that Michael Dell is on the track to salvation of the system and not its destruction.

The biggest problem with innovation in tech today, IMHO, is the fact that since the excesses of the NASDAQ bubble in the late ‘90s and the Sarbanes-Oxley Act (SOX) designed to curb them, companies have been shortening their sights to the point where executives can’t see beyond the next quarterly numbers.  That’s equivalent to wanting to trek like Lewis and Clark without being able to see beyond your feet.  Nobody wants to bet on the future because they can’t be rewarded for doing that.  You deliver your numbers, which are at least a small improvement over the old, by cost reduction if you can’t manage revenue gains.  And if you’re into network equipment or server sales you likely can’t manage revenue gains because all your buyers are staring at their feet too.

So do we fix SOX?  Heck, we can’t even fund a government or pass a debt ceiling extension, or approve nominees for key positions, or much of anything else.  Imagine trying to do something substantive in Congress these days.  So what’s the answer?  Well, it just might be to take your marbles and go home.  Leave the public company rat race and go private, where you can build for the future without having your hands slapped for not making the numbers in the next quarter.

I’m not Michael Dell’s confident, so I can’t say if this is what he has in mind, but the opportunity to leverage the “special benefit” of being “private” rather than “public” will be there whether that was Dell’s intentions or not.  Cloaked in the righteous anonymity of private-ness, Dell could quietly foment the revolution of networking and IT, emerge when they’re done like an erupting volcano, and totally transform the industry and confound competitors of all types.  Pull it off and Dell would be in a position to be what Chambers wants Cisco to be, the “number one IT company”.

Of course, it’s the pulling it off part that’s the trick here.  To revolutionize the industry like this, Dell would have to know what revolution they wanted to back and how to back it.  While I’m sure that some in Dell understand the benefit that being a private company could bring them, I’m less sure they know what they want to do next.

I think Dell and I agree on something, which is that “the cloud is the future”, but that’s too vague a notion to build a revolution on (anyway, everyone’s been saying that so the slogan has been used up).  The thing that’s the revolutionary part is the creation of an agile experience framework in the cloud, something that vendors and standards groups have sort-of-begun by looking at how things like IMS/EPC and CDN could be cloud-hosted.  Cloud-hosting isn’t the whole answer, though.  You have to add in a lot of flexibility and agility, the notion of not only highly dynamic resource-as-a-service frameworks but also a more dynamic way of building software to support experiences (something I blogged about just last week).

The most complicated parts of our revolution may not be defining slogans or pieces of doctrine, but simply finding a place where it can start.  A good revolution has to balance the realities of the present with the value of the future it promises; it has to build on the current system so that there’s not widespread problems associated with adoption.  But it can’t get bogged down by supporting the present.  I contend that our SDN, cloud, and NFV revolutions are too tied to current paradigms.  They’re all cost-based.

You don’t take up the barricades to save 8% or 12% on your phone bill.  The promise of the future that a revolution must convey—that Dell must embrace—has to talk about the wonderful things the future will bring.  Bringing slightly cheaper forms of the present won’t cut it.  All of our technology revolutions are just that, revolutions on the technology side that will impact how you do something and perhaps how much it would cost to do it, but they won’t deliver things different than we already have.  Those who are promising otherwise are just making empty promises, lacking convincing detail because they have no detail to offer.

I don’t have it either.  I believe the future is a fusion of our current revolutions with mobility to create a kind of gratification framework that grows around everyone and links them to the stresses and opportunities of the world they face.  I think a good tech company could build that framework, if they were unfettered by SOX.  You, Dell, are about to be cut free.  Can you take up the challenge?

We have software defined networks, software defined data centers, software defined servers.  What’s missing?  I contend it’s the most obvious thing of all; software designed software.  We’ve built a notion of virtualization and agility at the resource level, but we’re forgetting that all of the stuff we’re proposing is being purchased to run software.  If you have the same tired old junk in the software inventory, how are you going to utilize all that agility and flexibility?

I said yesterday, referencing Oracle’s quarter, that the key to the future for both Oracle and the others in tech was supporting point-of-activity empowerment, which simply means using agile technology to give people what they want, when and where they want it.  In a simple infrastructure sense, PofAE is a marriage of cloud and mobility.  In a deeper sense, it’s also a renewal of our agility vows, but starting at the software level where all experiences start.

If you look at software and database technology today, you will find all kinds of claims of agile behavior.  We have “loose coupling”, “dynamic integration”, “activity-directed processes” and so forth.  It might seem like software has been in the lead all along, but in fact software practices still tie developers and users to some rigid frameworks, and this rigidity is a barrier to full realization of the benefits of elastic resources.

One simple example of a barrier is the relational database.  We think of data as being a table, where we have key information like account number and we have supporting data like address or balance.  The problem with this in an agile world is that the structure of the data creates what might be called a “preferred use” framework.  You can efficiently find something by account number if that’s how the table is ordered, but if you want to find everything where balance is below or above or between specified points you have to spin through everything.

There’s been talk for ages about semantic relationships for the web or for data, but despite all this debate we’re not making much progress in moving out of the tabular prison.  We should be thinking of data in terms of virtualization.  If we can have virtual servers and virtual networks, why not virtual RDBMS?  Why can’t an “abstraction” of a relational table be instantiated on what is essentially unstructured information?  Such a thing would allow us to form data around practices and needs, which is after all the goal of all this cloud and software-defined hype.

Another example is in the area of processes.  If I develop an application for a single server, I can run it on that single server and lose efficiency because it utilizes it badly.  I can also consolidate it into a virtual data center where it shares server capacity with other apps, and it will be less inefficient.  Perhaps if I run it in the cloud where there’s even more economy of scale, I can be a little more efficient still.  But at the end of the day, I’ll still be running the same software and supporting the same experience that I started with.  In fact, realistically, I’ll be trading off a little performance to get that higher efficiency so I’m actually doing less for the experience than before.

A popular way of addressing this is to componentized software, to break it up into functional units.  Something that was once a monolithic program can now be broken into a dozen components that can be reassembled to create that thing we started with, but also assembled in different ways with other components to create other things.  The most architected extreme of this is found in the Service Oriented Architecture (SOA) which lets us build components and “orchestrate” them into applications through the use of a business process language (BPEL) and a workflow engine (like the Enterprise Service Bus or ESB).  There’s a language (WSDL) to define a service and its inputs and outputs to make browsing through service options easier, and to prevent lining up a workflow whose “gozoutas” don’t match the “gozintas” of the next guy in line. SOA came along almost 20 years ago, and it’s widely used but not universal.  Why?

The reason is the Web.  SOA is a complex architecture filled with complex interfaces that provide a lot of information about dynamic processes but that are difficult to use, particularly where you’re dealing with best-efforts network or IT resources.  The Internet showed us that we need something simpler, and provided it with what we call “REST”, a simple notion of a URL that when sent a message will do something and return a response.  It’s elegant, efficient, simple, and incredibly easy to misuse because it’s hard to find out what a given RESTful service does or needs or returns.

We clearly need to have something in between, some way of creating applications that are not just dynamic or malleable, as REST and SOA are, but are extemporaneous in that they don’t presume any process structure or workflow any more than a truly agile data environment would presume a data structure.  With something like this, we can handle “big data”, “little data”, clouds and NFV and SDN and all of the other stuff we’re talking about at the software level where IT meets the user.  If we don’t do this, we’re shadowboxing with the future.

You don’t hear much about this sort of thing out in the market, probably because despite the fact that we think software and IT is the bastion of innovation, we’ve let ourselves become ossified by presuming “basic principles” that guided us in the past will lead us indefinitely into the future.  If that were true we’d still be punching cards and doing batch processing.  The virtual, software-defined, world needs something more flexible at the software level, or it will fail at the most basic point.  What software cannot, for reasons of poor design, define will never be utilized at the server or network level, even if we build architectures to provide it.

Oracle, certainly no shrinking violet in marketing/sales practices and clearly a software leader, reported a quarter with light earnings and qualified guidance.  The news hasn’t broken through the euphoria of a no-taper-yet stance from the Fed, but it should be a warning that we really do have issues with IT spending.

What makes Oracle’s story particularly important is that the company is a software player primarily, and software is the on-ramp between productivity benefits and IT spending.  Nearly anything that’s going to provide fodder for new projects in IT is going to involve software, according to my surveys.  I noted in the spring that the balance of total spending to project spending in IT, which has historically been biased toward projects, has shifted since 2009 to “budget” or sustaining spending.  You can’t advance IT without new projects, so all of this is a signal.

Enterprises believe by an almost 3:1 margin that IT can provide them incremental benefits in enhancing worker productivity, sales, and overall company performance.  When we ask them to quantify how much more they believe could be obtained from optimized IT, they suggest an average 21% improvement.  That’s really critical because if you raised benefits by 21% you could raise spending by that same amount and still meet corporate ROI targets.

What’s more interesting (to me, at least) is that my model says that the actual gains that could be obtained from something like point-of-activity empowerment that fuses cloud computing and mobility to give workers better information at their point of work would be even higher.  The net investment needed for point-of-activity empowerment is actually lower than the average cost associated with securing a current and more traditional IT benefit set.  Thus, the model says that PofA empowerment could actually justify an IT spending increase of nearly 26% over the next five years.  So why don’t we have that?  I think Oracle is a poster child for the market’s issues.

First and foremost, the operations management of major enterprise buyers are simply not educated in the notion of point-of-activity empowerment.  They are stuck in a fragmented model of IT that recognizes “mobility” as a project, “the cloud” as a project, and nothing that combines the two.  Companies that are highly sales-driven (which means most companies, but Oracle in particular) tend to respond to buyer requirements rather than to propose new and broader ones.  Every salesperson knows that if you try to expand the scope of something you involve other people who have to approve it, increase project delays, and delay sales.

The second problem is that Oracle isn’t a mobile company in the first place.  Oracle has no specific mobility assets to play with; they don’t do carrier LTE or WiFi networking.  While I believe that there is no real need to be a mobile/wireless provider to address a corporate point-of-activity empowerment opportunity, Oracle likely thinks that bringing the cloud and mobility into any story would be tantamount to stamping “Cisco” on the cover sheet.  Overall, companies have tried to focus on what sells for them, and that means that a revolution in benefits may require stuff they never thought they’d need…and don’t currently have.

The third problem is inertia.  We have been stuck in project neutral since 2002 according to real data from government spending and GDP sources.  I’ve noted a number of times that our model of the rate of growth in IT spending versus growth in GDP since WWII shows not a steady ramp but a sine wave.  Each peak in the wave corresponds to a period when project spending as a percent of total IT spending grew significantly, and where new benefits justified as much as 40% better spending growth.  We had the last peak in the late ‘90s and we’ve been stuck near a historically low point in the IT/GDP ratio since.  What all this means is that we’ve trained a whole generation of sales and sales management people on the notion that IT is nothing but a cost center and that the only path to success is to help the customer spend less on the stuff you sell.  And, of course, hope that you get a bigger piece of the smaller pie than your competitors.

When we don’t have new projects, IT spending is at the mercy of the so-called “refresh” cycle, which is the regular modernization of equipment that happens because performance and reliability improvements eventually justify tossing the old in favor of the new.  The problem is that since 2005 users have reported keeping IT technology longer, so this refresh is not driving as much spending as before.  Users also tend to cut IT refresh spending early in any pencil-sharpening savings-finding mission.  Why buy a new version of something to do the same job that you’re getting done using something that’s already paid for?

Oracle, as I’ve said, isn’t the only company facing this sort of issue.  All of the network equipment space and all of the IT space that relies on enterprise purchasing has the same problem.  Even in the consumer space, we’re seeing smartphones and tablets plateau because the next big thing just isn’t big enough.  Operators don’t put “early upgrade” plans in place if users are willing to jump to new models without them.  We’re running out of low apples here.

The answer to this is to grow up and realize that we need some more “R” to drive the desired “I”.  But that’s been the answer for a decade now and we’ve successfully ignored it.  I don’t know whether the industry can learn its lesson now without a lot of serious pain, which is bad news.  We may find out.

The world of SDN and NFV is always interesting, like a developing news story filled with little side channels and some major scoops.  One of the latter just came from RAD, whose “distributed NFV” raises what I think are some very interesting points about the evolution of the network.

The traditional picture of NFV is that it would replace existing network appliances/devices with hosted functions.  Most presume that this hosting will be done on general-purpose servers, and in fact that’s what the White Paper that launched NFV actually says.  Most also believe that the hosting will take place in operator data centers, and most likely will.  But RAD’s announcement demonstrates that there’s more to it.

The details of RAD’s story aren’t out yet; they’re scheduled to be released in New York at the Ethernet and SDN expo in early October.  What RAD is saying now is that their vision is based on the simple principle that “Ideally, virtualized functions should be located where they will be both most effective and least expensive, which means NFV should have the option to return to the customer site.”  That means hosting at least some virtual functions on-premises or at least at the carrier edge, and that in turn might well mean taking a broader look at NFV.

There’s always been a tension between the operationally optimum place to put a network feature and the traffic-and-equipment optimality.  Operationally, you’d like everything to be stacked up in a common space where techs can float about getting things fixed.  However, some functions in the network—application acceleration is an example—rely on the presumption that you’re improving performance by conserving access capacity.  To do that, you have to be upstream of access paths, meaning on the customer premises.  You can always exempt this kind of technology from NFV, but it makes sense to think about whether an edge device might not have some local hosting capability, and might thus serve as a platform for part of NFV deployments.  That seems to be the sense behind RAD’s “distributed NFV” concept, and I agree with the notion.

That’s not the end of the NFV extension issue, though.  I’ve said many times that there are a number of highly credible situations where shifting from custom appliances/devices to servers and hosting doesn’t make sense.  As you move downward through OSI layers you flee features and encounter only aggregated multi-user streams.  What’s the value of software agility there, at say the optical layer?  Further, can we expect server technology to spin optical bits around as effectively as a custom device?  I don’t think so.  Even deeper electrical products like switches and routers may demand higher availability because they’re still aggregation devices not access devices.  You can’t make a data path resilient through redundancy unless you want to stripe data across multiple routes, which I think raises costs more than NFV principles could cut them.  Thus, we’re going to have things that are outside NFV but that stay inside the network.

Deploying a virtual network function inside “the cloud” is a function of cloud management APIs.  You could extend Nova implementations in OpenStack to handle device-hosting of virtual functions, or even simply use Linux cards to create what looks like a server inside a device.  You can also create an alternative “Service Model Handler” (to use our CloudNFV term) to deploy edge functionality using whatever mechanisms are required.  What changes is the question of deployment complexity.  The more we distribute virtual functions, the more likely it is that there are places where one could be put that would be, for the service situation being presented, seriously sub-optimal.  In some cases, in fact, it’s likely that the virtual function being deployed would be specialized for the edge equipment and couldn’t be hosted elsewhere.  That fact has to be communicated to the NFV implementation, or there will be multiple parallel strategies for deploying functional components of service logic.  All we need to ruin a cost-savings and agility-building strategy is multiple incompatible and parallel approaches.

A similar issue arises with non-virtualized functions, meaning native or persisting devices.  If we presumed universal transfer of network functionality from devices to hosting, we could presume cloud principles and software logic would define management practices.  Virtual service components could be managed as application components.  But if we have real devices, do we then force virtual components to be managed as virtual devices, or do we create two tracks of management—one mostly conventional EMS/NMS and the other software-hosted management—and hope to somehow reconcile them?  How do we even define a service that embodies both virtual components and real devices?

The point here is that it’s going to be hard to contain NFV.  Some of its impacts are going to spread out to involve things that the original mandate never included, simply because the original mandate of commercial servers won’t optimally support the full range of network service models.  I don’t think that would surprise the founders of NFV, but it might surprise the vendors who are looking to build NFV support.  In particular, it might surprise those who are looking at the area of “NFV management”.

Why?  Because there can’t be any such thing.  You manage services, you manage resources.  That’s what network management is, and must be.  There can be only one management model or management isn’t effective.  I believe that the management evolution of NFV, an evolution that’s likely to evolve from the liaison between the NFV ISG and the TMF, is the most important element in the success of NFV in the long term.  It’s also the most important element in the continuing relevance of the TMF and OSS/BSS concepts.  This is a test, folks.  Virtualization, fully implemented, would let us define virtual function management any way we like.  It cannot be fully implemented, so we have to harmonize in some way—without losing the cost efficiencies and agility that NFV promised from the first.  Can that happen?  I think it can, but I don’t think that every NFV implementation will support this vision.  That means it’s going to be important to look for that support as implementations emerge.

Juniper continued to develop its Contrail/SDN strategy, with an announcement it was open-sourcing a version of its Contrail SDN controller, which is also available via a traditional commercial-support license.  The move says a lot about the SDN space, and it also may give a hint as to how Juniper might (emphasis is important here) exploit and differentiate SDN.

In a real sense, SDN is an ecosystem building from the bottom up.  We started with OpenFlow, a research-driven protocol to control forwarding table entries, and we’re working up toward some hopefully useful applications.  One critical element in that climb is the SDN controller that translates notions of “routes” and “services” into forwarding commands.  A controller is a necessary condition for OpenFlow but not a sufficient one; you need applications that convey service/route intelligence to the controller.  That’s where all the SDN strategizing comes in.

The APIs that link what I call “service models” to OpenFlow controllers are those infamous “northbound APIs”, infamous because everybody talks about them but there’s relatively little substance provided.  We count nearly 30 controllers on the market or in open source today, and as far as I can tell none of them share northbound APIs.  That’s where this ecosystem stuff comes in, because if you need services for SDN you need service models and translation of those, via northbound APIs, to OpenFlow (or something).  If you make it too hard to get your controller you won’t get anybody to author those northbound apps and you have no service models and no real SDN utility.  So you open-source your controller to encourage development.

Juniper will obviously get some takers for this approach, and in fact some were announced.  The challenge Juniper faces is that Cisco’s OpenDaylight has much broader support and much wider name recognition.  Given that the average user doesn’t know anything about those northbound APIs, it’s fair to say that “all in a name” applies here more than usual.  For our CloudNFV initiative, we have very strong interest from the open source community in a Service Model Handler for OpenDaylight, but none so far for Contrail.

So what does Juniper do about this?  I think there are two tracks they can take.  First, they can shine a light on the whole question of service models and northbound APIs to make prospective users/buyers understand what’s going on there.  Second, they can start applying their API principles to real network issues in a conspicuous way so that their platform is perceived to have immediate value.  NFV might be a useful place to start.

For two possible paths to visibility, Juniper has two barriers to confront.  First, any organized appreciation for service models in SDN will have the effect of making the path to SDN adoption a lot clearer, and you can implement SDN using software switches/routers.  That could cut into the sale of real switches and routers, and so Juniper like other network equipment vendors has been a bit reluctant to trot out a strong service model story.  Second, this is a software ecosystem and Juniper is fundamentally a hardware company.  If you look at things like the cloud, you see Juniper building not a developer program but a channel program.  They want people out there pushing Juniper boxes.  That’s a problem when you’re trying to build an ecosystem north of a vendor-independent standard.

Juniper has some interesting assets with Contrail.  I’m of the view that SDN is a two-layer model, with an agile software-based layer controlling connectivity and a deeper hardware layer managing traffic.  This model would normally require some form of cooperative coupling between the layers, and Contrail extends that coupling to the exchange of address information.  I think it could easily be made to provide service-model communication from the application down through transport and across to adjacent branch or data center sites.  In short, it would be a decent framework for a cloud-like ecosystem and a nice way to frame service models in a general way.  It would be, providing Juniper articulated that view—and believed in it.

And of course there’s the time factor.  A move to establish a Contrail SDN ecosystem would likely provoke a response from Cisco and OpenDaylight, and there’s little question who would win if the battle became a long slog.  What Juniper needs is a strike, a strong and sensible program to create and publish a vision of future networking that is compelling because it’s sensible.  I don’t think that’s all that difficult to do at this point; you can see what networking-as-a-service has to look like already, and how it has to be created.  The cloud, SDN, and NFV have combined to give us all the pieces we need to bake a nice cake.  We just need a baker.

I know there’s already been a lot said about the Microsoft deal for Nokia, but I think that the deal may have some angles that still need more exploring!  That includes the “NSN dimension” of the deal, of course.

The biggest implication of the Microsoft/Nokia deal is that it doubles down on smartphones for Microsoft.  With the exception of a few die-hards, I doubt many think that Microsoft has a winning smartphone strategy at this point.  The challenge with the “Windows” model for the phone market is that it depends on a host of willing device partners, which has been hard for Microsoft to come up with in both the phone and tablet spaces.  By getting into the phone business directly, Microsoft controls the whole ecosystem.  Yes, it’s going to discourage anyone else from providing Windows phones, but it won’t prevent it.

The reason this is big isn’t that it makes Microsoft a phone vendor, it’s that it commits Microsoft to being one and thus puts a lot of company prestige and money behind what is very possibly a lost battle.  If you look at the Apple iPhone launch and its effect on Apple’s stock, it’s pretty obvious that the market recognizes that smartphones are becoming commodity items.  Even the market leader is now resorting to launching new models based on pretty colors, after all.  Can Microsoft, whose reportedly limited ability to be innovative and cool was the big factor in losing the phone space in the first place, now succeed when Apple could not?  I doubt it, but if they don’t then do they try to come up with new and different colors?  Heliotrope, burnt sienna, or umber, perhaps?  Bet there’s a run on art supply stores in Redmond already.

So why is this big?  It’s because Microsoft didn’t buy NSN.  In my view, the smartest thing the company could have done was to pick up NSN and not the phones, frankly.  That would have signaled that Microsoft was aiming to be a player in point-of-activity empowerment, the fusion of mobility, the cloud, and appliances that I’ve been talking about for some time.  Microsoft might have leapfrogged their competition had they picked up NSN, and even rehabilitated their decision to buy the darn phones by providing themselves a credible direction for differentiation.  The future of appliances doesn’t lie in finding new colors for phones or creating wearable tech, it lies in creating an experience ecosystem built not around devices but around the cloud.  NSN’s position with 4G and IMS could have been added to Microsoft’s own cloud to create the centerpiece of this whole point-of-activity thing.  Without NSN’s tools, Microsoft is still at the end of the day the same company it was before…which isn’t enough unless Microsoft leadership can truly transform their own thinking.  And no, Elop isn’t going to do that.

Which leaves us with the question of what happens to NSN.  Once the small piece of the Nokia tech pie, NSN is now arguably the flagship element and certainly the only place where there’s a major hope of growth.  The question is whether NSN, which had been focused on cutting back and cutting costs and cutting staff, can now focus on actually doing something revolutionary in a market that’s doomed to commoditization if somebody doesn’t figure out how to make features valuable again.  Mobile is the bastion of communications standards, and the inertia of the standards and the standards process has made it exceptionally difficult for anyone to drive real change in the space.  Can NSN now break out of that cycle?  Remember that the company wasn’t noted for aggressive marketing in the past.

The whole notion of “liquid” could encapsulate the NSN/Nokia challenge.  The idea is good in that it expresses the need for a fluidity of resources in an age where user demands for empowerment could mean as little as dialing a call or as much as researching a multi-dimensional social/location decision based on a dozen different factors and vectors.  The problem is that it’s easy to get the notion of “fluid” trapped in the network, particularly if that’s where you’ve been focusing it all along.  You need a fluid IT model for the future of mobile devices, not just a fluid networking model.  Can NSN provide that, or even conceptualize it?  It’s really hard to say at this point because NSN is still recovering from a change of ownership following a series of downsizings.  They may have cut the very people they needed.  But they may now, as the senior partner of Nokia alone, have some latitude in getting the right thing done.

SDN is an area where the media suggests Nokia may have an opportunity, but NSN hasn’t been a player in network-level technology for a decade, so there’s a question of just what NSN could apply SDN technology to.  Do they climb up the SDN stack, so to speak, and develop some smart “northbound applications” to OpenFlow controllers?  Do they build on an NFV-modeled vision of cloud/network symbiosis?  The problem with either of these approaches is that Nokia has nothing firm to anchor them to in equipment terms.  Most operators expect that there will be either an “open” strategy north of OpenFlow, or very vendor-specific vertically integrated strategies.  You can’t make money on the former and if you don’t have a complete network product suite you can’t make it on the latter either.

Microsoft, ironically, is in a better position to build those northern-facing apps than NSN or Nokia is.  Because they have the software credentials and a cloud framework in place, they could easily frame an architecture for software control of networking.  That gets me back to the point that maybe they needed to buy NSN too.  Think of the potential of that deal for SDN and NFV and you might agree.