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

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

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

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

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

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

We Are Almost There!

And so it goes on!  I have additional progress to report on the open-source-friendly ExperiaSphere model for management and orchestration for SDN, NFV, and the cloud.  I’ve completed my preliminary webinar series with major stakeholders in the operator and standards space, and it’s taught me a lot.

One thing it’s taught me is that explaining this on a webinar, even at a high level, is very difficult.  We’ve typically needed a hour and a half to simply introduce the model and to map it to open-source elements at a very high level.  My detailed slide deck, what I’ve been using to develop a complete explanation to the level needed to drive implementation, is already north of 70 slides, more than double the size of the high-level deck that took an hour and a half.  You can do the math.

What this means is that I am not going to schedule further webinars on the model.  It’s simply not going to be possible to make them truly valuable.  Instead what I plan  to do is to work harder on a series of public tutorial videos and slide decks.  I’m still planning to be able to release these in late July or early August, because the time I save in not doing other webinars can be directed at building the greater level of content detail I now know I’ll need.  Please check this blog, my LinkedIn Group (ExperiaSphere), my Google+ Channel (TomNolle) for information on when the videos will be available.  The good news is that you can play, stop, and start a video as many times as needed.  Large-audience webinars clearly will not work.

I’ve also been able to assemble enough information to do the critical mappings between the model and open-source tools.  In many cases I’ve identified alternate approaches that could be explored for situations where cost-benefit optimization is essential.  Let me go through the major areas to summarize.

In the critical central service data model, I’ve defined the structure of a service as a hierarchical collection of subordinate components that build downward to the actual resources.  I’ve determined how this model can be specified and how it is linked to deployment and lifecycle management.  While the approach I’m proposing is very “cloud-like”, it is also compatible with SDN and even with legacy elements.

I’ve identified how to extend the NFV IGS’s notion of a “Virtual Infrastructure Manager” to support any link between a functional vision of a service and the corresponding structural representation of components.  My “Infrastructure Manager” will codify both the deployment and management hand-off at the function/structure boundary, which means it identifies how you present and utilize all management data, including that for SDN.

In the management area, I’ve identified a management model that conforms to i2aex proxy repository principles and that provides for the collection of management data from all “real” sources and its dissemination in any logical, structured, form that’s required.  There are a number of enhancements to this area that seem to have potential, including the use of complex event processing (CEP) and big data.

The agile projection of management data is an element in lifecycle management and operations integration, but the other element is also provided in the model.  Service components at any level are finite-state machines that can define states and process events—some of which come from other components and some from underlying management repository processes.  The intersect of the state and event defines the lifecycle process to be run at that point, and so NMS, OSS/BSS, and other processes are integrated into a cohesive lifecycle vision through a common coupling at the service component level.

What my tutorial video is going to do is explain all of this in enough detail that a software team could then go out, get the identified open-source pieces, and integrate them into a structure for open management and orchestration that would work for any resource set that can be represented through one of my “Infrastructure Managers”.  I’m diddling different notions of how to structure multiple tutorials to avoid one of those “Gone With the Wind” endurance contests, viewing-wise.

I’m sure people will have questions on this stuff.  Those clients who want to do consulting on it can obviously do that, but for the rest what I’ll have to do is devise an economically reasonable way of answering inquiries.  What I’m doing there is using the LinkedIn ExperiaSphere main group.  If somebody posts questions or comments there, I’ll do my best to respond.  I’m not going to do phone or webinar work for this sort of support because I can’t absorb the loss of billable time.  Thus, if you are interested in getting questions answered on the model, you’ll need to join the group.  Nothing will be done there other than Q&A; nobody can post without moderation so there will be no spam or job offers.  I’ll post status and answer questions, and that’s that.

If you’ve indicated interest in one of the webinars that were to be done in June or July, I’m sorry to say they won’t be happening.  Not because I don’t want to, but because I know now from experience that the format won’t be enough.  I’ll be putting video tutorials up as soon as possible, and I’m pretty confident that it will be worth the wait.

Posted in Uncategorized | Comments Off

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!

Posted in Uncategorized | Comments Off

More on the Webinar and ExperiaSphere Q&A Process

We’re heading into our second round of briefings on the new ExperiaSphere model, and I want to let everyone know how the later rounds are going to work, as well as how I’m going to handle Q&A.  I want to start by reiterating that ExperiaSphere is not a project like my previous CloudNFV work—it’s not going to be an implementation with a consortium of vendors and formal contributions to this body and that.  I can’t spend the time on that sort of thing two years in a row!  This is an architecture and what I’m driving is purely information dissemination.  I want everyone to understand this new approach to operations, orchestration, and management, but I have to conserve the time I expend.

On June 9th, I’m scheduling another webinar on ExperiaSphere for network operators only.  The end of June or early July, I’ll schedule another for members of the ETSI NFV ISG, the ONF, and the TMF.  You’ll have to provide your name, company, and title to register for any of these webinars.  While there will be some opportunity for Q&A, I’m dedicating only 90 minutes to the sessions and so all questions will be taken at the end of the material, and with limitations on how many a given attendee can ask, to give everyone a chance.

In either late July or early August depending on my scheduling, I’ll be releasing the full model in an open public disclosure.  This release will be in the form of a slide deck that will also be put onto SlideShare, and a YouTube video for which I’ll provide a link.  Because of the number of people interested and the difficulty in setting a time for everyone, I’ve decided I have to do a video that can be played on demand.  Both these will be available on the ExperiaSphere website.

I can’t do phone calls on this or answer individual emails for Q&A because of the impact it would have on my business.  If you want special 1:1 presentations or personal input and suggestions, I can do it only as a normal consulting activity billed at the normal rate.  Beginning in mid-June, I can do company-private webinars for a fee as well.  Most support is going to be covered on LinkedIn, in the ExperiaSphere group.  I ask that any who are interested in the status of the project join the main group as soon as possible.  I’ve also set up two subgroups for detailed participation.  One is the Implementation Subgroup, which will be limited to those prepared to actually contribute to the project by undertaking some tasks.  Generally these will be related to the open-source components of ExperiaSphere.  The Insiders Subgroup is by invitation only so you’ll know you could be one when you get an invite!

This is an open architecture, contributed freely into the public domain for all to use and share.  You need not refer to your own implementation as “ExperiaSphere” but if you want to use the name and logo you’ll have to offer me a presentation deck on what you’re doing.  ExperiaSphere and “Think Outside the Bit” are Trademarks of CIMI Corporation, and so to use the term and logo you’ll need my license to apply it, which I’ll grant freely if what you do conforms to the architecture.  I want to be sure that anything that is called “ExperiaSphere” really works as I’m describing.

So that’s it for now.  Again, please join the ExperiaSphere LinkedIn group or at least connect with me on LinkedIn if you don’t follow this blog regularly, so you get the latest status.  Thanks again for your interest!

Posted in Uncategorized | Comments Off

Next Round of ExperiaSphere Webinars

Our first group of webinars on our ExperiaSphere open-source-driven approach to orchestration and management for the cloud, SDN, and NFV have been fully subscribed so please don’t send us any other applications.  We are scheduling our next round for the week of June 9th, with the current tentative date/time being June 9th at 10 AM Eastern Daylight Time.  The webinar will be scheduled for 90 minutes and content will reflect the feedback we’ve gotten from our first series and additional details on the architecture that have emerged.  This webinar will be open to network operators only.  We will do our first webinar for non-operators in July and it will target members of the NFV ISG, the ONF, and the TMF.  An open webinar will be held in late July or mid-August.  Contact our registration email (hangmeout@cimicorp.com) to register or inquire, or respond to me on LinkedIn (Tom Nolle).

Posted in Uncategorized | Comments Off