2011/12/03

Implementing authorization scripting

We've recently set out at my workplace to perform a daring undertaking: implement authorization scripting for a payment system that does not have a scripting facility. The idea initially surfaced some time ago as a half-joke. "Wouldn't it be something if the switch supported scripting"? It seemed a bit crazy at first.

We debated amongst ourselves for a while about the merits of such a capability. During our time working with the payment system, it became apparent that we could do anything we wanted by using the software development kits. It was also obvious that some solutions we provided were bloated-by-design by static code and would be better implemented by authoring a quick script. Validating the input of a cardholder performing a custom payment at the ATM is a very good example of such a situation. Validations typically examine few transactions and verify the cardholder input by using a custom verification algorithm, such as a variation of a check digit verification algorithm. The typical solution would be to author a custom plug-in and attach it to the payment system; easy and can be delivered in a few days. The scripting solution would require creating a few lines of scripting code; easier and can be delivered in a couple of hours.

There was value in the idea, no matter how preposterous it might seem. It's not, after all, every day that you set out to plug-in something as significant as a scripting facility to a payment system. However, the flexible nature of the system allowed us to be optimistic.

So we rigged a proof-of-concept implementation and tried it out. The results were surprisingly pleasant and everyone started thinking of scripts for everything after working with our pilot. Stress-testing the solution to more than one thousand scripts per second was the final action before we started using the ideas from the pilot to create a full-blown system.

Some time passed and we're now there, with a scripting product finalized. It's surprising how your perspective changes from the time when you're building proof-of-concept, throw-away code to the moment you set out to create a polished product. A gazillion things that we didn't expect needed to be handled in a manner that makes sense to an end-user. Create a new scripting language or use an existing one lots of people are familiar with? Which one? How would the user write and debug scripts? How would the scripting service be notified of configuration changes? What facilities should the scripting service offer to the end-user, on top of those provided by the scripting language itself? What level of control should we allow to scripts? How could scripts be extended to communicate with external data? And external systems?

Once again, the graphical user interface took a disproportionate amount of time when seen through the eyes of a developer/integrator who would be quite happy with configuring everything through a raw XML interface. But the real lesson here was understanding the need for a roadmap in order to reduce the scope to something manageable and release version 1.0 in a reasonable amount of time.

If we took the time to implement everyone's idea, and lots of people had great ideas, we would be lucky to have released 1.0 sometime at the end of the next year. One developer had a great visualization about how the graphical interface could be made to be much more intuitive. Another proposed a radical implementation that would allow anything in the payment system to be scripted. Yet another one indicated that a workflow should be used to push scripts through an author, then through an approving member, then to testing, to QA and then to production. Very often I was finding myself in the awkward position of having to shoot down good ideas that I liked just to keep the scope manageable for an initial implementation. "That's for version 2.0" became a phrase spoken quite a few times.

Having a developer's background, I can understand what a kill joy I turned out to be. Still, I had to be firm about the release date otherwise there wouldn't be a specific release date. And I do like releasing software!