Logic Centralization

How can the misuse of redundant service logic be avoided?

Problem If agnostic services are not consistently reused, redundant functionality can be delivered in other services, resulting in problems associated with inventory denormalization and service ownership and governance.
Solution Access to reusable functionality is limited to the official agnostic service that provides this functionality.
Application Agnostic services need to be properly designed and governed and their use must be enforced via enterprise standards.	Impacts Organizational issues reminiscent of past reuse projects can raise obstacles to applying this pattern.
Principles Service Reusability, Service Composability	Architecture Inventory, Composition, Service

Table 5.6 – Profile summary for the Logic Centralization pattern.

Problem

As we established in earlier chapters, reuse represents a key characteristic that typically needs to be realized on a broad scale for some of the more strategic goals associated with service-orientation to be attained. However, even if well designed agnostic services are consistently delivered into a service inventory, it does not guarantee that project teams building new solutions will use them.

For various reasons, it may be easier, simpler, or just more practical to avoid involving reusable services in order to concentrate on the fulfillment of short-term, tactical delivery goals. This approach may be convenient, but it eventually results in a denormalized service inventory where functional redundancy is common (Figure 5.x).

Figure 5.26 – Different project teams delivering services with redundant logic leads to functional overlap among services in the inventory.

Solution

To pursue the strategic goals associated with service reusability, the characteristic of reuse itself must form the basis of supporting internal design standards. The foremost of these standards needs to dictate that services classified as agnostic must become a primary (or even sole) means by which the logic they represent is accessed. This forms the basis for the Logic Centralization pattern. The level to which logic centralization succeeds as an enterprise-wide standard determines the extent to which a repeated ROI of services can be realized.

Figure 5.27 – Service consumers are required to reuse functionality provided by a single designated agnostic service.

Application

When defining a service inventory blueprint, the intention is generally to establish a highly normalized view of the enterprise. This means that each service establishes a distinct and unique functional domain.

When solution logic for new processes is being created, there is always the risk that a project team will build new logic that already exists as part of an agnostic service.

Common reasons for this are:

•       The project team is not aware of the serviceÕs existence or capabilities because the service is not sufficiently discoverable or descriptive.

•       The project team refuses to use the service because it is considered burdensome to do so.

While the former scenario can be avoided through the application of the Metadata Centralization pattern, the latter is where an inventory-wide design standard is required. In fact, the manner in which this pattern is applied is through the creation and enforcement of a standard that requires that services act as the sole entry point for the functional boundaries they represent within a given inventory.

Figure 5.28 – In this case, only one service is considered the ÒofficialÓ entry point for Invoice-related processing.

This type of standard essentially dictates that agnostic services must always be used as intended, even if they do not yet possess all required functions. For example, if a new capability needed by a project team clearly falls within the boundary of an existing service, the corresponding functionality needs to be added to that service instead of ending up elsewhere (Figure 5.x).

Impacts

As straight-forward as Logic Centralization may sound, it can be difficult to achieve, depending on the scope of the planned service inventory. For larger organizations working toward an enterprise-wide service inventory attaining a state where all development project teams agree to not build redundant logic and instead use existing services may seem like an unattainable ideal.

Introducing Logic Centralization into an organization that does not have a history of fostering reuse or using design standards in general will almost always raise cultural issues with some of the groups affected by service delivery projects.

For example:

•       Existing project plans and processes are impacted by requiring the involvement of reusable services as part of their development projects.

•       There may be resistance to giving up control of solution designs if teams are forced to include existing agnostic services or produce new services that need to be reusable.

These concerns need to be addressed prior to the delivery of agnostic services to avoid compromising the strategic value of a service inventory. If only partial support for the delivery and usage of reusable services is received within an IT division, the risk of ending up with a denormalized and potentially convoluted enterprise architecture is significant.

Relationships

Logic Centralization is a core design pattern that helps realize some of the most fundamental goals of service-orientation. It is very much focused on centralizing agnostic logic, which is why it is commonly associated with Entity Abstraction and Utility Abstraction patterns and also why its application is influenced by the Agnostic Context and Agnostic Capability patterns.

Contract Centralization has a very close relationship with Logic Centralization because together they position official services that can only be accessed via official entry points (contracts), which is fundamental to establishing a healthy federated endpoint layer.

There are also numerous peripheral relationships with additional specialized patterns, such as Metadata Centralization which supports the discovery of services to which Logic Centralization has been applied, and Redundant Implementation, which supports the scalability demands that tend to fall upon centralized services. Additional examples are shown at the top and bottom of Figure 5.x.

Perhaps its most important relationship is with Capability Recomposition. The consistent centralization of service logic preserves the integrity of agnostic services that provide agnostic capabilities subject to repeated composition.

Figure 5.29 – The Logic Centralization pattern supports the goals of many design patterns, but is itself also supported by others.

Case Study Example

Case study content is not available on this Web site.