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

Responsibilities:

• Generate new leads and work from existing lists for Neebula Solutions working these leads through the sales cycle continuing though the close phase.
• Contact prospects to gather and understand business goals/challenges to aggressively position Neebula’s Solutions via telephone.
• Manage prospects through sales cycle including account strategy and planning, cold calling, prospecting, probing, needs, analysis, qualifying and working with Neebula’s Account Executives in negotiation and closing Neebula’s software solution and services.
• Provide advice on changes to programs, strategy and inside sales procedures.

ƒ
Qualifications:

• BA/BS Degree, Business preferred.
• Minimum four years enterprise software sales related experience, preferred SaaS solutions.
• Familiar with inside sales processes to use best practices to increase efficiencies.
• Proven telephone-selling skills.
• Ability to plan an independent call strategy, and work to that plan to overachieve incentive compensation.
• Ability to work independently and as part of a team.
• Strong cold calling skills.
• Exceptional communication skills – Speak articulately on the phone and able to build good rapport with contacts.
• Ability to develop relationships with senior-level technical and business decision makers.
• Proficient with MS Office and Salesforce.com.
• Able to work in a fast-paced, self-directed entrepreneurial environment.

Location: East coast

Key Responsibilities

• Go to Market strategy and planning
• Creating and writing the company collateral and materials for external PR activity’s
• Manage and coordinate all external marketing, advertising and promotional activities
• manage external public relationships
• Demand generation – manage the marketing programs that drive demand for Neebula
• Lead generation – be responsible for all lead generation activities, including cold calling team
• Sales enablement – develop the sales tools that support the selling process
• Product launch – plan the launch of new versions and releases and manage the cross-functional implementation of the plan
• Market intelligence -  be the expert on Neebula competition and how to crush them

Requirements

• 5+ years of software marketing at the senior management level
• Experience with Internet sales, SaaS marketing
• Experience in creating and writing marketing collaterals
• Experience in the system management market
• Excellent communication skills in English
• Excellent written communication skills in English
• Willing to travel

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.

In this webinar we will review:

• What is a typical cloud implementation
• Organizational structures changes to consider to support cloud implementations
• The challenges in availability management
• How to address these challenges within the current ITIL processes in your organization

You can view a recording of this webinar.