Did you hear the news? It seems that reports of ITSM’s death have been greatly exaggerated!
Let me caveat this sensational claim by saying that, if you are coming from the perspective of a ten-person team just getting started, and you don’t own any actual physical IT infrastructure apart from your bestickered MacBooks, I don’t mean you. I have spent my career in enterprise IT, meaning large numbers of systems and a history going back decades. In this world, structure and process are at the very least necessary evils, required for dealing with the sheer size and complexity of the environment and everything it needs to do.
A brief aside: when did “legacy” become a bad word? Outside of IT, it is just as likely to be paired with positive synonyms like “heritage”, “endowment”, or “gift”. However, within IT, the second set of synonyms gets all the attention. Think “aftermath”, “repercussion”, or “residue”. While there is certainly a fair amount of the bad sort of legacy around – the temporary hack that somehow became permanent, the technical debt from everything that seemed a good idea at the time, and all the other barnacles on the ship of the enterprise – most companies cannot and should not throw out their valuable heritage.
The other important aspect of that legacy-as-heritage is that it is generally mandated by the business, not by IT. If the CIO and CTO were to sit down and map out the business from an IT perspective, it would probably look very different, and be much simpler to support from that IT point of view – but there is a good chance it would not support all the business objectives, especially once you start to get into weird corner cases that do not fit well into the database schema.
This situation is precisely why ITSM (or something like it) is necessary: it provides the framework for keeping track of the complex intersections of business decisions and IT decisions. It is the System of Record for the enterprise, documenting past decisions and enabling new decisions to be taken in a way that takes all the various constraints into account.
Why ITSM Gets a Bad Reputation
The reason ITSM gets a bad name is because it is not exactly agile (or Agile). The whole point of ITSM is to impose control on a messy process. This is a valid goal, but it does come with some trade-offs, especially at the expense of speed.
Once again, the difficulty arises at the intersection of IT’s needs with the business requirements. It’s a truism to say that businesses need to move faster than they ever have before, and this in turn means that IT needs to be much more responsive. Annual release cycles won’t cut it anymore, because the impact to the business’ agility is too high. The business cannot wait for the next meeting of the Change Advisory Board, things need to happen right now.
The risk of this mismatch in speeds and expectations is that changes start happening outside the process. When a large contract is at stake, or there is some sort of legal requirement to satisfy, that takes priority over The Process. That is all well and good, but is liable to cause problems down the line, if whatever was done is not then brought back into line with IT’s expectations. The main cause of deployment failures is finding out too late that the production environment is in a different state than was expected – typically because of an emergency change that went outside the process. The problem is then compounded, because everyone rushes to fix the bug in production, in turn creating more issues and setting more landmines for the incautious to encounter during future deployments.
ITSM Meets DevOps
So far, so bad. Meanwhile, new Systems of Engagement are emerging among the teams that are moving fast. Often, these ideas start from the Dev side of the house, and then through DevOps start be adopted also on the Ops side. These new approaches share a few common characteristics.
A big part of the difference between Systems of Record and Systems of Engagement is how different roles and teams work together. ITSM often ends up in a “waterfall” mode, where different teams work on a task in sequence. A single issue is worked on by one team, then reassigned to another, and so on. In contrast, the Agile mode is more collaborative, with different roles sharing information in real time. With the complexity of both modern IT environments and the business services that they support, the waterfall approach is no longer well adapted to the sorts of interconnected problems and requests that need to be dealt with. Instead, real-time collaboration is much better suited to those heterogeneous systems, mirroring the interdependent nature of the systems and service themselves.
Speed & Agility
Structured processes are not necessarily any slower than unstructured ones. The reason results may take longer to achieve is when those structured processes are implemented at human time-scales, meaning with significant dead time in the hand-offs between different roles and areas of responsibility. A more collaborative approach also has the benefit of minimising these dead times, enabling many parts of the process to run more effectively in parallel.
Integration & Programmability
An important part of the switch from a monolithic System of Record to a more heterogeneous approach is that integration becomes a key requirement. The Systems of Engagement (note plural) need to talk to the System of Record, and they also must talk with many other systems that are used by different teams for specific tasks. This has obvious benefits in terms of speed, accelerating both individual tasks and, perhaps even more importantly, the hand-offs between them. There is also a robustness to this composable approach, distributing responsibility and minimising choke points. Integration between multifarious systems used to be complex, intensive, and fragile, but nowadays standardised interfaces such as REST make integration, if not trivial, at least much simpler. Increasing adoption of enterprise service buses such as Apache Kafka or various forms of MQ will further simplify this task.
Where they often fall down is in their lack of connection to the legacy systems. There is some truth to the caricature of the DevOps Evangelist sneering over their latte at the stuck-in-the-mud Enterprise Ops team, and there is no simple technological fix to that cultural mismatch. The key is setting up the right communication between the two teams, and enabling proper communication between the people and systems involved.
In other words, there is a need for both Systems of Record and Systems of Engagement, but the two need to be integrated with each other. Teams can collaborate much better if they also have access to all the information about what they are working on. Taking decisions at an Agile tempo does not have to be at the cost of assuming extra risk, if automated checks can be built into the process.
The benefit to companies of integrating these two different views of the world will be a better balance of agility and control. IT organisations will be able to take decisions at the tempo that the business requires, using Systems of Engagement, with the reassurance of back-end integration with Systems of Record that ensure everything is checked and documented.
If you would like to continue the conversation, I will be attending SITS17 in London on the 7th and 8th of June. Come find me at the Moogsoft booth, we’ll get a coffee (or a beer!) and have a chat.
Latest posts by Dominic Wellington (see all)
- The Rhythm of IT – Why Dev and Ops Should Join Together to Make Great Music - May 4, 2018
- Don’t Have A Meltdown Over ITOps - January 23, 2018
- Is Premature Automation Holding IT Operations Back? - November 9, 2017