Service and application modeling
Business Services, Business Applications, and Technical Services
Business Services, Business Applications, and Technical Services are key components of application modeling. It’s essential to understand these components to fully understand what the model represents:
Term | Definition |
|---|---|
Business Service | A Business Service is functionality 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 | Business Application is essentially a synonym of Business Service. It is also defined as a service offered to end users or customers. Business Applications can 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 they are built from. |
Technical Service | A Technical Service is maintained by IT, and provides shared functionality that is used by multiple Business Services. These are not the services or applications that end users see but 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 services, business applications, and technical services, so modeling a service or application is a matter of providing business context to the information within BMC Discovery.
Service models are a collection of all the nodes and relationships that represent the current parts of the service, plus information used by BMC Discovery to keep the model up to date.
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 database and network services impact the billing and payment service, 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.
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.
Modeling services by using blueprints
The blueprint modeling approach provides complete control of the service composition. You can add static content (nodes) and dynamic content (rules in blueprints) to control the model composition.
See Service-modeling-with-blueprints for more information.
Start anywhere modeling
The start anywhere modeling (SAM) approach allows users to choose any entry point into a business service or application and begin modeling from there. See Start-anywhere-modeling for more information.
Do I need to replace my existing models with blueprints?
No. If you have existing SAM or Collaborative Application Mapping (CAM) models, you do not need to model those services or applications again using blueprints.
Should I choose blueprints or SAM for new models?
You can choose to create new service or application models using blueprints or SAM. You might find it easier to model some services or applications in one rather than the other; it really depends on the structure of the service or application being modeled and the way in which you can identify it. The following points provide some basic guidance on which method you might use:
- Blueprints—In most instances, you should choose blueprints as they offer the simplest way of creating service models. This option is particularly true if you can articulate simple rules describing what to model and all the required nodes have relationships between them. In practice, if you are undecided, we recommend selecting blueprints.
- SAM—if you view some of the nodes you know to be part of the service, and the visualization shows a good representation of the complete service, including most of the nodes that should be present, and not too many that should not be present.
- CAM—if you are modeling a service that requires multiple complex conditions, including situations where required nodes do not have relationships between them.
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.