In 1901 Guglielmo Marconi oversaw the first successful transatlantic radio transmission from Poldhu station in Cornwall. It ushered in a century dominated by broadcasting; from radio to television to color, teletext, VCRs, cable, satellite and digital. Broadcasting was at the cutting edge of entertainment technology.

Technical progression in this era was logical, and its value was self-evident. During most of the 20th century there was never a doubt that the world would want the latest developments TV and radio had to offer. But by the turn of the millennium, things had started to change. The market was starting to question the demand for yet more channels, and in the background momentum was building around something called the internet. A nascent online radio scene had appeared, and the emergence of file sharing platforms blindsided multiple industries, leading to a realization that the computing revolution was not only bringing radical technical developments, but a profound acceleration from the steady pace of evolutionary change we’d all become accustomed to.

Enter then the cloud, a wholly inadequate word for the global commoditization of computing infrastructure that it represents. Many of us think of cloud as referring to the large public cloud hyperscalers and their smaller competitors, or as software-as-a-service (SaaS) offerings like Office 365 or Salesforce. Sometimes it’s applied to on-premise installations in the form of “private” cloud. But the value of any piece of technology doesn’t lie within the technicalities of what it’s made from, but in what it does for us. A toaster isn’t defined by the specific electrical and mechanical components that lie within it, it’s any machine that can turn bread products into toast.

Automation

So what does cloud really do for us? I like to describe cloud as “Computing infrastructure dynamically defined and controlled by software”. The point is not what technical bits are involved, or who owns which of them, but that we can dynamically define and manage them all with automation. The dynamic part is important, because the automation can respond to our need for specific technical resources at particular times, and, by architecting the software for failure, can respond to faults and failures within the systems we’re controlling.

Automation offers us two key advantages; effort reduction and consistency. Whilst effort reduction has an obvious productivity benefit, consistency, in the form of repeatability, provides a longer term bonus by reducing risk and technical debt. The ability to re-deploy a “known good” infrastructure perfectly in minutes can dramatically reduce recovery time from incidents.

The Key Areas

The first key area where automation can be transformational is with testing. This includes not only testing of new deployments, but regression testing following changes or upgrades. Testing is an essential part of any project, but can be time and effort intensive, which tends to lead to compromises that increase risk. By applying automation to testing, with its speed and consistency, we can not only avoid a considerable amount of effort, we can radically accelerate our deployment and upgrade processes, whilst at the same time reducing their risk. Modern test automation tools have become very sophisticated and can include user interface responses, security checks and much more.

Unlike most traditional test environments, an automated cloud test deployment can be an exact replica of the production components, instantiated perfectly and configured cleanly every time for every test, and if needed, multiple tests can be conducted in parallel at the same time because there’s no dependence on specific infrastructure. Not only that, but all this unlocks a virtuous cycle allowing us the confidence to upgrade more frequently. Suddenly a small change that would delight a customer can be deployed in days rather than months. And security patches can be applied risk-free in seconds.

Building on this, the second transformational area is around automating fulfilment. New installations typically follow a known template, like a playout or a media management system. With the traditional hardware procurement route, which can involve RFPs, contractual negotiations and lead times as well as installation, configuration and testing, the process can take many months. With automation and cloud however, it can be done in minutes. What’s more, this opens up previously unviable possibilities, such as deploying only for a short period, like the duration of a major sporting event, “deleting” the infrastructure afterwards. Various Disaster Recovery scenarios may also be suitable for this approach, avoiding the need to procure expensive infrastructure that rarely, if ever, gets used.

Our organizations tend to be structured around delivering traditional infrastructure, not software. They also tend to expend significant effort optimizing and refining repetitive human-driven tasks that could simply be automated in totality. Early forays into cloud often fail to achieve business goals because either those goals are unrealistic, or because those involved don’t understand what they are or don’t have the means to achieve them. Initiatives can easily be pushed too far down the hierarchy for the necessary wide-ranging changes to be possible.

Business Challenge

It’s critical then to recognize that we face not so much a technical challenge, but a business challenge. Asking the same organization to do the same things, but using cloud, doesn’t get you there. Leadership must make and communicate a clear decision to leverage cloud and automation, and evaluate what business areas are most suitable. All departments must be in scope for supporting new ways of working, including finance, HR, and project management. Changes to long-established practices will be needed. Reporting lines may need to change. New skills will be required, through both training and recruitment. Consultancies and outsourcers can certainly help, but they can’t be the whole approach. Other industries have been through this, and there’s a lot we can learn from them.

The biggest thing to embrace is a change of thinking; technology used to be about the art of the possible, we built things because we could and value would usually follow. But building technology for its own sake doesn’t work anymore; it’s essential to identify the customers or users expected to benefit from any initiative, and orient our thinking around their needs. The new reality with cloud is that the business must first define the value it seeks, with clear measures of success, then it must shape the organization to build software and automation that realizes and maximizes that value.

The task here is immense, and profoundly different from what’s come before. It’s hard to imagine the world of a young Marconi, tinkering with radio communications when such things would have seemed like witchcraft, tenaciously persuading authorities to invest in new technology that would upset the prevailing order of wired telegraphy, but his achievements have come to define our modern world. Nothing worth doing was ever going to be easy.