November 2009 Archives

A survey of UK workers reveals that IT folk are the least fit of all job positions.  Nice.  And that's in the UK, so you can imagine what the stats are like for the US - in states like Texas, for example!

In the interest of "science," we decided to take a close look at the daily menu of your average service-desk employee in a Fortune-100 company. Here's what we discovered [results may vary depending on geographic location]:

7 am:
- Tacquitos with eggs and cheese (2)
- Bagel with cream cheese
- Bag of donut holes (small)
- Starbucks Iced-Frappuccino

8 am:
- Dr. Pepper (to stay awake during first meeting of the day)

9 am:
- Blueberry muffin (2-3) with butter

11 am:
- Dr. Pepper (to stay awake during second meeting of the day)

12 am (working though lunch):
- popcorn (because it is free, and it makes the boss feel guilty as he step out to lunch at the steak house down the street)
- Starbucks Iced-Frappuccino

1 pm:
- chocolate chip cookies (because they were just sitting there)

2 pm:
- Smoothie break at Smoothie-King

3 pm:
- lunch at an all-you-can-eat buffet (typically fried seafood, fried Tex Mex, or fried Chinese)

5 pm:
- Dr. Pepper (to stay awake during fifth meeting of the day)

6 pm (the drive home):
- Starbucks Iced-Frappuccino

8 pm (hanging out with nerds at the Pig'n'Whistle):
-  fried anything
- Dr. Pepper

10 pm (back home watching TV):
- bowl of pista-pistachio ice cream
- Dr. Pepper

[repeat next day]

Not exactly conducive to lean IT, is it?  Maybe they need to include dietary guidelines in ITIL v4!

I have started a mini-series in The Agile Executive on the subject of innovation. Part I discusses new forms of experimentation. Part II is about US national policy. Part III, to be posted early next week, will address Open Innovation.

I have preliminary thoughts about Part IV and Part V of the mini-series. I would, however, like to keep the mini-series open to contributions from readers and experts of BSM Review. The number of WW IT professionals is about 15M. Innovation, particulary in Business Service Management, is, I am sure, on the mind of many of them. I plan to tap into the wisdom of this "crowd."

Please post a reply, compose a guest post, or just send an email to isrgat@gmail.com.

Some years ago I wrote a book about making our lives easier, and I am glad to see that a lot of the ideas in there are now appearing as apps on the iPhone. Then when I worked for BMC I wrote a popular blog, which urged people to adopt a Service Mentality, and things seemed to be getting better round the world (not entirely due to me - my timing was just good!). Unfortunately we then entered a nasty recession and things have gone severely downhill as companies strive to save money and hence cut down on service.

I live in the UK, a country which appears to be run by a group of greedy incompetent people, and that means that we probably will probably de drowned by melting polar ice caps before we come out of recession. So I was not at all surprised to see an article in one of our Daily newspapers (Daily Mail) asking:

Infuriating call centres, feeble excuses - who gets YOUR wooden spoon for rotten service? 

The categories where they have asked for nominations are:

1. Overall worst customer service
2. Most irritating call centre
3. Longest time to solve a simple problem
4. Biggest incorrect bill
5. Most pathetic excuse for failing to solve a problem

Anyone care to share a nomination or two?

IMHO there is little point in spending lots of money on IT systems if you treat your customers like dirt, which is why I have always said that BSM is not a set of products or systems - it's a mindset.

 

Back in 2007 when I was still at BMC Software as Global Best Practices Director I worked with their CTO, Tom Bishop who worked on setting up an industry taskforce to set a standard for CMDB connectivity. As always these taskforces take some time to document their goals and objectives and then to actually release a specification. Well it did take 2 years for the specification to be released. Back in July of this year, the Distributed Management Taskforce (DMTF) gave its approval for the CMDBf specification for supporting federated CMDB systems -- or as ITIL v3 says, a federated Configuration Management System (CMS). In this vision, multiple reconciled sources including management data repositories, discovery systems, etc. can provide a cohesive frame to support more effective service management in its broadest, cross-discipline sense.

The CMDBf specification was first released by the CMDB Federation Workgroup in August of 2007, and the DMTF announced the creation of a working committee around the CMDBf specification on November 27, 2007. The Workgroup included BMC, CA, Fujitsu, HP, IBM and Microsoft in Q3 200. Some vendors left out wondered why they weren't included, but in this case small is beneficial. Keeping the group small was considered essential if progress was going to be made. Knowing how difficult it is to get busy people from different organisations together, I would agree that keeping it small and focused was the only way to get results, and 6 of the largest software vendors in the ITSM space is small, but powerful.  

Looking at the specifics, the CMDBf specification leverages SOA (Service Orientated Architecture) standards such as SOAP (Simple Object Access Protocol ), XML (Extensible Markup Language) schema, HTTP (HyperText Transfer Protocol ), and WS-I (Web Services Interoperability). It describes how APIs (application Program Interface) and calls to CMDB registration APIs can be pre-built into the management data repositories (MDRs) of management tool set providers. In this way, a federating CMDB can access data from a multiple MDRs using the query service defined in the specification. MDRs can push data to a federating CMDB using a registration service. The specification also supports CMDB-to-CMDB federation, as CMDBs can extract data from each other using the query service. In essence, the specification supports data access in a federated mode, as well as bi-directional data sharing across federated CMDBs.

Boy we like using acronyms! This is the first time I've really seen the term "Management Data Repositories" (MDR) used seriously and it's really what the CMS is all about, in my opinion. A term we should use when explaining the CMS to the Business, as it will resonate much more with them.

If such a vision is to become reality, then the industry needs a more consistent approach for federating multiple sources than the current rag-tag mix of adapters, APIs, and other technologies that still make federation, especially federation across multiple brands, such a painful experience.

For more information check out the DTMF announcements here >>

Colleague and friend Sebatian Hassinger sent me Jeff Dean's presentation Designs, Lessons and Advice from Building Large Distributed Systems. The presentation is fascinating in quite a few ways, not least of which is the (implied) statements it makes about requirements for business service management at large scale. For example, here is an excerpt from the slide entitled The Joys of Real Hardware:

Typical first year for a new cluster:

 

~0.5 overheating (power down most machines in <5 mins, ~1-2 days to recover)

~1 PDU failure (~500-1000 machines suddenly disappear, ~6 hours to come back)

~1 rack-move (plenty of warning, ~500-1000 machines powered down, ~6 hours)

~1 network rewiring (rolling ~5% of machines down over 2-day span)

~20 rack failures (40-80 machines instantly disappear, 1-6 hours to get back)

~5 racks go wonky (40-80 machines see 50% packetloss)

~8 network maintenances (4 might cause ~30-minute random connectivity losses)

~12 router reloads (takes out DNS and external vips for a couple minutes)

~3 router failures (have to immediately pull traffic for an hour)

~dozens of minor 30-second blips for dns

~1000 individual machine failures

~thousands of hard drive failures, slow disks, bad memory, misconfigured machines, flaky machines, etc.

The bullets listed above resonate with my Agile Business Service Management thinking. They can simply be thought of as the reality underlying BSM at scale. The scale and scope of operating on top of such envirnments necessitate new techniques in BSM. For example, Jeff discusses Protocol Buffers as one such technique used by Google to attain the requisite efficiencies. Likewise, treating infrastructure as code is - as we say in chess - a practically forced variant. In both cases, the traditional wall between development and operations is moot.

I don't generally tell people that a report from a vendor is a "must read," but in this case it is. 

I'm referring to IBM's The New Voice of the CIO report, a global study of 2,598 Chief Information Officers (CIOs) released back in September of this year. 

The report (registration required) highlights the somewhat schizophrenic roles that CIOs the world over are under pressure to take on, depending, of course, on the nature of the burning issue at hand.  The report identifies six distinct roles that CIOs must learn in order to keep up with the requirements of the job:



The bright side of the report:

The voice of the CIO is being heard in new ways--as CIOs are increasingly recognized as full-fledged members of the senior executive team. Successful CIOs are much more actively engaged in setting strategy, enabling flexibility and change, and solving business problems, not just IT problems.

Today's CIOs spend an impressive 55 percent of their time on activities that spur innovation. These activities include generating buy-in for innovative plans, implementing new technologies and managing non-technology business issues. The remaining 45 percent is spent on essential, more traditional CIO tasks related to managing the ongoing technology environment. This includes reducing IT costs, mitigating enterprise risks and leveraging automation to lower costs elsewhere in the business.

UPDATE: we now have a BSM Maturity Model (registration required) >>

These may not be the latest and greatest, but we found two more depictions of maturity models related to Business Service Management from HP and IBM. 

I'm sure they have others, but this is what we found (scroll down to the end of the post).

Stay tuned for more.

Continuing my thoughts on Bad IT = Bad Communication, I would like to give you an analogy.

Imagine you are a doctor and you have 3 patients and you have to decide (rapidly) which one to "work on" first - like the beginning of MASH when the helicopters come in.

The first patient has a blinding headache, the second one has stomach pains and indigestion, and the third one has a knife stuck in his arm. I am sure your immediate reaction is that you would treat the man with the knife first?

OK, now some more background. The first patient is the CFO, who pays your salary. The second is the VP of Sales, who won't get off the 'phone and is driving everyone mad,  and the third one is the boss of HR, who is currently selecting people for redundancy. Who goes first now?

Some more. The CFO says he must get the latest sales figures to the CEO immediately, the Sales VP is trying to launch a new sales campaign and has a TV interview lined up, and the boss of HR has just fainted. Changed your mind yet?

Now, you happen to know (because you are on the board) that the sales figures were printed last night and they probably haven't changed significantly today as we haven't got near the end of quarter yet, the HR man is not bleeding as your nurse is applying pressure and tending him, but your TV campaign was signed off last week and if you miss this slot the company has just wasted half a million dollars. Which one comes first now?

And people expect IT to make the right decisions without the facts?
 

Business Service Management, Six Sigma and your IT Compliance Program
by Chrisan Herrod
Institutionalizing a culture of continuous monitoring as an essential part of IT compliance management can be achieved using the best practices of the Six Sigma methodology.  IT compliance should be treated as a critical corporate program and to that end Six Sigma can be used to assist organizations in implementing a robust and effective information technology compliance program and culture. »

Business Service Leadership: The Time is Now! [Part 1]
by Peter J. McGarahan
Business Service leadership is about doing the right thing for the right reasons and making fact-based decisions. It's about challenging conventional wisdom and having the moral backbone to stand up for doing the right thing for your customers and the people that serve them. »

Colleague and friend Annie Shum shared with me fascinating data from her research on Cloud Computing. According to Annie, the economics of mega datacenters are compelling:

The study concludes that hosted services by Cloud providers with super large datacenters (at least tens of thousands of servers) can achieve enormous economies of scale of five to seven times over smaller scale (thousands of servers) medium deployments. The significant cost savings is driven primarily by scale.

In the context of BSM Review, the obvious question this study poses is the tweaking of Business Service Management to respond to and cope with operational and business challenges on such a scale. For example, at smaller scale configuration drift might be laboriously manageable through traditional techniques. For super large datacenters, however, it is a compound problem:

• Exception handling is prohibitively expensive at large scale.
• Scale economics are likely to diminish (due to configuration drift problems). 
• The associated risk could be lethal. Large scale configuration drift might go beyond loss of data in an IT department - the datacenter operator might lose customer’s data.

Knowing Annie, I have no doubt she will elaborate at length and depth in this blog on various Cloud Computing aspects of Business Service Management such as Virtualization Sprawl. (See her recent article A measured Approach To Cloud Computing: Capacity Planning and Performance Assurance for the first “installment” on this important topic).   I will do the same with respect to Agile Business Service Management at grand scale. For example, an intriguing question is the setting, modus, operation and governance of the Application Support Team in this kind of environment. One can actually view it as a Venn diagram:

• Cloud Operations on one ‘circle’ 
• Customer Application Development on another
• Application Support in the intersection 

Stay tuned!

I've just been reading about the interview with HP CEO Mark Hurd at the Gartner Symposium. He said that when he hears top executives tell him that their IT is bad, his first reaction is that the real problem is probably a bad CEO. He was actually answering a broad question about the interplay between IT and business processes, and whether HP should be aiming its messages at CEOs focused on business outcomes or IT leaders focused (according to the question) on technology. An interesting question, and as the audience was predominantly CIOs, I can understand the inclination to push the blame elsewhere, but I feel the Bad IT = Bad CEO answer is way too simplistic.

Where I feel the answer actually lies is Bad IT = Bad Communication. By that I mean that  IT will never be good if the fundamental communication has not happened at a senior level to define what the company actually wants from IT, and how much they are prepared to pay for it.

Many years ago I read a book called The Myth of Excellence: Why Great Companies Never Try To Be The Best At Everything.  Apart from some very sensible stuff about what consumers really want - Consumers are fed up with all the fuss about "world-class performance" and "excellence", what they are aggressively demanding is recognition, respect, trust, fairness, and honesty - they also recommend that companies be excellent at one thing, e.g. service, differentiating on a second, e.g. availability, and be average on the rest, e.g. price, quality etc.

Now, for me that makes perfect sense for companies and for IT. If you wander into McDonalds you do not expect gourmet food, but you do expect it to be quick and cheap. If you go to buy a Rolls-Royce, you expect to be treated like royalty and you know it is going to cost you an arm and a leg. The problem I find in many companies is that the CEO asks for "Roll-Royce" IT, but is only prepared to pay "McDonalds" prices.

So, for me the starting point is actuallly agreeing just what this company's strategy is, which systems are vital to its survival, prioiritising the others, and making all of those work at the correct service levels. For this to work, the CIO must be reporting directly to the CEO, and must be able to hold conversations with finance, sales, marketing etc. to understand what their business requirements truly are, and communicate these to his/her people in IT. Everyone he/she talks to in the business will say they require 24x7 systems with instantaneous response. Not true. Ask why, and ask some brutal questions like:

• If this system is down, is anyone's life or safety threatened?
• If this sytem is down, how much money are we losing?
• If  this system is down, is there an alternative, and how long can we run with it?
• Do you truly need your people/customers to be online at 3am?
• How much is this sytem worth to you?
• Why is your system more important than anybody else's?
  

I was visiting an IT Manager in Germany some years back, who was being asked to provide 3 or 4 hours extra online service every day (the batch housekeeping cycle had grown so much over the years that it was taking too long). I asked him much those 3-4 hours were worth and he told me he didn't know, so I told him not  to bother as the business would perceive no benefit in his providing the solution, and hence would not sign off for the software he needed to buy. He left the room to ask his boss what the solution was worth and came back 15 minutes later. The bad news, his boss didn't know either; the good news, they were going to run a task force next week to find out. We returned at the end of that week to be told that the 3-4 hours were worth €20M a year. I grinned at him and said, "Great, the software only costs €19M!", which fortunatley he realised was a joke. It was actually way less than €1M and was signed off very rapidly as the business now could see the cost and the benefit.

That is what I mean by communication.  

Here's a free Cloud Storage Toolkit for Service Providers to help them answer the question: "Should we enter the Cloud Storage marketspace?"

We should do one for Business Service Management - a toolkit like this for the CFO and CIO!

One way to decide which industries are the leaders in Business Service Management (BSM) is to look at the industries which are most interested in cloud computing. Perhaps that's too much of stretch, but if you go with this assumption for a minute, here's what we get:

   1. Financial services (12%)
   2. Manufacturing (10%)
   3. Business and management services (10%)
   4. Telecommunications and equipment (9%)
   5. Government (7%)
   6. Insurance (6%)
   7. Oil, gas and electric (5%)
   8. Professional/specialized services (5%)
   9. Schools and education services (4%)
  10. Food (4%)
  11. Retail (4%)
  12. Healthcare (4%)
  13. Media (3%)
  14. Chemical and pharmaceutical (3%)
  15. Military and National Security (3%)
  16. Freight services (2%)
  17. Energy management (2%)
  18. Membership organizations (2%)
  19. Commercial physical research (1%)
  20. Other (4%)

The data comes from Thomas Bittman's blog post: "Cloud Computing Inquiries at Gartner".

UPDATE: we now have a BSM Maturity Model (registration required) >>

One of our unstated goals at BSMReview.com is to create a maturity model for Business Service Management and beyond. Of course, this maturity model may differ slightly by industry, but the idea is to create a model which is good enough to create a "common roadmap" for IT and its business partners (yes, we will include cloud services).

To start the discussion, I've brought together some of the traditional thinking from IT 1.0, and some "edge insights" from people like JSB.

To start, let's look at Gartner's IT Management Process Maturity Model from 2005. Looks familiar, doesn't it? What should Level 5 and Level 6 look like?