One of the most important elements in service provider transformation is hardly ever talked about. It’s the portal that would provide users and operator personnel with access to information. Since service automation is the critical goal of transformation, and since there clearly has to be a different approach when communicating with an automated lifecycle process, the portal is critical to the business case for transformation, including SDN and NFV. What is a portal, and how should it work?
In a simple sense, a portal in (network management terms) is a GUI that provides a controllable view of services, resources, or both. Not everyone accepts this general vision; the media has tended to describe a portal as a means for customer (or customer-service-rep) interaction. Operators who think the portal concept through take a broader view, and that’s the one that I’ll take here.
Management systems offer APIs that let applications connect, and popular APIs (like SNMP) have viewers associated with them. Portals are generally more like application front-ends found in business applications, meaning that they are designed to get (and often put) information through APIs but to allow for considerable customization in terms of what the user interaction and even the user device should be. We see this approach taken regularly in supporting mobile devices (BYOD).
The front-end simile here is useful because it lets us take a step toward a functional model of a portal. Let’s say that there is, for any given portal, a data element directory. This directory lists all of the data elements (fields, if you like) that are available and the identity of the API that provides that field. The data element directory for a portal is derived in a logical sense from a master data element directory that shows all possible elements, and the derivation depends on the nature of the portal and perhaps on the credentials of the user.
From an implementation sense, I’d suggest that the data element directory for a portal is a kind of local wish list that’s associated with the portal instance. The portal instance connects to the management system through an API, and that API uses the portal information (including user credentials) to “shop” the variables. Anything the user asks for and the credentials don’t support is simply filled with the null value. This back-end piece of the portal implementation is also responsible for deciding if the portal/user is allowed to change any of the values, and perhaps defines simple edits on the new values.
If application or mobile-backend-as-a-service (MBaaS) tools and concepts could build the GUI of transformation portals, what do you do for the rest? These tools also offer a general model of application interfaces through APIs or through a service bus, and the service bus approach is probably the most general solution as the next step.
In a service-bus approach, the portals drop work on the bus and publish-and-subscribe or transaction routing processes then direct the work to the proper process elements. In some products, you can do some transformation on the data structures when you push something to the bus or pop something off. The model then would be to link the back-end process APIs to the bus through a small custom component that would be written based on the requirements of the service bus and the API, but would be simple in nearly all cases.
There are two sources of those back-end-process APIs. One is the exposed API set from the OSS/BSS/NMS framework, and the other is whatever would be exposed by the SDN/NFV orchestration process, including (and perhaps most importantly) the modeling process.
The easiest way to expose SDN/NFV/orchestration/modeling information would be to follow the approach that was first proposed in the IETF (in the now-expired i2aex submission) and later carried into my CloudNFV and ExperiaSphere work. All management information from any “prime” or “analytics-derived” source is pushed into a time-stamped repository accessed by query. A generalized repository viewer element then runs a query against the repository to derive results. That means the data available to the viewer is based on the query, and that by constructing a proper query you could view anything from the current status of the SLA in a single service model element to the state of resources overall.
It’s my view that the need to provide a useful and agile portal is yet another argument for the repository model of management data. I see no way of avoiding storing all management data in a repository, if you intend to use analytics to review capacity plans or to assess evolving problems. If you’re storing it anyway, then why not generalize all service and resource management to build off the query-driven viewer approach? You could then create a portal to show anything you wanted to show, and you could generalize the portal approach from the limited customer-and-CSR mission to the broader mission of supporting any operations task undertaken anywhere.
There’s even more here. Many of the operations tasks, including billing, can be visualized as queries off our common repository, creating what is in effect a whole series of databases that are derived from a common repository, one that’s shared by service lifecycle management. The elusive goal of total integration of management and operations might then be on its way to being achieved.
That would be good, because achieving the unification goal is probably critical to fully exploiting the operations efficiency benefits of SDN, NFV, and OSS/BSS modernization. Service lifecycle management automation doesn’t address all the cost issues (it addresses perhaps half the addressable cost reductions). To address the rest, you need a very flexible portal approach, and you need to have both service automation and portals working off the same page, data-wise. We could do that by basing service automation on a management repository, and basing portals on data queries from that same repository.
The net here is that operations efficiency has to automate the service lifecycle process, but also transform the relationship between customers, customer service, operations, and the management and operations tools. Otherwise we move into the future with only part of the opex challenge resolved. Portals, meaning query-driven portals into a common management/status repository, can be the way to approach that second half of the opex challenge, and at the same time harmonize everything to a common repository. What more could you ask?