Export (0) Print
Expand All

Architecting Enterprise Loan Workflows and Orchestrations

 

Mike Walker
Microsoft Corporation

February 2007
Revised March 2007

Applies to:
   Application Architecture
   Loan Workflows and Orchestrations
   Architecture Design

Summary: Design, enhance, or augment existing workflows from within the loan-origination channel by using this article as your guide. (19 printed pages)

Contents

Introduction
Enabling Technologies
Loan-Origination Scenario
Human Workflows and System Orchestrations
Use Windows Workflow Foundation When:
Use BizTalk Server When:
Enabling Enterprise Workflows
Architecting Human Workflows for Loan Origination
Master Loan Workflow
MLF in the Scenario
Products and Pricing Workflow
PPF in the Scenario
Office InfoPath Forms Flow
IFF in the Scenario
Enterprise Loan Orchestrations
Decision Engine
Decision Engine in the Scenario
Integration Services
Underwriting Services
Conclusion
References

Introduction

This article will serve as a guide for architects who want to design, enhance, or augment existing workflows from within the loan-origination channel. It is part of a series of articles that describe the Loan-Origination Reference Architecture Pack (RAP). This article will focus solely on the workflow and orchestration capabilities of the RAP.

The guidance in this article will aid architects in unifying multiple loan-origination systems (LOS) and corresponding workflows. An LOS depends heavily on both loan processes and other services from within the enterprise. Unifying multiple loan workflows is a key concern for many lenders. With increasing acquisitions, and the respective increase in legacy systems, unification will give the necessary agility to be competitive in the banking industry.

Additionally, we will highlight how to automate the manual steps in the loan-origination process. As shown in Figure 1, oftentimes the largest bottleneck in the lending process is the manual steps. Between fax machines, paper-based forms, and manual data entry, this can get rather costly for lenders. Automation will ultimately shorten this process, referred to as the "application-to-close" process. Lenders can then process more loans with the same amount of infrastructure and personnel.

Bb330937.archentlwo01(en-us,MSDN.10).gif

Figure 1. The current state of loan processing includes a blend of manual tasks and legacy systems.

The scope of this article is in the context of the Loan-Origination Reference Architecture Pack (RAP). Links to all the corresponding articles and downloadable binaries will be provided in the References section.

Today, the loan-origination process is fragmented and inconsistent between different lenders. This is due to workflow complexity. To stay competitive, lenders use varying business processes to derive decisions on loans.

To aid in the development of this architecture we chose to break the loan-origination process down into a set of basic capabilities that the higher order business capabilities depend on. Surprisingly enough, this process comprises four core capabilities.

Loan origination is composed of the following basic IT capabilities:

  • Long-running workflow
  • Approval processes
  • Orchestration of consistent business rules
  • Semi-static calculations

We will describe how to create enterprise-scale workflows that enable your loan-origination process to run more effectively, reduce the amount of redundancy in the process, eliminate manual processes, and automate paper-oriented processing.

Enabling Technologies

Described here are the enabling technologies that are used in our scenario:

  • BizTalk 2006—By using BizTalk, banks can now orchestrate their business processes in a dynamic and fluid way.
  • .NET Framework 3.0—Windows Presentation Foundation (WPF), Windows Communication Framework (WCF), and Windows Workflow Foundation (WF).
    • WPF can reduce the training time of loan executives, officers, underwriters, and secondary marketing personnel. This is increasingly important in high-turnover areas.
    • 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.
    • WF provides banks the flexibility to create workflows around documents, such as Office Excel, Office Word, and Office PowerPoint.
  • Microsoft Office SharePoint System 2007 (MOSS)—For Office SharePoint, Office Excel Server, and 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 2005.
    • Office Excel Server can host your Office Excel data in a centralized SQL Server information store. This robust relational database provides data protection, centralized backup procedures, a single version of the truth, and security around sensitive data. This also provides the Office Excel user experience for multiple services without cross-training on other applications.
    • Document formats have been changed to Open XML, an open document format. This ensures cross-platform compatibility, robust integration, document manipulation opportunities, and controlled data integrity checks from within the documents themselves.
  • Microsoft SQL Server 2005—The repository of choice for storing all of the sensitive loan data needed for this solution. Additionally, SQL Reporting and Analytical Services will provide robust Web Parts to plug into our MOSS portal.

Loan-Origination Scenario

As mentioned in the introduction, we will be showing workflow in loan origination. For this scenario, we want to demonstrate the core capabilities of WF and BizTalk Orchestrations. We will walk you through a wholesale brokerage scenario, from the application process through the underwriting decision.

Please note that document-preparation and loan-closing processes have been excluded. The capabilities demonstrated within the architecture will show you how to build document-preparation and closing-document capabilities. The remaining capabilities will be addressed in forthcoming publications.

Click here for larger image

Figure 2. Business process that we will model in our scenario (Click on the picture for a larger image)

We will model our workflow after the business process shown in Figure 2. The purposes of these stages in the loan are as follows:

  • Registration—When the customer enters the proper qualification information for a loan product.
  • Select product and rate—The process in which personnel at the lender will analyze the secondary market and apply the proper pricing to the products (for example, 30-year fixed) or their portfolio products (products that the bank funds and usually does not sell to other banks or the secondary market).
  • 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.
  • Processing—This stage is where lender personnel known as "processors" gather the necessary documentation and prepare data for an underwriting decision. Processors are the data-entry point of the process.
  • Underwriting—The process in which an underwriter makes a decision on the loan for approval.

We will automate the majority of these stages in the workflow. As shown in Figure 1, there are many manual processes that hinder the process. To automate these steps, we have to look at the core capabilities that we want to expose from the loan process. We will be deriving the previously mentioned capabilities from the macro level and diving more into the details around the human workflow capabilities.

  • Document management and routing—Documents are routed, consumed, verified, and filed throughout this process.
  • Content management—Loan status, comments on loans, and rate bulletins are needed for both internal and external users.
  • Information security—Information that is required for a loan—for example, borrower's assets, liabilities, employment, and personal data—is of the utmost importance. It must be protected at all points in the process.
  • Automated data retrieval—Data is gathered from multiple sources both internally and externally through third-party services.
  • Document preparation—Documents are prepared in multiple stages in the process, such as before underwriting and when a loan is fulfilled for the borrower.
  • Unifying multiple loan systems—In many cases, lenders have many loan systems for both Point-of-Sale (POS) and Loan-Origination Systems (LOS). Choosing the right one for the right loan or loan product can be confusing and time-consuming.
  • Automated approval processes—Approval is often manual and requires individuals to hand-deliver or e-mail documentation for an approval. This is yet another bottleneck in many loan processes.
  • Electronic Interface for Brokers—In some cases, brokers have only manual means to interact with a lender. This can be time-consuming and can affect the relationship between the lender and the brokerage firm.

Breaking down these capabilities, it is easy to see why it takes lenders so long to approve and fund loans. We will focus on these detailed capabilities mentioned previously, and automate many of them—through the use of the Windows Workflow Foundation workflow automation capacities, BizTalk system orchestrations, and MOSS—to provide our core set of application services that will facilitate our process.

Human Workflows and System Orchestrations

Before we dive into the solution, it is important that we understand some basic principles of our architecture. The terms workflow and orchestration have been used throughout this article. These types of flows are similar but very different.

  • Workflow—Workflow is a style of computing in which a process is decomposed into a series of steps or events. These events flow from one step to the next based on conditional evaluation. The majority of the time, workflow is composed of activities that are carried out by humans.
  • System orchestration—Orchestration is a specific type of workflow that is generally applied to the construction of business services from business processes. Orchestrations do not include human-performed activities.

Perhaps the most well known Microsoft implementation of workflow today is in BizTalk Server (although BizTalk Server uses the term orchestration, instead of workflow). BizTalk Server lets developers create system workflows for business-process management (BPM), enterprise application integration (EAI), and business-to-business (B2B) integration. The next release of Microsoft BizTalk Server will add support for creating WF workflows targeting these areas.

Bb330937.archentlwo03(en-us,MSDN.10).gif

Figure 3. Human workflow versus system orchestration

BizTalk Server and Windows Workflow Foundation have some obvious similarities. To a developer, for example, the BizTalk Server Orchestration Designer looks much like Windows Workflow Foundation's Workflow Designer. This commonality is no accident; the same group at Microsoft is responsible for both technologies. For the most part, however, deciding which one to use for a particular problem is not hard. What follows are some guidelines to help you make this decision.

Use Windows Workflow Foundation When:

  • An application itself will host workflows. Windows Workflow Foundation lets workflow be built into an application, allowing the workflow to be deployed and managed as a native part of the application. Conversely, because it's focused on integrating diverse applications instead of providing a general workflow framework, BizTalk Server always runs orchestrations within the BizTalk Server process that is external to the application.
  • The business process being implemented requires human workflow. BizTalk Server addresses system workflow, and so it lacks Windows Workflow Foundation's support for things such as state-machine workflows and dynamic update. A scenario that requires both human workflow and more complex system-integration services could be addressed by using Windows Workflow Foundation and BizTalk Server together, however. For example, the Microsoft Office 2007 support for document-centric workflows, based on Windows SharePoint Services, might be used for the human aspects of the problem, while BizTalk Server handles the system integration aspects. The two can interoperate using the BizTalk Server Adapter for Office SharePoint.
  • The workflow will execute on a client system. BizTalk Server is a server-focused product, and so it's less well-suited to run on desktop machines.

Use BizTalk Server When:

  • Solving an EAI problem that requires communication with diverse applications on diverse platforms. Because of its focus on cross-platform integration, a large set of adapters is available for BizTalk Server that allows communication with a range of other software. Windows Workflow Foundation is focused solely on workflow, not EAI, and so it does not provide these things.
  • B2B services are required. Windows Workflow Foundation does not address this area, while BizTalk Server provides tools for working with trading partners, accelerators for Mortgage Industry Standards Maintenance Organization (MISMO), Society for Worldwide Interbank Financial Telecommunication (SWIFT), and other industry standards.
  • BPM services, such as Business Activity Monitoring (BAM), are required. While the Windows Workflow Foundation tracking infrastructure can be used to create these services, BizTalk Server provides important extras, such as tools that let information workers define their own BAM views.
  • A complete management infrastructure and support for increased scalability are required. Unlike Windows Workflow Foundation, BizTalk Server includes a full set of tools for administering and scaling a production environment.

Enabling Enterprise Workflows

For this reference architecture, we want to architect this solution in such a way that the workflows and orchestrations can interact and manage other external workflows. To enable these capabilities, we will rely on BizTalk's usage of industry-standard Business Process Execution Language (BPEL).

Bb330937.archentlwo04(en-us,MSDN.10).gif

Figure 4. BPEL usage within the enterprise

A common thread within the process is the information that it uses. Throughout the loan process, data is gathered, manipulated, and sent to other systems. If we have a centralized loan-information store, business processes can work together more efficiently.

Bb330937.archentlwo05(en-us,MSDN.10).gif

Figure 5. Centralizing information

For our scenario, we are only looking at origination and underwriting. However, we want to ensure that we provide mechanisms that can automate the downstream processes, too.

At the center of Figure 5 is a store of common information, such as borrower, assets, liabilities, and property. Aligning the information with the process areas containing information common to loan processing will also provide an information model for both process and information consolidation.

Using open standards for consumer mortgage is also helpful when interoperating with other system workflows. For example, MISMO has organized the business-process areas across the mortgage industry under four broad categories: Origination, Servicing, Secondary, and Real Estate Services. Processes under Origination include Mortgage Application, Underwriting, and Closing; Servicing includes Loan Setup and Transfer, Investor Reporting, and Default Reporting; Secondary includes Securitization, Bulk Pool Transfer, Funding, and Pricing and Discovery; and Real Estate Services include Appraisal, Credit Reporting, Flood, Mortgage Insurance, and Title.

MISMO aligns directly with the business process that we are enabling. However, RAP can support multiple loan channels, such as commercial. Organizations considering consolidating or augmenting multiple channels must ensure that they employ the right standard. For example, MISMO is a U.S. consumer-mortgage standard and would be inappropriate with other channels.

Architecting Human Workflows for Loan Origination

The human workflow aspect of the architecture will be controlled by Windows Workflow Foundation. WF will be running in conjunction with MOSS. Our architecture can now interact with several key areas:

  • Document libraries—Standardized MISMO XML will be saved to document libraries, to be versioned and to trigger key events in the lending workflow.
  • Web services—Because the key to our architecture is extensibility with XML, Web services will be used throughout, thus loosely coupling each layer that provides a rich interoperability story between our varying workflows. In turn, Web services provide the flexibility in the communication between workflows and orchestrations.
  • Tasks—Tasks are assigned within MOSS to accomplish specific workflow duties. This helps with the asynchronous behavior of the master loan workflow (MLF).
  • E-mails—Underwriters can receive their loan pipeline right to a familiar Office Outlook client, thereby providing rich collaboration and information rights management features.

For the loan application, we created several workflows, including:

  • Master Loan Workflow (MLF)—This is the workflow that manages the entire life span of the originated loan, from registration to closing.
  • Products and Pricing (PPF)—Enabling Office Excel to interact with a products-and-pricing workflow that enables approval processes and alerting mechanisms.
  • Office InfoPath Form Flows (IFF)—This is not a WF workflow, but instead a set of views within the registration and underwriter entry forms. Because Office InfoPath takes care of the flow and presentation validation automatically, there will be a dramatic drop in UI development time.

Bb330937.archentlwo06(en-us,MSDN.10).gif

Figure 6. Global workflow within the Loan-Origination Reference Architecture

As shown in Figure 6, there is a bit of intersection between the workflows. There are a variety of types and styles in which these workflows are used. Different personas and activity requirements drive the design of the workflow architecture. We are exposing the best-of-breed workflow solutions for each of these.

Products and Pricing Flow (PPF) is the mechanism that allows for the loan products and pricing process to occur. Because of the serial behavior of this process, we choose to use a sequential workflow.

However, for the Master Loan Flow (MLF), a state-machine workflow was used. The interactive nature of this workflow drove this decision. Documents are consistently updated and are working through various approval processes in a non-serial fashion. Additionally, this is a long-running workflow that will potentially last for several weeks.

The InfoPath Forms have their own sequential flow built in. By using the view feature of Office InfoPath, we can simulate multipage groups of forms. As an InfoPath form is iterating through the update of XML stored in the document library, the changes in the file trigger events in the MLF. Thus, Office InfoPath does not internalize any of the workflow, but rather indirectly invokes the workflow.

The events that will be triggered through our architecture will be generic and reusable. Table 1 shows the events that we used:

Table 1

EventInterface
OnWorkflowActivatedMicrosoft.SharePoint.Workflow.ISharePointService
OnWorkflowItemChangedMicrosoft.SharePoint.Workflow.ISharePointService
OnTaskChangedMicrosoft.SharePoint.Workflow.ITaskService
OnWorkflowItemDeletedMicrosoft.SharePoint.Workflow.ISharePointService

We will now walk through the elements of Figure 6 in more detail.

Master Loan Workflow

The MLF state-machine workflow provides the architecture for long-running workflows that can take up to many weeks or months. The MLF governs all loan-origination workflows. Measuring the health of the workflow holistically can provide views into the workflow, integration services, and system orchestrations. The only workflow that is not governed is the PPF process. It is the only exception to the rule, because PPF is an administrative function in the context of originating loans.

Because the MLF workflow governs all workflows, there are many touch points where other workflows and orchestrations intersect. One common touch point is the use of Office InfoPath forms. To simulate page workflow, we use the view feature of InfoPath. These flows in Office InfoPath are only sequential. This works well within portions of our loan process, especially in the registration processes, in which a series of steps need to occur in a uniform way. This process is shown in Figure 7.

Click here for larger image

Figure 7. Intersections between human workflow and system orchestrations throughout the process (Click on the picture for a larger image)

In Figure 8, we can see the MLF workflow weave through a series of workflows and orchestrations.

MLF in the Scenario

The PPF workflow updates the product rates. After that has occurred, the blackout period is turned off. A blackout period is controlled by secondary marketing personnel that determine the lenders' rates for the day. The blackout period is from the close of business the previous day to the period when the new rates for the next business day have been determined. For example, if the blackout period is on, a borrower cannot select a product and rate because the rates are not available yet.

An activate event starts the MLF workflow initiated by the PPF workflow. We will discuss more on the PPF in the next section.

After the blackout period has concluded, brokers can use the MLF to lock and float loans through the system. Typically, brokers will go through an initial discovery and data gathering process. This is an iterative data collecting process that occurs when a borrower has initial interest and is still collecting personal information on all the assets and liabilities.

Bb330937.archentlwo08(en-us,MSDN.10).gif

Figure 8. Document libraries and standards in the MLF workflow

Office InfoPath Web forms are used to collect this information. Using the MOSS portal capabilities available to us, we can expose Office InfoPath Web Parts throughout the registration and underwriting process.

As shown in Figure 8, after all of the information is collected, the broker saves the information to a document library as standardized MISMO XML. Events are triggered when the borrower MISMO XML is saved to the document library as the XML is consumed by the registration process that is formed by Office InfoPath throughout the process. These events determine whether the loan can proceed or stay in the same state in the workflow. In some cases, alerts can be sent out to personnel.

The next step for the broker is to select a product and a rate. To do so, an event must be triggered in WF. This happens only when all of the required MISMO XML data is completed and the blackout is lifted. Upon completion, the workflow event will be triggered to allow the broker to access the product and rate selection page.

Bb330937.archentlwo09(en-us,MSDN.10).gif

Figure 9. Integrating system and human workflows

The products and corresponding rates are retrieved from the decision engine. The decision engine is a set of system orchestrations coupled with a business-rules engine (BRE). In Figure 9, we use .ASPX Web services to link the system and human workflows.

Using industry-standard MISMO XML, we can be assured that our loan workflows are now extensible. Other LOS solutions can also use this centralized decision engine. Because both the MLF and ELO can extend Web service endpoints into the processes, interchanging other legacy technology is less of a burden than it once was.

Extending this architecture to other LOS solutions is also a possibility now. Web services now enable the architecture to extend many services to existing Commercial Off The Shelf (COTS) applications, or custom solutions built on other technologies.

After the broker selects a product and rate, the final step is to choose to lock or float the loan. If the broker chooses to lock the loan, the workflow will set an expiration timer automatically for 30 days. Other timers can send out alerts or reminders throughout the process, too.

The majority of the broker's portion of the workflow is considered to be over, with the exceptions of pipeline management and status inquiries. The automated underwriting process is now kicked off.

The first step, after all of the initial loan data is retrieved, is to retrieve data from a set of third-party services, such as credit, flood, appraisal, mortgage insurance, and others. We will automate these activities by using our Enterprise Loan Orchestrations (ELO). This orchestration will call out the services tier to make external Web services calls. The majority of these activities will occur in the ELO. This will be discussed in more detail in the ELO section, later in this article.

Bb330937.archentlwo10(en-us,MSDN.10).gif

Figure 10. Underwriter approval workflow

After all of the necessary information is retrieved and prepared, the ELO triggers the underwriting event in the MLF by a Web services call. As shown in Figure 10, the underwriter will receive an Information Rights Managed (IRM)–protected e-mail with an embedded Office InfoPath form.

The underwriter can now manage loans through a loan pipeline view from within the familiar Office Outlook 2007 client application user interface. The underwriter will have a folder dedicated to the loans that are currently assigned. The e-mail that was sent from MOSS embeds an InfoPath form. This form uses the property promotion feature to make the key sets of data elements available as properties. Underwriter pipeline management can now occur within Office Outlook instead of navigating back and forth between an Office Outlook 2007 Client and an Office SharePoint Portal. This streamlines the process, adding time and reducing the amount of training required for underwriters.

The underwriter can select a given loan in the Office Outlook loan pipeline. When the e-mail opens, an Office InfoPath approval form embedded in the e-mail provides the underwriter with a loan summary. The underwriter can choose Accept, Reject, or Modify. Through MOSS, this form data is automatically processed on the back-end, just as if the user had left Office Outlook and gone to a separate forms application.

If the underwriter chooses Modify, the modify form appears in Office Outlook where data can be manipulated or rerouted to other personnel. Additionally, comments can be assigned to the loan. This is a communication mechanism back to either internal lender personnel or to the broker who is assigned to the loan.

Choosing Accept or Reject will close out the process that we have modeled. This seemed like a logical endpoint to show the majority of the technical capabilities of the reference architecture.

Click here for larger image

Figure 11. MLF state-machine design in Windows Workflow Foundation (Click on the picture for a larger image)

The following are the detailed states of the MLF workflow, as shown in Figure 11:

  • WorkflowInitialState—The first state of the state machine. This state is reached when a new workflow instance is created. This maps to a new loan form being saved in the form library.
  • LoanActiveState—The state of the loan before it is locked.
  • SavingLoanState—This is an intermediate state where the workflow saves the loan details into the database. Then, depending upon the status of the loan, it transitions to the Active, Locked, or Float state.
  • LoanLockedState—The state after the loan has been locked. In this state the workflow sends requests for third-party services.
  • WaitingForServicesState—The state the workflow is in when it waits for the requests for third-party services to be fulfilled.
  • SendLoanForUnderwriterApproval—The state the workflow is in when it creates the approval task for the underwriter.
  • WaitingForUnderwriterApprovalState—The state the workflow is in when it waits for the underwriter to update the approval task.
  • LoanFloatState—This state is reached when the loan is in the float state.
  • FinalState—The last state of the workflow. The workflow is marked as complete when it reaches this state.

Products and Pricing Workflow

The Products and Pricing Flow (PPF) is the workflow that updates the product rates. As soon as that occurs, the blackout period is turned off and the loan process can continue.

Click here for larger image

Figure 12. Lender rate worksheet and workflow (Click on the picture for a larger image)

PPF in the Scenario

The PPF workflow, shown in Figure 12, starts each morning when the rates are in a blackout period. The secondary marketing resource is responsible for analyzing market trends and rates. With this rate, information is then applied to the products on the lenders' portfolio.

The first step is to open a standard rate template on the Secondary Marketing Team site. In Office Excel, click File | Open | Secondary Marketing Team Site | Rate Worksheet Template.xlsx.

The template that we will be using is shown in Figure 13. The secondary marketing resource will apply the rates to the specific products. Shared and standard calculations can be embedded into the Office Excel template to automate the many manual tasks and eliminate potential human errors in the process.

As soon as the rates are applied to the workbook, it is then saved to the rates document library. An event is then triggered that determines that the rates have officially been completed. This triggers the final stage of the workflow, which triggers a set of parallel activities.

To add to the PPF workflow, a lender may choose to extend the PPF to inject some approval processes. This would allow for a final verification of the rates before promotion to the LOS. For simplicity, we have not included the approval workflow in the PPF.

An event will trigger on the sequential PPF workflow that will then perform various tasks:

  • E-mail alerts—Informing underwriters and other personnel.
  • Updates to line-of-business (LOB) systems—This could be other LOS systems or other LOB systems that depend on current rate data. For example, an online banking application could use this data for cross-sell purposes.
  • Updates to the lender portal—Updates the portal to display the current rates to the broker community.
  • Persist rate data to SQL Server—This allows the rate data to be used by the application.
  • Blackout period trigger—This allows brokers to get product and pricing for borrowers.

Office InfoPath Forms Flow

The Office InfoPath flows are not directly controlled from WF. They are, however, influenced by WF. The XML data stored in the document library is directly controlled by WF. This has implications on the order in which Office InfoPath forms flow.

Figure 13 show the sequential flow of the registration Office InfoPath form. All of the screens shown are different views of that form.

Bb330937.archentlwo13(en-us,MSDN.10).gif

Figure 13. Broker MLF screen workflow

IFF in the Scenario

The steps include the following:

  1. The broker enters site and views BDC-enabled pipeline.
  2. The broker clicks New Registration.
  3. The InfoPath Borrower Entry Screen Web Form displays. The broker enters borrower information and clicks Next.
  4. The Property form displays. Property information is entered, and the broker clicks Next.
  5. The Product and Rate Selection screen displays, giving the broker product options for the borrower. The borrower and broker select a product and corresponding rate, and then click Next.
  6. The broker can now lock or float the loan, based on the terms that were selected for the loan.

We will not cover the other Office InfoPath forms, such as the Underwriter form, given that we have discussed these earlier in the article.

Enterprise Loan Orchestrations

The ELO is meant to be a robust and reusable asset that can span across organizational barriers, thus toppling application silos in which loan origination occurs. ELO can span across not only consumer mortgage loans, but many other retail and commercial channels, too. This is due to the same base characteristics of each loan process. Here are some opportunities:

  • Unify the entire loan channel—Across the various channels of loans, such as commercial and retail, they inherit the same base functionality. This can be reused.
  • Cross-sell—Many lenders want to enable cross-sell opportunities. Achieving this is difficult, given the rigor of integration. Injecting cross-sell logic into specific stages of the workflow can be achieved.

Bb330937.archentlwo14(en-us,MSDN.10).gif

Figure 14. Core business capabilities of the Enterprise Loan Orchestrations

This architecture provides the following core capabilities:

  • Interoperability throughout the lending processes—ELO uses open XML technology and industry standards throughout the architecture, allowing for the strongest interoperability story. Additionally, the BizTalk 2006 platform has a wide variety of adapters and accelerators for both legacy and modern systems.
  • Centralized business-rules engine—BREs provide a host of benefits. The most important capability we will talk about here is the ability to orchestrate business rules in multiple ways without re-engineering these rules.
  • Manageability—Centralizing the business rules and system orchestrations make development, performance management, and configuration simple management tasks within the lenders' environment.
  • Health measurements of the process—Rich BAM capabilities are native to BizTalk 2006. This allows IT personnel to measure how effective the processes are and adapt accordingly.
  • Consolidation of IT systems—Some lenders struggle with multiple variations of LOS and POS solutions. The ELO can provide a consolidation platform for iterative consolidation.
  • Agility—The ability to react or predict market conditions is an absolute necessity in the banking business. The ELO, coupled with the other technologies in this reference architecture, enables such agility.

Each business capability area referenced in Figure 14 is invoked separately through the management of the MLF. It is important to understand that part of the flexibility of this architecture is that these capabilities are somewhat autonomous in nature. If there are other loan channels that require these services, they can have their own management layer, such as the MLF, to govern these system orchestrations. In this way, the RAP is essentially a service-oriented architecture (SOA), and you can use the services to address your specific capabilities.

Throughout the architecture, there are activities in which credit is run for a borrower or APR calculation routines are run. These activities are simulated; they would be subject to change in your enterprise, and the value of this architecture is how we expose those services.

Decision Engine

The decision engine will be evoked by the MLF when the broker wants to inquire about a borrower's eligible products and the corresponding rates. The MLF makes a Web service call to a Web service proxy for the decision-engine orchestration. The information sent is in the form of MISMO XML to the GetProducts Web service.

Decision Engine in the Scenario

Bb330937.archentlwo15(en-us,MSDN.10).gif

Figure 15. Decision-engine orchestration within BizTalk 2006

Figure 15 shows the orchestration that calls the BRE. The decision engine that is in the BizTalk BRE is leveraged for the complex decision-making on borrower product and pricing.

Integration Services

After the registration is completed, the locked loan data is ready to undergo the automated underwriting stage in which third-party services are ordered. The retrieved data can be from credit, flood, appraisal, mortgage insurance, and others sources. We will automate these activities by using our ELO. This orchestration will call out the services tier to make external Web services calls.

  • Flood—An asynchronous message-exchange pattern that is originally called from the MLF. Web services call a fictitious flood provider. As shown in Figure 16, a Web service call is made to a flood-insurance provider. After an undefined period of time, a response is provided back asynchronously to a file share. This triggers an event in the orchestration and propagates the data back to the document library that is managed by the MLF.
  • Credit—A synchronous message-exchange pattern that is originally called from the MLF. It is assumed that this request will go over HTTP SSL protocols and return a response immediately.

Click here for larger image

Figure 16. Flood orchestration within BizTalk 2006 (Click on the picture for a larger image)

Underwriting Services

Underwriting services are not included in this reference architecture. However, this does not preclude lenders from adding underwriting services to the model.

Conclusion

We have covered the breadth of the various workflows within this architecture. At the beginning of this article, we showed you the current manual lending processes. With the Windows Workflow Foundation and BizTalk System Orchestrations, we have shown lenders, ISVs, and Systems Integrators how to build service-oriented composite-style workflows.

In Figure 17, you will notice that we eliminated the majority of the antiquated technology, such as the fax machine and paper copiers. Paper is almost non-existent within our solution. It has been replaced with electronic forms and system integration.

Bb330937.archentlwo17(en-us,MSDN.10).gif

Figure 17. Automated loan process

Lenders can now provide brokers with a rich collaboration platform, which automates broker processes, shortens the loan application-to-close cycle, and improves the overall customer experience.

With the rich workflow and system-orchestration capabilities, you will have learned the difference between workflow and orchestrations. You will be empowered with the knowledge of how to architect varying orchestrations and workflows.

References

Microsoft Office Communicator 2007

MSDN Financial Services Industry Center

Office Business Applications Center

Show:
© 2014 Microsoft