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

Imagine a company department that works the following way:

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!

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. 

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.

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.

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

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.

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.

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!