What Now for ExperiaSphere?

Some of you have asked me what I plan to do next with ExperiaSphere, given that I’ve just published the last of the five tutorials I promised.  The answer is “nothing specific” or maybe “it’s up to you!”

I believe that NFV specifically, and the whole notion of an NGN model in a more general sense, needs a holistic end-to-end, top-to-bottom architecture that virtualizes everything, because I don’t think you can efficiently adopt virtualization in little islands.  We virtualize services, resources, and processes, or we anchor agile things in legacy inertia.

When ExperiaSphere launched as a project back in 2007, the goal was to prove that you could represent service and resource abstractions with software objects.  That was proved, and that concept was the basis for my CloudNFV project in 2013, and for the new ExperiaSphere work directed at an open NFV model that has just been completed.  I think all of this adds up to a pretty well documented proof that this can be done right.

Some of you have expected me to form a company or launch another CloudNFV-like consortium to implement the model I’ve described.  I’m not prepared to do either.  I’m a strategy consultant, and that’s what I want to be.  The job of running a startup is more work than I want at this stage in my life.  I can’t dedicate more uncompensated time to running a group of companies in a cooperative project like CloudNFV was.  So I’ve done as much as I can do with this, and the industry at large now has to decide if the work was useful or not.

I won’t regret my efforts here even if nothing comes of it.  Strategy consulting involves giving a lot of advice you know your client isn’t going to take, but it’s still the truth and still what they should do.  I’ve done my part, and now others are welcome to use as much of this concept as they find useful, and build what serves your own goals.  If further industry activity suggests something more can be done here, within my constraints of donating time, then I’ll take up that something when it arises.

Posted in Uncategorized | Comments Off on What Now for ExperiaSphere?

The Final ExperiaSphere Tutorial is Available!

I’m happy to say that I’ve completed and posted the final ExperiaSphere Tutorial.  You can find this on the ExperiaSphere website or download from below.
Tutorial Five:  ExperiaSphere Service Lifecycle Phase 4: Deployment

  • Slides for the Management phase are available HERE.
  • Annotated slides for the Management p;hase are available HERE; we recommend you use for the notes per slide.
Posted in Uncategorized | Comments Off on The Final ExperiaSphere Tutorial is Available!

Deployment Phase Tutorial Now Available!

I’m happy to announce that the tutorial for the Deployment lifecycle phase of ExperiaSphere is now complete and posted on the ExperiaSphere website.  Click HERE for the page.

There is one more tutorial remaining, on the general Service Management lifecycle phase.  We’ll get to that as work permits!

Posted in Uncategorized | Comments Off on Deployment Phase Tutorial Now Available!

Service Order Phase Tutorial Now Available!

I’ve completed the service order phase tutorial for ExperiaSphere, and posted the tutorials on the ExperiaSphere website.  We have two tutorial formats, one in PDF ONLY for those who want only the slides, and one in ANNOTATED PDF form with my slide notes attached.  As always, this material can be exchanged freely as long as our copyright notices and trademarks are intact.

Please use our Google+ Group to post questions and comments!

Posted in Uncategorized | Comments Off on Service Order Phase Tutorial Now Available!

Service Architect Lifecycle Phase Tutorial is Now Available!

I’m happy to say that I’ve completed the slides and annotated slides for the Service Architect tutorial for ExperiaSphere.  They are now available on the ExperiaSphere website as follows:

  • The slide deck without annotations and in PDF form is available HERE.
  • The annotated slide deck in the same form is available HERE.  We recommend that you use this deck for learning since the notes are highly valuable.

These documents can be shared freely as long as they remain in PDF form with our copyright and trademark notices intact.  You may not use the term “ExperiaSphere” except to describe the documents unless you contact us for permission.

There is no obligation for you to reference us or the ExperiaSphere project or design in your own work, even if it is derived from ExperiaSphere.  We’d hope that you would voluntarily do that, and provide a link to the website, if you do incorporate ExperiaSphere principles into your design or product.

Posted in Uncategorized | Comments Off on Service Architect Lifecycle Phase Tutorial is Now Available!

The Second Tutorial is Coming in August

I’m happy to say that the second of the ExperiaSphere tutorials will be available in August 2014, likely toward the middle of the month.  For those who found the first one heavy going, this one is going to be even worse, but the good news is that successors will get much easier.

The second tutorial is the first of the four “service lifecycle” tutorials aimed at explaining what ExperiaSphere will do and how it will work by following the path of a service from conception to deployment and management.  The tutorial is aimed at the first lifecycle phase, that of the Architect.

ExperiaSphere builds services by harnessing resources.  The inherent behaviors available from cooperative systems of resources like networks or data centers are framed into useful groupings called service models, and these then form the lowest-level building blocks of the services themselves.  The critical step in this evolution from resource to service model is the creation of Logical Resources that are virtual functional chunks that can be instantiated as needed.  ExperiaSphere builds down from them to the actual networks and data centers and up from them to services.  Architects control all this by building object containers for resources, both logical and physical, and these are then used as proxies for the resources in assembling stuff and committing infrastructure to customers.

I know this tutorial is going to be a challenge; it’s over 50 slides.  But it’s the heart of ExperiaSphere, the thing that makes everything else work, and so getting it right will set up for the simpler tutorials on ordering, deployment, and management.

Posted in Uncategorized | Comments Off on The Second Tutorial is Coming in August

ExperiaSphere Tutorial One Slides Available!

I’m pleased to say that the slides (both plain and annotated) for the first of the ExperiaSpere tutorials are now available and the ExperiaSphere website has been updated to track the new open-source-driven management and orchestration model.  Carol Wilson of Light Reading published a nice piece on ExperiaSphere HERE, and I’m happy to finally have the architecture overview complete and published for review.

The slide decks in PDF form can be found at:

http://www.experiasphere.com/ExperiaSphereTutorial1Slides.zip (slides only)

http://www.experiasphere.com/ExperiaSphereTutorial1Annotated.zip (slides and notes)

This tutorial is not a light-hearted romp, and the slide decks aren’t small (37 slides).  I wanted to be sure to convey enough detail to permit a technical planner or architect to evaluate what I suggest and take a stab at laying out a project based on the architecture.  I can be a bit more explanatory in the video that will come next, at the expense of making it an hour and a half long, perhaps!

With this release, I’m moving all of the ExperiaSphere activity to the ExperiaSphere website and blog, and to the Google+ ExperiaSphere Community.  I’ll not be updating the LinkedIn Group further, so be sure you’re registered for the new Community.  I’ve also created an ExperiaSphere Insiders Community on Google+, for those who contact me and commit to actual implementation work.  Not to keep harping on this point, but I can’t support Q&A and clarifications on the approach in any form except posts in the ExperiaSphere Community, so please don’t send me emails with questions or ask for phone calls.  I will try to cooperate with the media, of course.

I’m asking everyone in the ExperiaSphere Community to obey common-sense rules about questions and postings.  Don’t post irrelevant information or something that’s self-serving without advancing the topic.  I don’t want to pull someone from the group or limit admissions, but we all need this forum to be open and useful at the same time, and if we have to sacrifice the former to get the later, so be it.

I’m starting on the four ExperiaSphere lifecycle presentations, and also preparing the audio for the YouTube version of the first tutorial.  I can’t promise exactly when any of this will come out but my goal is to have at least the slide decks (annotated and plain) for all the tutorials available by the end of August.  I look forward to working with those who are really interested through the Community.

Posted in Uncategorized | Comments Off on ExperiaSphere Tutorial One Slides Available!

Tuesday June 24 is the Release of the First Tutorial Slides

On Tuesday June 24th I’ll be releasing the first public tutorial on my ExperiaSphere universal open-source management and orchestration model. From the first, this activity has been aimed at defining a way to deploy and manage services made up of any combination of legacy technology, SDN, virtual network functions from NFV, and cloud application components. It’s also been a goal to integrate with any OSS, BSS, EMS, or NMS component, to support virtual functions and cloud components without modification or the use of specialized APIs, and above all to utilize open-source technology wherever possible.
Those who have followed my interest in the management and orchestration space know that there were two previous projects with goals that were substantially similar. The first, the original Java open-source ExperiaSphere project, was aimed at validating a model of service management where Java objects representing service features could be composed into applications that would then, through those objects, create services. This “Service Factory” approach was the source of much of my insight into service management, and it derived from work of the IPsphere Forum and the TMF’s NGOSS Contract and SDF activities.

Last year I launched a project to demonstrate that Network Functions Virtualization could be implemented in an open, multi-vendor, manner using these principles. CloudNFV was an implementation project involving a half-dozen vendors, and I served as its Chief Architect from the foundation through the end of January 2014. The project garnered a lot of press and won a TMF Catalyst award in Nice in June 2014, so it’s fair to ask how ExperiaSphere and CloudNFV are related.

To understand the technical differences between CloudNFV and ExperiaSphere we have to start with a technical commonality. Both were based on my “Structured Intelligence” and “Derived Operations” principles that were aimed at making service event handling and management totally virtual. The primary difference between the approaches at the ExperiaSphere technical level arise from the goal of supporting open-source elements, which was not a goal in CloudNFV. Because of the unique capabilities of EnterpriseWeb’s software, CloudNFV combined the service, resource, management, and process models into a single structure called “Active Virtualization”. Active Virtualization glued the work of a lot of other dedicated companies and people into “CloudNFV” and it’s been successfully demonstrated many times.

Operators told me loud and clear that they really wanted an open-source option. Since I could not identify an open-source equivalent to Active Virtualization, ExperiaSphere creates a virtualized service domain to which service lifecycle processes are linked, but it records management data, service variables, and lifecycle event-to-process and resource-to-service bindings in a Management Repository that is linked to but separate from the service modeling domain. Modeling and management are functionally unified but still explicitly separate, because that fits with how open-source tools have evolved. The rest of the goals of the two projects are congruent.

The way that virtual functions are deployed and managed is, from the perspective of the virtual functions themselves, the same for both approaches. VNFs in ExperiaSphere are resources just like devices or architected NMS services like VPNs. Their management interfaces are linked to proxies that populate the Repository with their data as the IETF’s i2aex recommendation describes. That Repository is then the source of information for query-based management proxies that can present aggregated and complex management views through whatever interface is convenient. Any virtual network function that could be deployed by ExperiaSphere could, with proper proxies, be deployed by CloudNFV and vice versa.

SDN and higher-level legacy network features (like “VPN” again) are represented in both architectures by “Service Models” that are presented to the service layer for functional orchestration and that are realized on resources through an Infrastructure Manager (in CloudNFV this was called a “Service Model Handler”). An IM can represent a Service Model “imported” from another provider, so the architecture is self-federating and that is also true for CloudNFV. Because the ExperiaSphere work has to support open source development and integration, the process of building service models and integrating Infrastructure Managers is defined in greater detail for ExperiaSphere, but CloudNFV could be made to work the same way.

There’s a non-technical difference between ExperiaSphere and CloudNFV, though. ExperiaSphere is an architecture or a model of open-source management and orchestration. CloudNFV is a project that sought to prove out these principles in an NFV context. It is an implementation, and ExperiaSphere is not, nor is it my intention to make it into one. The architecture I defined was contributed openly into the public domain for CloudNFV and so it is for ExperiaSphere. It will be up to those who believe that the ExperiaSphere model is useful to drive one or more projects from that model.

In just a few days the slide deck presentation on the overall ExperiaSphere approach will be available on the ExperiaSphere website. I hope everyone with interest in management and orchestration reviews it, and since the approach is open to all you can take whatever parts you like without attribution to me or to ExperiaSphere. I’ll try to answer questions on the approach through my Google+ ExperiaSphere Community (please don’t ask questions like “Can you explain the implementation in detail, taking three months or more?”) but I can’t take individual emails or calls on this unless you want to pay consulting fees.

There will be a video tutorial based on this same material, as soon as I can get it done. There will also be at least four and probably five more tutorials coming out between now and the end of August, based on the service lifecycle steps as a framework for a deeper dive, then looking into broad implementation and integration (time permitting). I designed ExperiaSphere to be open-source-ready, but you could do just parts of it in open source or do it all with completely proprietary tools. You could use a different service modeling and description approach than I’ve proposed and still be open-source, too. You may know of open-source elements I didn’t know about. All of this, I hope, will come out in Community discussions.

I’m going to moderate the community. I’ll accept useful posts but not spam or blatant and non-useful promotions. I’ll give offenders a chance, they remove them. We can make the Community work if everyone is reasonable. If I can’t make it work, then the only avenue I have to answer questions on this will disappear. We’re all in this together.


Posted in Uncategorized | Comments Off on Tuesday June 24 is the Release of the First Tutorial Slides

First Tutorial is In Production!

I’ve made a lot of progress with my ExperiaSphere open-source model for cloud, SDN, and NFV management and orchestration.  I’m finalizing the introductory material, which I’ll first share with a key source of insights within the next 10 days.  When I’ve accommodated any changes/suggestions from this final review, I’ll prepare the introductory video tutorial, which I’ll post on my YouTube channel when it’s available.

I had originally intended to use LinkedIn Groups as a means of coordinating questions on the model when the tutorials are published, but I’ve been having ongoing problems with sharing posts on LinkedIn, and so I’m moving my activity to Google+, where I have established an ExperiaSphere Community.  This is where I’ll be making announcements on the availability of videos and answering questions on the model, so if you are interested please join the community.  I’ll not be keeping the LinkedIn Groups active beyond the end of June, though I’ll sustain the groups to protect the name (which is Trademarked by CIMI Corp).

What’s being planned in the way of video tutorials?  Well, my current plan is to do a primary introductory video that will explain the model at a high level.  This will be followed by a series of videos that will cover the details in the form of a walk through an ExperiaSphere-modeled Service Lifecycle Management process.  The steps to be covered in these tutorials are:

  • Component and Resource Architecting: Defining Basic Service Components and Onboarding Functions and Resources
  • Service Architecture: Building Services from Components
  • Service Brokerage: Ordering and Instantiating Services
  • Service Management: Responding to Changes and Events

I’ll also be providing a tutorial on Creating the Glue for the ExperiaSphere Model, which will cover how to develop the connecting logic needed to link the open-source tools and create the models needed to orchestrate and manage services.

These tutorial videos will range from 45 minutes to 90 minutes depending on the topic, and I’ll also be providing PDFs of the annotated slide decks, both on the ExperiaSphere website and on SlideShare.

Please note that the ExperiaSphere model is open and released to the public without restriction, so anyone can implement the model.  The material will be freely distributable in its original form with copyrights intact.  If you want to use the term “ExperiaSphere” to refer to the activity, you must assert the trademark:  ExperiaSphere™ and say that the term is a Trademark of CIMI Corporation.  If you want to assert that you have an ExperiaSphere-compliant implementation, we’ll review your material and provide you permission and logo artwork to use.  This is only required to use the term; you can use the design concept freely without attribution.

I know this has taken some time to mature, but I want to promise that the concept when it’s available will be just what I’ve said it would be, and presented at a greater level of detail than is available for any other management/orchestration approach.  Be patient just a little longer, and thanks for your interest!


Tom Nolle

Posted in Uncategorized | Comments Off on First Tutorial is In Production!

More Details and Refined Status for the ExperiaSphere Project!

I’m trying to provide regular updates on the ExperiaSphere activity without giving you old news or nothing useful.  Hopefully today I have something that avoids these traps!

I’ve determined that the best way to explain ExperiaSphere is to start with a multi-plane vision of services and applications.  The top plane of this, which I’ll call the Service Domain describes the logical structure of a service, experience, or application.  This is related first to what it is, second to how it works in a functional sense, and finally how it can be described as deployable functions.  The bottom plane is the Resource Domain where the real stuff lives—including servers, storage, network equipment, legacy stuff, SDN, and so forth.  The resource domain is a lot of things because there are a lot of old and evolving things that live, will live, even have to live in this space.  It’s a classic moving target or collections of silos so potentially vast that it might look like the Farm Belt from the air.

ExperiaSphere’s goal is to accommodate anything that can be considered a service or a resource, period.  Further, the goal is to accommodate and not to make the other stuff do the accommodating.  Nothing has to change, not cloud or NFV components, not SDN or legacy technology.  The benefits of the network of the future can’t be achieved by limiting how you get there or by making early transitional phases totally unprofitable.  So we accommodate, and we start with a mechanism for defining services and applications that’s totally flexible, creating the Service Domain.

Service Domain functions are represented by objects, which I’ve called the process of structured intelligence because the service domain is about how to structure the intelligence, the logical or functional pieces.  If we’re going to deploy one of these objects we have to be able to map it to something in that vast chaotic world of resources.  We have to bridge these domains.

We actually have to bridge them twice, because there are really two binding issues between the two.  One is the deployment process, the linkage of service object to resources.  The other is the ongoing lifecycle management.  From the very first days of the open-source project that launched ExperiaSphere, we represented these two layers, imposed strict separation, and mandated explicit binding between the two.  One aspect of that binding was a dynamic data model that was built when a service was deployed and sustained as a kind of contractual record of the service.  This works nicely for services built as Java applications, but not so well for something built through a more agile service-architect process set.

The ExperiaSphere model, rather than build two bridges, builds a functional double-decker.  We have an Infrastructure Manager or IM that bridges both the deployment and management functions.  Whatever technology might live down in our resource-domain land of silos, there can be an IM designed to create the deployment and management bridges.  You can deploy any service object (a component of a service, application, experience, or whatever) and manage it on an ongoing basis by having the appropriate IM for it.  Anything that can support an IM, then, can be used as a resource.

Both services and resources have models, and I’m proposing to use the same open standards and open-source tools to describe both domains.  The principles applied in the modeling are consistent with the TMF’s operations structure (GB922) but ExperiaSphere does not use the TMF model explicitly for either services or resources.  I’d rather use an open standard to get open-source support.  It’s possible to map between the TMF model and ExperiaSphere but this is to me an “Adapter” function and it’s beyond the scope of the project.

The Service Domain in ExperiaSphere is a domain of functional models, and the Resource Domain a domain of real stuff.  To get all the siloed possibilities in the latter under some sort of control, ExperiaSphere proposes an i2aex-like repository that will hold not only all of the “primary MIB data” that real resources generate, but also all of the derivations or restatements of primary data that describe the management properties of the service objects.  Why?  Because these objects are virtual devices and we need to be able to make them appear in the most convenient and manageable way.  I called this part “Derived Operations” and it’s the second pillar of ExperiaSphere execution.

Operations processes have to be integrated too, of course.  Every functional Service Domain element defines state/event relationships that will map to the service lifecycle.  For each intersection we define a process link, and that process is treated as a Resource and supported by an Infrastructure Manager (see below).  That allows ExperiaSphere to bind any current or future operations or management task to the lifecycle process, which means that operations at all levels can be integrated with the Service and Resource Domains.  Even cloud applications can be represented as services, decomposed into deployable units, and then lifecycle managed.  Scale-in and –out and other new cloud-driven resilience and performance enhancements are, to ExperiaSphere, secure lifecycle elements and not the responsibility of the applications or functions.  And anything that runs on a platform that can be modeled as a Resource can be deployed and managed.

Our open-source mission here can be viewed in this light.  We need a set of open-source tools that will let us build that functional-symbolism-laden Service Domain.  We need a set of open-source tools that will let us build that great and agile management repository.  The former will obviously have to be a combination of what we could call descriptive/parametric processes and the latter a generic database function surrounded by proxies that can populate and represent it.  The good news is that I’m fairly sure at this point that I can identify what makes up both of these layers, what open-source pieces lie on both banks of the ExperiaSphere stream.  For the Service Domain I can identify tools and even implementations close enough to my own that there’s validation in the real world.  I’m working through the details of exactly how these two layers can work in open-source, and I think I’ll have the answers within a month.  Then it’s a matter of putting together a set of videos to describe them.

The bridge, the Infrastructure Manager, is where most of the variability comes in.  I’m going to propose a standard model for representing the linkage between the layers so that it can adapt to any software component/API.  That means that the Service Domain can speak a single language looking south to the resources.  What will have to be done is to create the shim (which in software is often called an Adapter Design Pattern) to translate this common language to each of those silos, or at least those that a given implementation is prepared to support.  Where there are open-source tools to facilitate this, including OpenStack or OpenDaylight, the shim can link to the existing tool/API set and that will generalize support for anything that the selected tool can support on its own southern border.  I can’t bridge a gap to so diverse a set of resource options as we have already with a single strategy, and no single open-source element does everything needed without at least a bit of customization.  I’m going to go as far as I can, then define what needs to be done to glue the assembly together.

In total, I think that 15% to 20% of an ExperiaSphere implementation could be done using off-the-shelf open-source tools.  The rest will be customization, largely in the area of the IM and the mapping between operations and management processes and the state/event structures that define lifecycle processes for the Service objects.  Existing structural models for things like SDN and the cloud, including OpenDaylight and OpenStack, could be integrated under an IM without anything more than the stub I’ve described.

So this is where we are.  I’m working on the detailed tutorial material, and I expect that it will start with a high-level picture and then divide into additional videos to deliver the details of the Service Domain, the Resource Doman and Derived Operations, the Infrastructure Manager, and a final one applying all this to a model service lifecycle.  The material will obviously take time and it may stretch even into September to get the last of it up.  By August, though, you’ll have enough of the picture to see what open-source software can do for the modern age of virtualization.

Posted in Uncategorized | Comments Off on More Details and Refined Status for the ExperiaSphere Project!