“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:
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.
Are you about to embark on an OSS transformation? It’s a huge journey that awaits. It won’t be without risks and fears either. Like any
We recently discussed how the “Ultimate Game,” a study in behavioural psychology, might help to explain why there tends to be less initial animosity between
The great thing about the holiday period is you often get the chance to step away from business as usual (BAU) activities. As customer projects
Last year, we published a series of articles about the chasm that exists between OSS/BSS buyers and sellers. “The chasm” is best exemplified by the
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
4 Responses
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
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.
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
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