A new category of OSS?

People who are really serious about software should make their own hardware.”
Alan Kay
.

Something really intrigues me… In the not too distant future, assuming a majority of organisations are hosted on service provider infrastructure (ie XaaS) rather than running in-house infrastructure, does this imply the number of customers for hardware (compute/storage/networks) will significantly reduce? Service providers would obviously be major buyers, but who else do you envisage would be buyers of hardware?

The reason I ask is because I’m intrigued about the impact this question has on OSS as we currently know it. Does the customer base for traditional OSS (ie inventory, alarms, performance, etc) also shrink down to the service providers that buy the hardware? But in turn, this leaves an opening for a different type of OSS (ie managing apps, content, cloud infra management) to evolve to needs of the enterprise customer base.

The simplified diagram below demonstrates the concept with customer-facing (above the line of complexity abstraction) tools and SP-facing (below the line) tools:

The Service-Provider-facing (Below-the-line or BTL) OSS will increase in complexity because there are more layers to manage in a virtualised environment. I won’t get into that in today’s post, but will undoubtedly be discussing it in upcoming posts. You can also see more about this from an earlier post about the components of SDN, NFV, MANO and OSS.

The above the line (ATL) OSS (if OSS is even the right name for it) will need to provide a drag and drop interface that allows an organisation’s designers to easily add servers, storage, networks & connectivity, security devices, applications, etc. This interface will also allow the customer to see network diagrams, utilisation, service reliability against SLAs, events, order tracking status, etc.

Now you might be asking why the ATL OSS is not supplied as a portal by the service providers. Actually, that is one possibility. However, the major benefit of providing this as a third-party tool is to allow a customer to independently pick-and-choose-and-migrate capabilities/offerings from more than one service provider.

The customer-base for this type of tool is any organisation that relies on a communication network and/or hosted services (ie massively larger than the current pool of potential OSS customers).

At some point in the future, I’d expect that the customer-facing interface could be simplified to the point that almost anyone could build a technology environment to suit their organisation’s needs across multiple service providers, not just the IT/network gurus of today.

There are only three ways that this level of simplification can occur:

  1. The options within the underlying infrastructure / services have to be heavily simplified compared with the massive amount of configurability options offered today AND/OR
  2. The abstraction of complexity (as shown in the red box in the diagram) becomes an interfacing master-work AND/OR
  3. Managing the infrastructure cloud would need to be done using entirely different approaches than are used by current OSS (see more on this complexity here)

EDIT. The Cloud Portfolio Management platform offered by Rightscale has been brought to my attention by a colleague as an organisation that’s building out capability in this space.

Read the Passionate About OSS blog for more.

4 thoughts on “A new category of OSS?

  1. Ryan,

    Great article and think we should give it more thought in the various bodies and within the organizations potentially impacted by it.

    We had a workshop at one of our conferences on skills transformation and that fits right in there.

    Cheers,
    Thomas

  2. Thanks Thomas

    Yes, I’ve begun thinking of it as above the line (of complexity abstraction) tools and below the line tools. Whether the term OSS even applies to either of these categories is another interesting discussion. Perhaps OSS is relevant for below the line and some other term is used for ATL?

    I’ll be fascinated to see how the standards bodies and markets evolve with this rapidly changing world.

  3. Ryan,

    Thank you for sharing.

    I agree that OSS implementations will be more platform-based, if not already. The biggest consumers will eventually be the custom apps, in general, driven by business requirements.

    In a global multi-location / service provider scenario – service chaining between cloud, network and managed service providers to deliver a set of services to an enterprise customer – creates a level of sophistication and complexity due to different levels of maturity or capabilities between vendors.

    So support models need to evolve around horizontal ‘connectivity’ models and vertical app/infrastructure ‘capabilities’ – something your diagram can be extended to. This will be where 3rd party OSS can address the value gap.

    I’m not so sure if customers will eventually be migrating implementations between service providers as the capabilities & needs are unique in nature, addressing specific business challenges. One important area to explore will be how ‘app security templates’ in your OSS diagram can be developed to address data sovereignty & regulatory requirements (eg. helping the audit process) in a global hybrid multi-cloud environment.

    Hisham

  4. Hi Hisham,

    Thanks for the great insights and suggestions in your comment.
    The horizontal connectivity and vertical app/infrastructure model is a good one for improving the visualisation of concepts that I tried to present in the first draft of the diagram. Definitely food for thought!
    Great suggestion about covering security templates. That’s actually a topic for an upcoming blog entry.

    Rgds

Leave a Reply

Your email address will not be published. Required fields are marked *