Introduction to Collaborative Application Mapping
What is Collaborative Application Mapping?
Knowing what business services are supported by which part of the IT infrastructure is essential to effective Business Service Management (BSM). Typically, most organizations have a list of the most critical applications, most of them tied to Service Level Agreements (SLAs). The goal of Collaborative Application Mapping (CAM) is to find out what hardware and software support which business applications, and to build the applications into service maps that can automatically be maintained. A dynamic, automatically maintained, effective application map enables you to understand the key relationships between how your business operates and the infrastructure that supports it. It also becomes the initial, crucial part of Service Impact Analysis by maintaining accurate service models for BSM.
The CAM approach is designed to capture the rules that define where an application is running, not to simply define that information statically. This means that as you deploy the applications more widely in your estate, or you migrate them around your infrastructure, your service maps will stay current.
Collaborative Application Mapping workflow
The following is an illustration of the CAM workflow:
Business roles
The following people are involved in the CAM process:
Application owner
The application owner is usually part of the application support team, and he might not have any knowledge of BMC Helix Discovery. He handles trouble tickets and maintains the running application. Every application has an application owner; however, he takes direction from business owner of the application. The application owner has no stake in the mapping initiative, so getting full cooperation can be difficult. He is too busy maintaining the application and can only spare small increments of time to collaborate on the maps. Consequently, the application owners are the greatest single cause of failure in the application mapping process. The goal is to create the application map without a large initial investment by the application owner. An effective application mapping process minimizes the reliance on the application owner, and any interaction must be as non-intrusive as possible.
In the business examples used in this guide, the application owner is named George.
Application mapper
The application mapper is part of the team responsible for BMC Helix Discovery rollout and maintenance. He knows BMC Helix Discovery well, particularly how to report, search, analyze, and use the application mapping user tools. The application mapper is responsible for executing and driving the mapping process, and to do this he must be familiar with the way in which business applications are put together, such as the roles of middleware, databases, web infrastructure, and message brokers in application architectures.
The application mapper's collaboration with the application owner should be as limited as possible, requiring only the basic information at the outset of the process and some feedback during the Prototype and Share stages of the process.
In the business examples used in this guide, the application mapper is named Mike.
Example
George, the application owner, administers the Friends application, a web-based corporate social networking application. Mike, the application mapper, is the BMC Discovery guy.
George is always busy responding to requests from the business owners, reacting to incidents, performing software updates, rolling out new versions of Friends, and so on. Friends is not the only application that George maintains.
Mike knows that George is the guy to speak to, but George does not need a map of the Friends application, because he has one in his memory. It is difficult for Mike to get George to commit much of his time to the application mapping initiative.
Mike must keep George on his side because he is going to need George's cooperation in the future.
Comments
Log in or register to comment.