Keeping pace with innovation in IT and security

To initiate change, organisations must currently overcome a range of technical barriers, but this may be offset over time by the growing importance of non-technical factors in technology procurement.

The ongoing transition from on-premises infrastructure to the cloud, to modern-architected web-based applications and API-based services, is driving organisations to take stock of past technology choices. 

Nowhere is this more apparent than in security. Existing security tooling is often not well-suited to applications that are cloud-, web- and API-based. 

That is driving an important discussion around when is the right time to move or change technologies. 

Unfortunately, even if the right time is 'now' or 'imminently' - say, within the next 12 months, aligned with system upgrades or operational changes - 'agents of change' within organisations often come up against barriers that can slow or derail change.

Resistance to change is nothing new, of course. But the business world is meant to be much more adaptable to and accepting of change than it was a few years ago. It's only when organisations test this out that they may encounter barriers.

Understanding these potential barriers allows organisations to effectively counter them ahead of time in their planning for change. 

In addition, in the mid-to-longer term, the effect of these barriers may be counteracted or offset to a degree by emerging requirements placed on suppliers of technology systems and services. This could ultimately make the job of 'agents of change' simpler

Busting the tech barriers to change

Technical barriers are often placed in front of existing systems that make change - and switching these systems out - appear more difficult than it actually is.

One of those barriers is industry folklore. We've all heard tales like the Twitter 'load-bearing Mac Mini', where a system whose origins are lost in the mists of time becomes practically untouchable because no one's sure what it does or wants to be the one who switches it off to find out. 

This is a skewed risk assessment. Leaving IT debt or legacy applications untouched is actually a higher risk than peeking under the covers and, in some cases, replacing that technology. A 'black box' will always pose a greater risk to the organisation than a solution with a documented configuration.

Another barrier is customisation levels, which often act as a counter-argument to change. Many organisations have systems with a high degree of custom configurations and 'workarounds' that make the system functional in specific scenarios. These custom configurations and the reasons for them may be undocumented and poorly understood. They're often hand-coded, which may give a false impression of them being overly complex.

However, organisations will have spent a huge amount of time, effort and resources on the customisation and have the mindset of sweating that investment when in fact, a more modern system with broader out-of-the-box capability could be more cost-effective and operationally efficient. Modern systems that utilise configuration-as-code enable web application and API security controls to be replicated and automatically monitored: efficiency gains that should counteract any inertia towards change.

A third barrier is full stack commitment. For the sake of contracting simplicity, bundling discounts or integration, organisations may try to put as many eggs as possible in one basket: served out of one technology stack. Stack integration may make it look harder to unwind or decouple any particular piece, even if moving to an API-based or overlay system would be functionally beneficial. Full stack integration need not be an excuse to stick with sub-par capability, and that is particularly the case for security.

A fourth barrier is the pathway for technology procurement. In domains such as cybersecurity, fear is often a tool that is employed by vendors in the sale process. In the past, it has been effective, but results in tool bloat: Fastly's latest global cybersecurity report, The Race to Adapt, found that, on average Australian and New Zealand organisations rely on seven network and application cybersecurity solutions with one in three of these solutions overlapping in feature functionality and less than half of the cybersecurity tools fully active.  

On average, organisations are spending US$63,000 on web applications and API security tools annually, clear evidence of businesses buying a range of tools that aren't designed to work effectively together, all in the hope of protection from security threats. Not only is this dangerous for organisations as it creates the illusion of security, but it can place enterprises at risk of a severe compliance breach.

At the same time, where purchases are made even partially on fear, other important factors, like choosing products that are right for the organisation's needs and that integrate and 'play well' with existing tools in the environment, get de-prioritised. But switching to a new tool, particularly one that consolidates multiple existing purchases, is often preferable to continuing to back a previous fear-based decision.

Non-tech barriers receiving higher billing

Increasingly, organisations have other reasons to change, specifically the extent to which existing suppliers meet emerging non-technical criteria that affect decision-making at a whole-of-business level. These factors do not take priority over technical capabilities, but they can make it hard to continue to work with a vendor that does not have these factors covered.

Technology purchases today often need to align with broader environmental, social and corporate governance (ESG) commitments made by the customer organisation. The expectation is that suppliers - of technology, and indeed any service - will align with that. 

For vendors, knowing any sustainability impact of a tool, particularly one that is SaaS-based, is important since where it is hosted can impact a customer's Scope 3 emissions. In addition, having a modern slavery statement and policy that aligns to Australian reporting rules is important, and is increasingly being sought by large (often, listed) companies.

A more common non-technical criterion is 'fit'. In technology case studies, organisations often publicly say that partnerships are based on the way vendors approach business and conduct themselves. Organisations want a supply chain that is aligned on work ethic, ethics and values. And so the question is often: How do you identify a vendor that has a technology that's going to improve your security posture but is also a vendor that you want to do business with? 

We're now in a period where this has indeed become an additional factor that drives organisations to change.