Recently in Business Service Management (BSM) Category

Every once in awhile, something nice happens.  I was referred to Jeff Cerny of TechRepublic for an interview re: my passion and background for business service management.  Jeff did a great job of capturing the core of why I believe the time for BSM has arrived, and why it is a critical consideration in moving IT out of the geek house and into the business partner role.  He's added a few things associated with high tech marketing and presentation skills, but the essence of this interview deals with the importance of BSM moving forward.
For those of you who live on another planet, e.g. Venus, or in another country, which has no interest in what goes on here in the UK, e.g. most of you, we are going to have a General Election soon. This means we get to choose who is going to make a complete hash of running the place for the next five years, whilst they line their pockets with our hard-earned cash. (If you think that's cynical, you should have seen my initial version!)

The UK used to be a superpower. When I went to school, most of the world was coloured pink on my school atlas, which made geography pretty easy. However, things have changed dramatically, although a lot of people here don't seem to have realised that. No, they still think we should be poking our noses into places we don't belong and throwing our (light) weight around. To quote the youth of today - get real.

So it is also with computer systems. You may dearly love the one you built 30 years ago and think it is the greatest thing since sliced bread. You may think the new technology from WhizBang Inc. is fantastic. In some cases, you will be totally right; in others sadly wrong. Being able to stand back and look at things objectively, and with an open mind is very difficult, but I believe it is vital if we are going to squeeze the optimum results out of the limited resources we have available. Always ask yourself "Why?", and "What is it worth?"

I just hope our next government thinks the same way.

Compliance?

| No Comments | No TrackBacks
Imagine a company department that works the following way:

  • There is no external salary control - the department decides how much everyone should be paid and gives itself major raises at regular intervals
  • If the department does not like the tax that they have to pay, they change the rules so they don't have to pay any
  • The expense budget is uncontrolled and they can claim for anything they like 
  • If anyone complains they point you at an obscure piece of legislation from the 1600s and say that their department conforms to that
For those of you don't live in the UK, this is how our Government has been run for many years, and is now the subject of a major scandal. I've just watched Tiger on the TV admit that he thought he was beyond the controls that other mere mortals have to abide by. So the next time someone comes and asks you whether your systems are compliant, please don't raise your eyebrows and think they are wasting their time - this stuff is vital. 

Health and Safety, on the other hand, in this country appears to be controlled by a bunch of morons and has unfortunately become a laughing stock. Petty controls are put in place - e.g. you must not run during a race as you might slip!!! - with the result that everyone thinks the whole thing is a waste of time and money.

So what is needed is a sensible set of rules, enforced via a sensible set of controls. That's why I've always liked the combination of ITIL and CobIT. ITIL giving me best practice ideas of what I should be doing and CobIT to check that I'm doing it right/sensibly. Now where do I find the same thing for Governments and Health and Safety? 

I recently had the pleasure of interviewing Robert Urwiler, the SVP and CIO at Vail Resorts Inc.  Yes, this is the Vail ski resport in Colorado. They also own and manage 5 other mountains, resort hotels and more. It is rougly a $1 billion business. As a side note, I would highly recommend visiting a few of their websites for the experience alone -- I wouldn't be surprised if they win a few design awards. In particular, drop by the Keystone Resort site and check out the immersive video of Prospector run.

I wanted to share a project that was driven by IT initially which resulted in a BSM initiative that has become a significant differentiator for their highly competitive business. The approach landed Vail Reports on the list of CIO's 22nd annual CIO Awards and resulted with Robert on the cover of CIO Magazine.

Tactically Vail Inc. needed to replace an old fleet of bar code scanners that are used to validate guests at lift gates on the mountain. RFID was the natural replacement technology for bar codes and had been used successfully in Europe. It would have been easy to just use what others had already done. But the leadership at Vail wanted to differentiate the guest experience and learn more about guest patterns on the mountain.

The CIO made the case for investing in UHF RFID, which was higher risk and more costly, but met the requirements of the business. What looked like a tactical move to replace older technology resulted in a strategic decision for the business. This is a great example of how BSM principles lead to strategic business advantage. 

Utilizing UHF RFID and Wi-Fi infrastructure, Vail has been able to deliver a unique guest experience at the lift gate and can track guest patterns across the mountain which was not possible before. Knowing where the guests are skiing allows them to execute highly targeted marketing programs to promote offers on and off the mountain. 

For the details on the story see the article in the RFID Journal. 

By Bill Keyworth and Annie Shum

A fantastic BSM article appeared last week (1/18) in InfoWorld entitled "Run IT As a Business - Why That's a Train Wreck Waiting to Happen."  The author, Bob Lewis, identified the futility of IT organizations continuing down the same broken path that is not connecting IT with their business counterparts ...yet he sees too few IT executives who are willing to initiate the necessary BSM changes.  One of Bob's central messages to IT is that "no one inside your company is your customer."  Fairly basic principle ...but highly compelling to initiate change in the way IT performs their labors.

Bob provides some outstanding examples of IT executives that struggle with providing the "same old ...same old" IT services to business people who can't see the benefit of paying what they perceive as premium prices for products and services that they see advertised elsewhere for a fraction of the cost; or who fixate on short term deliverables that are "good enough" but don't address the company's strategic business opportunity for the longer term; or who won't document requirements in a way that ensures IT can deliver on expectations.   In these cases, IT consistently finds itself in a defeatist catch-up mode.

The article provides some common-sense advocacy that running "IT as a business" ensures that IT doesn't satisfy corporate business needs.  It's an interesting twist to the dichotomy of how BSM is perceived by IT versus how BSM should be positioned and executed by IT.  Bob concludes with a vision on what an IT organization actually does and looks like when it is integral to the business community, and not an add-on cost center that depletes profits.  Again... great BSM article!

Dilbert on BSM

| No Comments | No TrackBacks
The recent Dilbert strip might be too close to reality for many IT shops that have difficulty in justifying their IT management initiatives in a way that has any meaning or relevance to their business counterparts.   Given the highly reactive nature of many IT organizations, the tendency to put "lipstick on the pig" is pervasive and unfortunate.  Moving to more predictive and proactive BSM activites would be a worthwhile alternative ...to say the least. 

Data Relevancy for BSM

| 1 Comment | No TrackBacks
The idea that IT operates on behalf of the business has been around since the time the first international business machines appeared on the horizon. In the early days, it was simply using machine speed and power to complete data acquisition and analysis tasks that much more efficiently or effectively than could be done manually. The concept hasn't changed all that much. But, the technology and potential for contribution has grown as mechanical technologies gave way to the 'smart' and integrated technologies of today.

In the 21st century, business was awash with data ...data that is collected, sliced, diced and presented in a multiplicity of ways. But, somehow the really big payoff remained just out of reach. Clearly, the problem isn't the amount of or access to data. The problem was in the lack of timely, cost effective aggregation and analysis presented as business consumable information.

The first decade of the 21st century, we experienced a beneficial convergence of infrastructure capabilities, architectural implementation and a new understanding between IT and business. Changes in technology, data architectures, maturity in use of the technology combined with a drop in the cost of computing and its support infrastructure to provide the capability to collect, correlate and analyze massive amounts of data from sources and in ways that were previously inconceivable.

The fulfillment of BSM lies in its ability to bridge the communications gap between business and IT operations. That gap has consistently hindered the transformation of IT's data collection and processing powers to services that will seamlessly operate to support and enable successful enterprise operations. It isn't simply a matter of mindlessly adding instrumentation to collect more and more data. It's about improving data quality by identifying and eliminating irrelevancies. It's about improving the quality of communication and cooperation to effectively leverage existing resources. And, it's about focusing on representing the beneficial impact of technology on the measures of business success.
(Co-authored with Jasmine Noel) Cloud computing makes CA's acquisition of Oblicore interesting because cloud services without serious level contracts (....or a BSM orientation) are an enterprise disaster waiting to happen. Cloud Service providers (be they public, private or hybrid) will need business service management solutions capable of delivering against business-oriented SLAs. Cloud service users will need such solutions to help them make a wise choices from a confusing array of options.

The problem is two-fold, first Cloud implementations transform monolithic IT service delivery into a dynamic supply-chain with volatile interdependencies, interactions and impacts between each link. SLAs will be required that can identify, track, measure and report on each segment of the chain. CA has been working on this aspect of the problem under the Spectrum Service Assurance moniker.

Second, there is the translation of business oriented contract terms and requirements into a meaningful and measurable metrics that apply in a Cloud-environment. It will require a combination of creative modeling, impact analysis and metric identification and definition that relate business needs to infrastructure implementation...or a BSM type bridge between the business and IT gap. Oblicore focused its efforts on this aspect of the problem.

If CA can integrate Oblicore's technology with its Service Assurance efforts with minimal fuss then the results should be a very interesting BSM solution to these Cloud services problems.

Read the full commentary at http://ptaknoel.com/research-analysis/commentaries/ca-acquires-oblicore/

See the press release for details on the acquisition of Phurnace by BMC. This acquisition is in perfect accord with the vision articulated in BSM Review on the subject Agile Business Service Management.

'The Man in the Dock' Theory

| 3 Comments | No TrackBacks

Eric Ries has just published a post entitled Continuous deployment for mission-critical applications. In this post he takes a very clear stand on the suitability of continuous deployment to mission-critical applications, as follows:

 

"I want to directly challenge the belief that continuous deployment leads to lower quality software. I just don't believe it. Continuous deployment offers three significant advantages over large batch development systems. Some of these benefits are shared by agile systems which have continuous integration but large batch releases, but others are unique to continuous deployment.

    1. Faster (and better) feedback... Engineers working in a continuous deployment environment are much more likely to get individually tailored feedback about their work.
    2. More automation... Continuous deployment requires living the mantra: 'have every problem only once.'
    3.  Monitoring of real-world metrics... There are huge classes of bugs that "work as designed" but cause catastrophic changes in customer behavior. My favorite: changing the checkout button in an e-commerce flow to appear white on a white background. No automated test is going to catch that, but it still will drive revenue to zero. Continuous deployment teams will get burned by that class of bug only once. 
    4. Better handling of intermittent bugs... For example, consider a bug that happens only one-time-in-a-million uses. Traditional QA teams are never going to find a reproduction path for that bug. It will never show up in the lab. But for a product with millions of customers, it's happening (and being reported to customer service) multiple times a day! Continuous deployment teams are much better able to find and fix these bugs.
    5. Smaller batches... Continuous deployment tends to drive the batch size of work down to an optimal level, whereas traditional deployment systems tend to drive it up."

I could not agree more - continuous deployment is very effective as a software quality improvement strategy. Whether you do BSM, ERP, transaction management or any other mission-critical application, thoughtful continuous deployment is an excellent way to go. The laws of software engineering apply to any kind of application you might be developing and deploying.

I believe, however, we might have a metrics problem on our hands. What often happens is that continuous deployment flies at the teeth of the 'Man in the Dock' theory. When a major disruption happens, we look for a single point of accountability instead of deciphering the complex pathways to the disruption. Such a theory in use, of course, leads to less frequent deployments which in the long run adversely affect software quality.

A major task for Agile Business Service Management is the development of metrics that take us away from 'The man in the Dock' mindset. These metrics need to satisfy two criteria:

  1. Map software quality to customer value.
  2. Help us realize that service disruptions are systemic. They are a matter of complicated pathways, not of the incompetence of one individual or another.

The Future Behind Us

| 1 Comment | No TrackBacks

In Backing into the Future, Bernard Knox makes a fascinating observation:

"The early Greek imagination envisaged the past and the present as in front of us - we can see them. The future, invisible, is behind us... Paradoxical though it may sound to the modern ear, this image of our journey through time may be truer to reality than the medieval and modern feeling that we face the future as we make way forward into it."

How appropriate this mental model is in view of the recent and no so recent past. As pointed out by Perez, we should view the burst of the "dot-com bubble" in 2000 and the financial collapse in 2008 as a double bubble which is part of the fifth techno-economic cycle. Building on this premise. I made a bullish 2010 prediction for the Cutter Consortium. Here is the botton line from this prediction:

"I expect 2010 to be the first year of a prolonged golden age. Serious as the various problems we all are wrestling with after the 2008-2009 macro-economic crisis are, they should be viewed as systemic to the way a new generation of revolutionary infrastructure gets assimilated in economy and society." 

Likewise, my prediction for The Agile Executive is optimistic with respect to Agile Business Service Management:

"Agile breaks out of Development into IT (and beyond) in the form of Agile Infrastructure and Agile Business Service Management."

Click here for details of my techno-economic prediction for Cutter, here for my Agile-focused predictions for The Agile Executive. 

Is your company’s IT department passionate about their work?

If not, then perhaps you’re not letting them solve problems…  Passionate IT solves problems - not just for IT, but for the business.

More from John Hagel on pursuing passion »

Colleagues Rico, Sayani and Sone recently published a book entitled The Business Value of Agile Software Methods: Maximizing ROI with with Just-in-Time Process and Documentation. Based on hundreds of systemic research studies, the authors cite some very impressive numbers. Even their least impressive numbers are awesome. For example:

  • Agile methods ROA 1.6X more than traditional [software] methods
  • Agile methods NPV 2.3X more than traditional [software] methods

We do not have anything like this rigorous study in the nascent field of Agile Business Service Management. I would, however, allow myself to suggest that the gains to be had through Agile  Business Service Management might be as impressive. The three main reasons for my suggesting so are as follows:

  • Deja vu. Much of the gain in applying Agile methods to software engineering comes from breaking the metaphorical wall between development and test. Likewise, the application of Agile principles, technologies and practices to Business Service Management leads to breaking the metaphorical wall that seperates development and test from operations.
  • Life cycle economics. As observed by Boehm, defects fixed during the Operations phase can be two orders of magnitude more expensive to fix than during the Requirements phase, one order of magnitude more expesive to fix than during the Code phase.
  • Data-driven decision making. Agile deployment enables "real time" customer feedback. Hence, the quality and timeliness of business decisions are greatly improved.

I don't really know whether colleague Dr. David F. Rico might have an interest in Agile Business Service Management. I will most certainly try to induce him....

I recommend the following acid test in The Agile Executive post entitled Prior to Sprint Zero: A Note on Jakob Nielsen's "Agile User Experience Projects":

If you consider this "prior to sprint zero" approach a bit heavy-handed, I would offer a simple test to assess its reasonableness. Play with a number of IT Service Management (ITSM) products that you picked in random. Once you did so, compare the numbers of those that clearly have services at their core, to the number of those that integrated services into their user interface as an afterthought.

Granted, the test was originally conceived to make a point with respect to the timing of user interface architecture tasks in the cycle of Agile software development. However, it is actually applicable to ITSM products in general. For example, the results of the test cited above are indicative of how far a system management vendor shifted his mindset, architecture, technology and practices from servers to services.

I would actually go one step further to suggest the user interface architecture test as a reliable "bullshit detector" for vendor hype. Whenever a fundamental application paradigm change takes place, the degree to which a vendor embraced the change can be tested by examining the orientation of the user interface. As a potential customer, it tells you how seriously the vendor walks the talk with respect to embracing paradigm changes and investing in so doing in earnest.

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.

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

The Joys of Real Hardware

| 4 Comments | No TrackBacks

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.

voiceofcio.gifI 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:


IBMCIO.gif

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.

So IT is increasingly viewed as strategy enabler, but not everyone is on that bandwagon.  The low-growth companies are, as might be expected, focused on bean counting and fire-fighting.

Visionary IT, on the other hand, is focused on strategic initiatives:

cioinitiatives.gif

What's interesting here is that for high-growth companies, IT leadership is critical to both decision-making and innovation which are key to value-creation.  They're focused on the future of the business.

When I read this, I immediately thought of VG's three box strategic framework for how companies compete:

According to VG, "many organizations restrict their strategic thinking to Box 1. This tendency has been particularly acute in the past two to three years, as most leaders have emphasized reducing costs and improving margins in their current businesses."

That seems to square nicely with the IBM findings.

So it seems like the role of the CIO is largely determined by the culture and mindset of the executives running the company.  It's pointless trying to be strategic or innovative in a company that focuses on Box 1.

Where does business service management fit into all of this? IMHO, the CIO who sits at the decision-making table (in boxes 2 and 3) is practicing BSM.  The ones who are stuck in Box 1, not so much.

Once again, I suggest you find some time to read the report >>

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.

Internet-Scale BSM

| 2 Comments | No TrackBacks

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!

Bad IT = Bad CEO?

| 9 Comments | 1 TrackBack
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!

About this Archive

This page is an archive of recent entries in the Business Service Management (BSM) category.

Book Reviews is the previous category.

Business Strategy is the next category.

Find recent content on the main index or look in the archives to find all content.

Pages