How confident are you that your software will perform the way it is meant to in the moment of truth? How sure are you that a system going down somewhere else in your industry won’t take yours out, too, or vice versa?
Making your software “safe and sound” requires a mix of hyper-awareness, good planning and foresight, and learning quickly from mistakes, according to Frédéric Véron, the chief information officer and head of safety and soundness for Deutsche Bank.
“Safety and soundness is about ‘How do we make the enterprise safer and more sound, right from the get-go?'” Véron said May 23 at the MIT Sloan CIO Symposium. “Not just when things happen, but before things happen.”
He said getting to that point is about knowing your software better than ever before.
First, Véron said, many organizations are unaware of exactly how end users are using their software—what features they are or aren’t using, what they are using them for, and whether they’re using the software for purposes for which it wasn’t originally intended.
He advocated adopting a stance of “hyper-awareness” that involves knowing how all your software is actually being used day-to-day, ensuring all stakeholders in development understand the full scope of the product, and continuously taking baseline metrics to understand what can be considered normal operating conditions for a system.
“The connection of the different contexts—not just IT folks, but operations and business, too—you’re connecting all of this together, so that when you have to take care of a system, you will know what’s normal,” said Véron.
To get that end-user perspective, send developers out to observe software users in action.
Learning about and understanding every aspect of the software and the systems it will need to interact with, from design to construction to production and operations allows the company to “go beyond DevOps to see the entire stack, to focus on customer experience,” he said.
Ensure operational readiness
Safe and sound software development isn’t just about coding and sending the finished product on to production, Véron said. To ensure a system is operationally ready, get everyone involved earlier in the planning process. Véron calls this approach to the design process “moving to the left.”
“All of the different procedures that will be necessary to maintain the system in production mode need to be thought through ahead of time. You can always bolt it all on later, but it will cost you more money and it won’t be native or work as well,” Véron said. “In the meantime, you’re at risk of your system not working.”
Véron is constantly measuring the readiness of new software releases, and said he’ll reject changes that don’t score higher than the previous version.
Fail fast, adapt fast
Adopting agile and DevOps, which are designed to allow iterative flexibility in software development and closer collaboration with customers, allows you to take a stance that values “failing and adapting fast.”
Developing and releasing minimum viable products helps a company confirm that its product is on the right path, learn from that, and adapt the concept and design to how people are using it. The process may seem slower than traditional development methods at first, Véron said, but eventually it speeds up the process.
“The whole point of agile is about adopting the philosophy where you break down major efforts into smaller efforts, allowing you to do incremental releases so that you can make a small change, and if it isn’t working you can pull it out of production quickly without impacting the whole thing,” Véron said.