Achieving Situational Awareness in Enterprise Services
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).
Figure B1: Setup and Rule or Policy Change behavior
Figure B2: Setup and Rule Policy Change behavior
Page 5 of 6