I was writing about Loan Processes, Service Orientation and Business Rules yesterday, when I remembered the write-up on the MSDN Architecture Site on an Architecture for a Loan Origination System.

This article explains in some detail about Loan Origination Systems, and explains how you can use the MS Technologies stack to implement a solution. Please read the article, it is a nice write-up.

But as I read it again today, some of the statements that Mike Walker, the author of that article makes, I found very strange. The four main process areas that Mike mentions are as below

• Products and pricing—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).
• 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 sub-processes 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.

The article also suggests a architecture stack as a solution. But the interesting statement was this.

A common question is, “Why is there a separation between the business-rules and the orchestration layers?”

This separation is not always necessary, but in complex situations such as this scenario, in which business processes change frequently and rules are somewhat static, this scenario is ideal.

By separating out these two layers, you achieve:

• Agility. The ability to have a base set of rules that can be used in different ways (that is, orchestrations) without development.
• Reduction of code complexity. Now, business analysts or developers can model the process based on rules developed and versioned in BizTalk.
• Reusability. In loan origination, there often are multiple loan-origination systems (LOS) in a lender’s IT enterprise. Lenders are looking to consolidate and leverage a central system.

I find it strange because, I would have said exactly the same things, but for the completely opposite reasons.Here is why.

1. It is necessary to manage the business process, and you can choose to use a BPM to do this.
2. But, as I understand what a Business Process represents, it details how things work in an Organization, and these are never as volatile as rules are.
3. In the Loan Origination Scenario, I am not sure if it is the process that is volatile, but rather it is the business rules that are volatile
4. Pricing Rules, for example will change up-to 2-3 times a day because the prices are determined by the capital market
5. Every new product will typically have its own underwriting & eligibility rules. To support new products, he system Must allow for these new eligibility rules to be added quickly

Mike Walker’s somehow seems to imply that Agility is always the ability to change the process quickly.I disagree completely there.

In scenarios, where business decisions are automated, how quickly you can change the rules that will determine how quickly you can respond to a change request from the business

Related Reading

1. Extreme Mortgage - Generating a 1 Billion $$ Pipeline in 6 Months