Start anywhere application modeling

Start anywhere application modeling is a quick and easy approach to modeling, which enables you to choose any entry points into a Business Service, Business Application, or Technical Service and begin modeling from there.

Related topics

Creating a model

Managing models

Manual grouping

BMC Helix AIOps Open link

Business Services, Business Applications, and Technical Services

A Business Service is a service offered to end users or customers. If you ask your end users or customers what services they use, the things they name are the Business Services. Examples are services like “Commodities Trading” and “Holiday Booking” that are used by internal users, or “Shopping Cart” and “Order History” that would be used by external customers of a retail organization. In most cases, a single Business Service is used by many different end users or customers. There would be just one “Order History” service for all customers, or perhaps one per region, but certainly not one per customer.

Business Application is essentially a synonym of Business Service. It is also defined as a service offered to end users or customers. Partly the existence of both Business Application and Business Service is a result of history, but it can also be used to represent a hierarchy, where an overall Service has several distinct end-user Applications within it. For example, the “Corporate Communication” Business Service could be composed of Business Applications “Email”, “Instant Messaging”, “Video Conferencing” and so on. Note that the Business Applications are still end-user applications that non-technical users would recognize, not the underlying technical building blocks like databases, message buses and web servers that they are built from.

A Technical Service is a service maintained by IT that provides shared functionality that is used by multiple Business Services. These are not the services or applications that end users see, rather the infrastructure upon which they are built, and that are managed by particular groups within IT. Examples are services such as “Oracle Database Servers in London”, “Santa Clara Edge Switches” and “Kubernetes Cluster ABC”.

Business Services of course depend on facilities provided by Technical Services, but not in a simple blanket manner. For example, many Business Services would make use of databases that are managed as part of the “London Oracle Databases” Technical Service. If one database fails, it must be fixed by a member of the “London Oracle Databases” technical support team, but the failure probably only affects one particular Business Service, not all the Business Services that use any of the other databases in the Technical Service. The Business Services affected are likely to have an influence on the priority of handling a failure – fixing a database that is part of “Commodities Trading” is probably a higher priority than fixing one that is part of “Holiday Booking”.

BMC Discovery automatically finds and connects most parts of most business applications, business services, and technical services, so modeling an application or service is a matter of providing business context to the information within BMC Discovery.

Essentially, the modeling process involves these steps:

  1. Search for something in your application or service.
  2. View it in the Software-Connected visualization focus.
  3. Add or remove components as required (usually remove).
  4. Save the model definition.
  5. Publish, and view the Business Application Instance, Business Service, or Technical Service.

The following video (02:42), provides a brief introduction to start anywhere application modeling (SAAM).

Where to start?

You should start modeling from anywhere that is interesting in the context of the application or service that you are modeling. The best way of doing this is the search box in the top right of the UI. Enter the name or other detail of something you know to be in the application or service, and explore the data from there. When you see what you are looking for, click Model.

Good starting points depend on the type of application structure, and what you know about it. Sometimes it is most effective to start from application entry points like load balancer services; other times the databases used to store application data are well known, and are the easiest place to start in finding all the parts of the application; in many cases, simply searching for the name of the application is sufficient to find many parts of it.

One of the easiest places to start exploration of the data is often Host nodes, because some or all of the hosts used by an application are usually known to the application owners. However, most hosts run many pieces of software that are not directly part of the application of interest, including management and monitoring agents, and sometimes parts of other applications. If you model an application or service having started at a Host node, there are often quite a lot of unwanted nodes to remove. In this situation, it is often most effective to start with the Host node visualization but then click through to a Software Instance node or other more specific node. That automatically trims off many of the unwanted nodes that happened to be sharing a Host with the required nodes.

Wherever you start from, the starting points are only relevant to finding parts of the application in the first place. Once you have modeled an application, the original starting points are no longer important, and the system does not remember them.

For a detailed procedure about how to create a model, see Creating a model.

The modeling process

For the user exploring the data of BMC Discovery and creating a model, start anywhere application modeling (SAAM) is based around the software-connected visualization. The software visualization enables you to explore the nodes connected to the entry point or points, and select those that are interesting in the context of the Business Service, Business Application, or Technical Service. You then save the view as a model definition that you can access through the modeling home page, for later use, or you can continue to model. When you are satisfied that the definition represents the application, you can publish the model, which creates the node that represents the Business Service, Business Application, or Technical Service.

For a detailed procedure about how to create a model, see Creating a model.

Versions and instances

Invariably applications and services have a number of versions and a number of instances. Start anywhere application mapping aims to be so quick to complete models that you should model each instance and version separately. Once the general structure of the application or service is understood, it is simple to repeat the steps of searching for content, viewing, and removing unimportant items; the actual process of modeling and publishing is very rapid.

Shared infrastructure 

The system automatically identifies software nodes that are likely to be shared by multiple applications, for example shared database servers and message queues. Visualizations do not follow relationships out of these nodes, so the view is simpler and less cluttered. This also applies to saved models. When BMC Discovery updates models at scan time, it takes shared software nodes into account, so models do not balloon with unwanted nodes.

If the system does not identify a software node which you consider shared, you can force it to be considered shared. This change affects just the node selected, in all visualizations and models. As with system identified shared nodes, nodes that you have forced to be shared are taken into account when updating models. Similarly, if the system has decided that a node is shared, you can force it to be considered not shared. If you have forced a node to be shared or not shared, you can change that behavior and let the system decide whether software is shared or not.

Shared nodes are displayed in visualizations with a grey dashed border. If you force a node that the system considered shared to not be shared, it is still shown with a grey dashed border, so you can identify it again in case you want to let the system decide from now on.

The starting nodes for a visualization are always displayed with a green highlight. If any of the starting nodes are shared, they are shown with a green dashed border, and the usual behavior of suppressing related nodes is disabled for those nodes, to avoid it looking like they are orphaned.

Dynamic models

You create a model by selecting nodes and relationships that have already been discovered, but the model does not stay static and unchanging. BMC Discovery automatically updates them as the environment changes. If you scan the environment and a new component of the application or service is discovered, it is automatically linked in to the existing components, and reflected when you view the model again.

The way in which a model is updated is very easy to understand. To create a model in the first place, you start a visualization from one or more starting nodes, and the system traverses across the graph data to find related nodes that reflect the connected software. A model is essentially a saved visualization that remembers any nodes that were present, plus any that were manually removed. When new data is discovered, affected models are re-evaluated as if a new visualization was generated starting from all the current software nodes that are in the model. Any newly included nodes are automatically added to the application model.

For more information about how models are updated, see Lifecycle of a model.

Static models 

You might choose to create a static, rather than a dynamic model. Static models are not updated and consequently do not reflect changes in the underlying data. However, if a node is removed, for example, an SI is aged out, that node is removed from the model. Nothing is added to a static model.

Candidate software instances

Where some processes are not identified by patterns, but BMC Discovery has determined that the process is involved in interesting communication, it creates a Candidate Software Instance to represent the process. A good rule of thumb is that if a process is not identified by a pattern then it is, in the vast majority of cases, not very interesting. A list of candidate software instances should not be viewed as a to-do list. However, if a candidate software instance is involved in your application, perhaps it links parts of the application, then it may be worth creating a software instance.

When you create an SI from a candidate SI, all matching candidate SIs in the current view are converted, and the system creates and activates a pattern to do the same. After the pattern is activated, it converts all matching candidate SIs in the datastore.

For more information about creating SIs from candidate SIs, see Using candidate software instances.

Where is the TPL?

Most automated data creation and maintenance in BMC Discovery is performed by TPL patterns, but models created this way are not maintained with TPL. They are automatically maintained by the system. To transfer some model definitions from one instance of BMC Discovery to another, you export and import the models, rather than transferring TPL.

What about Collaborative Application Mapping (CAM)?

Collaborative Application Mapping (CAM) is still supported, and still a part of BMC Discovery. However, we no longer actively develop CAM, as our resources are devoted to start anywhere application modeling (SAAM). BMC Discovery 11.0 was the first release of start anywhere application modeling (SAAM), and later versions built upon it. That does not mean that work done in CAM is wasted, far from it. Using the Application modeling home page, you can still import CAM application mapping definitions into BMC Discovery, and you can view CAM models in the application model view.

Was this page helpful? Yes No Submitting... Thank you