Service modeling guidelines

Provided here is a set of guidelines that supplement the previous modeling process with some additional considerations. These guidelines help ensure that your service candidates attain a balance of proper logic encapsulation and adherence to the service-orientation principles. (Note that some of these guidelines apply to business or application service candidates only, and are so identified.)

12.2.1. Take into account potential cross-process reusability of logic being encapsulated (task-centric business service candidates)

Identifying a real opportunity for reuse is an important consideration when grouping operation candidates into service candidates. It introduces the potential of leveraging existing units of business logic and creating a modularized enterprise business model. A knowledge of other business processes in existence or in development within an enterprise is required to recognize reuse opportunities for task-centric business service candidates (Figure 12.8).

Figure 12.8. Service logic being reused across processes.

To further promote reuse, some have a tendency to model task-centric business service candidates on a granular level. The less business logic a service candidate provides, the greater the chance of it being useful to other processes. This may be true, but it is no reason not to create coarser grained service candidates that also have reuse potential. As explained later, coarse service candidates can be decomposed, providing reuse opportunities on both granular and coarse levels.

12.2.2. Consider potential intra-process reusability of logic being encapsulated (task-centric business service candidates)

Also worth mentioning is the ability for a unit of business logic to be reused within a single business process. Larger, more complex workflows sometimes repeat collections of process activities. If this redundancy is consistent and if the logic represented by these process steps is sufficiently atomic, then you can consider wrapping them into a business service candidate (Figure 12.9). Many workflow systems already accomplish this by identifying predefined processes or sub-processes.

Figure 12.9. Service logic being reused within a process.

12.2.3. Factor in process-related dependencies (task-centric business service candidates)

After you've identified a set of process steps that represent the business logic you want to encapsulate, you need to ensure that you are aware of any dependencies that tie this logic to the current process or to its position within that process.

This will require a bit of analysis, in that the process will need to be broken down into granular processing steps, each of which will need to be assessed individually. What you are looking for here are any input values or parameters upon which business rules, decision points, formulas, conditional statements, or other types of workflow logic are dependent.

The extent to which a service candidate depends on external information (information external to the business service boundary) can determine its potential mobility and the degree to which it can be reused and composed.

12.2.4. Model for cross-application reuse (application service candidates)

Each business service candidate is structured to represent a specific part of the overall business model. These service candidates therefore are highly customized and carefully modeled to ensure accurate representation within a predefined business boundary.

Application service candidates typically do not need to be modeled to accommodate a specific business requirement. In fact, the more generic an application service candidate is, the more reusable it becomes. A business-agnostic design allows it to fulfill numerous potential requirements through reuse by multiple business service candidates across different solution boundaries.

The context with which application service operation candidates are grouped into service candidates is therefore completely neutral to the service-oriented solutions that will eventually use them.

12.2.5. Speculate on further decomposition requirements

It's useful to consider whether the part of a business process you've identified as a service candidate can exist as a potential service composition. In other words, even though immediate business requirements may be satisfied by your existing service candidates, it may be worth determining if the business logic you're encapsulating can be broken down into additional, more granular service candidates.

If decomposition is possible, then you can perform a speculative analysis to determine the likelihood that it may actually be required. This should give you sufficient information to decide whether or not to model a service candidate into a service composition. It also will help you properly label a service candidate (as explained in the Classifying service model logic section later in this chapter).

12.2.6. Identify logical units of work with explicit boundaries

This is simply a reiteration of the service-orientation principle that dictates that services (and service candidates) need to be autonomous. We re-emphasize this principle here as a guideline because it is also the golden rule of service modeling. The logic encapsulated by a service candidate must have an explicit boundary, meaning that it must be able to exist as an atomic collection of individual tasks.

This boundary also claims a level of independence from the underlying business or application logic. It accommodates changes to business requirements by allowing service candidates without dependencies to be more easily remodeled as part of augmented business processes. It further supports the concept of reusability and service composition on a logical level.

Note that defining boundaries for application service candidates can be more difficult than for business service candidates because these boundaries often need to encompass complex legacy environments. The details of exactly how an application service accomplishes its encapsulation are dealt with in the service-oriented design process. Therefore, the boundaries defined within application service designs can sometimes end up being significantly different from what is defined in the original service candidates.

12.2.7. Prevent logic boundary creep

As more services and service candidates are created over time, it is conceivable that some may inadvertently encapsulate business logic already contained within others. This can be prevented when services are first modeled.

Boundary creep can happen in the following circumstances:

• Services in different business processes are created at different times. The logic they encapsulate is the same.
• Services in different business processes are created at different times. The logic they encapsulate overlaps but is not the same. This is the case when different process workflows incorporate similar logic in different workflow designs.
• Services are derived from the same business process at different times. This is especially common when variations of the process exist. For example, high-level and detailed-level views of a complex process may be used by different project teams.

There are a number of steps you can take to reduce the risk of this happening:

• Check available metadata documentation of existing services prior to defining new service candidates (see the Document services with metadata guideline in Chapter 15).
• Implement a set of standards to be used by all those that model services (see the Create and publish service modeling standards guideline provided later in this section).
• Raise an awareness of this issue among all of those involved with business process and service modeling.

Note that this guideline does not apply to service composition, where the encapsulation of services by parent services intentionally results in overlapping boundaries.

12.2.8. Emulate process services when not using orchestration (task-centric business service candidates)

The introduction of the orchestration service layer changes the complexion of business and application service layers, as it establishes one or more parent controller services that pretty much run the show. If you are building business services without the use of process services, you can take steps to minimize the impact of a future move to an orchestration-based model.

The best way to prepare task-centric services is to have them emulate the process service. This means creating and positioning parent business service candidates to act like the process services that would normally form the orchestration service layer (Figure 12.10). By creating a master controller business service that simulates a process service, you end up complementing this service with business and application services that fit nicely into the orchestration composition model.

Figure 12.10. A parent business service layer acting as an orchestration layer.

12.2.9. Target a balanced model

Services rarely are modeled to perfection. And even if they are, they don't stay that way once environments around them change. It is important to accept this reality instead of wasting time and effort trying to achieve an unrealistic ideal.

A fundamental goal of any service-oriented environment is for it to be properly partitioned and represented by services modeled according to:

• business requirements
• consistent standards
• industry conventions

Often these influences will introduce conflicting modeling requirements. Therefore, it is most important to achieve a balance in your service candidates that accomplishes your goals, as you've prioritized them. The quality of a service candidate can be measured by how well its model addresses an organization's short and long-term goals.

12.2.10. Classify service modeling logic

Use a system of categorizing services based on their scope and role. Be clear on how different types of service candidates relate to each other and on how you identify and compose service candidates. Otherwise, your models could become confusing and inconsistent.

The Classifying service model logic section toward the end of this chapter provides a basic sample classification system.

12.2.11. Allocate appropriate modeling resources

A service-oriented enterprise is further characterized by how the business end of an organization relates to the technology responsible for its automation. Service-orientation fully supports and enforces the vision of business-driven solutions, where automation technology is designed to be inherently adaptive so that it can respond to changes in the governing business logic.

Limiting the application of service-orientation principles to technical IT staff can inhibit SOA's potential of realizing this vision. Technical architects and developers typically do not possess the depth of business knowledge required to model services with quality business logic representation. Therefore, business analysts often need to get involved in the service modeling process (Figure 12.11). Their knowledge of business models and their business process expertise usually is required to successfully model business-centric services.

Figure 12.11. This intentionally simplistic diagram highlights the type of expertise recommended for modeling service layers.

12.2.12. Create and publish business service modeling standards

The guidelines supplied by this section can only provide you with a direction on how to implement service modeling within your organization. Depending on the modeling tools and methodologies already in use, you will need to incorporate those that fit within your current business modeling environments.

Regardless of which guidelines you choose to follow, it is highly recommended that you formalize them as official modeling standards. When an organization makes a move toward service-orientation, the manner in which services are modeled should ideally no longer be voluntary or open to interpretation.