Populating the Functional Zones of ExperiaSphere

I’ve gone through almost a half-dozen webinars/presentations on the ExperiaSphere model, and the good news is that I’ve not found any major issues.  That means that my activity can continue along expected lines and that I should have something I can share in a public video and slide deck by August, as expected.

One thing I did find is that this is a very difficult topic to address in abstract.  My instinct was to present a model for defining orchestrable services, explain what was in it, and then talk about how it could be implemented in open source.  That works OK for people who are somewhat immersed in orchestration and management, but not so well for people without that specialized background.  I’m now looking at a slightly different approach.

What I’m proposing to do going forward is to explain the model by explaining an open-source-mapped implementation of the model.  This means that I’ll start by laying out a representative service lifecycle, the steps operators take in going from an opportunity gleam into the realization and sustaining of customers that address that opportunity.  I’ll then take these steps to illustrate what’s needed and how it’s done using open-source tools and open standards.

It’s also become clear that the problem divides itself into three main areas or “functional zones” of logic.  First, the service model or data structure that defines a service and supports automated provisioning of the service.  Second, the management derivation process that bridges between the functional/conceptual view of a service that a customer or customer-service type would have, and the resource-and-status view that’s needed for network operations and remediation.  Finally, we have the state/event processes that link lifecycle events (wherever they’re generated) with the appropriate network, service, and business processes.  I’m pretty confident at this point that I can identify open-source solutions for all of these three areas, solutions that have (within their areas) some reasonable level of actual market validation.

The challenge now is to figure out how these “solution zones” that align with my problem areas can be merged into a cohesive application.  Certainly there are primitive open tools that can be used to facilitate the development of the linkages.  The question is which tool is best, meaning likely which will offer the best combination of flexibility/agility to respond to changes, but at the same time minimize specialized development and integration.  It does not appear possible to create an industry-wide model for management and orchestration without some custom glue being needed.  There may be better ways than others to get it, but something will have to be developed in the end.

Clearly there’s a relationship between the stuff we can identify in to support our major areas and the glue we’ll need to bind them together.  That’s something that is particularly true in my management derivations category, because you need a lot of flexibility to be able to 1) incorporate data from the widest classes of resources and 2) present that data and derivations of it through the most flexible possible combination of views.  If you have any knowledge of this problem set, please join the LinkedIn Group ExperiaSphere or contact me directly.  I’ll try to put you to work!

This entry was posted in Uncategorized. Bookmark the permalink.