I spent last week bouncing around Australia. “Bouncing” is almost literal: in one week I visited Sydney, Canberra and Melbourne. BMC was running events in each of those cities, in which I had the opportunity to present our automation vision, together with Dean Forster from Macquarie Telecom, who was presenting his company’s experience putting that vision into practice.
Incidentally, Australia is a great IT market, with a very well-informed and sophisticated understanding of the issues – and I’m not just saying that because they were nice to me. Check out what James Staten of Forrester Research has to say about the Australian IT market.
My theme Down Under was that automation can be incredibly valuable and effective, but it must be deployed correctly and in support of the right goals. In fact this was my opening slide:
I sometimes define automation as a force multiplier – before adding the important caveat that you have to pay attention what you point the multiplied force at…
The specific application that I chose to discuss was compliance. The whole area of Governance, Risk and Compliance (GRC) is a perfect example of automation failing to live up to its full potential. There are many products automating aspects of the GRC process, but none that look at the whole process from end to end.
The result is what I call the SecOps gap.
This is named by analogy with the more famous DevOps gap. In that case, the gap between Developers and Operations results in botched application rollouts and production outages. In the same way, the SecOps gap between Security (GRC) and Operations (ITOM) spans two very different ways of looking at the world. GRC teams focus on working out how things should be in an ideal world, and want to get there as quickly as possible. On the other side, ITOM teams have to deal with the messy real world, and live by the maxim “if it ain’t broke, DON’T TOUCH IT!“.
The conflict between these two different worldviews arises over the issues of changes. GRC teams want changes to be made as quickly as possible to reduce vulnerability windows and non-compliance exposure. ITOM teams know that change is dangerous, especially in modern environments with many moving parts and interactions between different teams. Gartner tells us:
Through 2015, 80% of outages impacting mission-critical services will be caused by people and process issues, and more than 50% of those outages will be caused by change/configuration/release integration and hand-off issues.
(Ronni J. Colville and George Spafford, Configuration Management for Virtual and Cloud Infrastructures).
In both cases (SecOps and DevOps) both teams have dedicated tools, and indeed various sub-teams within each area will have their own increasingly specialised tools. While these tools may help with one specific task, none address the overall issue of the entire process.
What BMC does is to close that gap, providing a single unified view of how things should be and how they are, and giving options to manage the inevitable differences. I recorded a webinar on this topic a little while ago; you can find the recording here. There is also a whitepaper where I go into much more depth on this topic, which you can download here. Sorry about the registration forms – we promise not to spam you!
Do get in touch if you want to discuss this topic further.