Application modeling refers to the creation of a database model which represents the current state of "interesting" software applications on your network. When you have created an automatically updated model you can then employ BMC Atrium Discovery for managing:

• Application Availability
• Service Maps for BSM
• Change Control
• Data Quality for CMDB
• Data Center Optimization
• Standardization
• Virtualization

How do I model my applications in BMC Atrium Discovery?

Applications are modeled using the The Pattern Language TPL. TPL files, or patterns define how software entities are identified on the network, and how nodes to represent them are created, grouped, and updated in the datastore. The core aim of TPL is to make it easy to describe the most common structures to be modeled, while remaining powerful enough to describe the vast majority of modeling situations.

BMC Atrium Discovery ships with countless patterns that model commonly deployed software, and that these are updated monthly via Technology Knowledge Updates (TKUs). The Technology Knowledge Network team work constantly to refine and update patterns and to create new patterns to increase coverage of the leading products running in global 2000 data centers.

Understanding the application

You need an understanding of an application, its structure, components, dependencies, and communications before it can be modeled. You are creating patterns to recognize applications according to rules that you define, and to create a representation of them in the datastore. One of the easiest ways to understand the structure is to draw a picture of the application. When you have a picture of the application, it is easy to decide the components and connections that are important to model.

Decide the depth of modeling

Part of understanding the application is working out which components to model to achieve the level of detail that you need.
There are two extremes to application modeling:

• Footprint modeling
• Deep modeling

These are extremes, most of the modeling that you do will probably be somewhere between the levels. The most important thing is to create a model with as much detail as you need. You can always extend a pattern to capture more detail at a later date.

Footprint modeling

For example, if you have a major component which is essential for the operation of an application, and you can extract all of the information required from that, then it may be unecessary to do more than model this component and identify the ancillary components.

Alternatively, for inventory management you may simply want to know that a component is running. Modeling in any more detail than identifying the instance would be unnecessary.

Deep modeling

Deep modeling is detailed modeling in which, at the extreme, all components, dependencies, communications, and so on would be modeled. If you have an application with a failover pair of servers, you would probably want to determine the role of each instance (MAIN or BACKUP). Additionally, if you are concerned with dependency mapping or disaster recovery, you may need to assign each server's host to a geographic location.

Writing patterns

Patterns are written as plain text files and uploaded to the appliance. A number of template patterns are supplied with BMC Atrium Discovery which contain examples of techniques that you are likely to require.

An example application

A simple example application has been designed to show many of the basic techniques that you need to write patterns and model applications. It contains a number of components, versions, dependencies, and naming schemes which are similar to those you are likely to encounter when modeling real world applications. This is the Wibble Software QuickExpense application.

• For information on the QuickExpense application see Wibble Software QuickExpense application.
• For information on modeling the QuickExpense application see Modeling the QuickExpense application.
• For reference information on The Pattern Language see The Pattern Language TPL.