
Part 2: Why adopt managed services?
In this article we examine why managed services have grown in popularity and what makes them appropriate, or otherwise. Firstly we should make one thing clear. Outsourcing is not new; we have always done it.
- Third parties supply data
- Hardware manufacturers screw together servers
- Communications firm run cables to our building and handle our telephony switching requirements
- Datacenter providers house our servers
- Landlords own office space and ensure utility supplies
- Energy providers deliver reliable power to our facilities
- Consultancies provide specialised skillsets
- Administrators confirm the NAV of our funds
- Brokers match trades
- Custodians hold assets
- Exchanges intermediate transactions
- Clearers transfer funds between institutions
However, what has changed is the availability of options in terms of the services available and the talent to utilise them, particularly in the IT space and increasingly across aspects of the business we were previously forced to undertake ourselves. Nonetheless there remain elements of resistance to change. Resistance is derived from a lack of availability, understanding, and/or trust.
- There are many tiers to managed services but, for example, managed infrastructure provision is now broadly accepted for several well-founded reasons. There is a competitive marketplace (granted one in which there are a couple of dominant players). There are also niche requirements that were previously not available such as FPGA rental via Amazon EC2 F1 instances, and collocated servers in a datacenter of your choosing (or at least the exchange’s choosing), with low latency cross-connects. These factors illustrate a new maturity in the market. The mechanisms to appropriately leverage managed services have evolved. For example, there is now a greater availability of devops engineers capable of building services in cloud. So it’s easier to leverage those services.
- Understanding a technology involves a number of factors. There has to be sufficient talent and experience to leverage the service, and there has to be an understanding of the impact it will make on the purchaser’s business. There is now a broader appreciation of the risks associated with outsourcing so the purchasers of managed services have become better at assessing the associated risks. We have extrapolated out from our assessments of datacenter and networking providers to quantify and qualify the degree of risk. There are grandfathered exposures to subordinate service providers. Your SLAs are dependent on a hierarchy of other service providers, and the weakest SLA has to be inherited by all services above it. Similarly buying a managed service means that you generally give up the right to make granular changes to the levels of support staffing; the support levels provided are contractually defined rather than defined by the number and quality of staff you have hired yourself. Some seasoned professionals come from a background where they owned and installed the entire stack from server installation upwards and only felt comfortable with resilience if they were able to personally vouch for each tier of the stack. Notwithstanding the fallacy of their assertion, they never owned power generation or networking for example, the “tin-strokers” are leaving the marketplace either because they are dying off or being forcibly removed due to the industry’s overarching direction of travel.
- Finally, if we align the demonstrable track records of a managed service provider with acceptable, mature SLAs, and the increased capabilities of purchasers to assert the appropriateness of the service and to understand and mitigate the risks of contracting the service then we reach a point of trust.
The less abstract, and more technology-focused categories of managed service are perhaps easier to accept because they deal with more tangible assets or measurable services. As we move away from technology we deal less with “stuff” and more with people and processes, and the services becomes harder (or at least more nuanced) to measure and more emotive.
Regulation
At present there is no direct regulation of managed service providers across financial services. Nonetheless the EU’s Digital Operational Resilience Act (DORA) and the proposed UK response to it that was referred to in a recent Queen’s speech suggest things will change and the trust requirement will be formalised. DORA has been agreed by the European Parliament and Council of Ministers so seems destined to be implemented across Europe. Furthermore it seems unlikely that Europe will bring in legislation of this nature with no response in the UK. This means we are going to have a degree of formalisation and oversight in that trust relationship. This is no bad thing provided it is well-founded and considered. When boundaries are codified the intention is that they are clarified, and with clarification and transparency comes trust.
Regulation can also be a driver for the use of managed services. A provider operating within a specific jurisdiction is likely to have experience dealing with local regulation that can be leveraged. It is worth remembering however that in most cases the responsibility for compliance remains with you the client rather than the service provider.
Some Benefits
Different categories in the taxonomy we stated earlier offer different benefits but aggregating across all the categories they variously include:
- Improved time to market
- Replacing capex costs with opex
- Key person dependency mitigation (operational risk reduction)
- Availability of SMEs
- Purchasing/delivery latency
- Outsourced hardware life cycling
- Simplified proximity hosting
- Leveraged local legal and regulatory expertise
- Reduced procurement, legal and staff management effort
- Reduced delivery risk (assuming your service provider is over-provisioned)
- Consolidated vendor relationships
The consequence of many of these being that ancillary aspects of the service stack are removed enabling you to focus on alpha generation.
Some Risks
Adopting managed services involves swapping some risks since consolidating or outsourcing brings with it some increased or additional concerns:
- Concentrated contractual risk – this is classic counterparty default risk since you are at risk of a service provider failure.
- Reduced ability to force platform changes – you are dependent on your service provider to agree the change, undertake the work and schedule the change. This is no different to the dependency we have on third party software providers but may stretch across other aspects of the business.
- Outsourced dependence for regulatory compliance.
Where IaaS is concerned extended use will probably cost you more than self-hosting. You get the opportunity to tear down instances at will to reduce costs but running 24/7 means that your provider is not able to mutualise any downtime costs, meaning you are paying for their profit margin in totality.
Virtualised instances inherit the drawbacks of IaaS but add some further risks. Your provider may make changes to the underlying configuration of their instance. The more abstracted it becomes the greater the likelihood that more low level requirements you have will break. Consider the recent case of a firm that made extensive use of the aforementioned lightweight processes and found suddenly that the image they deployed on one occasion, and was still running, could not be redeployed. The reason was that the cloud vendor had, unannounced, changed the configuration of the underlying supporting service layer preventing one of the libraries he relied on from running. It would still run on a fat instance, but not on the lightweight instance. The cloud vendor had silently introduced a bug in restitching the binary image but since their SLA does not include notification of underlying platform changes the bug was introduced silently and required a significant degree of contingency workaround and subsequent investigation to unearth. Secondly, you can’t always choose your chipset, so if you make use of some manufacturer specific libraries you may not be able to leverage them. Worse still if you are running virtualised which is usually the case, the deployments may be non-deterministic, and you end up with a mixed bag of servers in terms of physical composition and server capacity. In the first case this may mean some aspects of your application may behave differently due to the underlying architectural differences of elements of your estate. In the second case you may experience non-deterministic runtimes – a fat tail on your risk compute for example, since you have carefully sized your task granularity based on a subtly different test infrastructure.
When you consider the higher tiers of outsourcing you should remember that you may be accepting layered third party vendor dependencies. You may grandfather in exposure to a vendor you know nothing about, be it a library vendor or cloud provider. You may think you have a multi cloud policy but that gets difficult to enforce if your service provider has a critical dependency on a particular facet of a subordinate supplier’s offering. Consider the case of a well-known SaaS CRM provider that uses a particular cloud provider. You now have exposure to that cloud provider and with the crown jewels of your client information. This example is very common.
In conclusion
We are seeing a growing maturity in the provider marketplace because:
- There is competition
- Providers have had time to build the experience to demonstrate competence and their capability to scale
- There is less resistance to managed services in general across the board due to:
- A better understanding of risks
- An inherited acceptance of managed services based on experiential evidence
- Credible track records of providers
Picture: To continue the DALL.E 2 generated theme, this one comes from the text “Computer hardware, computer software, and financial services all managed by someone else”. So it’s managed to get clear references to finance and IT in which is a step up on the “Part 1” attempt.