Broadcast engineers, powerless to help, stand by staring at blue screens. The last update from IT is we’ll make it in time for live at 9, probably, maybe, but there won’t be time to test, and this is why we asked for a functional sandbox environment, and go away please.
Everyone’s been there. What was meant to be a routine upgrade has turned into a 3-day project complete with consultants, overtime, broken workflows and murderous end users.
The old paradigm of versioned software deployed by end customers to their own installations has created a deep-seated and often fully justified fear of upgrading any enterprise software to newer versions. With workflows as complex as those needed in a media production facility - and especially one dealing with the incredible pressure of live video production - there is little appetite to take on the risk of upgrading except when forced to by external factors. After all, the software still works! It does what we installed it for 2 years ago!
Unfortunately, the logic of “it still does what we bought it for” means forgoing the entire advantage of software - that it develops. It means ignoring the fact that there is an army of brilliant developers out there working everyday to make improvements, large and small, that can revolutionise the way you work, save you money, make you more efficient, and make your output higher quality. You stagnate, and so does your product.
Ditch the drama, dig the delivery
One of the greatest advantages - and perhaps one of the least promoted ones – to true, cloud-native SaaS solutions is continuous deployment. In a nutshell, continuous deployment takes the risk and work of upgrading out of the hands of end customers and places it where it belongs - with the developers creating the software. Individual improvements, large and small, are introduced into the software continuously, with no disruption to usage and no interruption of uptime. We are not talking about quarterly releases; but monthly, weekly, sometimes even daily.
Think of it this way; if Google decides to change the order or colour of buttons in Google Docs or if Microsoft 365 add a new formatting function, the only thing you might notice is the change in functionality itself - and even that will only be flagged to you in a discreet, non intrusive manner. There is no downtime, no disruption, no risk.
More utility, less futility
To achieve continuous delivery, the architecture of SaaS software is engineered to ensure code changes are released directly to the production environment once they are tested - mainly through a regime of automated testing. Once such a series of tests have been passed by a new snippet of code, since all deployment work is the responsibility of the developer, that new feature is pushed directly to the end users.
This comes with a number of advantages for both software end-users and other supporting stakeholders such as IT and engineering. For the end user this means
- No downtime means no downtime, and there is no need to plan work outages and workarounds
- There is no risk of falling behind competitors because you are working with old fashioned software solutions, outdated in the every-faster arms race of research and development.
- Incremental improvements are easier and faster to integrate into existing workflows - rather than a host of changes making the software unrecognisable, requiring re-training, re-planning and re-thinking large chunks of workflow.
- Rapid responses to customer feedback - where new features and bug fixes are implemented and tested faster - because the effort and risk of doing so is lower also for the developer.
- More targeted development - when each feature, fix or change is individually implemented and evaluated, it becomes less tempting for developers to hide away hundreds of nice to have upgrades, and focus on what the customer wants most.
At the same time, for the supporting functions such as IT and engineering at businesses investing in SaaS solutions, there are a number of real-impact advantages including
- No version control. With literally always being on the latest version, a continuously delivered solution removes the need to care for which version is deployed to which hardware - globally.
- Automatic license control. True SaaS solutions by their very nature must incorporate a mechanism to manage and control the licensing of the software and usage of it - and the responsibility for this will fall mainly on the developer.
- Happier end users. With no downtime for upgrade, no downtime for testing, no disrupted workflows, no department-wide training programmes to understand new software, and at the same time continuous access to the very latest updates to their most important tools, end users tend to be happier.
- Less work. Resources do not need to be dedicated to upgrade projects, to executing upgrades and to hand-holding superusers through such a process.
- Risk reduction. The risk of upgrading the software is borne by the developer - and since they are affecting all of their customers at the same time with the deployment of new software, it is reasonable and logical to expect a very high level of efficiency and diligence in this work - work the developer is incentivized to do extremely well.
- More secure. Any security risks discovered in software can be quickly remedied by the developer and a fix delivered to all global customers, obviating the need for workarounds.
- With all customers running on a single version worldwide forces the developer to work with backwards compatibility and compliance in mind - there is no space to break what already works.
Strength of cloud
Flexible, efficient, agile, integrated, seamless, etc etc etc. All of these and more are true of the advantages that come with a well-built, cloud native SaaS software solution, but they have all nigh-on lost their meaning thanks in no small part to the technology marketers of the world.
So let’s focus instead on simple facts. Does it make sense to disrupt users in their job of creating content and by extension creating revenue? Does it make sense to force them to work with outdated versions lacking in key features? Should you introduce security risk by operating on old software? Should your IT and engineering teams be seen as enemies of efficiency and productivity when they roll into town with painful upgrade projects? Is it better to needlessly slow down production retraining staff on new versions because it’s been two years since the last one?
Probably not.
Upgrades are stupid. Always being upgraded is smart.
Do you want to learn more about how SaaS based asset management and newsroom tools can transform how you work? Please get in touch with us.
