Business Service Management Hub

Business Service Management practices have the greatest chance of success when:

• The solution provides several different views of the same data. The technical team needs a few different views (top down, bottom up, inside out), the end users of the systems (internal or external customers) want to see the services they are using along with the health (email, payroll, etc), management wants to see impacts to the business, revenue related metrics (trade volume).

• Granular security control is needed to control the depth that end users are allowed to drill in as well as controlling which users are able to perform actions such as Acknowledging an alarm.  While the BSM solution must be able to represent the service from end to end, there rarely is a reason to have an executive drill down and look at the performance metrics of a network card on some obscure server.   Showing that a single node of a cluster is down is important to some users, this is useless data to others.

• The solution fully understands health of the Service. Integrating with the JUST the top management tool may provide ‘all’ of the alerts within the environment, it won’t provide easy drill down into the underlying tool reporting the failure in order to get at additional details or command and control, it won’t tell you to fix Service A over Service B, it won’t tell you that if you do not reboot server123 in the next 10 minutes you will breach a critical Service Level.

• Root cause is more than determining the router being down is the root cause of the server being unaccessible. While this is useful information, this type of root cause does not always map to why a Service is down.   Don’t get me wrong, it is very important and needed information.   The team responsible for resolving outages need quick answers, they need to be able to to quickly see within the sea or red alerts that this particular server being down is the reason that payroll is down.  Between this server and the 15 other outages, they might want to work on this server first… it’s payday.

• The end users of the implementation are consulted with to understand their requirements. Just because you can set up the view one way doesn’t mean that it provides value to the end users.  They need easy access to the data, they need quick access to other internal tools (knowledge base, help desk, etc).  The solution needs to make their lives easier.

• Start with an important Business Service, or a single important application or one that keeps the CTO up at night worrying about it.   If you start with mapping the one service end to end (as best as possible without getting stuck in a rabbit hole), get an internal win, ROI, etc., it helps map out the next Services, rally other teams to get involved, etc.   Trying to do every service end to end completely automated, etc is trying to boil the ocean, it’s not going to work.   Sometimes a partial view is better than no view.  Stating small and working out from there is key.

One other reason that I purposely omitted is management buy-in.   I feel that it is important, but to get started, it may not require complete management buy-in.   What I mean is, sometimes management buy in is only needed within your own group or department, other management buy-in is sometimes needed in order to expand the footprint or get additional details.   I’ve seen that come along as the BSM team gets wins under their belt.

Okay, don’t be shy, what are some reasons that Business Service Management worked for your organization (or you think you need for your planned BSM implementation to be successful)?   Dashboards, HA/DR, CMDB, Discovery, ITIL projects…

– Tobin

In recent post, fellow BSM Blogger, Lee Frazier, gave The Top Reasons We Have Not Reached SLA Nirvana – Yet. Lee gave a lot of good reasons why we’ve failed to reach that perfect state just yet when it comes to service level agreements (SLAs).

At a session recently at the AIIM/info360 conference, analyst Jarrod Gingras from the Real Story Group gave a presentation on what he considered to be cloud myths. Gingras wasn’t there to sing the cloud’s praises that’s for sure. In fact, using content management as the example, he put a decidedly negative spin on things. That’s not because he wanted to be contrary just for the sake of it. He wanted us as individuals to think through the pros and especially the cons of this approach.

And one of those myths was that you could protect yourself legally via the SLA. Hold on a second! I was always under the impression the SLA was the final abriter and the saving grace of cloud computing. Not so says Gingras and not for any of the 7 reasons Lee Frazier outlined in his post — but because of technical limitations.

He gave the example of a Canadian company that wanted to go with a Cloud solution, but because it was dealing with public records that had to remain inside Canada, and there were no guarantees the files would not be stored on a server in the U.S., they simply couldn’t go with the solution they liked, and no SLA language could have protected them in that instance.

He went to discuss instances where a company needs to ensure that files are deleted completely, a process he referred to as “digital shredding.” Gingras said that to his knowledge there wasn’t a provider that would put such a guarantee in an SLA because it was too hard to ensure. As he put it, “If you think the SLA will protect you [in this instance], think again.”

So perhaps we should an eighth item to Lee’s list.

8. Legal System hasn’t caught up with technology.

As Lee indicated, none of these are necessarily show stoppers for every company, nor are they insurmountable. Some are cultural, some are technical and some are legal. Sooner or later we may actually reach SLA nirvana, but for now we have people like Frazier and Gingras making sure we understand there is no such thing as an iron clad agreement just yet.

Photo by Cletch on Flickr. Used under Creative Commons License.

Why aren’t we at Service Level Agreement (SLA) nirvana?  I mean really, we have had SLA tools for 10, 15 years or more.  You probably have 1 or 10 or more tools that measure SLAs, of which most probably aren’t used.  Why aren’t all of our data centers, applications, servers and everything else just numbers on some dashboard that we just glance at to make sure everything is good to go and that we are open for business?  This troubled me so I decided to make a list of some of the possible reasons:

1.  Too many different tools, specialties and areas of focus

You have tools the measure SLAs for the network, different ones for the infrastructure, different ones for virtual machines, different ones for the cloud, and the list goes on and on.  I think this is one of the biggest issues with SLA reporting.  Who wants to look at 3 – 10 different tools to know if they are passing all of their SLAs?  Or who wants to maintain integration into all of those tools to then pull all of that data into one dashboard?  And then what do you do if someone wants to see historical data?  This becomes a very deep and very big hole. So then companies move on to my number 2 reason.

2.  SLA monitoring via trouble tickets

Wow, this is great.  Finally one source for all of our SLA data.  All we have to do is make sure every issue we have gets opened as an issue in our help desk tool.  Right!  The issue eventually happens that you missed an outage and that outage caused you to violate your SLA.  Then the logic pervades the company something like: ‘If our tool missed that SLA, what else is it missing?’  And eventually: ‘We just can’t trust this tool’ or ‘We just can’t trust our monitoring’ etc.  Also, this is dependant on someone putting in the correct data and time.  Not to say they would purposely fudge the numbers but how long would you say something was down that you were responsible for?

3.  SLA status based on Network availability

Ok, we have all been guilty of it.  If you have ever had to guarantee 5 9’s availability, you reported on just the network availability.  Why?  Because you had the data, your data met what was expected ( 5 9’s ) and you could easily report on it.  Did that meet the intention of the SLA?  No, but (insert your excuse here).  When someone that cares about an SLA defines it as 99.999% availability, they truly want to be able to access the application or business function 99.999% of the time not just the network.  This is discussed further in item 5.

4.  Can’t get the data.

Sometimes we just can’t get at the data that we would need in an automated fashion to allow us to have an SLA  defined.  This may be due to  political or technical issues, I am sure you have seen both.  This must be resolved with either the customer pushing for it or someone pushing for the customer.  In the IT world we live in today, virtually all data is accessible with permission and ingenuity.

5.  Technical vs business data

This one is also very common.  You report you are meeting your SLA of 99.999% up time and the customer says, ‘but it is never available when I need to use it.’  Been there?  Why is this?  Because you are reporting that all of the things that you are responsible for technically, are available.  But when the customer goes to use the application or business service, some piece that he uses and you might not be responsible for isn’t functioning or responding in a timely manner, etc.  Does this make your SLA data wrong?  Yes, from a customer perspective (and does anything else really matter?).  Your SLA must be looked at from the business point of view as much as possible.  Now, you won’t be able to take into account the customer’s home network being down and then having that blamed on you, but if you have enough data showing the service was available from a business point of view, you will be able to push back on them.

What do I mean about monitoring the SLA from a business point of view?  Well, it means a few things and these will change depending on how your customer uses the service.  Through put, response time, transactions processed per time period, synthetic transaction, functional status of all single points of failure for the service.

6.  Data is too bad

When you do get everything monitored and all of the data in one source, sometimes the data is just too bad.  Instead of 5 9’s, you’re showing 5 7’s.  So instead of showing this to the customer or management instead you (insert your excuse here).  This issue can be overcome by either going into the underlying tools and fixing the monitoring to only report outages when they are outages or by fixing your applications and infrastructure.

7.  SLA’s just a punishment tool

I have seen this in many different companies.  You struggle to meet the SLAs and whenever you miss, here comes the stick.  This will then motivate you to either fix the issues or quit reporting.  Too often I have seen the later.  This doesn’t have to be.  Used correctly SLAs can be a carrot and a stick. They can allow you to qualify exactly what is part of the SLA and what hours you are responsible to meet the SLA, thereby reducing/eliminating penalties for off hours and devices that aren’t part of the service or not in you control and then allow you to better meet the SLA for the true service times.  SLAs need to have the carrot to be managed effectively.

As we have remained in a reactive mode for many years, now is the time to turn that around into proactive and aligning with the objectives of the business.  In the next post we’ll talk about how you turn this around and stitch together a successful Service Level strategy.

What would you add to this list of challenges?

Lee Frazier

The Hub Commentary_

The IT Skeptic has an interesting post regarding service levels, running IT as a business, business service management practices.  I’ll cut to the chase on my views on these topics:  internal IT SLAs are meaningless when after the fact reporting the score, IT is not a business and IT is not a profit center.

Why is IT the only unit within a business that we speak of as IT and business?  Do we say sales and the business, marketing and the business, customer service and business, the list goes on and on.  All of the units are the business and all should practice good business service management practices measuring cost and value against the objectives of the business in prioritizing work and investments.

As a product company in technology, I think we may have a unique view.  We produce a product that needs to meet the requirements of the market and customers, sales, support, consulting, marketing, development, testing, etc. – all departments must contribute to the success of any given product brought to market and each is evaluated for cost and value.

Embracing business service management practices is a step in the right direction in breaking the “and” versus it’s just business.  Monitoring and measuring as services and changing the dialog around to cost and value supporting business objectives will advance your IT organization.

Are you an “and” or just business?

Michele

___________________

“Run IT as a business”. I’ve been guilty of using it in the dim dark past. If providing IT is your business, say you are EDS, then that is a special case where the mantra makes sense. But for most organisations, running IT as an internal business is counter-productive if not downright destructive. In most situations, IT is a team-member not a supplier.  (Read Full Article…)

The Hub Commentary_

The other consideration is value to the business and uniqueness to the business.  Those services that are similar across industries and even within your industry, lend themselves to outsourcing.  Cost saving is not the only reason and in the long run, outsourcing is often not cheaper than in-house.  However, decisions need to be made how to best use your in-house resources and right source the commodity.

Outsourcing occurs to drive change.  Some of the change is adherence to standards driving down the cost of services as well as support for services where not all services are created equal.  Both of these changes are difficult to drive from within a business unless there are good business service management practices in place driving cost and value discussions.

It is relevant to consider the right sourcing option for all services and right source the environment to drive change and allow for flexibility.  As part of the sourcing engagement will how you will measure and monitor the service provider.  This is critical to insure perception and reality are in synch.  Managing the relationship of the service provider becomes the new role of IT as part of the end-to-end service provided by the business.

How are you right sourcing IT?

Michele

___________________

There is a misconception that switching to SaaS or a cloud-based IT infrastructure is solely a cost-savings measure. The reality is, most companies today are looking to switch to SaaS for its convenience and simplicity – not cost savings alone.   (Read Full Article…)

I have worked with many customers to track service level agreements in their BSM implementation. I can honestly say that there is only one thing that all of the projects had in common: they were extremely difficult.

Now, I was usually called in mid way through the implementation when the decisions had already been made and the schedule was looking impossible. Or even worse, I would become involved after the implementation had been put in Production and the mistakes were already made.

So why are SLAs so challenging to track and manage?

• Have you seen the contracts? In general, I don’t like contracts. I’m not a lawyer, and let’s face it, they can be difficult to decipher. With SLAs, the first thing that needs to be done is take the contract and figure out what exactly was promised. Then determine what underlying data should be used for the calculations. Then figure out how to get that data from the IT devices and put it all together for the service. These steps are crucial to success, and must all be done before implementing the SLA solution.
• It’s just (total time – downtime)/total time… Saying that a service needs to be available 99% of the time during peak hours is easy. Determining the actual availability key metric is more challenging. You need to determine what exactly constitutes an outage, set up calendars for peak hours, and determine any outages that shouldn’t count (should 1 second of downtime count?). The math for simple availability isn’t difficult, but accounting for all of the necessary factors…well, that is more complex.
• So many numbers…so little time. Since computers have existed, engineers have worked tirelessly to optimize performance. There are limitations to what software can do. One must think about the amount of data to be stored and calculated. For instance, if the data for availability is being stored every minute, and the report shows the last two years of availability metrics, oh, and also real-time metrics, this report is going to take some time to calculate and display the results.

These are the main three challenges I see when working with SLA implementations. Now how do we solve these?

1. Know the data before starting. This sounds like a simple task, and most people think they have a good understanding of all of the underlying devices, metrics, relationships that go into defining the service and the key metric for their SLA. No one would want to start implementing a SLA project without knowing all of the ins and outs. Or would they? People often start modeling their services and tying services to SLAs before all of the underlying infrastructure is in place. A thorough understanding of where this data will come from (monitoring software, trouble ticket systems, back-end databases) is critical because the calculation can change due to the type of data.
2. Determine what details can alter the key metric. Like I mentioned earlier, calculating availability is not difficult. However, determining the total time and downtime can be. Take into account the time periods that determine maintenance. Is there a weekly maintenance period? What is “on time”? Also, what sort of data can be ignored? Are there certain outages that do not affect the service’s availability? Don’t be too generic…try to figure out all of the details that contribute to the SLA’s key metric.
3. Be realistic when creating reports. The dashboards or reports are what we really care about. We need a way to show how the SLAs are tracking. We need a nice way to get a quick visual on what might have failed or what is on its way to failing. Putting 1000 services on a single page is probably not the way to go. Let’s also not reinvent the wheel. If your organization has been calculating SLA metrics for years in an external program, use that data. Why spend the extra time to set up the lower level data to feed into a program that is going to do the same calculation?

Tracking and managing Service Level Agreements will continue to take time and effort. It requires buy-in from many different departments and resources, but BSM should and can simplify an SLA implementation.

I have been asked many, many times “what is the return of a business service management project / practice”.  The answer is honestly, “it depends” on your environment, how much efficiency can be driven into it, how much consolidation, cost of outages, the list goes on.  However, I know that is absolutely the answer everyone despises and I can say by NOT tackling a shift from technology to services, it costs you 2% of revenue (at a minimum) every year.

Thus, I put my old analyst hat back on and thought as an analyst what would I do?  Create a model by which to calculate and start building out a business case.  I have put this basic information into a short presentation and have added it to our resource page.  The first link is a streaming slide presentation and the second is a self contained PDF file with sound.  The PDF file takes a few minutes to download, but you can share the file as you like.

The objective with this slide show was to bring together the statistics from many analyst papers, provide a simple model and understanding of what it costs you to not manage services.  We are at a tipping point this year with agile technology, new deployment options and competitive cost models.

This post goes hand in hand with the previous Featured Post on Finding Your Services.  Know how to identify and classify your services for service value.  The next in that series will be examples of services and the start of a service catalog.

Let me know your thoughts on this!  How are you getting to service value and what does it cost you?

Michele

Click Here – This is the streaming slide show and is just over 6 minutes.

Click Here – This is the self contained PDF download – 8M download, it does take a few minutes to download and start, but you may share accordingly.

The Hub Commentary…

Several good  insights into effective ways to quantify the cost, quality, and value of IT in a way the business understands.

Randy

———————————–

Recently, we brought together 60 CIOs and IT leaders from the Fortune 1000 for our bi-annual “CIO Technology Business Management Council” meeting. The purpose of this event was to provide participants with an opportunity to learn from their peers about how to transform their IT organization into a services oriented organization and run “IT like a business.”  Read full article

There were some funny commercials and some not so funny commercials during the Super Bowl.   The one with Ozzie and Beiber was kind of funny, but I question if the commercial had impact, as in, did it sell something?   If you saw the commercial, which company was the commercial for, what is it that they were selling?

Business Service Management has some of the same challenges.  There are many metrics that IT is watching, but in the end, what is it that they are trying to get out of the metrics, what is it that we are watching in IT?   Does looking at a dashboard with response times mean BSM, does looking at a group of correlated alarms equate to doing BSM, does showing the availability of a database imply BSM… no, but all of it together with even more gets you into the ball park of Business Service Management.

The point is, focusing on the underlying technologies or only specific areas of the enterprise does not allow for IT to have a good understanding of the Services being offered and/or if the Services are up, running and happy.  One of the main objectives of Business Service Management is to have a clear picture of the Services that are being offered to the end customer (internal or external), being able to see the services end to end and understand the overall health and availability.   Don’t allow IT to get distracted by the technology silos, get them focused on the Services being provided to the end users.

Tobin

Tonight we’re gonna manage like it’s 1999.  I was introduced to a prospect today that made me feel like I was in a timewarp.  I was given of of those old school 400 question RFPs  which called for in-depth answers about Event Management – and I mean everything about it, correlation, rules, weighting, etc.  I had two reactions: isn’t this a “done” topic? Hasn’t Netcool been doing this so long that IBM bought them years ago to replace that dreadful T/EC? Couldn’t you have used the time and resources to put together this treatise to just download open source Zenoss and give it a try?

I know I shouldn’t be snarky about customers, but imagine you are a car dealer and someone comes in and wants to know every minute detail about the workings of a seatbelt. Wouldn’t you say “it’s a seatbelt, you click it and it holds you in”?  My next reaction was, “what does this have to do with Business Service Management (BSM)?” and the answer I got was “well, we want the events to be on a dashboard, that’s the BSM part”.  So now BSM = webpage front end?

We asked about managing from a business perspective, for example, if they are an insurance company perhaps managing the availability of claims processing, as opposed to servers and network segments and then spoke of setting service levels based on the business process as opposed to a server being up 99.xxx% of the time?  Actually, my point is that many of us that live and breathe BSM take if for granted that IT shops are up-to-date simply because we strive to stay ahead of the curve with BSM.

Here’s a quick definition, courtesy of Wikipedia.  “Business service management (BSM) is a methodology for monitoring and measuring information technology (IT) services from a business perspective; in other words, BSM is a set of management software tools, processes and methods to manage a data center via a business-centered approach.” Oh, and here’s a link to download open source Zenoss for monitoring, it might save you from having to write a 400 question monitoring rfp:  http://community.zenoss.org/community/download

I find more and more customers taking advantage of the open source technologies and consolidating at the monitoring level to remove costs in order to invest in the business service view.  The dynamic and distributed nature of the environment makes it nearly impossible to understand the monitoring events in terms of business impact without technology to map and present it as a single-pane-of-glass view.

I hope you enjoy my little humor for the week.

Phil

The Hub Commentary_

Hooray!  Great post by Mary on the management and service level management requirements for the cloud.

Michele

___________________

IDC is forecasting that the total cloud systems management software market will total $2.5 billion by 2015. This market will encompass virtualization management, automated provisioning, self serve provisioning portals, dynamic consumption based metering and capacity analysis, service catalogs, end-to-end real time performance monitoring and related management software tools deployed into public and private cloud environments.  (Read Full Article…)

The Hub Commentary_

This article inspired me to write a full blown feature on the subject of vendor management, service level measurement/management/communication and basic business service management practices.  The net of it, IT you own it – no shifting blame to others and no government intervention to set up terms and conditions.  This is outsourcing, plain and simple – manage your provider.

Read the feature commentary in this post.  I do predict there will be a very large outage in 2011, it will be a brand name company, there will be hype based headlines and buried deep in the article disguised in hype will be the root cause – poor contractual terms and conditions, poor vendor management and complete lack of service level measurement keeping perception in check with reality!

Michele

___________________

Back in December, after Amazon summarily pulled the plug on WikiLeaks using its servers for alleged violations of terms and conditions, the CTO of Fujitsu Technology Solutions wrote that the action constituted a serious threat to the business of cloud computing…. (Read Full Article…)

Face it, we all blame our siblings for everything that goes wrong, in my case my baby brother – who towers over me.

Today I’m writing an article instead of just sharing the news having spent a little time consulting and reviewing major sourcing contracts for customers and being trained in the Ross Perot bootcamp of outsourcing early in my career.  What I always find amazing is how much trust a subscriber puts in the provider during the contract negotiation.  On one hand there is trust (I call it naivety) and the provider was successful in creating a relationship, playing on emotion and expertise in the market.  On the other hand it is a recipe for disaster,  a lose – win situation for you the subscriber.  Know your rights.

Cloud computing is still just outsourcing, however, agile and dynamic technology enables a more dynamic purchasing option than in an early adopter phase.  What differentiates the providers at this time is their maturity to manage the services and service level agreements and the flexibility of their services.  When the market matures, we will reach a state of similar services, standard agreements and get down to price based decisions.  Price based decisions currently reflect the “buying” of a customer base and immature operating processes.  Buyer beware in these situations of early adopter buying and low cost options – shame on you the buyer.

Here’s my usual SLA and sourcing advice.  Outsource the commodity, the services that are absolutely the same regardless of industry, stop being unique, special and different and accept the standard and low cost option.  Go back to my Service Value chart.  Remember you still own the services and you can’t blame your sibling.  To that point, you own the service level – availability, performance, response, contract termination, etc.  Just remember the more stringent you are with the terms the greater the risk to the provider and the higher the cost.  Evaluate their standard terms and fill in the gaps, but fill them in appropriately based upon the value of the service.  Do not tell the provider “how” to deliver the service or how to manage the infrastructure, you are outsourcing for a reason.

My prediction for this year is that a major customer will engage with a major provider and there will be a major outage this year and there will be front page headlines creating noise how the cloud fails.  I will point back to front page Wallstreet Journal news of just about 10 years ago.  IBM, Seibel and SAP fail and Hershey misses Halloween – their largest candy selling season.  Pages and pages of an article playing to the hype of the big names and the market and failure.

I remember exactly where I was when I read the paper, waiting on my relentlessly late co-worker in the lobby of a San Francisco hotel.  Net of the story, change management and testing issue and Hershey found we are not loyal to chocolate.  We will go to another drugstore for a brand of toothpaste, but when we want chocolate we will take what is on the shelf.  Moral of the story was Hershey missed Halloween, Thanksgiving, Christmas, Valentines and most of Easter to sort out their order to distribution challenges for what they thought was “14 days, we can fix anything in 14 days”.

I predict the same hype will occur here and it will boil down to a mismanaged, lack of defined and monitored SLA’s.  Just because you subscribe to a service does not alleviate you from the responsibility of the service and contract.

Monitoring, management and measuring cannot be an afterthought – how are you monitoring your service provider(s)?

The article that riled me up for this post is the following:

Cloud Computing (still) Needs a Bill of Rights – ZDNet

Back in December, after Amazon summarily pulled the plug on WikiLeaks using its servers for alleged violations of terms and conditions, the CTO of Fujitsu Technology Solutions wrote that the action constituted a serious threat to the business of cloud computing:  (Read Full Article….)

The Hub Commentary_

I cannot escape the cloud discussion today and must say that I agree with Don and his article this week in contrast to the other I just posted today.  Business Service Management practices, Service Level measuring and management of the service regardless of where it runs is the responsibility of the service provider – IT.

Having a view of the overall service, who’s doing what and how each component is performing is the value of the integrated end-to-end view of services IT delivers to the business.  Take advantage and evaluate the most cost efficient and best use of your resources when evaluating where it should be deployed, however, do not forget you must still instrument it to be managed and measured.

Service levels are a key component when engaging with the service providers.  You want to define your expectations for service availability, performance and responsiveness to an incident, but you need to map your requirements to the value delivered by the service.  Exercising your right to define very stringent service levels only increases the price, balance your real requirements with your service level requirements.

Are you measuring your service provider and cloud services?

Michele

___________________

(Read Full Article…)

The Hub Commentary_

All the news these days seems to be about the cloud.  This is a nice summary of things to consider, however, leaves out the usual after thought that makes or breaks new technology deployment – management of it.  Business Service Management practices and instrumenting for management and measuring performance should be a factor to consider when planning a movement to the cloud.

All services, applications and technologies will be scrutinized in the coming year for suitability to be deployed in the cloud or some mixture of cloud and in-house resources.  One important factor will be the service levels and how you will measure the service in conjunction with in-house services for value to the business as well as monitoring the service provider for performance.  Without the performance monitoring and instrumentation to manage the service, it becomes a he said / she said debate regarding the perception of service quality.

Just because you move services to the cloud, you do not alleviate the requirements to manage and measure the services for service value.

How are you measuring your cloud providers?

Michele

___________________

Everyone is talking about cloud and they want to implement the same in their companies. CIOs are the first people who will get the work on this new initiative or change. This article will give them the quick overviews on what all are the factors needs to be considered during cloud movement.  (Read Full Article…)

The Hub Commentary_

The article references the cost of a single cost of downtime as approximately $100,000 and the risk of downtime increases as systems and infrastructures become more and more distributed and complex.  Now more than ever, services must be service enabled from a proactive monitoring perspective before it goes live into a production environment. Management cannot be an afterthought and also keep in mind, not all services are created equal.

Service enabling and creating adequate redundancy comes at a cost and has to be weighed against the value the service contributes to the business.  Managing the infrastructure as services is an imperative in 2011 to balance cost and value, while insuring service quality and availability.

Integrating the metrics from various technologies and make sense of them as an end-to-end service becomes critical in proactively managing services in real-time and taking action based upon leading indicators that illustrate risk of an outage is rising.  Mitigating risk and reducing downtime must be a factor of service enabling the infrastructure as it goes live in production.

As the article states, the cost of down time is high, catastrophic and the scavenger hunt that ensues to solve and restore service leads to lengthy downtime and is costly to your organization.  As technology professionals, leveraging new technology and deploying agile infrastructures is just a piece of the puzzle, management and service enabling the infrastructure is equally as important.

This is the year of investment in IT technology as well as it’s management infrastructure to service enable the infrastructure to insure it continues to execute in market time.

Michele

___________________

North American businesses are collectively losing $26.5 billion in revenue each year as a result of slow recovery from IT system downtime according to a recent study. The study also indicates that the average respondent suffers 10 hours of IT downtime a year and an additional 7.5 hours of compromised operation because of the time it takes to recover lost data.  (Read Full Article…)

The concept of Business Service Management and why it is good for IT (and the business) is reasonably understood by most people.   The reality is that people tend to buy BSM solutions for the features it provides not just on the definition of BSM.   For some organizations, a BSM product is purchased within some type of internal project like ITIL or a Dashboard project.  When it comes down to it, those projects have requirements and they tie to specific features needed in the end solution such as;

• Console consolidation
• Root cause analysis
• Impact analysis
• Service Level Management
• Dashboards
• End to End visualization of Services

The list tends to go on and on.   When it comes down to it, BSM is something that you do within the solution (Managing to the Service, not the technologies), the features and functionality tend to be part of the BSM solution and where the purchasing focus should be.   One of the core features required for BSM is the ability to integrate to many sources.   There are many upon many tools within a large enterprise and many opportunities to pull in specific silo’s of data in order to provide a more complete view to the end users.  Large enterprises need the luxury of swapping out underlying tools/application in the future due to over priced maintenance renewals, bad support, acquisitions, poor software and numerous other reasons.  If the BSM solution is limited or not highly flexible in the ways in which it integrates to third party products, you may be stuck with some of those underlying technologies.

When evaluating BSM solutions, ensure that the solution has a robust integration feature.   Some BSM solutions are only good with integrating with their own companies products, this is a bit limiting.   Ensure that the are a few different options, ie: more than an SNMP trap or CSV import.

Tobin

Earlier this year I suggested a prediction regarding the waning discussion of ITIL and this week I expanded upon that prediction in a post, “ITIL will be the end of ITIL”. The same day I posted my discussion, I received my brochure for the HDI Conference where Malcolm Fry is set to speak on “What’s up with ITIL?”.  The description starts with questions regarding the dying of ITIL, what’s going on, etc.  Defense – first indication that a wave is starting to swell in the market.

I received many great questions and discussion, which still says ITIL is alive and well in the ranks of IT organizations, trainers, consultants, certifying organizations, etc.  I do want to mention again, I do not see the practices and advice dying, going away or becoming replaced, just that the outward facing conversations will and need to stop being about ITIL and need to start being about the business service, value and performance.  ITIL is merely advice on how to manage your internal operations efficiently.

The catalyst in the market is the cloud and the explosive growth of service providers.  They need to have good operational processes in place or they are one outage away from being out of business.  However, the difference is they are not talking about ITIL, they are talking about the benefits to the business and the simplicity of running and subscribing to services in The Cloud.

The business leader has an internal organization  talking about justifying a CMDB project and a cloud provider talking about monthly subscriptions to online purchasing systems at a monthly or usage fee and here is a rate card, use it like a credit card.  Did I just see that leader walk away from the project justification discussion table and walk off into the sunset all googly eyed with the cloud service provider?

Last night I pulled another article from CIO regarding the innovation expectations the business has for its IT organization.  Embrace the development of innovating services and automate the commodity, routine, mundane that merely powers the lights – free yourself to drive growth.

I had a discussion with a very large and mature cloud service provider organization this morning on just the topic of providing the value add transparency on top of their services – the dashboard view that will communicate service performance to their customers.  The providers know that the business wants transparency and the providers want to insure that there isn’t a perception challenge regarding service delivery and the ones that will be most successful are baking it into there infrastructure and services from the beginning.  IT, are you or are you still talking about ITIL?

I’ve digressed, but the example is clear.  Those that sell technology services for a living know how to speak to your business leaders and how to bake proper service monitoring, management, measuring and communication into their services.  Steal a play from their playbook – implement and deliver the communication of service performance and service value into your services and sell your services, not the process of building services.

Are you communicating Service Value by selling the car or are you still selling the parts and directions as to how to build the car?

Michele

Free Summary – EMA Radar for Business Service Management: Service Impact Q3 2010  – Enterprise Management Associates(Read Full Summary Report …)

I ran across this article the other day by Doug Mueller and it reminded me of the multi-layer Service Catalog.  I’m not sure if this is an actual term or not, but it’s a good description of what it is.  If you take a very large organization that is broken up into distinct areas such as the teams that support:

• Hardware & Operating Systems
• Technologies (web servers, databases, messaging bus, etc)
• Applications (email, timesheet, payment processing)

For mature IT groups, they typically will drive towards a list of supported hardware and support operating systems, they will also typically drive towards a list of support technologies that will be supported within the environment.  On top of these, some common applications (or services) are then provided to the employees such as email and the corporate web server.

If you walk through this, each of those teams has their own Service Catalog (and as Doug said, a Service Request Catalog).   Someone in the technology area, after significant research wants to make this new technology available for sharing documents.  The person requests from the hardware group for hardware and an operating system to be provisioned for this technology to run on.

Someone in the application area then decides to tie the document sharing, email, web and video together for a collaboration solution, so they in turn request services.  The end users then request access to the collaboration service.

I have seen a few different approaches to this such as different links on the internal website to request hardware w/OS and another set of  links to get applications/technologies installed to simple help desk requests.   Regardless, while it may not be a full fledge electronic Service Request Catalog at each layer, there are lists of approved hardware, operating systems and technologies for many companies.

Tobin