21 December 2012

So why are you in IT?

The ASL BiSL Foundation’s annual Focus on Demand conference was sandwiched between two tragic events: the untimely death of Remko van der Pols, founding father of the ASL and BiSL frameworks, and the abhorrent massacre in Newtown. Events like these tend to put things into perspective, with the ‘why’ question taking central stage. Traditionally, when asked for the corporate justification for their activities, IT folk have tended to defer to the business. Whether it’s a project or a process, if the business wants it, they’ll do it. They’re order-takers. But every day my conviction is growing that “we’re just taking orders” or “we’re just following the process” isn’t good enough. Charlie Araujo brought this up during the BookStore simulation. Playing the role of the business, and irritated by the incessant questions that were being fired at him, he said “I don’t want questions, I want solutions!”. The questions should be implicit. If not, then you’ve lost the plot.

As a response to the criticism of  enterprises prospering at the expense of their communities and being a major cause of social, environmental and economic problems, Harvard Business School’s Michael Porter came up with the concept of ‘shared value’. He believes that business can escape from an outdated, narrow approach to value creation. They can bring business and society back together if they redefine their purpose as generating economic value in a way that also produces value for society by addressing its challenges. Just as this shared value approach reconnects company success with social progress, I believe that IT can play its part by looking beyond the demand-supply interface and involving itself more in influencing IT decisions for the better. Using IT to benefit society. At the end of his keynote, Chris Dancy used the word ‘humanity’. Why not? Think big.

Yes, of course it’s the enterprise’s responsibility to make these choices. But it’s also your personal choice to work for that enterprise. While the current climate can make this seem like a cheap shot, each of us can take a stand in our own arena, taking our individual circumstances into consideration. 

Five challenging but rewarding steps. 1. Think about your core values. 2. Understand the specifics of your business. 3. Understand the generic opportunities that IT offers. 4. Combine the three. 5. Sell it. Daniel Pink talks about three factors that determine job satisfaction: autonomy, mastery and purpose, and all of these apply to the five steps. For IT, there’s more to ‘purpose’ than achieving high customer satisfaction, independent of whether the customer’s in healthcare or gun running. So why are you in IT?

02 December 2012

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. 


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'.

17 November 2012

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.”

14 November 2012

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.

12 November 2012

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.

14 August 2012

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?

30 July 2012

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?)

11 February 2012

Reinvent IT Service Management and embrace Occupy IT

Demand-supply fetish

I'm afflicted with a congenital demand-supply fetish and obsessively try to determine whether people are fulfilling a demand (usually business) role or a supply role. Some people find this annoying but I just like to pinpoint responsibilities. Sort of helps if you know who's doing what for, with or to whom. Another distinction that I find useful is on de supply side. Has the supplier taken on the responsibility of fulfilling the client's needs or 'just' to supply the goods or services that the supplier has defined. In other words, as a client, is it just my responsibility to specify what I want (in the case of a 'custom supplier') or do I also have to establish whether the supplier is providing something that fulfils my needs ('standard supplier')?

Reinvent IT Service Management

As with all technology, IT passes through the standardization / commoditization stages of innovation, custom product, standard product and service. With applications, we're clearly well into the services stage. And there are a multitude of standard suppliers who do their thing. Not my thing. So it's up to me to 'agree & adapt' to their services and conditions. Caveat emptor: let the buyer beware. Although these services (e.g. SalesForce.com) also need to be managed, we seem to use the term IT Service Management mostly to denote the organization that is responsible for providing the services (sometimes I prefer 'functionality') that the end-user organization needs. In other words the IT Department. And the added value of the IT Department is that it is a provider of custom services. They do my thing, not their thing. This is not to be taken lightly. Caveat vendit. Let the seller beware!

And if they don't do my thing, they should seriously reconsider their position in the ecosystem. Because no way can they compete with the specialized standard service providers in the marketplace. They should acknowledge, accept and even embrace the multitude of standard services that are available and reinvent themselves. In order to survive they have to move up the value chain towards the business and fulfill three roles: business partner, service integrator and broker.

Role 1: Business partner

First they're a business partner and even I must admit that my demand-supply fetish has to be revisited. The IT Department departs temporarily from the supply dimension and jumps though a time warp to the demand side, but in an advisory role – the business is still in charge. Closely collaborating with the business and thinking up how IT can be used to fulfill business needs. Understanding the IT related processes ('information management': check out the BiSL framework) that the business execute. All of this is more easily said than done. It needs not only business knowledge but also business empathy in order to tune into the business' wave length. Because business people ("normal people" as my wife calls them) differ in so many ways from IT people. Sorry. My paper IT is from Flatland, Business is from Spaceland goes into this topic in more detail and another paper, IT Spring, takes a look at commoditization and the democratization of the user community. More IT savvy and more demanding. Watch out for 'Occupy IT'.

Role 2: Service integrator

The next role refers back to the custom service provider, as opposed to the standard service provider. Custom service providers add value by ensuring that they provide me with services that fulfill my requirements and they realize this by assembling/integrating standard services and by creating custom services for the parts that aren't available as a standard service. Before they create a custom service they have of course given the business the option of an inferior but considerably cheaper standard service. Sometimes it's better to change the business to adapt to a standard service. The fact that it's an imperfect solution annoys IT people tremendously and, again, I refer you kindly to the Flatland/Spaceland paper. This new role need considerable collaboration skills to deal with an increasing number of third parties who usually deal with you on their conditions, not yours. Another skill is the ability to see creative combinations of services and to integrate these. And finally you need to have and maintain an overview of the complex ecosystem of services that are used plus an overview of what's available in the marketplace.

Role 3: Broker

The third and final role of this reinvented IT Service Management is the function of broker. Some standard services don't have to be integrated with other services in order to provide the required business functionality – they work well stand-alone. But there's added value in ensuring that they're acquired at the right conditions and that they're still the best option to use – things changing so quickly as they are. Procurement? Yes, but more than that.


So IT Service Management is on the move. Under pressure on the supply side from suppliers of standard services in the marketplace and on the demand side having to deal with increasingly IT savvy and demanding users. Reinventing itself to move from supplier to business partner. Moving up the value chain and embracing Occupy IT.

21 January 2012

Breakfast with Betz

Machteld Meijer and Mark Smalley had the pleasure of meeting up with Charles Betz for a breakfast discussion on Saturday 21st January 2012. Charlie is based in Minneapolis in the USA and a highly respected member of the IT community. He was on business in Europe and found time on his way from Antwerp to Amsterdam to exchange thoughts with a couple of members of the of the of ASL BiSL Foundation.

The wide-ranging discussion covered fundamental topics such as the difference between information (referring to Shannon) and information technology; the gray boundary between demand and supply of IT services and when to formalize and divide the demand-supply responsibilities; the MBA fallacy (managers don’t need to understand the underlying business) and the general business management skills that many IT people lack; the lack of a common language between business and IT; IT services (distinguishing between types and instances); IT goods being replaced by services and IT professionals moving up the IT stack; cargo cult science and people regarding IT as magic; the role of the CIO and the often dysfunctional CFO-CIO relationship; the funding of IT (referring to Meyer).