DATE	Thursday, May 31st, 2012	PRESENTER:
TIME	1:00pm EDT/10:00am PDT	Noam Biran Director Product Management Neebula Systems
DURATION	60 minutes (including Q&A)

A service catalog is a central repository of all services provided by the IT organization, as defined by ITIL.
The service catalog is expected to serve as the central repository which unifies all IT & business (non-IT) functions around a common terminology and definitions.

However, there are no best practices or commonly accepted disciplines to create and populate a service catalog in a manner that actually integrates with existing IT processes .

Join Noam Biran, Director of Product Management at Neebula, for a discussion about how to create a service catalog and the benefits you can achieve by successfully integrating the service catalog in your existing IT processes.

The webinar will cover:

• What is a service catalog
• The goals that a service catalog should fulfill
• Best practices for creating a service catalog
• A review of available tools to support a service catalog initiative
• How to keep the service catalog up to date in a constantly changing environment
• How to realize value from the service catalog by improving existing IT processes

^*These fields are required.

Typically, many IT issues signified by an event are accompanied by additional derived events. A database failure will likely include multiple console events related to database connection failures, application errors, etc. On your path to identifying the root cause of a problem, you will have to filter through all such derived events, as well as other unrelated events.

Here’s a quick look at 5 different problem detection methods and tools, followed by some thoughts on how to select which ones are the most suitable for you.

1. Users help detect unknown problems that are not reported by infrastructure monitoring tools. The challenge – this occurs late in the process as the problems have already impacted your users. Additionally, the reporting of ‘symptoms’ by users is far from being objective and accurate and may lead you in the wrong direction in your quest to find the root cause.
2. Infrastructure monitoring tools let you monitor resource utilization – disk, memory, CPU, etc. These are excellent for identifying availability failures, but also include many false positives – e.g., the database is reported as running smoothly, though it is not. Another drawback is the difficulty correlating infrastructure problems to user experience issues.
3. End user experience monitoring tools are a great method for identifying problems and overall response times from a user perspective largely before the real users are impacted. Such tools become more powerful when integrated with infrastructure tools. The drawback? They will generally not be of much assistance in pinpointing the root cause of problems.
4. Transaction management tools help you follow business transaction paths while highlighting potential problems. These tools are excellent for correlating end user experience to specific technical components. These tools cover only a specific domain, rather than the entire data center.
5. Domain specific tools such as Application Performance Management (APM) tools, or tools targeted at databases, ERP systems, or other applications, let you drill down and diagnose problems within a specific application. These are very helpful once you are aware of a problem and where it resides but leave you without the wider perspective and without the ability to detect problems across the data-center realizing the interrelations between applications and components.

So which one is best? Unfortunately, there is no silver bullet solution.
Instead, you should select the right mix of methods & tools – the one that suits your environment, applications and processes.

You should consider selecting tools that go beyond problem detection and also help you in finding the root cause of problems.

The final piece of advice relates to detecting and managing cross-domain issues. These are the more difficult problems that cannot be easily identified within specific technological silos. For such problems, you should try dependency mapping tools, which map business services and applications to infrastructure components. Once problems are detected, by providing a visual topology of all configuration items of a business service, such tools help with the identification of the root cause. Take a look at our live product demo to experience the value of dependency mapping.
For a more detailed review, watch Noam Biran’s webinar: The Elusive Root Cause of IT Problems and How to Easily Identify it.

When things go wrong and the pressure is on, you’ll start hearing things like “this cannot be a network problem”, “it’s a database issue”, or “but all servers are up and running.”
Sounds familiar?

That’s natural human behavior – shifting the heat to others, so you can go on with your own business. Even before resolving the problem, management is first faced with a communication challenge – bringing everyone to the same table and working as team to isolate and resolve the problem.

So how can such scenarios be avoided? For one, you could build a great team that works in harmony and full cooperation. A politics-free team with a laser-focus on problems, and whose members help each other – even if the problem at hand does not relate to them directly.

Another option is adopting a tool that can do the dirty work for you – isolate problems and pinpoint their root cause – network, storage, servers, application or other. This requires the ability to map the dependencies between each of your managed business services and the entire infrastructure supporting it. Then, when a business service is having problems – the related configuration items (CIs) can be immediately identified.

In the meantime, stay away from IT finger pointing and work with your fellow team members on resolving IT problems.

DATE	Tuesday, May 1st, 2012	PRESENTOR:
TIME	13:00 EDT/10:00am PDT	Ariel Gordon VP Products Neebula Systems
DURATION	60 minutes (including Q&A)

Application dependency mapping is a key component for availability and change management processes as well as other strategic IT initiatives (e.g. data center consolidation, Business Continuity Planning, etc.). Organizations use application dependency mapping tools to model business services to support the above mentioned goals, as part of the ITIL processes.

However, in spite of the growing popularity of application dependency mapping tools, leading analysts found that only 1% of business services are actually modeled.

Join Ariel Gordon, Neebula’s VP Products and the former CTO of BMC Software, to learn how to avoid common pitfalls and use best practices to succeed with application dependency mapping and service modeling.

In this webinar, we will review:

• The common IT use cases for application dependency and service modeling
• How to correctly define the goals for an application dependency mapping project
• The relation between application dependency mapping and service modeling, or how to achieve true service modeling with application dependency tools
• The common pitfalls in service modeling to watch out for
• Best practices for a successful mapping project

A video recording for the webinar is now available. Please register to get immediate access.

^*These fields are required.

So how about 2 tips that will make your Configuration Management Database (CMDB) succeed? Only 2 pieces of advice, compared to 10 failure reasons – but hey, we’re about quality not quantity.

What’s the purpose of a CMDB?

Let’s start at the end. Why are companies spending all the effort & resources on building a CMDB? Creating a repository is not an end goal in itself. There are quite a few reasons behind a CMDB, and these two are probably among the top ones:

• Change management – be able to identify how IT changes will impact your business environment.
• Incident resolution – use CMDB as a reference to quickly resolve problems – identify problematic IT components, understand the interrelations with other CIs, and so forth.

So with these 2 goals in mind, here are our 2 pieces of advice:

Use business services entry points

Begin your CMDB journey with your end goal – the business service. Discovery of applications, CIs and relationships – all should be done in the context of a business service in order for them to be useful later when they are needed for change management or incident resolution.

But now comes the question – how do you define a business service? Seems like a no brainer, but reality is – you’ll find some major disagreement on this (more on this in a separate blog post).

We say, keep it simple – find a unique identification for each business service. The best approach is to follow the way users ‘consume’ or access the service. Put in other words – find a tool that lets you begin populating the CMDB by providing an entry point of the business service. Whether it’s the URL, an IP address, or any other address – this should be the starting point for each business service to allow identifying all of the IT elements comprising the service.

Use automatic mapping of CIs to business services

If the CMDB is to help you resolve incidents and analyze impact of IT failures on your business, it must clearly map CIs to business services. The important question, though, is – how is this mapping done, manually or automatically?

A few words about ‘mapping’. There is a lot of confusion in the IT space around this term and its variations. For example, ‘discovery and dependency mapping’ has become a popular phrase often used by many vendors. But what stands behind it, in most cases, is the automated discovery of applications, CIs, and their interrelationships – and not their mapping to business services, which needs to be carried out manually.

So our second tip is – when building your CMDB, make sure the mapping between CIs and business services is automatically created. Or else, you’ll be spending significant resources on manual updates.

Noam Biran
Director, Product Management

Abstract:

Identifying the root cause of IT problems is critical in managing the availability of today’s complex and mission-critical applications. However, this task is almost impossible using the commonly used tools and methodologies.

Join Noam Biran, Director of Product Management at Neebula, for a discussion of ways to improve application availability by focusing the problem resolution process on that actual cause of IT problems rather than on a never ending search for the root cause that takes a significant amount of the problem resolution cycle.

The webinar will include:

• A review of various methods for identifying the root cause
• The impact of root cause analysis on IT processes and organizational goals (e.g. increasing availability, reducing MTTR & MTBF)
• How to make the best use of existing tools
• New methods to assist in quickly and easily identifying the root cause of IT problems

A video recording for the webinar is now available. Please register to get immediate access.

^*These fields are required.

Ariel Gordon
VP Products

Monitoring tools are the cornerstone of any IT management solution. At their core, proudly stands the event console geared to alert the IT team of all issues requiring attention. BUT… these event consoles are very commonly misused resulting in significant degradation of service availability and prolonged Mean Time To Repair (MTTR).

Join Ariel Gordon, VP Product at Neebula and one of the industry pioneers behind Business Service Management (BSM), in a discussion on how to effectively use event consoles in combination with other tools to properly address the main IT monitoring use cases:

• Recognizing Issues by the NOC
• Recognizing the events signifying real problems that impact services and their derived events
• Prioritizing the events that require highest priority of attention
• Implementing a successful event correlation strategy
• Understanding the infrastructure components impacted by each problem for assignment of the events to the right team to drive immediate resolution (or how to avoid event ping-pongs that increase MTTR)

The webinar will suggest best practices for designing and implementing event consoles in a way that guarantees the maximum return on investment.

Or use the following link to register:
https://www3.gotomeeting.com/register/545420382

Update: registration is now closed but you can watch a video recording of the webinar.

But the monitoring tools today seem to be focused on the infrastructure level. There are so many tools out there that tell you everything about the health of the network, storage, and servers. It is all very accurate and detailed information but totally unrelated to what matters – the business.

Application Performance Management (APM) tools attempt to provide information about the health of the business service or more precisely about the application level. This is of course much more useful.

But there is still a need to connect this “higher level” information to the “lower level” information coming from the monitoring tools that know what elements are failing or responding slowly. To enable that – a real time mapping of how IT components, either on-premise or in the cloud, are configured to deliver a business service – is warranted.

This mapping, referred to as Business Service Mapping is essential for both efficient root cause analysis and for impact analysis. Business Service Management tools rely on this service mapping to deliver intelligent IT monitoring information that is tied to the topology of the business service. With this info, isolation the location or a problem becomes easier and the mean time to repair a problem (MTTR) is shortened with root-cause analysis becoming far more efficient.

A managed service model for BSM eliminates these obstacles and offers a much more efficient, less painful and less risky path to success.

But wait a second. What is, exactly, “BSM as a service”? How does it work? And how is it different from the ‘traditional’ business service management model? Here are 5 key points you should know about BSM as a service.

1. Minimalistic setup

Like other SaaS-based offerings, BSM as a service eliminates the overhead of setup, configuration and maintenance. All that’s needed is a minimal, 10-minute install of a ‘collector’ application inside the data center, which communicates with the ServiceWatch NOC and carries out the interaction with the local data center resources.

You manage your business services and IT infrastructure from the web dashboard – add new business services, view dependencies between configuration items (CIs), perform impact analysis and analyze IT change effects.

2. Deep application knowledge not required

In the ‘traditional’ BSM world, the discovery/mapping process requires a deep know-how of the applications’ architectures: what are the application components, which components run where, what are the dependencies and what is the configuration are only some of the questions that need to be answered. The folks who can provide the answers are highly sought after in most organizations and are generally quite busy.

With the BSM as a service model, there is no need for any of this. Why? Because this deep knowledge is delivered as part of the service by a dedicated team of domain experts and best practices that are implemented into the offering.

3. Top-down discovery & dependency mapping

In the conventional discovery methods, the network is automatically scanned to create a huge repository of the local configuration items (CIs), which is usually kept in a CMDB. In our SaaS model, discovery and mapping uses a streamlined, top-down approach. You provide an entry point for the business service (such as a URL or an IP/port) and the discovery process automatically identifying only the related IT components. This creates a focused repository that lets you immediately understand the link between a business service and its supporting CIs. Read more about bottom up vs top-down discovery and dependency mapping.

4. One business service at a time

With Neebula’s managed service BSM model, you can start with a single business service, and then add additional critical business services any time you like. No need for a full-blown, 12-month implementation till you see any results. You’re up an running within days.

5. Pay as you go

Instead of paying for technology, you pay for value. Pricing is based on the the number/scope of business services you manage, so that you really pay for what you get. No hidden costs related to training, consulting, hardware or maintenance.

But, seeing is believing, right? So why not try out our live online BSM system to see for yourself.

With the growing complexity of IT systems, virtualization, cloud and the like — there’s an obvious need for accurate up-to-date data. Whether the goal is change management, impact analysis, handling of critical events, allocation of resources, or all of these — there’s an obvious need to discover all Configuration Items (CIs),  identify their interconnections,  and understand the link between the underlying IT infrastructure and business services.

So what are your alternatives for discovery and dependency mapping?

The common method – bottom up

Considering the scope of IT systems, it is obviously impractical to use manual discovery methods. Automation, therefore, is a must.

Indeed, most discovery and dependency mapping solutions automatically scan the network, discover all CIs and build a large CMDB repository. We call this a bottom-up approach.

What’s the problem with bottom-up discovery and mapping? The first is TMI – too much information. The final result of such a discovery is a huge repository with tens of thousands of elements, but no meaningful categorization that relates the data to business services. Such a repository will include many irrelevant components (e.g., any virtual server that was temporarily used for testing a year ago). Each CI has a large amount of data associated with it- most of which is unnecessary and detracts from your ability to sift the meaningful data.

The second issue is the repository update. According to our recent Business Service Management survey, over half the organizations report 11 to 100 IT changes on a weekly basis. Bottom-up auto discovery methods do not offer a path for an automatic update of the data. Instead, the system has to be re-scanned in order to remain accurate.

Probably the most problematic issue is that the bottom-up approach requires you to manually filter the huge repository and map CIs to business services. So, for instance, if an application server has many connections, you’ll still have to decide which of the connections relate to a specific business service. Naturally, by the time you are done with such manual mapping, it will most probably no longer be accurate anymore.

The bottom line is that in order to successfully map a service, you must actually know its structure, components and application map. So in a sense you really need to  know the mapping to do the mapping… What’s missing is a process that uses the business service context and enables the mapping to be done automatically.

Top-down discovery and dependency mapping

The key to automating the business service mapping process is to use some simple means to identify the service, and then derive from it all the components and structure. This is where the top-down discovery approach steps in, making the business service itself the anchor point of the discovery process.

The top-down approach uses the only possible business service identification key – the point at which the business service is consumed. The user

provides an entry point for the business service – for example, a URL for a web-based application, or an IP, port and server for a fat client application. The discovery process then advances tier after tier to identify the IT components related to the business service. This results in a much smaller repository, and a 100% focused service map that lets you immediately understand the link between a business service and its CIs.

Moreover, the process keeps the business service context, and is therefore able to follow any dependencies which are part of the particular business service. Isolating only the relevant dependencies is also key in mapping the business service to the underlying network and storage IT components which always serve multiple business services. This enables a true holistic cross-domain mapping and impact management solution which is simply not possible otherwise.

To further complement the top-down approach, Neebula’s automated discovery process also builds an abstraction of the business service structure which is independent of the actual real-time model. We call this abstraction a Skeleton. The skeleton is used to define business service policies and rules on the generic application structure and makes sure that the actual business service structure is always up-to-date. For example, there are certain parts of the business service which are more prone to changes, such as the members of a web server farm behind a load balancer (these can change overtime to adapt to the changing demand, especially in dynamic cloud environments). Such load balancers would therefore be scanned more frequently than other entities, such as databases, which are less likely to change.”

This bottom line is a much more effective discovery process, yielding a focused dependency map that is always up to date. Want to see this in action? Take a look at our BSM demo.