Credit Risk Calculation Engine
A credit risk calculation engine calculates the risk exposures for certain types of financial transactions.

Traditional Application-Centric Design
A credit risk calculation engine is designed as a self-contained financial application that:

• Utilizes financial transaction data from the operational data store with related details from the reference data, client reference, and money market data stores (supported by four different teams)
• Calculates risks according to the predefined formulas
• Stores credit exposures (results) in the result operational data store

The calculation engine team has a schedule of when to calculate intra-day and end-of-day risks and knows which data should be used in each case, when and how to check data accessibility in each of the data stores, which procedure to follow in the case of data store schema changes, which procedure to follow if security and compliance rules and regulations change, and when and what should be re-deployed in case of life-cycle changes in each of the consumer applications.

It's obvious the team has to perform a lot of activities that are unrelated to the credit risk calculation. Thus, any change in the calculation business rules or an appearance of additional calculations starts a laborious process of negotiations and synchronizations between the credit risk calculation engine team and all other resource and consumer teams, each of which has its own objectives and, sometimes, conflicting interests. This results in slow and sometimes a partial implementation of the change, i.e., higher cost and longer time-to-market.

SOA Design Style
The credit risk calculation engine is designed as a service (CRCS) with a set of contracts with its consumers. There may be single contract for all or multiple contracts. The engine is obliged to perform credit risk calculations on the data that's totally described by certain metadata (descriptors) with predefined performances. This is it.

The CRCS receives a command from the Business Process Management (BPM) Service on when to perform this or that risk calculation task and which data to use. The CRCS engages the data access service to obtain all necessary data for the calculations. The exposures are returned to the data access service as well.

The CRCS doesn't know where the data comes from and where the results would go, and what policies are to be applied and how. If the CRCS gets household data instead of financial transaction data, it still has to be able to perform perfect calculations until the data meets the metadata definitions.

The CRCS team is only concerned with service performances, stability, reliability, and deployment/configuration manageability. It shares concerns of scalability with the Business Process Management Service because the latter may be able to invoke several CRCS, if needed.

Now, when a new type of financial transaction has to be processed in the CRCS (such a big change indeed), very little needs to be done. First, data for the new calculations should be provided by the Data Access Service in the form of a unified document-style data container. Then the CRCS has to add a new formula to the calculation module. If the module has an interface of the Command Pattern style, a new formula invocation isn't more complex than a new command request. Plus, the data for new calculations, provided by the data access service, is encapsulated in another unified document-style container.

Thus, without the knowledge of a real business service provided by the credit risk calculation function, it might be not obvious that the CRCS needed to be designed with the Command Pattern style and that the data needed to be encapsulated into the document-style containers by the data carriers. In such a case, the processing of new financial transactions would require a lot of application and/or service interface modifications (including all dependents). You can imagine how costly it would be in production with many consumers in place.

Summary
The SOA RM standard emphasizes the business aspects of SOA and provides a rich foundation for positioning enterprise architecture around the enterprise business model. This article has described one of possible interpretations of the enterprise business model in terms of business services and business processes. The observation was followed by two examples of how a SOA service may be designed for these changes based on the understanding of the enterprise business services and processes and their business scope. Indeed, if we have an enterprise architecture that's focused on real business functions (rather than on operations), why don't we take advantage of it?

Resources

Reference Model for Service Oriented Architecture 1.0. OASIS:
www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

Ostenwalder, Y. Pigneur, and C.L. Tucci. Clarifying Business Models: Origins, Present, and Future of the Concept. Communications of AIS, Volume 15, Article 1:
www.businessmodeldesign.com/publications/Preprint%20Clarifying %20Business%20Models%20Origins,%20Present,%20and%20Future%20of%20the%20Concept.pdf

Digital Business Architecture: Harnessing IT for Business Flexibility. Forrester Research:
www.forrester.com/ResearchThemes/DigitalBusinessArchitecture