We’ve all hearing stories about Cloud based services and how they’re going to change the way we live and work. If you manage services in a large firm you’re probably hearing little snippets here and there about Cloud projects that are already underway at your firm. But what does it mean for you? Just why does the cloud matter? Well, one reason it matters, not surprisingly, is cost. If you use the Cloud selectively, there is probably at least one service that can be provided more effectively by a Cloud provider (with a much large client base, and therefore a lower cost per user). There are issues and problems, but there are also clear advantages in buying services from whoever has the best solution deployed to the largest number of users. To understand this, let’s go back, Back, BACK in time to the very beginning.. the early 80’s.
For the last 20 or 30 years there has been a bit of corporate, well, hubris. By the early 80’s big firms became REALLY BIG and technology was became easier to use and much cheaper; big firms believed that they could build or run pretty much anything. Every Clark Kent was no Superman… all-powerful and invincible! Firms that sent a lot of work to printers created internal copy centers that used the new computerized/plain paper technology. Internal travel agencies were created, especially after computer based airfare booking systems became available. PC’s were suddenly everywhere, and the cost of computer processing plummeted. It was only natural that these firms would write their own word processing software, email systems, CRM’s and other applications. Very big firms built their own private telephone networks, because they could afford it and they felt the security was needed. All sorts of new internal departments were developed. Big firms were not completely wrong; they could build these non-core services… but that didn’t mean that the services were very good or very cost-effective. For a while it looked like this massive insourcing was effective, because corporations often built their new services using new technology, and compared it to their previous providers using previous generation of technology. For example, corporations used photocopiers for printing services but old providers used offset printing (and other technologies). It’s not completely straightforward, but as time went on it because clearer that just because you can build a service it doesn’t mean you should.
By the early 90’s it was becoming very clear that internally developed word processors, email systems and CRM’s couldn’t keep up with commercially developed systems. Now, big firms switched to buying externally but supporting internally. Funny thing is, the products that continued to be developed internally devoted a lot of resources to non-value added features (color of a screen, placement of a button on a page, etc.) driven by powerful users, but commercial products devoted resources to value added features (better interface, faster processing, etc.) driven by the majority of users. Commercial products and services increased their lead. Then the Internet hit, and small firms had access to the same (or equivalent) services that only large firms had. Which led to the next generation of services. While 30 years ago the big firms could say they had to build services that didn’t exist or that weren’t right for their needs. Today it’s hard to ignore all of the publicly available services that can compete with internally developed services. Many of which have a lot of advantages, better price points, and are evolving more quickly than internally developed services. You can especially see this with the smaller services that are provided by the big firms.
For example, a few years ago almost every big firm developed video conferencing systems. Today, free Cloud services are often more feature rich and reliable. And they’re getting better very quickly. There often isn’t enough use of these services to justify a fully staffed support team, which leads to low quality support (with poor user feedback) and high cost per service provided. These are obvious candidates for migration to a cloud-based specialty service. However, if that is the starting point for migration, is there an end point? For every firm this is going to be different, but the answer lies with an earlier discussion about core functions. If the function is not a core function, and you don’t do it very well (compared to a publicly available service), why do you want to perform it internally? The answer to that question probably defines the upper limit of the Cloud, beyond which services should stay internal. It can definitely be complicated. Tomorrow we’re going to pick up this same theme and look at today’s practical uses for the Cloud. But for now… that’s my Niccolls worth!