Archive for September, 2006

An interesting incident - value versus commoditiza…

Thursday, September 21st, 2006

An interesting incident - value versus commoditization

I recently met the senior IT management at a leading bank. This was the final stages of negotiating a license agreement with the customer. Over small talk i wanted to find out the perception from a senior management side? What was the value they perceived from the rules engine?
The answer came down to “IT maintenance”. it was clear tht the enterprise had not really thought through what the rules approach could bring to the table in terms of agility. Considering that the banks frontline agents were doing eligbility manually (despite having a recently installed Loan Origination System).

I asked them why the elgibity criteria were not captured - pat came the answer “Well the LOS vendor takes way too much of time and by the time the changes are done there are new ones and there are backlogs”. So in other words there were certain rules where the change cycles were way too fast. Understandable, in a competitive home equity loans kind of environment this is bound to happen. What was the implication? The eligibility process became a human to human process. Any manual process was bound to be full of errors and by the time the processing moved to underwriters it was a lot of loan applications that needed to be looked.

Now add the impact of training all these agents for enabling eligibility. Get the picture? Inability to match the cycle of change really ballooned to a much bigger problem than just IT maintenance.
Arguably, one could say that throw enough number of developers and it should be solved. It wont! There is a fundamental bottleneck of understanding those rules, implementing them and doing that correctly. Not unless you go in for a business rules approach.
So that bunch of developers at the very least need to externalize those rules - using some good design patterns or in essence build a rules engine.

Whats the point of ranting? Some classes of problems (where the constraints and rules are high) would invariably require a rules driven approach - whether it is a build or buy. How does one identify such classes of problems then?

The result was fairly perceivable - a time to close a loan reduced by 19% which is fairly significant considering that there were no fundamental changes to the process.