Start anywhere modeling
Where to start?
You should start modeling from anywhere that is interesting in the context of the service or application 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 service or application, 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 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 service; in many cases, simply searching for the name of the service 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 service owners. However, most hosts run many pieces of software that are not directly part of the service of interest, including management and monitoring agents, and sometimes parts of other services. 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.
Essentially, the modeling process involves these steps:
- Search for something in your application or service.
- View it in a visualization focus that shows the types of nodes you wish to include.
- Add or remove components as required (usually remove).
- Save the model definition.
- Publish, and view the Business Service, Technical Service or Business Application Instance.
The following video (02:42), provides a brief introduction to start anywhere modeling (SAM).
The modeling process
For the user exploring the data of BMC Discovery and creating a model, start anywhere modeling is based around the the data visualizations. The Software-Connected visualization focus is often the most useful to explore the nodes connected to the entry point or points, and select those that are part of the Business Service, Business Application, or Technical Service; adding the Infrastructure focus allows you to also see infrastructure elements such as network switches in the model. 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 service, you can publish the model, which creates the node that represents the Business Service, Business Application, or Technical Service.
Versions and instances
Invariably applications and services have a number of versions and a number of instances. Start anywhere modeling aims to be so quick to complete models that you should model each instance and version separately. Once the general structure of the service or application 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.
For a detailed procedure about how to create a model, see Creating-a-start-anywhere-model.
Shared infrastructure
The system automatically identifies software nodes that are likely to be shared by multiple services, 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-start-anywhere-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 service, perhaps it links parts of the service, 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 Modeling-a-software-instance-from-a-candidate.