Export (0) Print
Expand All

Financial Services OBA

 

Mike Walker

Microsoft Corporation

December 2006

Contents

Introduction
Loan-Origination Office Business Application
Technical Architecture
Enabling Scenarios

Introduction

This white paper will walk you through a loan-origination scenario. This scenario is tailored for the banking industry. It will provide guidance for making architecture decisions around real-world business and technology issues that plague the banking industry. It will also help you identify opportunities in your business for using Microsoft Office SharePoint Server (MOSS), Microsoft BizTalk, and Microsoft SQL Server. Using these, we will show how to:

  • Enable business processes through a standardized application-services tier.
  • Create a scalable messaging architecture to expose standardized Web services and maximize interoperability inside your organization.
  • Expose Office Business Applications (OBAs) through these reusable services layers.

The MOSS platform provides a rich application-services layer that enables many reusable services for your enterprise's SOA. These services include, but are not limited to:

  • Enterprise Content Management (ECM). Can be leveraged to publish dynamic and user-manageable content.
  • Workflow. Using Windows Workflow Foundation (WWF).
  • Composable portal platform. A framework for building rich composite Web-based user interfaces.
  • Web Parts enabled through the portal platform. There are several out-of-the-box parts for both Office SharePoint and SQL Server Reporting and Analysis Services.
  • Digital Rights Management (DRM). To control who can view, distribute, or print content.
  • Document storage facilities. To aid in versioning and document-auditing capabilities.
  • Business-Data Catalog (BDC). To expose line-of-business (LOB) data to the presentation layer.

Building feature-rich composite-style applications is the goal of OBAs. Using this technology, financial-services organizations can migrate to an SOA with more ease than ever before. This paper will discuss both integration and composability issues between applications, and how these can be accomplished in several different ways.

The first and most mature way to integrate is by focusing on the integration of data. This approach, however, leaves much to be desired, because you lose the behavior that goes with the data. The introduction of service orientation and XML-based standards have created a second and much more useful method of integration that allows for applications to be integrated while preserving behaviors and data to bring together disparate business logic. However, because there are many ways to provide a service that exposes application functionality, as well as many ways to implement the XML standards used, integration at the service level can become cumbersome due to a lack of consistency.

We will use a scenario to focus on some of the specific needs for financial services. This scenario will provide means for partners and customers to integrate banking applications and establish consistency in this integration.

Enabling Technologies

  • Microsoft BizTalk—By using BizTalk, banks can now orchestrate their business processes in a dynamic and fluid way.
  • Microsoft .NET Framework 3.0 (WPF, WCF, WWF)
    • Windows Presentation Foundation (WPF) can reduce the training time of loan executives, officers, underwriters, and secondary marketing personnel. This is increasingly important in high-turnover areas.
    • Windows Communication Framework (WCF) will reduce the increased complexities of the integration needs. For example, it will cover integration of: broker, correspondent bank, flood, mortgage insurance (MI), appraisal, credit, verification of funds, and cross-sell services.
    • Windows Workflow Foundation (WWF) provides banks the flexibility to create workflows around documents such as Office Excel, Office Word, and Office PowerPoint.
  • 2007 Microsoft Office System (Office SharePoint, Office Excel Server, documents)
    • Office SharePoint can host your loan documents in a centralized, versioned, and secure environment while also adding functionality, such as approval workflows and communications, using Office Communicator.
    • Office Excel Server can host your Office Excel data in a central store with robust relational database features that will provide protection of data, centralized backup procedures, a single version of the truth, and security around sensitive data. This will provide the Office Excel user experience for multiple services, without cross-training on other applications.
    • Document formats have been changed to an open document format: Open XML. This will ensure cross-platform compatibility, robust integration, document-manipulation opportunities, and controlled data-integrity checks from within the documents themselves.
  • Smart Client—Having disconnected systems for the mobile work force is becoming increasingly important for banks.
    • Microsoft Windows Mobile—Mobile devices can be leveraged in the field for appraisal visits and zoning.

Financial Services Business and Technical Challenges

In the context of composite applications, there are quite a few challenges in financial services. Banks and insurance companies are starting to push more and more services to the edge—things like ordering stamps at an ATM, from a consumer perspective.

For this paper, the focus will on a specific line of business (LOB): the consumer loan. Within the consumer loan, there are multiple channels in which business enters into the process and many stages in those channels. There are four major channels that are common in banks today:

  • Wholesale
  • Correspondent
  • Telesales
  • Retail

There are some commonalities among these, but there is also exclusive behavior.

Loan-Origination Office Business Application

In the loan-origination business, there are many business drivers for banks: process consolidation, regulatory compliance, and faster product delivery (loan completion). Loan products change frequently and are usually dynamic, based on location (regional or state). Developing and modifying products in an agile manner enables banks to be highly competitive and adaptable in key markets. Also, compiling and staying on top of regulatory laws is always a challenge, given the turbulent changes happening in the industry today. Laws such as the Community Reinvestment Act (CRA), Home Mortgage Disclosure Act (HMDA), and anti-predatory lending often require cumbersome integration issues and data-mining exercises. The complexities of multiple processes for regions, tiered pricing, or special market demands complicate the overall process. Banks are now trying to consolidate processes to reduce this complexity and maximize value. Not only are banks trying to reduce the amount of processes, but they are also trying to reduce what is called the "application to delivery cycle." By reducing this window, banks are seeing savings in the range of three basis points and closing more loans per month.

The application demonstrates alignment with key business processes within the loan origination. Because we are only taking a subset of loan origination and focusing on one channel, there will be some processes missing. It is also important to note that the reference architecture will stop at document preparation and closing. The channels highlighted are the following (see Figure 1):

  • Products and pricing—The process in which personnel at the lender will analyze the secondary market and apply the proper pricing to the products (30-year fixed) or their portfolio products (products that the bank funds and usually doesn't sell).
  • Application or registration—When the customer enters the proper qualification information for a loan product.
  • Processing or locking loan—When a customer agrees to a specific product and rate, and "locks into a commitment." This stage kicks off many subprocesses that gather extended information on the customer, to prepare the underwriters to make a decision on the loan.
  • Underwriting—The process in which an underwriter makes a decision on the loan.

Bb245764.cmpappsfinserv01(en-us,MSDN.10).gif

Figure 1. Business channels

With this solution, it is important to understand the amount of complexity both in the business processes and the current-state technology landscape. The technology landscape will be defined in the technical architecture section that follows.

Defining the business architecture will aid in the value proposition to banks and other enterprises that deploy similar solutions. This business architecture will define the core process areas and model them to derive the proper technical architecture.

Keep in mind, when architecting solutions, that the technology components are just one of the pieces. There are human elements when architecting solutions. So, not only do we take the system-level processes into account, but also the human or manual processes, in order to give the architect the complete perspective.

Understanding loan origination is not easy, due to its complexities. However, comprehending some core concepts of loan origination will make things easier:

  • Definition of products and corresponding pricing
  • Long-running workflow
  • Approval processes
  • Calculations

Figure 2 is a representation of the business capabilities. These are not independent functions. There are interwoven dependencies between each of the business functions.

Bb245764.cmpappsfinserv02(en-us,MSDN.10).gif

Figure 2. Business capabilities

Briefly, these capabilities are described as follows:

  • Origination—The process of acquiring the customer, the corresponding data, making decisions based on processing, and requesting data from third-party services.
  • Third-party services—Used to pull data on the customer and the property being purchased.
  • Secondary—Processes that happen at varying times in the process. For the scope of this solution, we will focus on pricing for the various mortgage products (such as 30-year fixed).
  • Servicing—After origination, loans are either booked on the bank or sold on the secondary market (other banks, Fannie Mae, Freddie Mac, and so forth).

These might seem like simple processes, on the surface; however, there are several business challenges here. Earlier core concepts were described (long-running workflow, approval, and so forth). These core concepts are very complex. Listed here are some of the challenges the loan industry faces. The goal is for this architecture to aid in the simplification or elimination of these issues:

  • Workflows are complex and difficult to manage. These are often based on exception processes, particularly portfolio loans, and region, and typically will have business logic embedded in each of the processes.
  • Fragmented processes and little automation.
  • Redundant systems supporting business process.

Technical Architecture

Now that we understand the business architecture, we will describe the technical architecture in each logical tier of the solution. This is shown in Figure 3.

Click here for larger image

Figure 3. Logical architecture (Click on the picture for a larger image)

Microsoft Office SharePoint Services Architecture

The MOSS architecture is really several logical layers (see Figure 4). This consists of the:

  • Presentation layer. Serves as the user interface. ASP.NET 3.0 Web forms hosted on the Windows SharePoint Portal Server. Office SharePoint will provide the underpinnings for the application. There will be several services that can be inherited from this environment—specifically, the portal architecture that will be required to deploy Web Parts for this solution.
  • Application-services layer. A reusable layer in the architecture. This will allow applications to use functionality such as Digital Rights Management, Document Libraries, Workflow, and so forth.
  • Services layer. Provides an infrastructure to communicate messages. The MOSS layer will use WCF. The Integration layer will use BizTalk.

Bb245764.cmpappsfinserv04(en-us,MSDN.10).gif

Figure 4. The MOSS layers

Presentation

There were several options when considering the user-interface architecture. The presentation layer will be a Web-based application. It will expose MOSS Web pages from here. For security and scalability reasons, the presentation and business-logic layers are separated.

  • Windows Presentation Foundation (WPF)—Used for rich user interfaces. Similarities with other presentation frameworks would include Adobe Flash. WPF was ruled out for this scenario, because this rich of a presentation was not required by the solution. However, it could be a fit if organizations want that rich interface.
  • ASP.NET Web Forms—The .NET form of Web pages, also referred to as "aspx pages." Web Forms were chosen as the UI of choice for this solution, for their ease of customization and more application-centric presentation.
  • Office InfoPath Forms—Form-based services used when data-entry forms are required. These were not chosen, because the application was process-oriented and not data-oriented.

The following table represents a comparison chart of the technologies we used.

Table 1. Comparison of technologies

CriteriaWeb FormsOffice InfoPath Forms
User experienceApplication-centricUser entry/form-centric
Content controlAllows customized or fine-grained control over page elementsDynamic UI is possible by creating multiple views of the same form.
Page plow and navigationNeed custom code to handle navigationNeed custom code to handle navigation
Development environmentMicrosoft Office SharePoint Designer/Microsoft Visual StudioOffice InfoPath client or VSTO.
Integration with Office SharePointNeed to add pages to SharePoint sites

Need custom code to persist data from the page into a document library

Need to deploy forms on a SharePoint form library. After filling a form, the data can be automatically stored in the form library as XML.
Validation of page data when user enters valuesNeed custom code to validate fieldsDuring form design, validation can be added to fields with minimal code. At run time, the fields are validated without requiring post-back to the server.
XML integrationNeed custom code to map XML schema to Web page fieldsNative support for binding XML schema to page fields.
ReusabilityCan be used in a Web client onlyThe forms can be used in an offline scenario or embedded within e-mail.
PlatformBuilt on ASP.NET 2.0Built using ASP.NET 2.0 and Forms Services, which is part of MOSS.

Using the Web Forms, you can integrate Office SharePoint Web Parts in a more appealing way. In addition, you gain content management. Examples on how this can benefit financial-services organizations include the ability:

  • To customize themes and logos.
  • To display messages to users on specific pages for many reasons, such as marketing, training, or cross-selling of products or services.
  • To inherit rich navigation features provided by the MOSS portal platform.
  • For user interfaces to manage and version content within the application.

Click here for larger image

Figure 5. Office SharePoint user interface (Click on the picture for a larger image)

The greater portion of this page design comes from Web Parts, befitting the composite architecture of the application.

Microsoft Office Clients

Training resources on new applications can be costly. In contrast, clients of this system will all be familiar with the Microsoft Office client tools, such as Office Excel, Office Word, and Office Outlook. These tools will integrate in various ways.

Bb245764.cmpappsfinserv06(en-us,MSDN.10).gif

Figure 6. Using Office Excel as a client

  • Office Outlook—Used to send tasks to the underwriters, processors, and secondary marketing personnel.
  • Office Excel—Used to generate rates and enter them into the system (see Figure 6).
  • Office Word—Used to read generated documentation, integrate with document libraries, and publish content and communiqués to internal staff and brokers.
  • Office SharePoint Server—Provides a scalable and efficient records-management system. The record repository acts as the hub for all record-management processes, including content collection (spreadsheets, documents, e-mail, and non-digital items), policy enforcement, item retention in response to external events, and content disposal.

Bb245764.cmpappsfinserv07(en-us,MSDN.10).gif

Figure7. Solving regulatory issues with MOSS technologies

These capabilities will also aid in auditing and regulatory issues around records-management requirements, as shown in Figure 7.

The record repository has several features that help ensure the integrity of files that are stored there. The first is the ability to ensure that records are never automatically modified by the system. This means that records that are uploaded to a record repository and then downloaded later will be identical, byte for byte. The second are the default version and audit settings that monitor changes to content, to prevent direct tampering with records. Thirdly, records managers can add and maintain metadata on items separately from the records' metadata. This allows information such as who manages the item to be changed, without modifying the underlying record. Changes to this metadata are versioned, too.

Application Services

The following built-in MOSS services (see Figure 8) are used in this solution:

  • Portal framework—Has the ability to provide a composite architecture that exposes Web Parts for discrete pieces of functionality.
  • Content management—Used to control the content that is exposed to the users.
  • Office Excel Web services—Used for all calculations.
  • Document libraries—Provides management functionality for auditing and versioning.
  • Windows Workflow Foundation (WWF)—Used for orchestrating the business process.

Bb245764.cmpappsfinserv08(en-us,MSDN.10).gif

Figure 8. Application-services implementation reference

WWF and WCF Design Considerations

In this solution, you will notice that there are two workflows used; one is contained within MOSS and the other in BizTalk. The built-in workflow used in MOSS is WWF. This will be used to manage the user-centric aspects of the architecture and govern the overall process A-to-Z.

The workflow in BizTalk is used to manage workflow for integration, as shown in Figure 9. We will cover this in more detail later.

Click here for larger image

Figure9. WWF interaction with BizTalk (Click on the picture for a larger image)

Increasingly, there is a need to coordinate the interactions between real human actors in software. Humans are, of course, a key participant in almost every software system, especially in collaborative processes, and they play a key part in a composite application. There are some common challenges faced when involving humans in structured workflow systems. These include scenarios such as approvals, a participant is out sick or on vacation, and provisioning a user.

Within human workflow (see Figure 10), people communicate with various systems and other people in a business process implemented in software using a workflow model. In this model, prebuilt units of behavior and defined workflows can be coordinated. The key to human workflow is that those units of behavior represent not only system-performed actions, but also actions and decisions undertaken by human actors.

Click here for larger image

Figure 10. Business process modeled (Click on the picture for a larger image)

The detailed scenarios will be discussed later. The referenced scenarios will cover how WWF can extend the following business capabilities:

  • Products and pricing
  • Loan registration

Here, we will discuss the overarching workflows. There are two primary workflows that govern the loan-origination solution:

  • Master Loan workflow—Controls the full lifetime of the loan, from the original data entry of the registration to the underwriting decision (see Figure 11).
  • Pricing workflow—Used by the secondary marketing employees who are responsible for importing and applying daily rates on products.

Click here for larger image

Figure 11. Master Loan workflow (Click on the picture for a larger image)

Integration Layer Architecture

With this solution, we decided to have a dedicated messaging layer for integration. This layer is consistent with terms that are floating around the industry today, such as Enterprise Service Bus (ESB). However, for the sake of this solution, it will simply be referred to as a message bus.

Separating out the integration layer gives this solution many advantages. The architecture decisions leading to this course of action (instead of just simply using WCF for point-to-point integration) are the following:

  • Centralized messaging layer—In a heterogeneous environment, such as banking, a centralized messaging layer reduces complexity by removing the endless number of point-to-point integrations, thus reducing code complexity, cost, and error rates.
  • Message management—A message bus will provide Business-Process Management (BPM) facilities to monitor the overall health of the messaging in the solution.
  • Scalability—This is crucial when the business needs a resilient and high-traffic solution, such as loan origination.
  • Extensibility—A requirement in the loan origination. There are many external and internal touch points that are interwoven within the process.
  • Reduction of integration complexity—With so many services and varying applications, lack of integration is—in most cases—a business inhibitor.
  • Achieving agility—Having this layer will provide the necessary reductions in code, streamline business workflow, and tend towards an SOA.
  • Elimination of application redundancy—By using a message bus and business-rules engine (BRE). By doing so, banks can slowly migrate off of redundant solutions or platforms.

The integration layer consists of Web services stubs exposed from MOSS in conjunction with the BizTalk Web services endpoints.

Bb245764.cmpappsfinserv12(en-us,MSDN.10).gif

Figure 12.WWF and BizTalk interaction

As shown in Figure 12, we used Web services to interoperate with MOSS. This enables other external applications and/or workflows to interoperate using standard Web services with any layer in the loan-origination architecture, giving the solution ultimate flexibility.

Message Architecture

Messages that flow through the message bus will not only be Web services–compliant, but they will also use the business message standard called MISMO. This is a U.S.-centric mortgage messaging standard created by the Mortgage Bankers Association (MBA). It is critical to be compliant at both WWF and BizTalk layers to ensure interoperability (see Figure 13).

Click here for larger image

Figure 13. MISMO Accelerator in BizTalk (Click on the picture for a larger image)

Message Schemas

Throughout the solution, it was critical to use standardized XML (see Figure 14) to ensure standardized messaging and protocols for both compositability and extensibility. In addition to standardized XML, the MISMO schemas—which provide the proper business context, where used—ensure interoperability with existing commercial off-the-shelf (COTS) applications and existing third-party managed services.

This level of extensibility provides the ability to orchestrate several other external business processes that may be housed in other applications. This is a very common scenario. In many cases, there could be several diverse loan systems in varying capacities that must be integrated. Most times, these are used for specific business channels (for example, correspondent banking versus wholesale banking). In this architecture, BizTalk will coordinate the Web services using out-of-the-box Business-Process Management (BPM) facilities.

Bb245764.cmpappsfinserv14(en-us,MSDN.10).gif

Figure 14. Extensibility of the platform

When using the MISMO schemas shown in Figure 15, there were some gaps, because the last update of the MISMO DTDs were a few years old. Listed here are the missing components, from both a technical and business perspective:

  • Outdated XML contracts—Converted DTDs to schemas
  • Additional schemas—Created for needed business-processes functionality

Bb245764.cmpappsfinserv15(en-us,MSDN.10).gif

Figure 15. MISMO schemas used

Table 2. MISMO messages used

Message nameSenderReceiverPurpose
MortgageApplicationOffice InfoPathBizTalk orchestration and business-rules engineRegister in loan system
RequestFloodBizTalk OrchestrationStub third-party providerRetrieving the flood data about a property
RequestCreditBizTalk OrchestrationStub third-party providerRetrieving borrower's credit data
RequestMIBizTalk OrchestrationStub third-party providerRetrieving the property's mortgage insurance
RequestTitleBizTalk OrchestrationStub third-party providerRetrieving a property's title data

Table 3. Additional schemas created

Message nameSenderReceiverPurpose
Request3rdPartyServicesOffice SharePoint loan workflowBizTalk OrchestrationRetrieving the third-party data, like flood, title, and so on
Store3rdPartyResponseBizTalk orchestrationWeb service within Office SharePointSending third-party data back to Office SharePoint
GetEligibleRatesOffice SharePoint loan workflowBizTalk OrchestrationRetrieving the products for which a borrower is eligible
GetProvidersOffice SharePoint workflowBizTalkRetrieving the list of providers for a specific loan

Message Flow

Messages flow in and out of the centralized message hub using standardized MISMO messages. As discussed earlier, additional messages had to be developed for this solution.

Points to note:

  • The majority of the messages flow through the message hub.
  • All integration-based orchestrations and messaging go through the message bus.
  • The message hub brokers the BRE.
  • WWF is the overarching control that coordinates the entire business process.
  • Web services will be used primarily as the integration technology.

Orchestration Architecture

Orchestration is handled in two places in this solution. As described in the MOSS section, WWF handles the human and page workflow of the solution. The WWF workflow integrates with the second orchestration layer, BizTalk.

BizTalk will provide all orchestrations around the following:

  • Integration with third-party services, internal applications, and management of external workflow
  • Interaction with the BRE
  • Interface for all external integrations with the loan system

Business-Rules Engine Architecture

The BRE is an abstraction layer to separate the workflow from the solution. This will give the solution the necessary flexibility required in today's agile banking environment. The rational for this is the intensive business rules in loan origination, in which there are many business rules that have strictly similar logic. Separating the workflow from the solution generalizes these and provides a greater level of reusability.

Rules contained in the BRE will be built using .NET 3.0 technologies. It is intended that these components will be called from BizTalk or exposed as Web services at an extensibility point. Because the BRE is just another .NET assembly, the BRE can be extended to any .NET application by referencing the specific implementation of the BRE.

It is assumed that the reader has a basic understanding of BREs. We will minimize the explanation of these concepts and devote our conversation to the implementation of BRE in the context of BizTalk.

Terms

The following terms will be used:

  • Rules—The specific business-rule functionality that must be computed or verified.
  • Policies—Logical groupings of rules.
  • Facts—Arguments passed to the Policies and Rules. These facts are evaluated and used to perform some level of business functionality.
  • Vocabulary—Rule conditions and actions, usually expressed in domain or industry-specific nomenclature.

Click here for larger image

Figure 16. Integrating with the BizTalk BRE (Click on the picture for a larger image)

The process shown in Figure 16 is managed through a common set of highly integrated tooling. The Orchestration Designer, together with the BizTalk Editor and the BizTalk Mapper, provide an effective way to define a business process and the rules it uses. It can be useful, however, to have an easier way to define and change business rules.

Making the Case for BRE for Loan Origination

Usage of BREs in a formal manner is still not as common as one would think. BREs are not a new concept; they actually have been around for some time now. These engines were first used in the 1950s for experimentation with artificial intelligence. Through the course of the years, they have been used to isolate business rules in one discrete place. Developers will most often use the BRE; but, in BizTalk, business-oriented users can create and modify sets of business rules using a tool called the Business Rule Composer, as shown in Table 4.

Table 4. The BRE case

Business challengeBRE case
Loan origination has complex rules, based on a specific workflow.BizTalk has an open and extensible way of creating orchestrations with shapes and linked to specific business-rules implementations.
Majority of rules and calculations don't change often. However, invocation, order, and parameters of those rules change.Generic or reusable business rules can be created very easily on the BizTalk platform. There is clear separation of the Orchestration and Business Rule IDEs. Developers or business analysts can modify rules in a WYSWIG manner.
Loan systems have many business channels, with varying applications accessing them.With BizTalk and its adapter framework, different interfaces can be used for just about any protocol. The most open would be the Web Services or XML adapter. We use Web Services adapter for the loan-origination architecture.
With increased merger and acquisition, it is common to have redundancy of loan systems.Managing multiple systems is a cumbersome and large development effort. BizTalk can manage internal and external orchestrations in a short- or long-running workflow environment.
Multiple loan systems with unique business rules.Redundant loan systems can be managed in a similar method. Sometimes, it makes sense to keep these systems around or to have a phased consolidation approach.
Loan systems have an increasing need to integrate with internal and external systems, such as DDA, CRM, or marketing and external providers, such as credit or mortgage insurance.Integration is BizTalk's strong suit. With an extensive adapter framework and message-bus architecture, integration with disparate systems has never been this easy. Relevant adapters include:

MISMO (reference implementation)

IFX

SWIFT

3270 emulation

This implementation of the BizTalk BRE is useful when a complex set of business rules must be evaluated. Deciding whether to grant a loan might entail working through a large set of rules, based on the customer's credit history, income, and other factors. In addition to specific rules, these factors must be in sync with several business process determined by the bank. Underwriters are alerted whether to approve an applicant, depending on a number of things, including the applicant's age, gender, and external data request from third-party services. Expressing all of these rules as conditional statements using, say, an orchestration's Decide shape might be possible, but it would be fairly complex to implement. For rule-intensive processes like these, the BRE is the best design choice.

Bb245764.cmpappsfinserv17(en-us,MSDN.10).gif

Figure 17. BizTalk BRE message flow

As Figure 17 shows, a message is received through a Receive adapter. Different adapters provide different communication mechanisms, so a message might be acquired by accessing a Web service, reading from a file, or in some other way. The message is then processed through a Receive pipeline. This pipeline can contain various components that do such things as converting the message from its native format into an XML document, validating a message's digital signature, and more. The message is then delivered into a database called the MessageBox, which is implemented using Microsoft SQL Server.

The logic that drives a business process is implemented as one or more orchestrations, each of which consists of executable code. These orchestrations are not created by writing code in a language such as C#, however. Instead, a business analyst or (more likely) a developer uses an appropriate tool to organize a defined group of shapes graphically in order to express conditions, loops, and other behavior. Orchestrations can optionally use the BRE, which provides a simpler and more easily modified way to express complex sets of rules in a business process.

Each orchestration creates subscriptions to indicate the kinds of messages it wants to receive. When an appropriate message arrives in the MessageBox, that message is dispatched to its target orchestration, which takes whatever action the business process requires. The result of this processing is typically another message, produced by the orchestration and saved in the MessageBox. This message, in turn, is processed by a send pipeline, which might convert it from the internal XML format used by BizTalk Server 2006 to the format required by its destination, add a digital signature, and more. The message is then sent out using a Send adapter, which uses an appropriate mechanism to communicate with the application for which this message is destined.

A complete solution built on the BizTalk Server 2006 engine can contain various parts (sometimes referred to as artifacts): orchestrations, pipelines, message schemas, and more. These parts, or artifacts, can be worked with as a single unit, referred to as a BizTalk application. A BizTalk application wraps all of the pieces required for a solution into a single logical unit, making it the fundamental abstraction for management and deployment.

Different kinds of people perform different functions using the BizTalk Server 2006 engine. A business analyst, for example, might define the rules and behaviors that make up a business process. The analyst also determines the flow of the business process, defining what information gets sent to each application and how one business document is mapped into another. After the business analyst has defined this process, a developer can create a BizTalk application that implements it. This includes such things as defining the XML schemas for the business documents that will be used, specifying the detailed mapping between them, and creating the orchestrations necessary to implement the process. An administrator also plays an important role by setting up communication among the parts, deploying the BizTalk application in an appropriately scalable way, and performing other tasks. All three roles—business analyst, developer, and administrator—are necessary to create and maintain BizTalk Server 2006 solutions.

Not only does the BRE implementation make developers more productive, but there are other architecture considerations to keep in mind.

Architecture case for BRE in loan origination:

  • Composite-style architecture that is not tightly coupled with any one system or technology implementation. .NET, Java, or even COBOL systems can interoperate with the BRE through Web standards.
  • Clear separation of orchestrations and rules for maximum reusability.
  • No need of duplication of calculations or business rules. These can be invoked, based on a specific workflow.
  • Scalable infrastructure for rules and orchestrations.
  • Regulatory issues, such as separation of duties, are more manageable.

Database Architecture

The database tier of this solution is built out using Microsoft SQL Server 2006. Aside from the table structure, other database services are exposed:

  • SQL Server Reporting Services will be used to expose Web Parts in MOSS.
  • SQL Server Analytical Services will be used to expose Web Parts in MOSS.

Enabling Scenarios

Now that the architecture has been defined, we can show some possible usage scenarios based on this architecture. As discussed in the business description, we will model and describe how these scenarios can be implemented.

Products and Pricing

It can be difficult to manage pricing from multiple sources. With all of the different manipulations of data needed, Office Excel's formulas are an easy-to-use and empowering tool for secondary marketing analysts.

With this scenario, we want to demonstrate the following:

  • Data management—Data kept in Office Excel files can be difficult to manage. We want to keep this data on the server, to keep the lender compliant with data-retention regulations.
  • Auditablity—In many cases, data is difficult to audit when there are many users manipulating data in client-side tools. With this solution, the Office Excel files can reside on the Office SharePoint document libraries, where auditing is performed out of the box.
  • Approvals—Workflows can be developed around documents for approval processes. This is often needed in these environments when the data generated is depended upon by many processes.
  • User experience—Office Excel is the client for our solution, because business users want to have familiar tooling, business owners do not want to pay for retraining, developers do not want to create redundant tools, and architects want to reduce complexity and cost.

By using Office Excel, the business users are more productive and empowered. This, however, does not prohibit additional or alternate user interfaces. For example, Office SharePoint can be used also, if a Web user interface is required. From a technical perspective, Office Excel is used for this scenario to demonstrate the capabilities of document workflow and rich calculation functionality coupled with workflow. For larger banks, this might not be the optimal solution. For those implementations, a Web-based Office InfoPath or Office SharePoint application could be appropriate.

Click here for larger image

Figure 18. Product and pricing technical overview (Click on the picture for a larger image)

Figure 18 shows the overview of the technical implementation of the scenario. The process exposes the following capabilities:

  • The secondary marketing analyst starts their day by opening a standard Office Excel template that contains all of the necessary calculations. The lender is ensured that the same calculations are used by all personnel by storing the calculations on the server.
  • The secondary marketing analyst reviews feeds and market data, and puts it into Office Excel.
  • Manipulations are performed on the data, and the document is saved to the document library.
  • The workflow is then kicked off. The appropriate approver is sent an e-mail alert to review and approve.
  • The manager approves the rates.
  • Workflow persists product and rate data to the LOS SQL Server.
  • Web site blackout period ends, and registration can now continue.
  • The workflow then starts the distribution process:
    • Data is transformed and sent to disparate LOB systems.
    • E-mail alerts are sent to appropriate lender staff (processors).
    • E-mail alerts are sent to brokers, with a link to the current rates.
    • Rates can now be used by the application.

Loan Registration

With loan registration, we expose a Web portal through Office SharePoint Portal Server. As described in the UI description, an array of Web Parts makes up the UI. With this composite-style UI, custom workflows are easier for the user to orchestrate.

Click here for larger image

Figure 19. Registration technical overview (Click on the picture for a larger image)

Figure 19 shows the overview of the technical implementation of the scenario. The process exposes the following capabilities:

  • Broker comes to lender portal and authenticates.
  • The UI is dynamically generated, based on broker's role.
  • The broker enters the customer's information into the registration pages.
    • Alternatively the broker can choose to send a MISMO-compliant XML feed or standard Fannie Mae files to BizTalk, to reduce the duplication of data entry.

The Master Loan workflow is now started.

Appropriate messages are sent to BizTalk for business rules.

External data is retrieved automatically when workflow events occur, based on loan processors and required data.

Show:
© 2014 Microsoft