Service Modeling and Lifecycle Management: Where We Are

There has been a lot of talk about service modeling, and I’ve contributed my own fair share.  However, there have also been some developments in the space and I’ve gotten some questions from operators too.  Given this, a re-examination of the key points seems to be in order.

My conception of a service model is that it’s a hierarchical structure, something that looks a bit like an organizational chart.  Each of the boxes in the chart is an element in the model, and each element represents a building-block that’s used to describe service deployment and the service lifecycle.

The best way to look at service modeling is through a series of examples, all of which start where all models should—at the top.  The top element in any service model should be a representation of the service overall, meaning that Service should be presented as a combination of SLA attributes, orderable parameters, and decomposition instructions.  The customer sees everything but the latter; the operator is responsible for decomposing the element and propagating parameters downward toward resources, and propagating parameters upward to form the SLA parameters.

Underneath this nice, solid, vision we start to see some variations in approach.  Broadly, we can decompose to one (or more) of three things:

  1. To resources, which would mean that the high-level service can directly commit resources. I think that’s a rare outcome, but I’m introducing it here because in theory any layer of a service model might decompose to a resource commitment.
  2. To functional elements, which are logical subdivisions of the service. The classic example is that a VPN service could decompose into “MPLSVPN or “2547VPN” and a set of “EthernetAccess” elements, one for each site.
  3. To administrative elements, meaning requests for decoding of the element by a geographic or network-or-vendor subdivision. An example is “Firewall”, which might decompose to a virtual function in some places and a physical appliance in others.

In fact (as I suggested in the first point), any element in a service model could decompose the way I’ve just described.

You can see a combination of elements in the following example.  If our VPN service includes an element MPLSVPN, we could say that element could be decomposed into administrative domains representing various parts of the prime operator’s network and/or network services obtained from other operators.  Our EthernetAccess element might decompose into HighLevelFeatures and ConnectionFeatures, and HighLevelFeatures could decompose into VirtualEquipped or LegacyEquipped, in which domains Firewall would either deploy a VNF or generate a ship order to send an appliance.

Where decomposition results in resource commitment, the service model can continue to describe the decomposition steps, or hand off to a lower-layer model or management process.  The primary difference between these approaches is the way that service lifecycle management is supported, and that’s our next topic.

All services have a specific set of states that represent their progress from orderable to ordered to deploying, to deployed, to operational, and to decommissioning.  How many states and what they are is somewhat open for discussion, but the broad set I’ve outlined is the basic minimum.  Generally, a “state” is a context in which service events have to be interpreted, so if you start something with an event there’s a good chance that will generate a new state, where you await its completion or failure.

Events are conditions that are significant to a service lifecycle, and they’re a lot more variable than states.  Events can come from two general sources—from adjacent model elements (higher or lower), and from sources outside the model, which could include management systems or resources.  They’re signals that something has happened, and thus are triggers for management processes.

The states and events are traditionally correlated with processes through a state/event table, which is a simple array whose rows and columns represent states/events (in either order) the intersection of a state and an event yields a cell that typically defines the process to be run and the state that will be set when that process has completed.  Example: “If I get an ACTIVATE event in the ORDERED state, initiate the DEPLOY process and set state to DEPLOYING.”  The navigation through the service states based on service events defines an often-heard term, the service lifecycle.  Service lifecycle automation and management is simply the use of state/event-driven processes to respond to events.

Since everything from ready-to-order onward can be a lifecycle phase, this approach could subsume NFV and SDN deployment steps into a standard service model.  That would eliminate the boundary between SDN/NFV orchestration and service orchestration.  It would also bridge SDN/NFV and legacy technologies, since any provisioning approach would work as the resource end of the modeling process.

The problem with the approach is on the vendor side.  Every operations and management task would be individually orchestrable in the state/event model, which would break the lock that vendors now have on software tools in both areas.  The approach also demands broad strategic engagement with prospects, engagement that would take time and cost money to sustain.  It’s easier to blow kisses at benefits with some low apple like virtual CPE or SDN in data centers.

Operators are currently in a position of supreme contradiction with all of this.  On the one hand, nearly all of them recognize that they need, critically need, opex reduction and service lifecycle automation or they’ll never achieve any significant gains in profit per bit.  They also recognize that the scope of benefit delivery will be limited to the scope of the service model.  Despite this, they don’t call out full-scope solutions in RFPs and they aren’t even fully aware of who can deliver them.

A further note is that operators are voting with their own specs on the issue.  Both AT&T and Verizon have multi-layer orchestration, which I think is an attempt to harmonize their own need for broad service modeling and automation with the fact that the industry isn’t delivering it.  The problem is that where you have different models you have additional integration requirements, and we don’t know how complex it would be to deliver a state/event lifecycle management description that had to whiz back and forth across model and orchestration boundaries.  One model to rule them all.

There is no topic in all the transformation space as important as service modeling.  There’s probably no topic we know less about.  What would an SDN or NFV service model look like?  Bet you can’t find anyone who could draw one.  We’re not short of areas of transformation that have gotten superficial attention, but service modeling is at the top of the list, and also at the top of the list of places where we need focus, and need it now.