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:
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:
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.
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:
There are some commonalities among these, but there is also exclusive behavior.
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):
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:
Figure 2 is a representation of the business capabilities. These are not independent functions. There are interwoven dependencies between each of the business functions.
Figure 2. Business capabilities
Briefly, these capabilities are described as follows:
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:
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.
Figure 3. Logical architecture (Click on the picture for a larger image)
The MOSS architecture is really several logical layers (see Figure 4). This consists of the:
Figure 4. The MOSS layers
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.
The following table represents a comparison chart of the technologies we used.
Table 1. Comparison of technologies
|Criteria||Web Forms||Office InfoPath Forms|
|User experience||Application-centric||User entry/form-centric|
|Content control||Allows customized or fine-grained control over page elements||Dynamic UI is possible by creating multiple views of the same form.|
|Page plow and navigation||Need custom code to handle navigation||Need custom code to handle navigation|
|Development environment||Microsoft Office SharePoint Designer/Microsoft Visual Studio||Office InfoPath client or VSTO.|
|Integration with Office SharePoint||Need 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 values||Need custom code to validate fields||During 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 integration||Need custom code to map XML schema to Web page fields||Native support for binding XML schema to page fields.|
|Reusability||Can be used in a Web client only||The forms can be used in an offline scenario or embedded within e-mail.|
|Platform||Built on ASP.NET 2.0||Built 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:
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.
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.
Figure 6. Using Office Excel as a client
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.
The following built-in MOSS services (see Figure 8) are used in this solution:
Figure 8. Application-services implementation reference
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.
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.
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:
Here, we will discuss the overarching workflows. There are two primary workflows that govern the loan-origination solution:
Figure 11. Master Loan workflow (Click on the picture for a larger image)
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:
The integration layer consists of Web services stubs exposed from MOSS in conjunction with the BizTalk Web services endpoints.
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.
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).
Figure 13. MISMO Accelerator in BizTalk (Click on the picture for a larger image)
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.
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:
Figure 15. MISMO schemas used
Table 2. MISMO messages used
|MortgageApplication||Office InfoPath||BizTalk orchestration and business-rules engine||Register in loan system|
|RequestFlood||BizTalk Orchestration||Stub third-party provider||Retrieving the flood data about a property|
|RequestCredit||BizTalk Orchestration||Stub third-party provider||Retrieving borrower's credit data|
|RequestMI||BizTalk Orchestration||Stub third-party provider||Retrieving the property's mortgage insurance|
|RequestTitle||BizTalk Orchestration||Stub third-party provider||Retrieving a property's title data|
Table 3. Additional schemas created
|Request3rdPartyServices||Office SharePoint loan workflow||BizTalk Orchestration||Retrieving the third-party data, like flood, title, and so on|
|Store3rdPartyResponse||BizTalk orchestration||Web service within Office SharePoint||Sending third-party data back to Office SharePoint|
|GetEligibleRates||Office SharePoint loan workflow||BizTalk Orchestration||Retrieving the products for which a borrower is eligible|
|GetProviders||Office SharePoint workflow||BizTalk||Retrieving the list of providers for a specific loan|
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:
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:
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.
The following terms will be used:
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.
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 challenge||BRE 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)
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.
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:
The database tier of this solution is built out using Microsoft SQL Server 2006. Aside from the table structure, other database services are exposed:
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.
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:
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.
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:
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.
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:
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.