Ban the SLA

Business people just don’t get it. 

This strange stuff that we IT folk force-feed down their throats. 

Like SLAs. 

All very high-ceremony, with formal procedures for this and that, most of which seems inside-out if not inside-in. Subtle differences between incidents, problems and service requests. 

"I REALLY DON’T CARE – JUST HELP ME GET BACK TO WORK INSTEAD OF ME WASTING MY LIFE TRYING TO WORK OUT HOW TO AVOID DEALING WITH YOU."

They only play along with this SLA nonsense because they know that it’ll cost them even more time and energy to get us to change our ways. So then we get into discussions about response times and resolution times with us saying

 “No we can’t possibly guarantee a resolution time because one of the widgets is out of support”.

And they say “Yes but all I want to know is what kind of a delay will I have when there’s an outage”

… “Oh, we couldn’t possibly say – it depends on so many variables” …

 “But you’ve been doing this for years, surely you know what to expect?”

And so it continues, ending up with both sides adding preconditions and exceptions and penalties. This reminds me of the build-up of nuclear weapons half way through the previous century. And the Ban the Bomb movement and nuclear disarmament. 

I believe that the time has come for the Ban the SLA movement leading to an Anti-Ballistic SLA Treaty and a Strategic SLA Limitation Treaty (SALT), leading in turn to Service Level Agreement Termination (SLAT) and SLA disarmament. 

An interesting alternative to SLA’s is the Service Charter. Not the same Service Charter as defined by ITIL 2011 as “A document that contains details of a new or changed service” but a high-level document that sets intentions and general expectations. Deakin University in Australia has a good example and, strangely enough, most service charters seem to be used down-under. It’s only fair to state that that a service charter is not detailed enough replace the contract between business and IT, but it is certainly a more fitting instrument to lull them into a false sense of security before launching our all-out service level attack.  

Note: James Finister prompted me to write this for his blog.

Service catalogues - the business perspective

From a business perspective, the following categories of IT services appeal to business managers in the sense that they fulfill a business need: 

• Build or acquire, and then deploy functionality that supports the business processes (this is typically delivered in a project that combines applications, data, infrastructure and facilities to provide the required functionality) 
• Ensure that the functionality is operational and fit for use (this addresses availability, performance, security, continuity etc. and the corrective en preventive maintenance that is needed to keep providing the current functionality)
• Provide operational services such as providing a new user with access to the information systems (including supplying devices such as laptops and smartphones), running an IT function that is too technical for a user, e.g. a batch run, and supporting the users when queries and problems occur
• Change the functionality when business processes change and to improve how current business processes are supported (often delivered in a new release, and executed in a project when the risks justify it) 
• Advise about the consequences of proposed changes and which changes should be considered, and advise about longer-term choices, such as adoption of social media technology and when to replace an application
• Decommission the functionality

More on this topic in my white paper 'Service catalogues - the business perspective'.

Business Information Management

Business Information Management refers to the activities that organizations perform in order to ensure that they are using information in an appropriate manner. It includes the application of information technology but excludes responsibility for the supply of IT services, that are deemed to be provided by Application Management and IT Infrastructure Management working in unison with each other and with Business Information Management. The following definition is a combination of definitions used by the Australian Queensland Government and AIIM.

“Business information management is the means by which an organization efficiently plans, collects, organizes, uses, controls, disseminates and disposes of its information, and through which it ensures that the value of that information is identified and exploited to the fullest extent. It is a corporate responsibility that needs to be addressed and followed from the most senior levels of management to the front line worker. Organizations must be held and must hold their employees accountable to manage information appropriately and responsibly.”

BITA drives me bonkers

This Business IT Alignment thing drives me bonkers. Do we agree on what we mean by it? BITA is surely just a means to a goal. The goal is about getting value out of IT and BITA is ‘the degree to which IT as a business asset provides value’. I believe that it boils down to two questions:
1. Are we spending the right amount of time and money on IT (or should we be spending more or less on other business assets such as land and labour)?
2. Is the time and money spent on IT, well spent?
The first one is about decision-making, the second is about execution. Both depend on many factors for which people in both the business and IT are responsible.

Decision-making: We need the right business people taking well-informed decisions about critical IT domains in order to create an appropriate mix of value, costs and risks from a business perspective. And IT people have a responsibility to inform the business people in a way that they can apply the knowledge. I like the metaphor of power assisted steering here: the business steers and IT makes it easy to steer.

Execution: It’s all about competences and relationships. And I don’t think that competences are the bottleneck. Technical people (not only IT, just think about some medical specialists) are notoriously insensitive to human needs. And if there's no meaningful relationship, there's no trust. And if there's no trust and if you don't think that's your first priority, then you've lost the plot.

So invest in the relationship by showing genuine interest (and as a by-product, discovering what the business actually does instead of what you imagine they do or should be doing in an ideal world) and by demonstrating personal integrity (set realistic expectations and ensure that you meet them or managed them to avoid unwanted surprises), otherwise accept eternal frustration from being misunderstood and wallow in your victimhood. Steven Covey: seek first to understand, then to be understood. And if your relationship is really on the rocks, get a BITA marriage counselor. Or divorce and move on. The kids will understand. Really.

Scope of change

When scoping a process improvement project I use this checklist to talk the customer though the various elements that might have to undergo change. 
What's does he/she want changed in the IT department? Will anything in the user organization have to change as well? Do the information systems also need to be changed, for instance the procedures or the documentation? Are we just talking about making process descriptions for (quality) managers or are the practitioners actually going to change their way of working, therefore entailing change of behavior? In which case we're also talking about changing habits and 'attachments'. Is the IT department introducing new services or repositioning itself, for instance as a business partner? Is the headcount going to change? Their knowledge and skills? Roles and responsibilities? Tooling? 
I strongly recommend using something like this so that you can start with a decent scoping. You'll probably run into scope change along the way but at least you've got a frame of reference to support the revision.

Information management health check

If the business can answer most of these questions positively, they're probably doing better than average:

•          Do we know how much do our information systems cost – and is that normal?

•          Are the systems being used properly?

•          Do we know what do the users think about our information systems?

•          Do we know what information the business needs, now and in the future?

•          Is the information part of business projects delivered on time?

•          How much budget is available and are we making justifiable and predictable investments?

•          Do the information systems (incl. data) have business owners?

•          Have we effectively delegated responsibility for providing IT services?

•          Does IT give us enough strategic value?

Dinner with Betz and Sussna

After Machteld Meijer having hosting Charlie Betz and myself for breakfast in January this year in the Netherlands, Charlie very kindly took me out for dinner in his home town of Minneapolis on Aug 21st 2012, inviting Jeff Sussna, another local mover and shaker, to join us. 

Mark, Charlie, Jeff

A selection of the topics we discussed follows.

• Whether IT is any different from HR, legal etc. in the degree to which they say no to the business.
• That 'IT' is often use just to refer to the organization that's responsible for the infrastructure, pushing the application group towards the business.
• The core competence of apps people is abstraction, something that isn't as dominant, if at all, in the infrastructure (or ops) domain. Turing talked about the division of IT into masters and servants in 1953. Abstraction is also something that business people often struggle with, making 'programming' with business rules a challenge.
• That axiomatic thinking isn't what you need to deal with complex adaptive systems in which behavior is emergent. And if this even baffles Betz, surely the rest of us are doomed ;-)
• Building resilient instead of reliable systems.
• Systems are getting so complex that it's irresponsible to think that IT has got them under control – but who dares to tell the business?
• Jevons paradox wrt clouds – more expensive because of more use.
• Rogue IT can be regarded as a demand request.
• Mark Burgess' key insight is that IT can no longer rely on an axiomatic (first order predicate logic) foundation. Quote: "The field of system administration meets an unusual challenge in computer science: that of approximation. Modern computing systems are too complicated to be understood in exact terms." Again, IT is not scientific and most IT people do not understand science. It is logical without being scientific, an odd paradox that we think leads to much dysfunction. 
• The inability of IT (people) to comprehend the importance of probability.
• Quantum IT: you don't know if you have an incident until you look inside the box.
• DevOps filling in the gap that Agile doesn't address.
• That DevOps also deals with the business (not just the apps-ops connection).
• The need for T-shaped people: depth of knowledge complemented by broad interest.
• That IT started off with people who multi-tasked on both applications and infrastructure, then specialized and introduced a division of labor, but now seems to be reintegrating tasks.
• The confusing misnomer 'no-ops', referring to the fact that somebody else (e.g. cloud supplier) deals with ops. Might be better termed app-ops.
• The shift of IT from order takers to marketeers (markITeers?)