Service Layers (143) establishes a general means of organizing the services within an inventory into logical groups. Each layer is based on a type of service and therefore represents a set of services that conform to this type. These types correspond to industry classifications referred to as service models.
Following are the three most common service models:
• Utility Service Model– A type of service that provides generic processing logic that is not classified as business logic (as explained in the upcoming Business Logic and Agnostic Logic section). Utility logic is often referred to as “cross-cutting” logic because it is ideally agnostic and reusable and therefore multi-purpose in nature.
• Entity Service Model– A business-centric service type that is derived from one or more business entities. Entity services are also agnostic and therefore expected to be highly reusable.
• Task Service Model– Also a business service model, but one that is intentionally non-agnostic because its functional scope is limited to single-purpose business process logic.
These three service models correspond to the three inventory layer patterns described in this chapter as follows:
As explained by Three-Layer Inventory (715), it is a recommended practice to use all three of these design patterns together. For most organizations, they collectively represent an effective grouping of common service logic.
However, this is not absolutely required. The rule established by Service Layers (143) is that at least two layers must exist. Given that it is generally desirable to have one layer abstract non-agnostic logic, this means that Process Abstraction (182) can be applied together with either Utility Abstraction (168) or Entity Abstraction (175), as shown in Figure 7.1.
Figure 7.1 Two different service inventories, each with only two service layers. Inventory A establishes an entity service layer that is most likely comprised of services that also encapsulate common utility logic. Inventory B limits its agnostic services to the utility layer, which probably results in entity-specific logic being redundantly dispersed throughout the task service layer.
Service layer combinations that are less common include the following:
• Utility + Entity– If these layers are intended to represent agnostic and reusable services, then this layer combination will rely on composition via consumer programs that are not service-oriented. This can still foster reuse but the overall composability potential of services will be limited.
• Task Only– A service inventory structured with a single task service layer makes little sense because it would essentially be comprised of a series of independent, silo-based applications. Although it is common to find a set of single-purpose programs that represent some or all of an IT enterprise, from a service-orientation perspective, there is not much gain to this design. Agnostic service layers are required to establish services as reusable enterprise resources.
Note
Organizations can choose to derive custom variations of these fundamental abstraction patterns and can even create new service models and abstraction layers altogether. Sometimes this approach is warranted when a service inventory spans domains and a unique, business domain-specific service model is required.
When discussing service models and service layers (and service design in general), a distinction is always made between business logic and non-business logic. Logic is classified as being business-centric when it is derived from business analysis models and specifications. Examples of such documents include workflow or business process definitions, BPM specifications, ontologies, taxonomies, logical data models, business entity references diagrams, and a variety of other documents related to business architecture, data architecture, and information architecture in general.
Anything having to do with representing the manner in which an organization carries out its business can generally be classified as a form of business logic. When it comes to service encapsulation, we are primarily interested in business logic that can be automated.
Automating business logic requires more processing than is generally documented by the aforementioned business analysis documents. There are various underlying mechanics and resources that come into play at a technology level. Those parts of the processing logic that are not related to or derived from business logic are classified as utility logic, as explained in the upcoming description of Utility Abstraction (168).
The term “agnostic” originated from Greek where it means “without knowledge.” Therefore, logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Because knowledge specific to single purpose tasks is intentionally omitted, agnostic logic is considered multi-purpose. On the flipside, logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic.
Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be repurposed. Because agnostic logic is expected to be multi-purpose, it is subject to the Service Reusability principle with the intention of turning it into highly reusable logic. Once reusable, this logic is truly multi-purpose in that it, as a software program (or service), can be used to automate multiple business processes.
Non-agnostic logic does not have these types of expectations, which is why non-agnostic services are deliberately designed as single-purpose software programs.
Note
The word “agnostic” also has specific meaning within some religious communities. If you are uncomfortable using this term, you can substitute it with terms like “neutral” or “unbiased.” Although the underlying meaning is not quite as clear with these terms, they may still be effective in making the distinction between these logic types.
Each of the design patterns in this chapter defines a service layer that is based on a distinct combination of the four logic types we just covered, as shown in Table 7.1.
Note the absence of a service layer that represents both utility and non-agnostic logic. Such a service layer can be created, but it is not common and therefore not documented as a separate pattern. Generally, the need to assemble services together into compositions is driven by business-centric tasks or processes. This establishes the task service layer as the primary part of a service inventory that abstracts non-agnostic logic.
Among the logic required to automate just about any business task, there will be some that can be considered generic, “cross-cutting” processing functionality that has no relationship to formal business models. IT environments typically have a variety of technologies, products, databases, and other resources that offer features or functions useful for many purposes. This type of non-business centric logic can be considered utility logic.
The functionality associated with the automation of a business process will often include utility processing functions that find themselves bundled together into the same service with business process logic, business rules, and other forms of business logic (Figure 7.2).
This packaging results in hybrid services that make the individual strategic design and governance of utility logic practically impossible. For example, if generic processing functionality capable of addressing multiple cross-cutting concerns is embedded together with business process-specific logic, it becomes challenging to make the generic processing logic separately available for reuse.
Agnostic non-business-centric utility functions are defined and grouped into separate utility services. Because these utility services provide common functions that are not specific to any one task, they can be reused to automate multiple tasks. The result is a utility service layer (Figure 7.3) that is typically defined, owned, and governed by technology experts (usually without involvement of business experts).
Utility processing is common to all enterprises, but the process of abstracting cross-cutting functionality into reusable units of logic can be difficult. One challenge constantly associated with utility service designs is the definition of appropriate service contexts. Unlike business service contexts that can be derived from existing business models, the functional context of utility services is often left to the judgment of architects and developers. It can therefore be challenging to set a service context that is suitable for long-term reuse and service contract longevity.
Here are some guidelines:
• Avoid overly coarse-grained services that bundle lots of capabilities together. These can be difficult to reuse and establish awkward functional contexts that can lead to bloated services over time.
• Define a very clear functional context for each service but give it the flexibility to evolve with the inventory. Unlike business services that tend to have strict boundaries, utility service boundaries can be augmented somewhat as long as the parent context is preserved.
• Use Canonical Expression (275) to ensure the creation of easy-to-understand service contracts. Because utility services tend to be produced by technology experts, there is often the danger that their public-facing contract details will be too technology-centric and cryptic.
During the service modeling process, the logical utility layer is already preconceived and conceptualized. Subsequently, when service contracts are ready to be defined, a special process geared toward utility service design needs to be applied so that the unique issues associated with this type of service can be addressed.
Establishing a formal utility service layer that spans a service inventory requires constant attention to how logic is partitioned and grouped within functional service contexts. Despite best efforts, you should be prepared to eventually split up coarse-grained utility services, as per Service Decomposition (489). You can prepare for this by applying Decomposed Capability (504) in advance.
Adding this service layer to an inventory that already separates its services into multiple business-centric layers will predictably increase the size and design complexity of service compositions. Due to the additional inter-service communication required, runtime performance will also be affected.
Furthermore, the definition of utility service layers can make some impositions on how traditional development projects may have been carried out. However, the fact that object-oriented analysis and design (as well as aspect-oriented programming) have raised an awareness of the benefits of abstracting cross-cutting utility logic, these requirements will not be too foreign to most organizations.
Because its application also results in agnostic service layers—and therefore is fundamentally influenced by Agnostic Context (312)—Utility Abstraction shares many of the same pattern relationships as Entity Abstraction. The primary difference is the absence of business-centric influences.
Notable relationships specific to Utility Abstraction are Service Agent (543), which emulates its non business-centric functional context and Cross-Domain Utility Layer (267), which essentially results in a broad application of Utility Abstraction. Rules Centralization (216), Service Perimeter Guard (394), and Stateful Services (248) also can be considered specialized implementations of this pattern.
Case Study Example
Cutit’s immediate priority is to streamline their internal supply chain process. The order process in particular needs to be supported by the planned services so that orders and back-orders can be fulfilled as soon as possible.
A service-oriented analysis effort is carried out with the assumption that all three common service layers (utility, entity, task) will be used as the basis for the inventory’s logical structure. This stage includes detailed service modeling and business process decomposition, resulting in the identification of several key relationships between different Cutit artifacts.
Here are some examples:
• Everything originates with the manufacturing of chain blades in the Cutit lab, which requires the use of specific materials that are applied as per predefined formulas.
• The assembly of chains results in products being added to the overall inventory.
• Saws and kits are items Cutit purchases from different manufacturers to complement their chain models.
• Notifications need to be issued when stock levels fall below certain thresholds or if other urgent conditions occur.
• Finally, a periodic patent sweep is conducted to search for recently issued patents with similarities to Cutit’s planned chain designs.
These artifact relationships are incorporated into service modeling steps that produce the preliminary service inventory blueprint shown in simplified form in Figure 7.5. The analysis reveals a series of service candidates, most of which are business-centric in nature. The Patent Sweep and Notifications service candidates, however, have functional contexts that do not correspond to any modeled business specifications. They are therefore classified as utility services and together establish the beginning of Cutit’s inventory utility service layer.
Figure 7.5 The initial set of services planned to support the following types of processes: keeping track of orders and back-orders, chain manufacturing, tracking required manufacturing materials, and the inventory management of manufactured and purchased products. To support these tasks, two utility services are defined. Note that task services are intentionally excluded from this diagram so that they can be introduced in the case study example for Process Abstraction (182).
When attempting to abstract business logic there is a natural tendency to group together logic associated with a specific task or business process. Any potentially reusable business logic is embedded together with single-purpose, process-specific logic. Therefore, the reusability potential for this logic is lost (Figure 7.6).
Additionally, the business analysts who have entity-level expertise are often different from those who have process-level expertise. When entity and process logic are grouped together in support of automating a particular task, it is usually owned by the analysts responsible for the business process definition. This can result in missed opportunities to incorporate design considerations specific to business entity rules, characteristics, and relationships.
To carry out its business, each organization deals with different “business things,” like people, documents, products, and partner organizations. These things (or artifacts) are referred to as business entities. As organizations change the way they do business, new tasks may be required, or existing tasks may need to be altered. But throughout all of this change, new or revised tasks usually continue to involve the same business entities.
When looking for ways to design multi-purpose services that have a lot of reuse potential, it is therefore considered a safe bet to build services based on business entities. These entity services are naturally multi-purpose because each can be reused to help automate different tasks. This pattern partitions business logic that is evidently multi-purpose into a separate set of services with agnostic functional contexts based on business entities (Figure 7.7).
To apply this pattern, the service modeling process needs to be carried out to identify and group logic appropriate for entity service encapsulation. Subsequently, the service-oriented design process for entity services must be completed to create standardized service contracts based on business entity contexts. Often a logical data model or an enterprise entity model provides the source for these contexts.
The resulting service layer is comprised of a (usually large) collection of agnostic business services that can be reused across numerous different business processes. Each entity service can be owned and governed by a group that includes business analysts with the appropriate subject matter expertise to preserve its integrity and to ensure the service continually evolves in alignment with the business.
Note that the granularity of entity services can sometimes vary. Although deriving a single service context from a single business entity results in a cleanly modeled service layer, this approach is not always possible. Practical considerations sometimes require that a service context be based on multiple entities—or a single entity may form the basis for multiple service contexts (Figure 7.8).
Note
This pattern may not be suitable for organizations with business entities that are volatile and subject to frequent change. In this case other, more stable sources for agnostic business contexts need to be sought. Alternatively, a new business entity specification can be developed wherein more abstract business entities are defined that are less prone to change. For example, in a company that has constantly changing products, it can be more effective to base entity service contexts on an abstract product entity instead of individual product types that may have limited longevity.
Although there is tremendous business benefit to establishing an entity service layer, it can impose change on several levels, not limited to just analysis and design processes. Because this pattern positions a significant portion of business logic as reusable enterprise resources (services), a great deal of attention needs to be focused on its subsequent governance and evolution.
The application of this pattern can shift organizational structures, change the complexion of project teams, and introduce new skill set requirements. Therefore, Entity Abstraction should be incorporated as early in the planning stages as possible, so as to give all of those involved with service modeling and service design enough time to understand and accept the nature of this service layer.
One of the key success factors to maintaining an effective entity service layer is establishing a suitable ownership structure for the entity services. Because this can necessitate joint ownership between business subject matter experts and technology experts, it may require the formation of new groups and policies.
Entity Abstraction can be viewed as a business-centric application of Agnostic Context (312). It is therefore closely related to patterns that support the definition of agnostic business services, such as Logic Centralization (136).
As discussed in Chapter 16, coarse-grained entity services tend to require the application of Service Decomposition (489) at some stage. They also raise further business logic-related design considerations that carry over to contract design, which is where patterns such as Validation Abstraction (429) and Legacy Wrapper (441) may be required.
Case Study Example
Using an elaborate entity relationship diagram (that has long covered an entire wall in one of their IT meeting rooms), Alleywood architects collaborate with business analysts to carry out their own service-oriented analysis with a focus on identifying core business entities.
After iterating through and decomposing numerous business processes, a series of artifacts are documented, along with their inter-relationships:
• Employees use equipment to process natural wood in the field. The equipment needs to be maintained with an inventory of parts.
• Accumulated wood is placed on trucks, which haul loads to the mills where the wood is processed and refined.
• Mills are located in different regions, some of which are governed by different regulations.
• Alerts are issued for warning and emergency situations, such as when an employee is injured or a truck breaks down.
• Policy checks are periodically performed to look for amended or newly issued regulations that may affect existing wood processing plans.
• Finally, resource surveys are conducted to search through a central repository of workers available for field jobs.
Of these artifacts, it is determined that Alerts and Resource Survey are to be classified as utility service candidates because they do not correspond to recognized business entities.
There is some debate as to whether Policy Check should be considered an entity service even though their business entity diagram does not contain a policy entity. In the end, they decide to also classify this as a utility service candidate because they could not foresee the need for a functional context dedicated to policies (especially considering that the only policies they are concerned with are those issued by the FRC).
As shown in Figure 7.10, eight entity service candidates are defined, establishing a fair-sized entity service layer. With the exception of Employee, each of these entity-centric functional contexts corresponds to one business entity within their entity relationship diagram. The same business analysts responsible for maintaining that diagram agree to remain involved with the ownership and evolution of these entity services.
The Employee service candidate was actually derived from three separate, employee-related business entities for which the creation of separate services was not deemed justifiable.
Note that because Alleywood does not have a single business entity to represent an order, a task service is established to encapsulate all of the composition logic required to process order documents.
Services can be designed to resemble traditional silo-based applications wherein agnostic and non-agnostic logic is grouped together in each service. This can happen when services are delivered individually by separate project teams or service-orientation is disregarded as part of the delivery method.
This approach has several repercussions:
• It reduces opportunities for applying the Service Reusability design principle on a broad scale.
• It imposes governance complexity when expertise associated with business entities and business processes lie with different individuals.
• It makes it difficult to apply Non-Agnostic Context (319), thereby reducing the chances of successfully abstracting single-purpose cross-entity logic into legitimate services.
As illustrated in Figure 7.11, this grouping can further result in the fragmented implementation of task logic.
Figure 7.11 Parent business process-specific logic is grouped with other logic that is likely agnostic, resulting in some dispersal. The primary negative effect is that by combining task-specific and task-agnostic logic, the opportunity to establish agnostic services in support of Agnostic Context (319) and other related patterns, such as Logic Centralization (136), is hindered.
Business logic that spans multiple entity service boundaries is abstracted into a distinct functional context associated with the task service model. This establishes a parent service layer responsible for containing workflow and service composition logic required to carry out the parent business process (Figure 7.12).
The abstraction established by this process service layer can increase organizational agility because it is the parent business logic that is commonly subject to business change. As a result, being able to access and maintain this logic in a separate set of services can decrease the effort required to respond to change while shielding agnostic services in other layers from the impact of the change. This is because when a mature inventory of services is available, business changes will often only translate into a need to recompose agnostic services without modifying them.
It may appear as though this pattern is applied out of necessity in support of Utility Abstraction (168) and Entity Abstraction (175). Because these two patterns force the isolation of business process-agnostic logic, any logic that is specific to parent business processes must be located in its own layer.
However, logic residing in a parent business process layer does not need to be encapsulated by services. The formation of a task service layer is the result of repeatedly applying Service Encapsulation (305) and Non-Agnostic Context (319) to this logic so as to shape it into well-defined services.
Services based on a task-centric context are very similar in concept to traditional silo-based applications, in that they are associated with the execution of a specific business process. Therefore, these types of services are more easily incorporated into established project delivery lifecycles and subsequent ownership arrangements.
The intentional abstraction of process logic into a separate service layer needs to be established alongside the definition of other service layers to ensure that subsequent modeling and design processes properly carry out the allocation of this logic. As with the inventory structure patterns from Chapter 5, this pattern is realized via analysis and design processes, such as those explained in Chapter 3.
Note also that while it is common to associate a task service with a single business process, this limitation is not required. As with any service, a task service can be comprised of multiple capabilities, each of which represents a separate process or task. The only rule is that these processes be related to a common overarching functional context.
Often the desire to limit a task service to a single process is related to scalability and autonomy concerns. Given that a task service will generally contain a great deal of composition logic, it is usually beneficial to limit its functional scope to a single composition so that it does not impose performance burden upon one composition when being invoked to compose another.
These types of runtime performance issues is one of the reasons this pattern is combined with Process Centralization (193) as part of the application of Orchestration (701).
The deliberate separation of business process logic into dedicated services generally positions task services as parent controllers of service compositions. Because essential agnostic logic will have been abstracted into other services, task services will almost always depend on multiple agnostic services to carry out their business process logic. An organization needs to be prepared to implement and support service compositions in order for this pattern to be effectively applied.
Furthermore, this pattern places logic into services that could otherwise be located into other types of service consumer programs. This in itself introduces additional design and development effort.
Because Process Abstraction provides a service classification dedicated to encapsulating non-agnostic logic, its application filters out single-purpose logic in support of defining agnostic services, as per Entity Abstraction (175) and Utility Abstraction (168).
The key foundation of this pattern is Non-Agnostic Context (319), which establishes the intentionally single-purpose scope that results in the creation of task services.
Note also that Process Abstraction is a core part of Orchestration (701). The concept of abstracting parent process logic into a logical layer forms the basis for modern orchestration platforms that are commonly based on Web service composition technologies, such as WS-BPEL. In fact, when part of this compound pattern, the application of Process Abstraction results in a variation of the task service model called the orchestrated task service.
Case Study Example
There are literally hundreds of services planned as part of the FRC’s long-term effort to build an enterprise service inventory. Phase one of the roll-out schedule is comprised of the delivery of a core set of services that represent fundamental functions within the organization. The goal is to establish services as an accepted functional medium within the respective divisions before moving toward large-scale, cross-divisional process automation.
Following are some of the results of a large-scale service inventory analysis effort:
• Policies are official documents based on a series of regulations governed by the FRC’s Policy Management division.
• The Field Support division sends out FRC officers to inspect various forestry organization sites and issue evaluations.
• Based on these evaluations and other factors, the Assessment and Appeals division issues assessment reports.
• Negative assessments can require that organizations pay fines. However, these assessments can also be appealed.
• Various types of intra- and inter-divisional reports are anticipated, many of which will require runtime conversion of disparate data models and formats.
As with the Cutit and Alleywood examples, most of the service candidates are again based on the entity service model and the Reports and Divisional Conversion service candidates at the bottom of Figure 7.15> represent the utility service layer.
To understand why Adjust Policy Appeal is classified as a task service, we need to go beyond the artifact relationships to learn more about the analysis work carried out by FRC architects and analysts.
Adjust Policy Appeal is a specific business process that was decomposed and studied during the service-oriented analysis process. It essentially represents a business task whereby statistics from successful and failed appeals are collected and assessed to indicate possible changes made to various metrics (fees, date ranges, etc.) used in FRC policies. This business process requires the involvement of various previously defined services, including Policy, Appealed Assessments, and Reports.
It therefore contains logic comprised of:
• functions that can be completed by entity and utility services
• functions specific to the Adjust Policy Appeal business process, such as decision logic, composition logic, and unique calculations
Whereas the former type of functionality is carried out by agnostic entity and utility services, the latter type is specific to the Adjust Policy Appeal business process and therefore considered non-agnostic. This makes it suitable for encapsulation within a task service as part of the task service layer.