At the height of the pandemic in Spring 2020, a Gartner survey found over two thirds of organizations had accelerated their digital business initiatives. Throughout this crisis we’ve heard amazing stories of rapid digital deployments; banks rolling out emergency loan programs, medical equipment distributors transforming supply chain processes, retailers stepping up online services. In each case, the ubiquitous need for quality, governance, security, and customer experience still existed, but then - as now - apps needed to be scaled at break-neck speed.
Michael Coté is Staff Technologist, VMware Tanzu.
The new headwinds of coronavirus exposed how far organizations needed to go to modernize their approach to software. And not just in times of crisis. It showed us that the biggest barriers to rapid innovation aren’t the budget restraints, silos, compliance delays or skills gaps so often bemoaned. Overall, what holds organizations back from truly agile software development is mindset.
As we emerge from the crisis, what can these headwinds of 2020 teach us about mindset, and how can this help organizations achieve more from software innovation going forward?
Our need to modernize approaches
The impact of the pandemic on everyday life demanded that organizations get applications out of the door in days, not months. It proved that with the right impetus and mindset, stuff got done. The previous bottlenecks had to be broken.
Undoubtedly one of those bottlenecks has been the increasingly complex and intensified software supply chain, or path to production. Agile and DevOps approaches brought in project and product management, and then configuration, monitoring and infrastructure as part of projects. This led to an all-too common problem; lack of ownership.
While small start-ups or isolated teams in large organizations can be full-stream owners, in large enterprises this isn't practical. Someone needs to "own" and tightly manage the business outcome of the application.
When it comes to development it is rare to find a person or team who's responsible for the outcome from end-to-end. For example, in speaking with a group of 10 or so senior IT managers who represented a large bank's various IT functions, they all complained that it was hard to coordinate across silos. There were too many hand-offs meaning groups couldn't coordinate technology decisions.
This complaint comes up all the time. Too often there isn't anyone who owns and is responsible for discrete business outcomes and who can also make management decisions about all the activities in the path to production. While the CIO is ultimately responsible, at a large organization, it's unreasonable to think that they can be hands-on across hundreds of applications while also worrying about every other IT concern.
If heads of departments can't seem to coordinate, there is a headless pipeline. Rather than create yet another silo to solve this problem, there needs to be an owner for the end-to-end process. This starts with putting in the work to discover and document the path to production. The critical mindset shift here is two part: Firstly, there is an end-to-end path to production, and likely no one has ever discovered and charted it. Secondly, that path to production must be owned and activity managed to perfect how software delivers business value.
Mindset shift
More than likely, there be a few epiphanies:
- Despite years of automation, we still have so many manual and ticket-driven processes. Each silo may be optimized and automated (or, not!) but connecting all that automation together is often lacking.
- We have excessive governance resulting in long wait times between activities in the path to production.
- Security checks and policy, while valuable, slow down our process, especially when security is prescribed at the beginning and then verified at the end of the process.
Those two final points are particularly relevant. As organizations are scaling new methods, they are held up by governance and security. These two functions have yet to fully "shift left". What do we mean by “shift left”? Successful organizations are spending the time to work with auditors and security staff earlier in the process, hence, "shift left". While these relationships have been oppositional in the past, working together earlier in the process removes much of that opposition and serves both the needs of the auditors and the product team.
Cloud-native technologies and practices like Kubernetes and build packs are also helping speed-up security and governance. With these new platforms, you can tightly control and verify what code goes into production, giving security more control and assurance over your software. Using cloud-native technology like this to put up guardrails and automate governance enforcement is broadly called "DevSecOps" and has many successful examples to draw from, including from high-security organizations like the US Department of Defense.
The mindset shift here may seem simple in principle but can be hard to shift in practicality. It takes leadership to shift their collective minds to a new way of thinking about the purpose of software in their organization. Software innovation can no longer be thought of in terms of one-off projects, as it has in the past. This is a closed approach, not aligned with the need to adapt to new market dynamics. Rather, a product mindset focuses on continually learning what the product is and continually delivering new features as determined by evolving customer and business needs.
Thinking about software as a "product" is what's needed in this kind of environment. It all starts with the issue of ownership. Firstly, leadership must own and model a new product mindset of agility and dynamism. Within this, the process of bringing this to life requires ownership across the product development cycle. No more complaining about ‘the other guys’, no more silos and sticking to the rigid path previously trod. A shift left is a shift to swift innovation and stronger resilience, no matter the headwinds that might shake us.
- We feature the best mobile app development software.
