What is Collaborative Application Mapping?Knowing what business services are supported by what 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 supports what business applications, and to build the applications into service maps that can automatically be maintained. This is true for both enterprise and mainframe environments. 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 workflowThe Collaborative Application Mapping workflow is illustrated below: Video demonstrationsEach stage in the CAM workflow contains a video demonstration to illustrate the process. The following table describes the number of each video and the corresponding goals for each stage described.
Business rolesThe following people are involved in the CAM process. Application ownerThe application owner is usually part of the application support team, and he may not have any knowledge of BMC Atrium 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 mapperThe application mapper is part of the team responsible for BMC Atrium Discovery rollout and maintenance. He knows BMC Atrium 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. ExampleGeorge, the application owner, administers the Friends application, a web-based corporate social networking application. Mike, the application mapper, is the "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. Demonstration
Where to go from hereYou start the process by identifying the application owner and gathering seed data. |


2 Comments
comments.show.hideNov 03, 2011
Petrus Johansson
In the second text section, replace "service maps" with "Service Models" as this is the correct naming standard.
Might also be worth providing a Best Practice section about performing CAM work on the Consolidation Appliance if running a consolidated setup of ADDM.
Nov 03, 2011
Bob Massa
Thanks, Petrus. Ironically, I had just modified the intro to use "maps" instead of "model", as we had discussions with Marketing about not using model terminology within ADDM. However, I then added a graphic which shows the end goal and the word "model" is more accurate in this context. Thanks for reminding me to bring it back.
Also, with regard to best practices, I am compiling a list that will eventually be just that, a best practices section for CAM. I'll add your suggestion and do the research on the use case you point out. If you have any specific recommendations, please feel free to note them in a follow-up comment.
Thanks.
Bob