If only fast IT operations (ITOps) was just about choosing the right tooling. Instead, as so often in IT, ensuring optimum software and services delivery that gets business results involves the solving of “people’ problems too.
“There’s a big gap between what we see people do, and what we think they should do,” says Andy Venables, technology head at managed services provider (MSP) platform supplier Popx. “And what we do can be a really big investment, requiring a whole different thought process – versus, say, email.”
It is essential IT chiefs do their homework on a tool before investing. Venables says too few know enough to be confident of operational improvements. Once they have acquired a tool and learn more, it can be too late.
As an example, Venables points to Birmingham City Council, which this year announced financial distress after Oracle project costs quintupled from £20m to around £100m. “It just sounds like a typical case of they didn’t know what to ask, or what trouble they could run into, and didn’t have the right safeguards,” he says.
Venables suggests that avoiding such a fate relies heavily on curating the relationship between IT supplier and customer. He urges IT leaders to find out exactly what their organisation requires and how they want the system being implemented to operate, then work with their preferred IT provider to guide them with full transparency towards the integrations and self-service automations to boost productivity and customer experience over time.
“They can always challenge it, but at least we started with ‘our thing’. If that makes sense, you get the trust and you can move forward in the cycle,” he says.
First things first, and then the rest
According to Venables, ServiceNow customers often suffer from technical debt, platform misconfiguration or lack of ITIL alignment – on top of industry skillset shortages and cobbled-together applications. “A tool can be bent out of shape so much that it’s no longer working in an ITIL way,” warns Venables. “Once stabilised, then start talking about real automation that saves money,” he adds.
For Jeff Watkins, chief product technology officer (CPTO) at Xdesign, continuous delivery can play a significant role in helping minimise gaps between what IT decision-makers think they want and expect and what gets delivered into production.
“If you’re doing releases multiple times a week or more, it’s less scary,” says Watkins. “We’re just putting out a new widget on the page, or in the app. If it goes wrong, we’ll just feature-flag it back out again.”
Features can be deployed in the background and toggled back if not working for the user, continually iterating on the latest update, adding in A/B testing and so on – all of which adds up to faster more agile engineering practices and roll-out while better managing expectations and delivering to those expectations at the same time, he says.
“We’ll automate as much of that as possible,” says Watkins. “Including marking nodes as blue/green so you can deploy to parts of the ecosystem without taking anything down.”
He urges IT leaders to enable fast feedback loops, to ensure people are not left frustrated waiting for a new release.
This applies equally well when internal developer resources are used for a digitisation project. Nir Shafrir, chief executive at JetBrains plugin provider Digma, notes that IT leaders can enable continuous feedback in real time at the developer level, speeding up collaborative code improvement as it is deployed – in Digma’s case, with Java code on a JetBrains IntelliJ integrated development environment (IDE).
With all the excitement over a new digitisation project, it is easy to put less emphasis on the full lifecycle of the software developed. “Java brings a lot of challenges – people leave companies and nobody knows who wrote the code or how to change it, for instance, because Java has been there for so many years,” says Shafrir. “Developers can be a ‘people problem’ hardly spoken about.”
A system of miscommunication
Communication between developer teams and “business types” can be fraught. Developers typically work very hard for long hours to deliver what customers want. Yet efforts frequently fall flat, due in no small part to a failure of one or both sides to understand or explain what the other really wants or needs, says Shafrir.
“There will always be a wall between the two, but especially during this time with tonnes of services on the internet and daily changes to software. It’s a problem if only business people are in touch with customers,” he says.
Developers often have little idea how the customers are using the product – not least because they write code and “throw it over the fence”.
“Then it’s frustrating when we’re [developers] told our quality is very low and it’s not a good job and we don’t work hard enough and other things,” says Shafrir.
Shafrir recommends that IT leaders “take down that wall” between the two teams. If developers are notified and know exactly – continuously – how the code is performing in the customer environment, fixes can be rolled out faster. Of course, this can mean getting buy-in from all stakeholders in a project.
“How can you do digital transformation when half of the organisation is not part of that?” says Shafrir.
New technologies and open protocols, like open telemetry, mean that live environments can be monitored to deliver a view of scaling issues, slowness, performance issues and multiple errors. However, even if the problem is within the code, all of this data is usually with the IT and operations “in a big, beautiful dashboard”.
This is something they are unable to see and unless something goes badly wrong; their developers are not able to see it either. “This is actually preventing digital transformation in a SaaS [software-as-a-service] or cloud environment,” says Shafrir.
‘Bigger picture’ elements that strangle delivery
At the very start, when embarking on a digital transformation initiative, Jon Mort, technology chief at application lifecycle management (ALM) specialist Adaptavist, suggests IT leaders begin by pinpointing the smallest possible change that will start to move a desired transformation forward.
“We take some feedback from the solution partner, some from on-the-ground listening to the customers with our solution partners, and package that up,” says Mort.
He suggests IT leaders use more product thinking on software innovation, rather than projects with set timeframes. For Mort, trusted partnerships or partner ecosystems are also critical to help internal IT teams to deal with increased complexity and challenges.
“It’s not just about the solution partner. You’re looking for how open it is, and whether there’s apps and integrations that you can also use, or a user community that you can lean on as well,” says Mort.
Above all, he recommends that IT leaders assess whether their digitisation plan is genuinely innovative and offering value to customers. If the answer is really “not really”, Mort says the focus should be on making the technology super-reliable, and let it sit in the background.
Clearly, optimising the release of software is essential to success with digitisation. But IT operations must also be ready to support and manage the stream of new software-powered business initiatives and continuous updates often associated with digitisation initiatives. For Mark Appleton, chief customer officer at marketplace Also Cloud, the operational challenges IT leaders face in delivering effective software and services deployments include problem areas such as increased data usage and super apps, to ever-present cyber security risk.
The advice from the experts Computer Weekly spoke to is that IT leaders should prepare IT operations for digitisation project deployments with clear research and budgeting for future-proof infrastructure and long-term software maintenance. Training of IT staff is key to future success, as is, Venables notes, avoiding the temptation to bend an off-the-shelf product to fit the digitisation strategy.