I have found myself explaining Service Orientation to members in YASU these last few days, and it seemed to be a perfect opportunity to get back into my blogging ways once again.

Here is a simplified version of a Loan Process. I’ll use this to talk about Service Orientation , and where a Business Rules driven decision service can fit in.

So, here is what the model says

1. Step 1: Loan Application for a specified Loan Product is created either online or through a Sales Agent
2. Step 2: Validate the Application
3. Step 3: Determine whether the applicant is eligible for the given Loan Product or Not.
4. Step 4: For a Valid Application, the system generates an approximate Loan that the applicant might get
5. Step 5: Underwrite the Loan and determine how much loan can be granted and at what interest?
6. Step 6: Disburse the Loan.

Now here are two ways you can implement this Process

Possible Design Option

1. Step 1 will be a Website that either a Sales Agent or a Customer will use. This is a simplified model, remember !
2. Step 2 will be realized using a Validation Module
3. Step 3 will be realized using an Eligibility Module that will know how to determine eligibility for every Loan Product
4. Step 4 will be a PreQual module that will know how to compute Pre-qual loan amounts
5. Step 5 will be a global underwriting module
6. Step 6 will be a fulfillment module.
7. All these modules will run as one application with appropriate web front ends
8. Let us assume that the system is impleemnted using java/j2ee or using .NET

Now, that is perfect, is it not?

Well, think again. Will conventional ideas abot how we achieve process automation really work and scale over time?

Now, let us assume that a financial services company offers different kinds of loans, sub-prime, Alt-A, Reverse Mortgage, and Car Loans, Personal Loans and may be others.

Now, lets add some more requirements, like the following ones below.

1. For each product, the company might choose to have a different eligibility criteria
2. For each product, the company will use different UnderWriting Guidelines
3. The company might partner with 3rd party Loan Market Places like, say LendingTree.com
4. And the company might want to expose its eligibility and Underwriting Services to these partners
5. Different Loan may be handled by different departments, and they might want to share, use the same Service.

Now, 3, 4 and 5 will mean that the Eligibility, UnderWriting and PreQual Operations be available as re-usable Modules, or Services.

If you expose these 3 as reusable Services, and each department composes these Services into a working business process that they use, then we have built some thing that will satisfy every one’s requirements

We would also have built a infrastructure that will allow the company to partner with 3rd party market places, and get the partnership going in no time at all.

Now, let me ask, have we designed the best possible system we can think of? Well, the answer is No. And why is that?

Look at requirements 1 and 2 in the above list once again.

Anyone who has ever taken a loan will understand how big and legal the eligibility guidelines can get, and of course the UnderWriting Guidelines need expert attention during implementation.

And again, the cost of loan is determined by market forces and will certainly change everyday, often many times a day.

So, how would you go and build a Service

1. That can be built to be used by many different departments
2. Whose behavior can and will change many times day
3. That requires special and expert knowledge for implementation, and where the implemented Service might have to be Oked by your Business (Business Guys reading Code, Ha Ha )

So, do you think our usual technologies will be useful in implementing such a Service? No need to think, the answer is a No.

These Services (Eligibility, Pricing, UnderWriting) are what are classified as Business Decision Services, as opposed to regular Business Services.

These have a special name because these Services automate a critical Business Decision that would otherwise require an expert’s manual decision making.

Business Rules Technologies offer one clean solution to implement such Business Decision Services. If you have a large number of rules(as will be the case in Fin Serv), and these rules change often, then Business Rules Technology can be a good choice.

If you are new to business rules, here are some good links for you to begin

1. What are Business Rules?
2. Business Rules - An Introduction
3. More on Business Rules

I have argued earlier about why Business Process Automation != Decision Automation and this should be a good associated read in this context.

Some times DSL’s might be useful as well. Here is an comparison of Business Rules Vs DSL that you should read.