Just Say "No" to Hard Coded Logic

This is a blind case study about how a large US bank switched it's mode of operation under the pressure of forced governance changes. This new approach of leveraging explicit rules is now a new and growing habit for this bank. The story below, written by Paul Hessinger, CEO of InRule, shows the power of putting business rules in the hands of the business folks.

Scene I  The Legacy Problem:

Circa 2008, large USA bank is about to deploy a new, BRMS based BASEL II Risk Analysis Compliance System – The Source Code Control Governance staff informs the IT team that they consider the business rules authored by the Risk Analysts to be source code. As such, they need to be stored and managed by the bank’s standard tool, the even then venerable (read old) PVCS. The Source Code Control staff said that TFS would be the new standard at which point the “source code” would need to be “managed” there.

To put it mildly, a spirited (real heated) debate ensued. The IT team asked if the previous Risk Analysis Compliance System which was a group of complicated (a real  cluster %^*#) group of XL spreadsheets had been subjected to ‘source code governance”. There were quite a few blank stares but no answers beyond a “good question” shrug of the shoulders. Much of the logic had been written by quants (financial jargon for a quantitative analyst -a person who specializes in the application of mathematical and statistical methods – such as numerical or quantitative techniques – to financial and risk management problems) as underlying (real hard coded, hard to find let alone understand and certainly to update) formulas. The XL files were then put to use.

Scene II Big Change Hits the Fan:

Funny thing happened – BASEL I was replaced by BASEL II (remember those ‘May You In Interesting Times” in the economy  with the dot bomb crash and then the 2007-08 recession? The “code” had to be changed and the quants said “not our job – we only write new stuff".  The Risk Analysts went to IT and said “we need you to update these.”  IT did not even know they existed. The Banks’s Chief Risk Management Technology Officer (CRO) stepped in commissioned an RFP for an Systems Integrator (SI) to build a new “user friendly” system.  The SI proposed a multi-million Dollar “solution” that would in effect build a custom version of what COTS products called Business Rule Management Systems. The CRO was exasperated. The bank was facing regulatory pressure if not sanctions. He took it upon himself to google “rule solutions for risk management” and lo and behold on the first page he found what seemed to be a viable solution.  While at Starbucks he called the CEO of one vendor directly.  He suggested that the CEO have his team come visit ASAP.

Scene III The Solution: 

Within weeks, the CRO directed the IT team to use that product as it clearly would allow the risk analysts to author and maintain the rules.   He personally learned how to write rules, pretty quickly. The IT team breathed a sigh as it appeared they would be spared “harvesting” the XL “rules.” (see the PS foot note below). They also knew there were other essential components of the new system that required their passionate competencies, hard coded or not. There is no suggestion of a ‘silver bullet” here. but the SI had in effect been suggesting a propagation of the custom, hard coded logic problem, be it Cobol code or XL formulas. A spirited project (in a good way, the risk analysts were excited by light at the end of the tunnel) kicked off.  The CEO of the BRMS vendor had been asked by the CRO to provide personal some oversight to the project that include best practices guidance by his ROAD (Rules Oriented Architecture and Application Design/Development/Deployment) crew, in Agile/Sprint efforts.

Scene IV The Big Resistance:

There was an “uh oh” moment in one SPRINT review meeting pretty late in the effort. A very senior (being “PC” here) risk analyst exec who actually like the old system asked – “this new system really looks great but can I still use my XL files.” There were sighs, OMGs and a few fists formed under the table. The CEO’s response was a diplomatic but emphatic “FRIENDS DON’T LET FRIENDS HARD CODE LOGIC.”  The CRO added “AMEN, Let’s Git-R-Done!”

So when it was almost “go live” time, we return to the source code control get together/mandate (you know the difference between process bigots and terrorist? – you can negotiate with a terrorist).  The CRO got wind of the challenge and joined the discussion.  His “mandate”? “If you folks can harvest the XL formulas that I am sure you also treated as source code and migrate them to a new format in PVCS that my risk management team can maintain then your policy will be followed. Can you do that? And oh by the way, we need to go live next week.” Case closed.

Scene V The Bottom Line:

One week after the deployment, the CRO got a FedEx package – a baseball t shirt that said

On the front and on the back "Friends Don't Let Friends Hard Code" He wears it often and “walks the talk.”and new habits are forming at this bank and it's all good !!!

PS Footnote

There was another challenge that went largely unaddressed here, due to the complexity and non-transparency of the logic written in XL. It would have been close to magic if that logic could have been harvested and somehow migrated to or at least leveraged by a COTS BRMS.  Visit here soon for some thought leadership if not a a viable approach to Rule Harvesting and Migration

http://www.inrule.com/resources/blog