Summary from NGINX Digital Boardroom – Thursday 24th September 2020
It has been observed during the COVID-19 pandemic that many organisations have been able to accomplish more in six weeks of high pressure work than would normally have been in six months to a year through the use of Sprints and the need to change to survive in this ever changing world. Today, time to market is the key factor that drives competitive advantage. No longer do the bigger organisations corner the markets making it harder for smaller companies to break through. Now it is all down to speed.
Faster applications also lead to much better customer experiences with a recent survey showing 75% of consumers will abandon a brand they love after one bad experience as they expect a load time of three seconds. And while this is not a definite rule, there is certainly a noticeable correlation between slow speeds and abandonment developing. Also, improving the speed of your troubleshooting can greatly drive down operational costs, making things easier for employees and more worthwhile for customers.
The speed at which projects can be achieved can be thwarted by three major issues:
The developers within your team are the engine that powers everything. They need to be empowered to make the decisions regarding going to the cloud and they need to be supported through enabling self service to drive productivity. On the other hand, the major question around self service remains ‘how do you offer the same capabilities in that self service manner without locking them into a particular cloud or stack?’ The goal is to have the flexibility needed within the cloud without being locked into an agreement.
Another tip would be to reduce the number of meetings within your team. When the pandemic began it was a case of ‘out of sight, out of mind’, but now staff have established they can work productively while being remote, giving them a bit more trust and free reign can lead to less problems down the line with time wasted and looking over each other’s shoulders.
Tools and a lack of automation
In the past relentless standardisation of tools was the norm, however this is becoming much harder now and so there is a definite need to increase automation and reduce costs within an organisation, If the developers are the engine, DevOps is the transmission which needs to be able to move fast.
Treat the organisation infrastructure as code which will allow you to identify the necessary capabilities needed and add them to an application faster. And look to implement declarative APIs, expressing intent of what is needed rather than having to lead teams by the hand with step by step guides.
A common mistake made is to go too fast with change meaning we accumulate a lot of technology debt, some of which will do similar or the same jobs. Your engine and transmission will be the same, but technology, or chassis, needs to be adaptable for any shape and to any changes that may come in the near or distant future.
It is believed that you will have six different cloud systems on average per enterprise. Therefore it is imperative to remain portable and infrastructure-agnostic to avoid becoming hard coded into one system and allowing you to be open to change and other systems that may be available and of use to you.
What are your current challenges with modernising apps?
Current challenges faced by IT executives include:
- Scalability depending on the size and speed of the organisation
- Security, increasingly so as we work remotely
- Training and self service for employees to allow them to learn for themselves and speed up the customer experience
- Continuous deployment needs dependant on industry
- Legacy integrated into everything, the cost involved to remove it, customer’s desire for speed and regulator’s desire to remain compliant
- Rolling out omnichannel communication to customers including on social media
- Cloud repatriation, the difficulty of backing out and the need to be forward looking in your cost model
A pattern that is often observed with these projects is that it starts small, the business likes it, then the ‘experiment’ becomes integral to the company and is passed on to IT. The question then becomes how do you develop that to bring it back in house? The blueprint is there, but the skills to do this aren’t always there.
How much intelligence can you put into the automation?
By all accounts the tools needed for automation are already there and work well for many organisations. The major stumbling block for the widespread roll out is that customers still find it hard to trust it, wanting the work of automation to be verified against the existing controls to ensure it works as it should by running it in parallel. Therefore it is believed we are still some time away from full automated potential with the main key driver being human latency to complete the tasks needed initially.