This issue was raised earlier today on Twitter by Mark Craddock:








To be honest, at first I didn’t really understand why Mark might be right (or not). What do we even mean by a “cloud brokerage team” and what are the arguments for and against one?

I’m certainly not in a position to answer the question, but I feel it’s important enough for me to unpack it here and now.

So what does cloud brokerage do? According to this GCN article, we are really talking about two separate (but related things):

  1. ‘an entity (person or organization) that provides intermediary-type services between a cloud consumer and multiple cloud providers….. akin to a stock broker or commodity broker, where an intermediary assists a customer [to] navigate through a complex environment of many options. A better name for this may be “cloud agent.” ‘
  2. “a new type of software that sits on top of cloud providers to abstract, simplify and map various cloud offerings to your environment. Cloud broker software assists organizations in creating solutions in the cloud, migrating solutions to the cloud and moving solutions between clouds.”

Option 2 here is quite intriguing to me and worth digging into a little (without going completely down the rabbit hole). It seems that there is a similarity to the sort of brokers that are used in (for example) desktop virtualisation environments. A desktop machine might have the capability to link to virtual machine images, virtual applications, or virtual storage of many different kinds through the use of broker software.

I don’t think this is what Mark meant: I think he was referring to the first interpretation. The example he quotes, JANET cloud services, exist to “help research and education institutions move to cloud and data centre services through guidance, collaborative purchasing power, and due diligence.” This manifests itself in a small set of services around the provision of a purchasing framework of assured suppliers, advice and consultancy, help with the financial analysis around cloud services, “due diligence” on common cloud services contracts, and shared data centre space.

Sounds helpful. The value of this is that it can guide Local Government IT departments (and others) through the transition to cloud services that seems inevitable over the coming years. It should result in fewer disasters, faster uptake of cloud services, reduced costs etc and so on.

On the other hand, there are those that think the cloud broker model is broken. That link is to a US-based article, and not everything translates, but the fundamental objections seem to be

  1. using a commercial brokerage would reduce transparency in the purchase of cloud services (not a problem if the brokerage is not commercial but subject to public transparency rules)
  2. Cloud services require a trusted partnership between an agency and its cloud service provider; a broker adds no value and gets in the way. Certainly this is ultimately true: the question is if local government has the expertise right now to make such a partnership.
  3. “…cloud broker concept represents a substantial change in how government agencies would procure cloud services.” This may be true in the US but in the UK the G-Cloud Cloudstore is already well-established.

When I look at the IT expertise available in my own organization I don’t doubt that we have the technical chops to find and implement cloud services. My own worries are mainly about things like security compliance, financial management (especially the switch from capital to revenue-dominant budgeting), application performance and single sign-on.

Could a brokerage service help others solve these problems? Almost certainly.

How much value would it add? I don’t know. What do others think?