Jaco Viljoen, the principal agile consultant at IndigoCube
Most executives agree the IT landscape is changing dramatically and if it is, they argue, then how are they supposed to automate what’s in a state of flux? That’s just a recipe to waste time and money by redoing all your hard work in the near future. And in a world where scripts automate discrete business processes they’re absolutely correct.
But it’s important to realise that the business will never be in stasis, only the level of flux will change, and that there’s a different way to automate. It’s also important to remember that automation is one of the primary enablers of the digital enterprise, which is an agile organisation. And, Gartner agrees, enterprises face a mammoth task uniting disparate islands of automation.
In this context islands of automation are typically scripts, written in any number of languages, by any number of people, scattered throughout the business and its systems.
The problem with these islands is that it can be almost impossible to find broken scripts when a process breaks down. Even when you do the disparity of systems and scripts and lack of suitably skilled coders with time enough to resolve the issues can be a problem. Days and even weeks can pass by before things are fixed.
Another issue is that coders inevitably move on to new positions. They leave behind a nest of undocumented scripts that are impossible for replacement coders to maintain. And you may well need more coders who know several scripting languages.
They’re business risks but automation platforms blunt them.
Strategies based on automation platforms create viable roadmaps to get end-to-end automation with fewer scripting technologies, requiring fewer skills, to better serve customers, and enable rapid development.
Enterprises pursuing digitalisation must also mature their agility and software development capability. There are five levels and I’ve notice that the more organisations progress from one level of software development maturity to the next, the greater their need for automation.
As an aside, it implies that not all enterprises need to immediately fully automate since not all have achieved top drawer software development maturity.
The first level is the waterfall process we all know with its many disadvantages. Level two can introduce some low-level automation but the process following the development phase remains a waterfall approach. The next level of software development maturity introduces regular software delivery.
But regular can mean delivering new software to production as seldom as three or four times a year because it doesn’t necessarily mean often or frequent. And if that’s where you’re at then you have low automation needs. You have your release windows worked out, your process under control, and you can happily continue as you are.
But it’s normal for you to feel pressured to release more often. Some of South Africa’s banks are at this level and they release 10 times a year, essentially once a month excluding December and January since they’re peak periods. That release schedule is good enough for many.
Only highly competitive markets want you to release more often. A release feature may help a brand get market share or help the business achieve a strategic goal or build the image of being innovative.
In many ways we can link service orchestration and release automation to IT service management (ITSM). Lack of service management impedes the entire business by making it less competitive. And so it becomes an element of discerning an enterprise’s maturity level.
According to Forbes, when it assessed the state of IT service management in 2017, 10% of worldwide businesses are still focused on moving to IT self-service and greater ease of use of IT resources through the service desk. The service desk is essentially a workflow engine that can be used to automate some requests.
But 35% of global organisations are in the preliminary stage of adopting some form of automation and they are developing an awareness of how IT services can directly impact business value. They’re developing a more holistic view and they’re positioning their infrastructure, applications, hardware, and software and finding ways to better align with the business strategy. And they’re open to new service models.
Fifty-four percent of IT operations have advanced ITSM. They have automated service operations tied to analytics for continuous improvement and quality-of-service (QoS). They have collaborative change management and analytics drive them. They can embrace the latest technologies, from cloud to mobile, big data analytics, and the digital enterprise overall. They’re more competitive because they can overcome challenges quickly and take advantage of any opportunities.
But many South Africans still struggle to automate. Automation is inherently complex because of complex infrastructures and development toolchains, such as DevOps toolchain.
Looking at the development chain you can see that organisations innovate in two main ways, through the design and development phase then through the testing and operations phase. It’s easy to automate development, testing, and operations but not design.
There are some scenarios where automation is a no-brainer. The tools are available, its easy to do. But there are some real challenges and they’re not just technology problems. Sometimes these are social issues, for example, management’s willingness to make changes, or the availability of skills to make the changes, and more. There are good reasons why many enterprises haven’t yet automated processes from one end to the other.
It’s a difficult and complex job to automate across the whole organisation in the quest to serve a digitalised and agile business. Many simply don’t know what activities to perform, what technologies to adopt, and what skills they need to support the whole shebang. But that’s where assessing development maturity based on the five levels I mentioned earlier can be helpful to creating the roadmap that determines current maturity, desired maturity, and what steps will lead the business where it wants to go.
By Jaco Viljoen, the principal agile consultant at IndigoCube
Powered by WPeMatico