Cloud Operating Model

I stopped the other day to think about something that someone in the office said about a customer project after a good 3 months of work. It made me sit up and wonder what constitutes obsolete software these days. Before the cloud we could go years before upgrading to something new. I remember in the

This is a really key part of the cloud operating model; writing one set of approaches to technology that permeate the business and spread their benefits across all divisions. We've just started work on formalising this part of the Cloud Operating Model, here's a sneak peak: More coming on this soon

We've been thinking hard about how to classify data beyond the typical "On the Move"/"At Rest" definitions. We have divided the domains into areas of control independent of the physical storage mechanisms, which in the cloud may be abstract and nebulous concepts.

As people on the technical side of Big Data, building pipelines to ingest and process large amounts of data, we often find ourselves building distributed, loosely coupled software solutions. We use queues, Event Hubs, Hadoop and Service Fabric clusters, and large data stores like Data Warehouse.

We've been working to define the fundamental driver for using a Cloud Operating Model against a Cloud Strategy. Feedback as always welcome here .

There are many reasons that a Cloud Strategy may be adopted in business. Existing IT estates may be showing their age, new challenges may be emergent due to changing customer behaviour or competitors may be moving forwards gaining a competitive advantage that you seek to match. Whatever the root imp