As mentioned in a previous piece, it is critically important for an MSP to ensure that its services are adequately advertised to attract more customers. This can be through emails, paper-based adverts, or whatever, saying “this is what our service does.” However, this only takes things so far.
The problem is that automation and composite applications become more of the norm. For those wanting to replace hard-coded constraints with soft-coded constraints, linking together known services into a relatively unchanging process flow is one way of doing things. The more forward looking — and ultimately successful — companies will be looking for something quite different.
Where metadata comes in
At a very high level, metadata is the data associated with an entity that describes that entity. This can be seen with digital photos – they carry information such as what camera was used, what the focal length of the lens was, what the date and time was, and so on. This data is not visible when the photo is being viewed. It is carried with the photo file and can be interrogated by external systems as and when needed.
This is how MSP services also need to operate. First, there will need to be an organisation (or preferably, many organisations) that are looking for a specific service. Let’s assume that this is a simple function that deals with the clearance of funds between a customer and the organisation’s online retail store. The organisation has already been using a service, but they are unhappy with it, as it doesn’t seem to be dealing with the volume of customer traffic.
The organisation will probably have carried out a degree of off- and online due diligence. With a bit of luck, it will have placed your service on its short list. However, it still has to decide if you can deal with the traffic volumes. They ask you, and the response is ‘of course.’ However, this is the same response that they had from their previous provider.
It then comes down to a show-and-tell. You need to create an environment that reflects the organisation’s and demonstrate that your service can meet the synthetic traffic workload that the organisation says it has.
A better situation for MSPs
That’s quite a high cost of sale, though. MSPs are far more effective where they don’t need large pre-sales technical teams on the ground. It is far better to give prospects guaranteed service level information easily at hand.
So, put it in your service catalogue as metadata. Allow prospects to interrogate that service catalogue by type of function — and to further refine that search by whatever criteria are most important to them.
For example, being able to say “I need a customer funds clearance capability” is one thing. Refining this to “I need a customer funds clearing capability that can deal with 1,000 transactions per hour at a cost of no more than 1 cent per transaction” is quite another.
Within a service catalogue, this should be easy, but it shouldn’t stop there. If the service catalogue is deeply integrated into the platform, then it becomes a part of customer self-service. The prospect can interrogate the service catalogue with a script that lays out its needs. Providing that a response comes back that is positive, the prospect can then automate the provisioning and integration of that service into its own composite application, becoming a customer.
This creates further opportunities
For example, some MSPs may want to make a play for low-end, cheap services as a second supplier, taking non-peak time workloads away from higher-priced MSPs, or offering banded service costs depending on what the actual real-time requirements are.
Unfortunately, we still can’t do all of this in the most efficient and automated manner. Apart from a very few instances (such as in the automotive supply chain), the use of standardised metadata requests has not been a big thing.
Sure, some systems have built up their own ecosystem using proprietary metadata constructs, but for the multi-cloud hybrid platform to work at the highest level, such capabilities must start to feed through into cloud-based service catalogues. It will also be dependent on support from orchestration systems. Organisations that are using DevOps and AI Ops systems will need to be able to count on these systems being able to create and manage the metadata calls and responses that real-time composite applications need.
As an MSP, I recommend that you start looking at the sort of metadata that would make sense for your services. Encode this in any format that is open enough to be interrogated by a simple standardised method, such as ODBC or XTML.
This is a good first step, and as the market comes around to the acceptance that such metadata is important, you will be well placed to migrate that metadata to whatever actual standards have been agreed in the market.
Far better than waiting to see what happens and then having to catch up by creating the metadata from scratch.
Photo: Brian A Jackson / Shutterstock
