There is growing evidence of a harmonic convergence of Infrastructure and Operations (I&O) with Security and it is hardly an accident. We often view them as separate worlds, but it’s obvious that they have more in common than they have differences. I live in the I&O team here at Forrester, but I get pulled into many discussions that would be classified as “security” topics. Examples include compliance analysis of configuration data and process discipline to prevent mistakes. Similarly, our Security analysts get pulled into process discussions and other topics that encroach into Operations territory. This is as it should be.
Some examples of where common DNA between I&O and Security can benefit you and your organization are:
Gain economic benefit by cross-pollinating skills, tools, and organizational entities
Improve service quality AND security with the same actions and strategies
Learn where the two SHOULD remain separate
Combine operational NOC and security SOC monitoring into a unified command center
Develop a plan and the economic and political justifications for intelligent combinations
Earlier this week, I attended the Hornbill User Group (or "HUG" as it is affectionately known) to listen to Malcolm Fry, IT service management (ITSM) legend and author of "ITIL Lite," talk about ITSM metrics in the context of ITIL 2011.
There is no doubt that metrics have long been a topic of interest, concern, and debate for ITSM practitioners (I wrote a piece a few years ago that is still the most popular item on my old blog site by a huge margin), and IMO I&O organizations struggle with the area due to a number of reasons:
I&O is not entirely sure what it is doing (in terms of metrics) and why.
We often measure what is easy to measure rather than what we should measure.
I&O can easily fall into the trap of focusing on IT metrics rather than business-focused metrics.
I&O organizations often have too many metrics as opposed to a select few (often led by the abundance of reports and metrics provided by the ITSM tool or tools of choice).
There is no structure or context between metrics (these can be stuck in silos rather than being “end-to-end”).
Metrics are commonly viewed as an output in their own right rather than as an input into business conversations about services or improvement activity.
I need to make this brief; the failure of the lump of plastic that used to be my BlackBerry has made me very time-poor today …
It has been an interesting year for RIM and for the BlackBerry. RIM has seen the erosion of its corporate mobile-email dominance (as employees prefer the usability of iPhones and Android devices), its brand was adversely affected by the BlackBerry Messaging Service being "the weapon of choice" for the thugs involved in the London riots, its tablet play has limped into the iPad's market, and now we have the prolonged service outage ... Sorry service OUTAGES.
The extent of the outage has been and continues to be shocking (there is no way it should have been this severe). But to me, in my capacity as an analyst, and observer and advisor on IT service management best practice, the real issue here is how RIM has handled the situation.
In managing the outage, RIM has acted like an old-fashioned technology vendor rather than a modern-day service provider; while we talk about BlackBerry devices we are really buying into the BlackBerry service. And we expect that service to be consistently delivered relative to service promises and our expectations thereof.
While we would prefer there not to be an interruption to service, most of us appreciate that "stuff" happens. When there is a service-affecting issue, we have a set of minimum requirements as customers that need to be catered for:
Firstly, we want early notification and a speedy resolution or a work around. As a minimum, that the service provider is visibly seen to be applying significant and varied efforts to the resolution of the issue. We want to see that the service provider cares.
Secondly, we want our expectations to be managed. Communications should keep us informed and be honest about when we should expect service resumption.