When not to start your digital transformation
In the digital transformation blog, I stated “From personal experience, make sure your IT Engineering (including DevSecOps) is ahead of where the transformation needs it to be.” This actually applies to any transformation or big change portfolio (digital, agility or cloud). The personal experience I refer to goes back 20 years. I learnt the hard way that good engineering upfront saves a lot of anguish later. It has been a mantra of mine ever since.
As a technologist at heart, it’s a subject area that I have always been passionate about (I come from a long line of engineers, although my dads definition includes working with real engines!). IT Engineering can get very jargon infested, very quickly, so I’ve tried to minimise the jargon in this blog. For the technologists I’ve left a word salad at the end for you.
Starting with a statement of fact: modern technology especially for digital, is complex. In response, IT engineering has matured rapidly to help manage both change and ongoing service. This covers ways of working, automation and tooling. More importantly the leadership, mindset and cultural changes needed.
From a Hanya perspective, this covers DevSecOps, leading edge thinking (chaos engineering, SRE)and tooling such as test automation and AIOps (the application of AI to operations). Ouch that’s a whole lot of jargon. Put another way, it’s a mixture of new ways of thinking, working and using tools to increase the effectiveness of software delivery and managing service.
The benefits are many. Most importantly it increases trust between IT and other business areas, and within IT itself (change, operations, architecture & strategy). Trust is essential to any organisation that is looking for major improvements (obviously)!
It can also cut the time (and cost) to get new ideas to the customer/citizen, increase quality and accuracy (including safety), avoiding costs from rework. It also cuts the cost of experimentation and creates more stable, responsive service. Definitely worth having then.
In the previous blog we also spoke about technical debt . IT engineering helps minimise the creation of new debt and mitigate the impact of existing debt. Key parts of success for digital transformation.
Next, consider for a moment, if you do not have the IT engineering. You will find very quickly that your new teams/squads/tribes become dis-illusioned. They cannot release value as often as they are capable of. So much for that vaunted ambition to increase the pace and adaptability. Trust is eroded.
Or. You are still taking too long to get feedback to the developers on defects. So back into the code they go. Frustrating and not productive. There are plenty more examples. The good news is that IT engineering just need to be one day ahead (I’d prefer a few months personally!).
Another consideration is your partners. Can you help each other to deliver at your best? That will be the subject of a future blog.
Of course this comes with a price tag. The trick is to match your investment to the level of underlying risk and business ambition (value) that you are supporting. Comparisons with big tech can be useful to see the art of the possible, but it doesn’t mean you need to match them (unless you truly are managing a global 24×7 footprint, with multitudes of software releases per hour). Equally, realism is needed. This is complex. Engaging proactively with the senior leadership of the organisation is essential in ensuring the right investment (including Board/Exec oversight). This is informed judgement, not always easy.
So, is your IT engineering good enough? Or will it anchor, drag and destroy your ambitions?
#ITEngineering #IaC #chaosengineering #SiteReliabilityEngineering #AIOps #MLOps