This is a blind case study about how a large US bank switched its 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.  This story, 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, a large US 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, the rules would need to be stored and managed by the bank's standard tool, the even-then-venerable (read old) PVCS.  Furthermore, the Source Code Control Governance staff said that TFS^[1] would be the new standard, at which point the 'source code' would need to be 'managed' there.

To put it mildly, a spirited (read 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 Excel 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^[2] as underlying formulas (read hard coded — hard to find, let alone understand, and certainly to update).  The Excel files were then put to use.

Scene II:  Big Change Hits the Fan

A funny thing happened — BASEL I was replaced by BASEL II.  (Remember those "May You Live In Interesting Times" of the economy with the dotbomb 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 Bank's Chief Risk Management Technology Officer (CRO) stepped in and commissioned an RFP for a 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 term a "Business Rule Management System."  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, and pretty quickly.  The IT team breathed a sigh as it appeared they would be spared "harvesting" the Excel 'rules'.  (See the PS below.)  They also knew that 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 Excel formulas.  A spirited project kicked off (in a good way — the risk analysts were excited by light at the end of the tunnel).  The CEO of the BRMS vendor had been asked by the CRO to provide personally some oversight to the project that included 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 liked the old system asked, "This new system really looks great but can I still use my Excel 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 returned to the source code control mandate.  (You know the difference between a process bigot and a 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 Excel 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."

New habits are forming at this bank and it's all good!!!

PS — A Footnote

There was another challenge that went largely unaddressed here, due to the complexity and non-transparency of the logic written in Excel.  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.

Notes

[1]  TFS (Team Foundation Server) is a Microsoft product that provides source code management and reporting, as well as other related capabilities.  

[1]  'quant' is 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.  

# # #