Achieving Situational Awareness in Enterprise Services

Introduction

Service Oriented Architecture (SOA) is an architecture paradigm that supports the creation of business services that incorporate common enterprise-worthy business behaviors that are expressed by a re-usable interface and are governed by policies.

Given that business services are not tied to the implementation but to common business semantics have enterprise-wide applicability; these business services are capable of being discovered by the end users as opposed to "finding" these services by having to drill through terse and complex Application Programming Interface(s) or APIs. In addition, having business definitions of services that are "advertised" on an enterprise-wide platform promotes the concept of re-use of business services. This in turn leads to promoting business agility because business offerings are assembled from re-usable services instead of being built.

Among the stated benefits of SOA is the separation of the interface from the implementation of the service. The preservation of the interface can be referred to as interface durability. A byproduct of decoupling service definition from service implementation and deployment in a SOA-based service deployment model is enhanced service interoperability. In other words, the implementation of the "published" interface can be provisioned via software components that could be written in any language or be deployed on any platform as long as they adhere to the service interface and are available for remote access.

Despite all of the benefits, global multi-national enterprises face a special challenge in leveraging SOA as the architecture paradigm for deploying foundational services. Specifically, the concept of interface durability becomes the core issue. Being that enterprises that are typically spread across multiple geographic zones, they also are governed by multiple regulatory agencies. These types of enterprises find it challenging to adhere to common business service definitions, due to the vast diversity of "situational" and "locale" variances. This then opens up the need for an architecturally sound way to handle the "operational" diversity in a manner that enterprise-class services would need to support without breaking interfaces or replicating services.

Objective

I will introduce the Situational Awareness Injection Service Pattern to help those architects looking for an innovative, architecturally sound way to handle business variation in enterprise class services without the need for breaking interfaces or replicating services.

This article tries to demonstrate how an enterprise can deal with locale-based adaptation without impacting the concept of interface durability. The pattern also shows how enterprises can improve their responsiveness and enhance business agility to deal with the inevitable change in today's business environments.

Assumptions

This article assumes that the reader is a SOA practitioner and that this article is not a SOA primer. Neither is this article attempting to justify SOA as an architectural paradigm. A basic understanding of the concepts of externalized Rules Processing is assumed.

In addition, the article proceeds under the assumption that there is a strong relationship between the service interface and the business payload (referred to henceforth as a business entity or a business concept) being returned by the service operation. The service consumer context is considered to be the input to the service provider whereas the service consumer context adapted business concept is considered to be the outcome of the service invocation.

It should be noted that this article does not discuss the design constructs that could be utilized by the service provider to implement non-enterprise worthy or business-area specific business behavior. Whether the model includes the use of a rules engine that expresses business unit specific algorithms or else if the model leverages a service adapter, service gateway, or service broker pattern to identify and route the call to the specific service implementation layer is left up to the application architects' expertise. The article considers any of the previously mentioned design models as appropriate for incorporating business-area specific business logic.

Business Scenario Overview: Business Reasoning to Support the Need for the Situational Awareness Injection Pattern

I will use the following business scenario to illustrate the problem domain.

A global financial company has multiple divisions, such as a brokerage division, loans division, credit division, retail banking division; all of these divisions have a common need for getting customer account information. The assumption in this case is that this enterprise-worthy business concept is accessed via requests that are made to a common enterprise class "informational access business service."

Even though the various divisions of an enterprise such as this may have the need for customer account information, there are some core differences in what aspects of customer account information is needed for making further "business context"-specific decisions. Depending on the business division and the calling consumer, context retrieval of one or more aspects of the customer account information is governed by contextual business rules, regulatory rules, and locale specific business rules. Furthermore, associative business concepts that are needed to populate the customer account business attributes may be impacted by "business-area specific" rules. These may include business concepts such as the customer credit profile, customer preferences, and the customer profitability business concept definitions. In all cases, either the final customer account business entity attribute values or base attributes may be altered based on the business context, regulatory domain, and the "localized business" rules that govern the particular business subsidiary or business division.

The purpose of this article is to outline a strategy that would allow enterprise-class business services and the business concept payloads that are returned by them to be applicable and re-used across the enterprise's multiple business areas. There is also an attempt made to come up with some design and implementation strategies that allow the service behavior to be re-used while accommodating the "situational" behavioral changes.

To this end, I demonstrate how to incorporate localized business context, locale-driven regulatory policies, and regional influences into a common enterprise service by externalizing locale-specific rules and policies. Further, I show how these variant business rules can be incorporated at deploy time or runtime to deliver maximum business agility. The proposed solution also enables re-use of the service implementation layer, thus making a more compelling case to adhere to a common interface definition for a business service such as the customer account informational service that has cross-enterprise applicability.

Note: Appendix A details the Customer Account example in far greater detail.

Possible Alternative Business Service Options to Deal with Operational Variance Among Business Divisions

As mentioned above, SOA is a vehicle to achieve business agility. However, this does not mean that an enterprise and specifically a service consumer do not have to react to locale-specific rules and policies. Before you embark on defining the actual architectural pattern, you will review a few alternate design and implementation models that can be employed to accomplish this goal.

The following approaches point to various degrees of re-use that can be applied to the design and implementation of a service as a solution to accommodate "situational" variance:

1. Creating a new service interface and service implementation: Offers code reuse
2. Extending the service implementation while retaining the service interface: Service interface re-use (and possibly base service implementation re-use)
3. Injecting situational awareness into the service implementation while retaining the service interface definition and most of the service implementation layers: Service interface reuse and service implementation re-use

It should be noted that these alternative models are documented in the order of increased flexibility and enhanced re-usability of the service interface and the service implementation layers.

A. Creating a new service interface and service implementation. Some by code level re-use may be achieved by copying and modifying the implementation code base

Pros:

1. Existing service implementation or code-base remains unaffected.
2. The impact on existing consumers is minimal because retesting and redeployment efforts impact only the new consumers that use the new code-base.
3. May result in a more performant deployment because it is tailored for use by specific consumer requests and contexts.

Cons:

1. Creates the need for supporting multiple service versions and thus introduces new service versioning and service management policy issues.
2. Consumers may need to know which service version they need to target and this in turn may result in consumer side changes. The reason is that the consumer may be required to "know" the right target service to fulfill the consumer-specific context and this knowledge is embedded in the request. More fundamentally, this breaks the premise of SOA.
3. Consumers also may need to now be aware of dealing with the "situational aspects" of the changed payload as well.
4. Service location for the purpose of mediation may become a problem if there is inaccurate or an insufficient amount of metadata available on the service request/service response envelope or header.
5. Service location mediation may become a bottleneck and non-performant, especially if the entire payload has to be parsed to route the call to the right service version.
6. There is a risk that the service behavior being delivered may not be in keeping with service usage semantics and "service contract" as is expected of the service provider.

B. Extending the service allows retaining the service interface while altering the service implementation

Pros:

1. There is no need to support multiple service versions, just the need to redirect the request to the appropriate service implementation based on the service request context.
2. Consumers are insulated from business rule variations and also service versioning complexity.
3. Consumers do not need to worry about targeting their request to the "appropriate target service" because this is taken care of by the service provider.
4. Consumers may not need to alter the payload definition or their consumption of the payload, but may need to augment some information on the request header.
5. This model may be more in line with the SOA paradigm.

Cons:

1. Introduces a service router or a service mediator component in the architecture that may become the performance bottle neck if a custom service mediator is employed instead of relying on a commercially available ESB component.
2. Multiple service implementation code-bases will need to be supported by the service provider.
3. Extending the service implementation code-base causes the service to have to be retested and redeployed and may have a negative impact on existing consumers because the service redirection component will need to be retested.
4. Code base extensions may lead to overriding behavior instead of enhancing of the base behavior provided by the existing code base; this could lead to non-deterministic regression test results.
5. Code extensions could cause the service usage semantics to be altered, thus digressing from the expected and advertised behavior of the service contract.

C. Applying the "Situational Awareness Injection Pattern" to retain both the service interface and service implementation

Pros:

1. The Service Interface and the service implementation are preserved.
2. Service implementation is extensible and flexible.
3. There is a reduction in the amount of testing and redeployment level issues.
4. Service behavior can be altered by specifying metadata; this results in greater speed to market given that the changes are not made to the code base.
5. Business users could become self-reliant and responsible for altering the business rules, thus reducing the risk of loss of translation in the business rules.

Cons:

1. Performance may be an issue due to externalization of the business rules.
2. Depending on the metadata used to drive the business behavior, the metadata to business rule mapping logic could become complex.
3. There is a need to introduce a business rules engine component to deploy the solution.
4. Code testing and debugging during the stabilization phase of the service can become complicated.
5. There is a one-time analysis hit to create the metadata repository that is extensible and flexible.

Overview of the Situational Awareness Injection Pattern

Making an enterprise service locale aware allows both the enterprise level rules and the locale-specific rules to be incorporated in honoring a service call. However, to preserve the code base, I propose a model that externalizes volatile business rules (regulatory policies and locale-specific business rules). This model keeps the service interface and the service implementation layers constant because the service implementation layer does not hard wire business rule definition and business rule interpretation logic in the code base.

This model also allows all layers of the service stack—in other words, the service interface and service implementation layer—to be re-used to deliver a consistent and robust solution. At the same time, context-specific rules are applied by the service provider and not by the service consumer. This then helps in making the service truly business friendly. Furthermore, creating a configurable "situationally"-aware service allows specific QoS policies to be applied, thus enabling the service provider to deliver context relevant business solutions.

The service model presented here shows how the attribution of both the information model and the canonical message interchange model is driven via the use of a metadata. Additionally, the attribute values are arrived at via the use of a business user friendly rules engine framework.

In this model, the service could either just return a business concept if it is just an information access service or else, in a more sophisticated service, it could also wrap a common business function. If a business function is being wrapped, the externalized rules would apply to the creation of the business concept attribute-set and the order in which regulatory rules are executed to alter the attribute values. Here, the assumption is that the end result of a business function execution is the creation of a "context specialized" business concept that is adapted to deal with the "situational rules" governing the consumer business context.

It must be noted that only those service interface-based operations that need volatile "situational" rules are impacted by the need to interpret external rules. This type of selective rules engine interaction enables the service implementation to be optimized to honor the consumer requests.

Rules governing how the business concept is populated and which algorithms are used are all encapsulated in the business service. These could be embedded in the business logic layer if these are stable, enterprise-worthy rules. On the other hand, in the case of volatile departmental rules, these could be defined in a business rules engine and these could be incorporated into the business logic layer at runtime. The algorithms and the rules are all encapsulated in the service and are easy to change in a consistent fashion. For instance, the enterprise may define the algorithm that is implemented in the service to be consistently applied. For example, customer profitability may be calculated to be a ratio of the sales factual information and payment history.

The service implementation process logic may take on multiple paths depending on the consumer context. The service provider also uses the consumer usage context to insure that only the relevant information is returned based on the needs of the consumer. This could also dictate what the consumer is allowed to view. The service provider also may be able to use this same usage context to optimize the amount of processing performed and the amount of information returned. Also, the provider may be able to make a determination on whether the information that is embedded in the payload needs to be encrypted and certified depending on whether the consumer is an internal or an external third-party requestor. Again, the semantics of the service invocation may vary based on the consumer usage context.

Description of the "Situational Awareness Injection" Pattern

Architecture Tiers of a Standard SOA Model

The following key architectural components are leveraged in any multi-tiered, SOA-compliant model. The layers are service consumer layer, service mediation layer, service provider layer, and the service implementation layer. In addition to these logical architectural layers, the metadata repository is leveraged to accomplish the contextual adaptation and business variation being described.

Click here for a larger image.

Figure 1: Description of the core component interactions in the "Situational Awareness Injection" pattern

Click here for a larger image.

Figure 2: Core architecture components of a Service Implementation Layer

The following are the key to achieving a dynamic business concept attribute set, attribute values, and business function behavior.

1. Controller (not in the MVC pattern but in the service provider's service implementation layer) looks up the configuration to get information about the locale information, operating business context, Line of Business or Division, 3^rd party roles, regulatory policy categories, and so forth.
2. Controller uses the metadata repository to fetch the business rules that drive the attribute-set definitions for the business concept and the override rules that impact the static values of the attributes.
3. Controller leverages a DAO (Data Access Object) to load the attribute-set and any static attribute values from the database.
4. The DAO creates/loads the Attribute Set that makes up the business concept.
5. The DAO creates/loads the Attribute Values that makes up the business concept.
6. Controller delegates the task of constructing the rules to the Context Interpreter.
7. The Rules Framework takes on the task of applying rules and assigning the attributes to the business concept to the Rules Framework. Following are some details about the internals of the Rules Framework and the behavior it manifests:
• Rules may be used to define "context-specific" business concept attribute sets.
• Rules also may be used to override the static attribute values obtained from the database under "specialized" business conditions and when the business concepts have to be adapted to deal with volatile regulatory policies.
• Rules also may change the attribute set and the values assigned to the attribute set in response to any 3^rd party interactions that are involved in executing the business function wrapped by the service.
• The assumption is that static values are materialized from a single data source of values or in more complex businesses there could be a taxonomy of rules that override these attribute values as a series of rules fire, altering the base value.
• Rules Framework can also be used to define Rule Sets that support the definition of a hierarchy of rules where the order of execution of rules is important. In this model, one or more rules can be used to process static values of an attribute and then these attributes can be aggregated to create a complex derived attribute.
• Rules Framework may define taxonomy of rules based on the Rule Type categories as well. In this model, the order of precedence of situational Rule Type category application can be modeled into the Rule Sets. For example, business unit operational rules are applied and processed prior to regulatory rules. In this model, business unit operational attribute-sets or attribute values may be overridden when the subsequent regulatory rules fire.
• Rules also may be used to determine how to calculate and apply enterprise-compliant algorithms to certain attributes or attribute values of a business concept.
• In general, the Rules Framework is only leveraged to support volatile attributes. Static attributes of a canonical model are built into the business concept. It must be noted that there is a support and performance impact to having dynamic attributes and dynamic values via the Rules Framework.
• Finally, it must be noted that the behavioral model when leveraging dynamic rules renders the service implementation layer less deterministic from an error handling perspective.

Note: Appendix B defines the interactions of the infrastructure components in the setup view and runtime views that help to demonstrate how the architecture components work together to support the concepts of the Situational Awareness Injection service pattern.

Checklist to Identify Conditions of Applicability of the Situational Awareness Injection Pattern

The following business and service characteristics are the some of the key traits of the use case that could leverage this pattern.

1. Business rules are volatile and are subject to change due to changing business conditions, competition, or operational environment.
2. Business variations are manifested in the way a business concept is populated to respond to situational changes, such as weather changes or sports events.
3. Business rule changes are driven by external regulatory and governmental bodies.
4. Business rules affect or alter the attribute and attribute values assigned to the business concept.
5. Business users require a facility to simulate business conditions to alter the business concept state to understand how to react to business opportunities.

Caveats of Over Indulgence in Using the Situational Awareness Injection Pattern

The following caveats need to be kept in mind to prevent over dependence and over use of this pattern.

1. Over indulgence in using this pattern of externalizing the business rules of all types can cause the service to become ridden with the inconsistent application of process and business logic and will negatively impact the performance profile of the service. This is especially so when externalized business rules are used as a mechanism to short circuit analysis time needed to discern between the volatile rules and core business behavior.
2. If the primary driver is protecting oneself from change rather than supporting (appropriate) business variation, this would have a negative impact on how changes are rolled into the service. This results in affecting all the consumers as the service has non-deterministic and unreliable service behavior.
3. Service flexibility undoubtedly breeds complexity and has impacts on both deployment and on-going maintainability of the service.
4. Flawed analysis may cause the consumer context to start influencing the other aspects of the service not related to the core behavior of the business service. Not having strict separation of concerns may lead to the business service becoming tied to a single consumer context instead of encapsulating business rules that are generic and enterprise-worthy. In this case, the service provider code base will end up with consumer-specific information that is not just related to the context-based population of the business entity but also includes behavior related to the application of information to a specific consumer usage context. This renders the service non-reusable and will steer the service behavior and the expressed semantics expressed away from that of the published service interface.
5. Business rule and policy management is critical to the ongoing maintainability of this model. It is crucial to have a repeatable governance process in place to allow the alteration of business rules that affect service behavior.
6. Reliable tools that enable "what-if analysis" and "rule simulation environments" are required to insure that the new rules are in fact valid prior to being promoted into production environments.
7. It is imperative to have an audit trail of changes to the business rules being published to the service implementation environment. Additionally, the discipline of performing detailed impact analysis in releasing new rules to the services' production environment has to be practiced.
8. People and training are an important aspect that needs to be addressed in dealing with this architectural pattern. Business users need to be aware of the role they play and have to take ownership of the process of both defining the rules and the consequences of the rule changes.

Conclusion and Next Steps

As can be seen, contextual information such as business divisions and/or regulatory influences can all affect the service behavior and the population of the business concept. The "situational awareness injection" pattern leverages an external rules engine to apply rules to the service implementation layer. The service interface is retained across the enterprise despite the need to support variances in operational contexts across the multiple business divisions.

These externalized business rules are based on the business context of the consumer and are applied to alter the behavior of the business service while preserving the service interface. The business context is supplied either by the service consumer in the request or it is provided to the business service as part of the "configuration" or is embedded as an environmental parameter supplied during the deployment of the service. Regardless of where the context comes from, this pattern enables not only the ability of insulating the consumer from the rules and policy changes but also allows the encapsulation of all of the "situational" business rules in the service, thus making it easy for the enterprise or the business division to alter the rules without impacting the business consumers.

The reader will conclude that their company should seriously investigate applying the Situational Awareness Injection Service pattern. This includes the identification of business services fitting the Situational Awareness Injection Service pattern and the identification of required infrastructure services and runtime assets that might be needed to enable contextual variation without having to undertake service replication.

The architecture model presented here has great applicability in the realm of SaaS-style service offerings as well as in a service grid market place. The core architecture model and the interactions defined in this article promote the service interface preservation while allowing variations in cross-divisional business concept information. These variations may be needed to support situational behavior resulting from changes to regulatory policies or to the business unit-operating environment.

About the Author

Surekha Durvasula is an enterprise architect who has had 10 plus years experience in designing and architecting a variety of enterprise applications in the financial services sector and the retail industry vertical. Most of her work has been in the area of distributed N-tiered architecture, including JEE component architecture. Her more recent focus has been on Service Oriented Architecture, Business Process Management, and Business Architecture. Her efforts as an Enterprise Architect involve not only architecting new applications and business services but also in leveraging the principles of SOA to extend the life of existing Enterprise Information Systems. She currently manages the Enterprise Architecture Group that involves establishing the discipline of Enterprise Architecture for the organization including preparing the organization to take advantage of the concepts of Service Orientation.

Appendix A: Business Scenario

Customer Account: Applying the Situational Awareness Injection pattern

In an enterprise that uses the Customer Account information as a common business entity, the following divisions/lines of business all could leverage the same business service:

1. Brokerage/Investment banking division
2. Loans/Mortgage department
3. Credit division
4. Retail banking
5. Corporate marketing departments

The Customer Account business entity-based attributes and values are impacted by diverse the user communities needs and by the disparate operational business contexts that are needed by business divisions and/or regulatory policies. Furthermore, there is a possibility that these business variations influence the associative Customer Account business entities.

For example, the Brokerage division may need Customer Preference and Customer Service Election aspects and the marketing division may just need the Customer Profitability aspect of the Customer Account. Further, the Loan/Mortgage and Credit divisions may need Customer Profitability and Customer Credit Scores. The Customer Credit Score allows the Loans/Mortgage division to assess "Risk Exposure" ratios. Customer Profitability could be considered an aggregated attribute value that is derived from the Credit Score and the Customer History attributes. The Marketing department may be given a Customer Profitability Range to help create targeted campaigns, but may not be given access to the Credit Score.

Again, the information that is returned to the consumer is dependent on the usage context. It is this context that helps the service layer determine whether a numeric customer score is to be returned or else if a customer classification is returned. The usage context of the Marketing department is authorized only to get the Customer Profitability customer classification such as platinum, gold, or the silver status and not a customer credit score.

The business context can be obtained from the incoming request or from the deployment environment parameter. This is used as a reference by the business service to populate the business entity as the operating business context causes the appropriate rules to fire in the service. Business context also can be used to suppress a subset of business attributes for which the service consumer may not be authorized. This suppression of attributes may limit what the service consumer has access to and may occur in response to the application of business unit-level policies. To respond to these business unit level policies, the service provider may have rules in the service implementation layer that get triggered when the specific business context is encountered. This could be manifest in the customer example where the customer social security number or credit scores are returned only to the Mortgage or the Credit business units while a "Marketing" business unit context renders these attributes to be suppressed.

In addition, the business usage context could be used to selectively return only information that is expensive in terms of size of the payload or in terms of the processing required to build the payload. This business usage context allows the service provider to honor specific service invocations. By extension, depending on the specific business context the service can return either granular information or else it can return aggregated high level information. Thus, this business context can be used to determine the level of processing needed in the service implementation layer without impacting response time for all of the consumers.

For example, in the business context of the service desk or the retail personal banker, the service may return transaction history for open issues/inquiries, but the same level of information is not returned in the marketing consumer. On the other hand, in the case of the investment banking usage context, the customer preferences and customer service elections may be returned to improve personalization of services being offered to the end users.

In other cases, the business usage context may be used to perform additional business behavior. In the retail banking context, information may return information based just on the income information and the Credit Division context may force the service provider to enlist an external credit agency to get the credit scores. A call made to the service with a Mortgage may have to provide additional information to assess the customer risk prior to arriving at the mortgage rate.

Appendix B: Diagrams of the Infrastructure Service Interactions

Overview of the Setup and Rule or Policy Change Interactions

The infrastructure services and runtime assets used to implement pattern (Rules engine, Metadata Repository, Rule Caches and indexing algorithms, ESB, and so on).

Click here for a larger image.

Figure B1: Setup and Rule or Policy Change behavior

Click here for a larger image.

Figure B2: Setup and Rule Policy Change behavior

Overview of the Runtime Interactions

Click here for a larger image.

Figure B3: Runtime behavior

Click here for a larger image.

Figure B4: Runtime Behavior