Moving to the cloud is not called a journey for nothing. Cloud journeys, like other transformations, comprise a never-ending bell curve of change.

So, while it may be tempting to crack open the champagne once you have migrated some initial services to the cloud and shift attention on the next item on the CIO’s ‘to do’ list, the job is far from over. This period simply marks the point at which the cloud journey veers off on a different tangent.

A business-driven transformation

Because moving to a cloud model is a business-driven transformation, not a technology-driven change in service supplier: the journey is essentially a chain of initiatives stretching out ahead of you, only the earliest of which can be clearly defined today.

Outsourcing is often a key driver for a move to the cloud. In these cases, the primary goal is to move services to external providers with specialist expertise who can deliver the services for a lower cost, while agility and flexibility remain collateral benefits. These migration activities can be readily encapsulated within a specific project, with the timescales, budgets and scope being agreed by all parties. 

In theory, going live using the new technologies/suppliers will mark the project conclusion, and present an opportunity to measure the value delivered, followed by the chance to celebrate accordingly.

Moving the cloud goalposts

The reality tends to be rather different.

During the early stages of a project, the team becomes increasingly aware of the agility, flexibility and modularity made possible by the cloud model, leading to an expansion of the original strategy. What seemed like a finite goal at the outset morphs into something bigger.

This can be attributed to awareness of the ‘art of the possible’ and a realisation that these characteristics can help the business keep pace with, or overtake, competitors. This explains why what starts as a migration project can, if care is not taken, grow arms and legs – and may ultimately become as unwieldy as an octopus.  

In just the last few years, virtualisation has evolved the physical allocation of hardware resources between operating system instances to be software-controlled and more modular as a result. Containerisation built on this, evolving from operating system instances to application environment instances, sharing binaries and software libraries. Cloud has utilised each stage of this evolution. We are now seeing: ‘containers as a service’, which moves traditional ‘infrastructure as a service’ closer to ‘platform as a service’ for consumers; and serverless computing, which is exploiting microservices architecture (itself an evolution of service-oriented architecture) to offer ‘software functions as a service’.

The beauty of the cloud model is that it can adapt. But organisations still need to retain control over any strategy change. This can be achieved most simply by sticking to the original drivers and benefit measures, while starting another initiative in parallel to address the new drivers.

While organisations will undoubtedly generate value with this syndicated approach to cloud adoption, more value can be more readily achieved by thinking further ahead and establishing at the outset a longer-term transformation plan.

Organisations taking this longer-term, more strategic approach will already have plans in place to deliver agility and flexibility within their operating model, and to exploit modularity in architectural and commercial management. That said, of course nobody can truly predict how cloud architectures will evolve beyond the next few years.

Opinions tend to be driven from two different perspectives: the software teams with their focus on cloud-native application development; and the infrastructure teams with their focus on platforms, virtualisation and containerisation. Whatever prevails, there is little doubt that these two perspectives are heading towards common ground.

Legacy looms large

But both face a significant and unavoidable enemy: supporting, and integrating with, legacy technologies. After all, new solutions have emerged over decades, and will continue to do so. Today’s innovation is tomorrow’s legacy.

The only sustainable strategy to tackle legacy is to do it head-on: in fact many organisations are finding they need to do this before cloud migration even becomes feasible. Next they need to put in place comprehensive and persistent technology lifecycle management practices. This is something that organisations will have less control over with cloud provision in any case, so becomes a prerequisite.

Switching suppliers

Even without legacy considerations, one of the key benefits of a cloud model is the flexibility in service provision. Many organisations that start out with an outsourcing agenda neglect the supplier switching option and inadvertently end up being locked into a vendor. This may be through dependence on specific technical features, by limiting staff skills, or by simply not considering any future desire to utilise another supplier (e.g. for improved service features, resilience or costs).

It goes without saying that building-in a multi-cloud strategy from the outset can avoid considerable pain in reverse engineering further down the line.

Cloud as a moving target

The extent to which organisations wish to invest in their own IT (and how they define what this means) versus using IT services from specialist providers, will continue to vary in different ways as the industry evolves. The same applies to cloud.

Cloud started as a means to support IT agility and modularity, but has become a reincarnation of outsourcing – and is rapidly becoming the next-generation platform for software development. As organisations exploit different benefits, they will need to adapt their business case measures and key performance indicators accordingly.

In an uncertain world, the only certainty is that evolution is here to stay, not just within cloud itself, but also in the ways in which we exploit the different potential benefits this presents. Enterprise cloud adoption is still at an early stage in what will be a long journey. Belt up for the long haul.

Editor's note: This is the final part of a three part series on exposing cloud myths. Read part one, on business continuity and DR, here, while part two, on digital transformation, can be found here.

Read almost any article on IT trends today and it’s likely that ‘digital’ and ‘digital transformation’ feature heavily. And yet there is confusion over what this actually means. It has been misappropriated by some, diluting everyone’s understanding. I have heard it used for anything from technology change to new application releases, or, even more cringeworthy, to describe any IT focused project.

The latest usage setting my teeth on edge are those IT transformation projects focused on cloud adoption that are being promoted as ‘digital transformations’.

We’ve seen this happen before, with terms such as ‘intelligence’, ‘knowledge management’ and ‘cloud' being misinterpreted by some. But the difference is that all of those terms have clear definitions laid down by industry bodies: for example, the National Institute for Standards and Technology (NIST) defined cloud a decade ago.

What is digital transformation?

The challenge with ‘digital’ lies in the lack of any clear industry definition.

Observationally, the term tends to be used in two distinct ways:

• The first relates to the use of IT for something, such as ‘digital application’, ‘digital banking’ or ‘digital journalism’. These work well in subject areas where IT and non-IT versions are both readily available, distinguishing one from the other. However, when it comes to IT-specific contexts, we can safely assume analogue computing is not being considered, so the term digital is effectively redundant.
• The second relates to an older use of the term and is perhaps more insightful. Since the dot-com boom companies have been shifting their primary customer interfaces to be more digital in nature, replacing face-to-face, phone and postal communications with web sites, mobile apps and text messages. This has more recently expanded from IT and internet-enablement to more cultural change, with the prevalence of social media, chat bots and big data analytics.

Digital transformation in practice

As IT-enabled customer interfaces become more prevalent, they serve as the most obvious basis for the use of the term ‘digital transformation’. 

Similarly, we’ve seen the emergence of the term ‘digital workspace’: applying IT to provide more flexibility and agility in the interfaces between an organisation and its employees, and making it possible to securely work from anywhere. The term ‘digital’ can clearly apply to these transformations in an organisation’s interfaces with its customers, employees, partners and suppliers.

These digital transformations are also moving deeper into the IT solution space in order to meet such user-centric requirements. For example, customers expect rapid change and personalisation to suit their needs. They will not tolerate performance failings from demand-supply gaps and expect direct access on their own terms.

Cloud as a driver for change

Given these challenges it is no great revelation that cloud models are the norm for digital transformations because they offer the agility, flexibility and modularity required. Indeed, many consider cloud as essential for digital transformation. But that does not mean any move to the cloud is a digital transformation.

Surprisingly though, it is perhaps the redundant use of the term 'digital transformation' that should apply here, to remind us that cloud adoption, although not necessarily fulfilling a digital agenda, is transformational in nature. 

Many organisations simply perceive cloud suppliers to be lower cost and have more concentrated expertise in the technology services involved. With such basic motivations, the organisation simply has a goal to outsource, rather than considering anything transformational.

Nonetheless, when organisations start looking at cloud from an outsourcing perspective, they soon recognise the benefits available i.e. agility, flexibility and self-service. But to take advantage of those benefits, a more transformational initiative is needed to address any functional bottlenecks that may exist within the organisation itself, rather than simply a programme of work to shift from one supply base to another.

Adopting a transformation mindset

This is most readily achieved by first taking the time to develop the strategy and business case – ensuring they reflect the appropriate strategic objectives and target benefits. Both may need to be revised to shift from an outsourcing mindset to a transformational one.

As well as incorporating the ROI measures, the cloud business case should cover the effort required to change operating models, for example:

• more modular designs and costing models;
• integration with, and flexibility around the choice of, service suppliers;
• the large shifts in operational focus and skillsets.

Last but not least, it’s important to ensure that enterprise-wide cloud migration initiatives have wholesale buy-in across the IT function, its suppliers and customers before embarking on any activity.

Defining a clearer future

Similar factors apply to digital transformations. Without confusing one with the other, IT must work closely and clearly with the business in both cases. Using a common and well-understood terminology is key. So, if we associate ‘cloud’ with transformation, and only use ‘digital’ for those initiatives dealing with the critical business interfaces, everything will become far clearer.

Editor’s note: This is the second in a three-part series exploring common cloud myths and misconceptions. You can read the first part, around disaster recovery and business continuity, here, while stay tuned to CloudTech for the final part in the series.

With all the hype about how cloud delivery brings new levels of flexibility and availability, many organisations may be falling for misleading reports claiming that moving to a cloud model somehow diminishes the need to worry about business continuity (BC) or disaster recovery (DR).

Nothing could be further from the truth.

Like the parody disaster movie Airplane, it would just take one thing to go wrong and you could find yourself in quite a pickle, but without any of the humour. And you will need more than an inflatable autopilot to get you back on course.

Some cloud providers have done a good job clarifying that responsibility for continuity and recovery in the supported IT service remains with the customer. Cloud providers do offer some help – for example, providing multiple availability zones – and organisations should, at the outset, consider this, as well as the benefits of a multi–vendor cloud strategy to reduce the risk of any critical services going down.

Three different areas are needed to address BC and DR: continuity planning to ensure the relevant events, risks and business impacts are represented in the solution requirements; recovery solutions that are well-designed, professional managed and inspire confidence through effective testing; and crisis management to escalate incidents through a clear process, up to DR invocation and beyond to repatriation to the primary/BAU state.

While continuity planning is clearly the responsibility of the business, rather than the IT function, it is still important for IT to ensure its service impact assessments cater for all relevant risks. Cloud service dependencies may need more analysis, as a number of low-criticality business services sharing the same infrastructure-as-a-service can incur a combined impact even greater than that from a single high-criticality service.

The role of the IT function – and particularly the IT incident desk – in crisis management is obvious and requires a close collaboration with the business. IT has to quickly recognise any underlying or growing crisis-level events and invoke the necessary action plans. Never underestimate the importance of executing the action plans in a controlled manner. A certain degree of panic is unavoidable in a crisis, severely limiting the ability to analyse situations and make the right decisions. Simple, broadly understood and well rehearsed action plans mitigate this risk.

Recovery solutions is the only area that falls clearly under IT’s remit. In this regard, it is also true that cloud suppliers are likely to manage technology platforms better than most of their customers – it is their core business after all — but these platforms are merely ingredients in the bigger solution.

While we may expect small platform resilience improvements after moving to the cloud, solution availability and recovery remain the responsibilities of the IT function. The benefits of using a cloud model can include the use of multiple availability zones, or even multiple suppliers, as well as the management and support of these platform components.

AWS, Google, Oracle and others have promoted availability zones for some time. Recognising the importance of this customer need, Microsoft recently announced it would follow suit. The growth of multi-cloud strategies also reflects the customer requirement for flexibility between suppliers, including protecting against any single vendor outage or issues.

Even when all this is taken into account, organisations must consider consolidated service impacts. Cloud providers’ SLAs will likely reflect minimal periods of downtime, but it is the organisation’s responsibility to address any repeated points of failure within the business impact analysis, such as multiple services relying on the same infrastructure provision service.

This becomes more critical as companies undergo digital transformation, leading to a growing number of business-critical applications becoming reliant on the same cloud services. Suddenly this minimal outage period is a major business headache.

IT’s domain extends beyond the data centre space and is increasingly responsible for workplace recovery through digital workspace 'work anywhere’ practices. Extending this further, a business function may misinterpret their adoption of software-as-a-service as being separate from the IT function. However, as with other shadow IT, management of the service wrapper and service inter-dependencies must remain the remit of the IT function.

While IT is accountable for recovery solutions, and partially responsible for crisis management, it is clear that it cannot own business recovery. It is down to the individual business functions to manage their working practices to support service continuity through to complete business recovery. Since IT cannot address this, cloud certainly cannot.

The SIAM effect

With DR, and particularly BC, we are reminded that impacts on people and process are at least as high risk as those from technology. This is where the service integration and management (SIAM) and operating models have to be updated with an eye on end-to-end service delivery and skills coverage.

When IT service layers are supported across multiple internal or external suppliers, it is vital that all incidents are clearly tracked and consistently managed end-to-end through a single SIAM function. This is critical for effective crisis management as well as being a cornerstone of successful cloud adoption.

In fact, unless it is managed well, cloud adoption can have a negative impact on the people and process, driven by the false view that cloud is simply another technology platform. For example, cloud adoption will involve a significant shift in the knowledge base and focus areas of the IT staff. The IT function must recognise how this impacts DR and BC solutions and ensure access to the expertise it needs, whether internally or externally.

Although cloud adoption should never be thought of as a solution to an organisation’s DR and BC challenges, it certainly can play a positive role. The combination of an effective SIAM model, an evolved cloud operating model, diligent IT service impact assessments and use of availability zones across multiple cloud suppliers, can help organisations ensure their business have the built-in resilience to survive any outages and disasters. If IT and the business work hand-in-hand on the planning and execution of DR and BC strategies, you can leave your inflatable autopilot at home.

Editor’s note: This is the first in a three-part series exploring common cloud myths and misconceptions. Stay tuned to CloudTech for the next instalment.

Only a fool believes that moving enterprise applications to the cloud is a panacea for the majority of the challenges facing today’s CIOs. Even cloud migration itself, like any IT project, presents a number of complex challenges. My favourite piece of advice is to think the same as you would if buying a house: don’t be impulsive. By taking the time to develop a clear focus at the outset, cloud buyers can eliminate unwanted costs and complications down the road. First and foremost, be clear around what you are looking for and why.

Updating the procurement function

The procurement department had a firm grip on IT purchasing until the advent of cloud. Now there is the risk that buying cloud services slips through the procurement net. Self-service applications mean that business line executives can whip out a credit card and pay for a small service themselves without involving procurement. But, just like a kid when in-app game purchases get out of control, at some point the bill might be too big to hide or the security too lax.

As with any IT change, the biggest challenges to a successful transition are generally cultural.  It’s not just the IT department and users that need to think differently when moving to the cloud. The procurement department also has to change well-engrained mindsets as it adjusts from dealing with products to services.

To transition from a Capex to a granular Opex model, the processes involved in purchasing and evaluating IT have to become more nimble. Without this, the procurement department becomes a bottleneck and the backlash will be a significant increase in shadow IT and shadow cloud.

Instead of negotiating with product providers every couple of years, the procurement team will have to adopt a new model that supports buying Opex services from more than one provider at a time. This means embracing a new level of agility, because cloud features and capacity change overnight.

Drivers for cloud

The first question to ask when someone requests a cloud service is: why? Only by understanding the key drivers at the outset – particularly when those factors are agility or cost – is it possible to choose the right model. This approach undoubtedly helps with negotiations and also makes it easy to switch providers if needed at a later date.

Defining cloud

Having a clear definition of what is meant by cloud within your organisation – and communicating this clearly to everyone inside the company and to your cloud provider(s) – is an important step. Then when your internal business customers talk about ‘cloud’ there are no misunderstandings.

Everyone within your firm should understand that it is an architectural and commercial model rather than simply a location – and that it does not mean any managed services or service delivered over the Internet.

Cloud repatriation and exit strategies

Cloud repatriation – moving workloads from the public cloud to a private cloud – is a growing trend. Even Dropbox, a company that started in the cloud, has now moved from the public cloud to its own data centres for faster performance and lower costs. Although security is one of the main drivers for repatriation, high profile cloud outages, greater control, cost, compliance and latency are all contributing factors.

Exit strategies are often neglected at the outset. But cloud buyers who don’t consider exit costs at the start of a relationship are missing a trick. Moving to a different provider – or repatriation – will require budget and time for recoding and retraining to get your staff up to speed.

Avoiding lock-in

One topic that is generating a lot of discussion right now is how to avoid cloud lock-in. A key reason for moving to the cloud is to gain greater flexibility. But this is stymied if your organisation takes advantage of a cloud provider’s set of compelling, but proprietary, add-on features and APIs without considering how you will manage without those features should you wish to change cloud provider down the line, or add a second cloud provider to the mix.

Balancing the need to avoid becoming too reliant on a provider’s proprietary features while at the same time making the most of what your chosen provider has to offer needs careful thought.

Cross-department collaboration

While DevOps and agile processes have transformed software development, buying cloud services require the business line, IT and procurement teams to work together in new ways. There is a need to collaborate on decisions and to ensure the work force has the right skills to benefit fully from the cloud.

Engaging early

As with any IT change, it is important to remember the users’ perspectives. This requires engaging with users early in the process to fully understand their needs; then at a later time educating them about the new service, particularly if it is self-service, and ensuring it continues to meet their needs over the long term. To do this effectively, many organisations engage third-party cloud expertise early on to transfer essential knowledge and innovation through lessons learned elsewhere.

You can’t manage what you can’t measure

We stressed the importance of being clear about what you are looking for and why at the start. The next step is to set up clear measurements and baselines to measure benefits. Only then is it possible to track improvements and evaluate the return-on-investment.

Despite all these notes of caution, don’t be disheartened. When it is well planned and executed, moving to the cloud is a beautiful thing to behold.  Be as prepared as a boy scout and you will reap the rewards.