January 21, 2021
Hot Topics:

Achieving Situational Awareness in Enterprise Services

  • By Surekha Durvasula
  • Send Email »
  • More Articles »

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

Page 4 of 6

This article was originally published on March 27, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date