Model-based systems engineering (MBSE) continues to show robust growth in adoption driven by increased digital transformation efforts within our government as well as boosted adoption by industry. One area specifically benefiting from MBSE adoption is enterprise architecture (EA). In a previous post, Modeling Capabilities with Model-Based Systems Engineering (MBSE), we discussed one of the EA domains—capabilities, and the benefits of modeling them. In this blog post, we explore another domain of EA, the usage of services as an architectural concept that provides a method for successful alignment of business and IT entities.
Modeling services will help practicing business-, enterprise-, and solution-architects present groups of functionalities through the lens of a service-oriented architecture. System engineers can also use the concepts of services in their capabilities breakdown and further architectural analysis.
This post explores an approach to designing services using MBSE with OMG’s Unified Architecture Framework (UAF) in general and, in services modeling, with UAF’s Services Viewpoint. We show services as an abstraction layer that connects capabilities, operational activities, and underlying software solutions. Modeling the relationship between services and these types of objects may reveal the need for additional decomposition of the analyzed services, capabilities, and operational activities. Service modeling can lead to the discovery of existing functional gaps or duplication of the purchased and/or deployed software. In this post, we will demonstrate that a decomposition of services clearly distinguishes between service interfaces and functions.
The Role of Services in Architecture Decomposition
UAF defines services as “specifications required and provided service levels of these specifications that exhibit a Capability or support an Operational Activity” (Figure 1).
Figure 1: UAFML Service Definition
Service specifications define objects that are able to perform specific business functions, processes, transactions, or operations. For example, a customer relationship management (CRM) tool can be modeled as a service responsible for managing customer profiles, contact management, customer behavior trending for sales campaigns, etc. The CRM service may assist in sending customized notes, play the role of a collaboration and communication tool for cross-functional teams, provide analytics on customer preferences, and many other ongoing activities.
Figure 2: Customer Relationship Management Service
The CRM service shown in Figure 2 can perform “Send Customized Note” and “Provide Customer Preferences” activities that represent daily business operations and exhibits two capabilities. A real-world model would reveal more complex structure matching services to capabilities as well as business requirements.
Figure 3: Matching CRM Service to Requirements
For example, as shown in Figure 3, service specifications can include high-level business requirements related to process automation, report generation, or access control. Now the CRM service can be traced to the business requirements it is supposed to satisfy, to ensure the completeness of the service specification using a dependency diagram, as shown in Figure 4 below.
Figure 4: CRM Service Requirements
Once the service is matched to the identified capabilities and known requirements, any existing systems or evaluated platforms can be brought into the models as resources implementing the service.
Figure 5: Tools and Platforms Implementing CRM Service
The CRM tool of choice may not include all required capabilities. It may be augmented with business intelligence systems, messaging services, planning tools, etc.
A dependency diagram, similar to Figure 6, can be built to trace the resources the service was related to. This type of diagram can demonstrate all services, including redundant platforms, as well as any gaps in the modeling or analysis. Figure 6 shows that Pipedrive and Salesflare have not been traced to the CRM service.
Figure 6: Resources Implementing the CRM Service
On the other hand, services may be implemented by more than one tool, and one tool may offer various capabilities that can be matched to several services. For instance, as Figure 7 illustrates, the Norton Deluxe offers antivirus and malware protection, scam protection, password manager, cloud backup, VPN, parental control, and other services.
Figure 7: Platform Implementing Multiple Services
Services Decomposition and Structure
In the UAF domain meta-model (DMM), service is described as a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed service interface and is exercised consistently with service constraints and policies, as shown in Figure 8. Examples of services in the cybersecurity domain would be user or device authorization and authentication, access management, identity management, sensitive information protection, static code analysis, encryption, and security monitoring.
Figure 8: UAF DMM Service Description
Let’s look more closely at sensitive information protection as an example of a service. Assuming that the system under investigation operates and stores sensitive information, one of its core cybersecurity capabilities will be sensitive information protection. To implement this capability, an architect needs to think about how the sensitive information will be discovered, identified/verified, and marked as such, as well as how the sensitive information will be protected at rest and in transition while being ingested. Even before any specific solution is chosen, a high-level grouping of the related functionalities can be identified as services, and corresponding business rules, conditions, and policies must be articulated. Thus, discovery, identification, verification, and marking of the sensitive information (and corresponding data sets), as well as protection in transition, can be modeled as services using UAF and its modeling language, as shown in Figure 9.
Figure 9: Sensitive Information Protection Services
By definition, a service interface is a contract that declares service methods and service message handlers that define interaction between services. A service interface can include specifications required to perform an activity or operation. The service decomposition can be modeled as functions that represent the service behavior. The service functions specify activities the service can perform.
Figure 10 shows how a high-level service, such as “Sensitive Information Scanner” service, is decomposed into more specific services: “Sensitive Information Discovery”, “Sensitive Information Verification”, and “Sensitive Information Marking”, with identified interfaces and functions. An interface should be modeled as a standalone element for reuse and utilized as a type for a service port located on the service. To illustrate that, on the service structure view in Figure 10, the second-tier “Sensitive Information Discovery” service has a service port typed by “Sensitive Information Discovery” interface and linked to the behavior element service function “Discover Sensitive Information” by
Figure 10: Sensitive Information Scanner Service Decomposition
The real-life services have business rules and conditions that constrain a service. To model them, an architect can use an element called Service Policy that can be created in the context of a specific service and is a constraint kind of abstract element called Rule in UAF as seen in policy 1 and policy 2 in Figure 8.
After decomposing services, an architect may need to model how those services are connected to each other and exchange information. In our example, “Sensitive Information Scanner” service gets a signal from “Sensitive Information Monitoring” service, and the second-tier services exchange information, such as the location of potential sensitive information provided to the discovery service and the sensitive information for verification or marking services (Figure 11).
Figure 11: Sensitive Information Scanner Service Internal Connectivity
The dependency matrix in Figure 12 below shows all types of connections between services in the model. “Sensitive Information Monitoring” service interacts with “Sensitive Information Scanner” service via a service association with information exchange allocated to it. Services that constitute “Sensitive Information Scanner” service interact with each other using service connectors, port to port, with information exchanges allocated to them, in the same way as described above. The matrix is a useful instrument to analyze connectivity between services in bulk, identify wrongly connected services or missing connections, as well as the impacted services if one of them were to be changed.
Figure 12: Services-to-Services Dependency Matrix
Summary of UAF Service Usability
UAF services play an important role in the framework connecting capabilities and operational activities to specifications representing an abstraction layer over software and physical resources. Service specifications can be traced to high-level business requirements to ensure comprehensive coverage of the requirements. Service structures can evolve as architects perform the decomposition of capabilities and operational processes. In this process, service relationships and functions start shaping the design of underlying resources. The service interfaces can be useful to lay the foundation for analysis of resource interactions, exchanged information, API design, etc.
Architects can leverage the traceability analysis based on services to raise awareness of potential functional gaps in existing systems and redundancy in the acquired platforms. Traceability matrices that include services can facilitate an impact analysis, providing a view on the operational environment through the lens of the services. The service modeling can play a pivotal role in specifications for new products and systems before any technical details become clear.
