Service modeling with blueprints

Defining a service enables you to efficiently manage the underlying applications and infrastructure that is relevant to your business needs. Blueprints are templates that give you complete control of the service that you are modeling. You can use both static and dynamic content to control the model composition. 

Related topics

Service-and-application-modeling

Managing-models

Blueprints

Blueprints are predefined service templates or building blocks to be used by organizations for defining services when creating service models. Blueprints visually map out the steps that make up a service process, and make it simpler to design a new service, or improve an existing service. Blueprints play a significant role in managing service operations, service design, and service positioning.

Blueprints in BMC Discovery include nodes that can be defined to have static or dynamic rules. Each blueprint contains one or more nodes of the same kind, interconnected to define a relationship.

Service model design considerations

Building a service model can be a daunting task. When you begin with the process, it might be helpful to identify one critical Business Service in an application, identify dependencies of the service, and build a complete service model for that part of the application.

Understanding how various nodes in a Business Service interact with each other helps you build other related services and design your service model. In addition, it helps you understand how services depend on each other, which in turn helps you decide the hierarchy of services in the service model.

For example, if you are in the retail business, one of the applications in your organization can be the order processing application. This application consists of several services. From the list of services, you might identify that your billing and payment service depends on the database that stores information about the products offered to the customers through the application. The billing and payment service also depends on the network that enables communication between various nodes. Also, the database and network are not dependent on each other. Therefore, you might want to build a separate service for each of them. Because the billing and payment service is impacted by the database and network services, you can add the database and network as the child services of the billing and payment service.

The following figure shows an example of a service model with a top-level service, Order Processing with its child services, which includes the Billing & Payment service. The Billing & Payment service is further dependent on its child services. The arrow lines between the services represent the direction of the impact relationship between services. For example, the Billing & Payment service is impacted by the changes in the Retail-AWS, Database, Mainframe, and Network services.

Hierarchy_242.png

Based on your organization's need, you can define a blueprint to:

  • Start with an application node, such as Namespace, and have the rest of the service contain one or more applications and infrastructure nodes. You can then use these applications and infrastructure nodes to create an application to infrastructure map.
  • Start with an infrastructure node, such as Host, and have the rest of the service contain one or more applications and infrastructure nodes. You can then use these infrastructure and application nodes to create an infrastructure to application map.
Can I use the same blueprint multiple times?
  • You can use a blueprint more than once in a service model. However, you can use a particular blueprint only once in a single service. 
  • You can use a combination of blueprints in a single service.
Example

Becky is a service designer at APEX Global. A request is sent to Becky to create new services to manage her organization's operations. While creating the service models to map these services, Becky realizes that a few common processes are part of each of these service models. For example, the Kubernetes cluster service and virtual applications management service are essential basic services that are part of many other services, such as Kubernetes deployments, network availability monitoring, and virtual data center operations. Becky defines the common basic services as blueprints.

Blueprints in BMC Discovery

Global flags in Python are meant to be placed at the start of regular expressions. Earlier versions of Python issued warnings for misplaced flags. BMC Discovery now uses Python 3.11, in which misplaced flags are an error. TKU patterns have been updated for this change, and the TPL compiler now warns if flags are misplaced in your custom patterns. However, regex searches with misplaced flags fail silently. In Blueprints, the searches fail to match and, without notification, your Blueprints will be empty, or will not contain what you expect.

A simple example of a misplaced flag is: '^(?i)Linux' which can be corrected to '(?i)^Linux'

Similarly: '/Common/(?i)((FV|dl)515sy):2121' can be corrected to '(?i)/Common/((FV|dl)515sy):2121'

An example from the EMC ControlCenter StorageScope pattern is: '^(?i)EMC ControlCenter \d(?:\.\d)*' which has been corrected in the TKU to '(?i)^EMC ControlCenter \d(?:\.\d)*'

Nodes and node kinds 

  • A node is an object that represents an entity in the environment discovered by BMC Discovery and stored in the datastore. Nodes can be connected to other nodes by using relationships.
  • A node kind is the type of a node, such as a Host or Software Instance. The default set of nodes and their named attributes and relationships are defined in the BMC Discovery taxonomy. 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*