Blog

Operations Automation – the Key to ITOM’s Success

Adrian Sandham

ITOM and ITSM initiatives where platforms are concerned are often a top-driven decision. The nature of decisions, such as this, do inherently come with resistance in various forms within the business. This resistance is something that should never be overlooked and should be mitigated as early as possible through inclusion and respect of existing teams and employees.

Mitigation of resistance and inclusion of all stakeholders are two things that can be over looked when we see companies try to roll out ITSM and ITOM related platforms in their environments. Using approaches such as CDI’s Hybrid Cloud Automation Framework (HCAF), we can soften the introduction and include as many perspectives as possible early in the design process. This is invaluable to ensure that stakeholders and existing parts of the business do not feel excluded and, instead, feel directly involved and contributing.

It is rare in our experience at CDI that we come across clients that simply want to approach ITOM platform roll outs with a sledge hammer. Often clients come to us looking for a solution and inherently we find ourselves on a mission of helping and educating the client on what is involved by firstly defining their solution through workshops such as HCAF — and ultimately delivering it. In this process, we work to make sure that the solution meets their organizational and technical requirements. Ensuring inclusion at this vital stage is what greatly ensures the success of this project.

The former areas are typically of primary focus, but again it is the rollout process and the incorporation of existing knowledge and experience within the business — particularly in the area of ITOM that is essential for success. Many client’s success is built on the knowledge and assets that have been created and developed by internal teams. In many cases, these are overlooked, but with the gap between operations teams existing assets and the targeted platform’s makeup (different languages, architectures and introduction of approval flows) the transition of this knowledge and associated assets from exiting sources often proves to be too much of an overhead to consider.

This can be said from both CDI’s and the client’s perspective. This ultimately involves losing out on the migration of essential company experience and prior art. The nuances addressed by existing automation are missed as there is limited input (even with the best of intention) from these teams which is where a huge amount of knowledge lives. It is usually later in the engagement that these teams, that are deep within and essential to the business, are discovered. When the design is being implemented and their insights can be impactful to the design produced, it can induce rework and re-factoring in many cases. More importantly, a team who is left feeling alienated and with a feeling of resentment. This can eventually leave a cultural and organizational rift in its wake. This is a complex issue in consulting terms, one that money won’t really fix unless a client is willing to do 12 months of workshops and interviews to understand every facet of the relevant organizations.

Rightly so, that’s not going to happen.

However, there is a different approach. It may seem a little unorthodox at first, but the implications are far wider reaching than one may expect. The solution here is to include those teams by supplying them a tool that makes their lives easier, called Rundeck and the rest of this post is all about it!

Rundeck is a system that allows scripts to be transferred and standardized extremely quickly. It allows teams to cross-pollinate and store existing automation and provide a way to securely share it within the team, where all executions are logged, producing a unicorn audit trail for adhoc scripts. Once their team leverages it, another team can login and be given access. This begins to break down barriers and introduce that elusive cross-pollination that so many companies crave but can’t reach.

Beyond that, if this platform integrates with a git repository it brings with it a soft introduction for teams that traditionally wrote scripts and stored them in shares. Bugs can be opened, and code can be hardened. It doesn’t stop there, this is something that can be leveraged by Jenkins and other pipelines easily, drastically expanding its implications.

To have a hardened library with all existing automation in place that can be called via REST API is the supercharger that ITOM platform initiatives need. While ultimately the automation required for auto remediation by platforms etc., should reside there, it should only make it there once it is justified. Until then, it can be used and bettered in the jump pad the platform needs. In most cases issues mentioned at the beginning of this piece just need a little seed, to drive inclusion, mitigate resistance and avoid duplication.

Adrian Sandham

Adrian Sandham, Chief Automation Architect, OCTO, CDI

Adrian Sandham, Chief Automation Architect, OCTO, is an innovative thinker that provides solutions to complex issues at both a technical and business level. In his current role, he works in the areas of pre-sales and solution design, which involves the evolution of engagement models developed internally to accommodate the many new technologies in which CDI is investing. In his previous role at CDI, Adrian was part of the Advanced Services Group, where he worked to deliver and develop new technologies and their associated delivery methodologies. He is highly-trained and certified in today’s leading technologies and has filed multiple patents over the past few years, which fulfills his desire to find abstract and useful solutions to problems that are likely to occur in the orchestration area of enterprise-grade computing. Adrian is a graduate of the Cork Institute of Technology and holds a degree in Software Development and Computer Networking. In his spare time, he enjoys art, mountain biking and researching, understanding and implementing new technologies.