When Systems Override Logic - Why you should not let IT dictate business rules

Jason Lackey

Today I got to celebrate Friday by spending a fair amount of time on the phone dealing with a mobile operator's customer care department. I had a phone, in this case an HTC Kaiser, aka HTC Tytn II, which I use for demos. In this case it was SIM locked to a particular operator. Unfortunate but understandable, except in this case I had actually walked into the brick and mortar store and paid full price. Since I had paid the full, unsubsidized price, I figured that I should be able to get it unlocked without further hassle or backtalk.

A reasonable assumption, yes, but there is the hoary old adage about assumptions and what they do to you and me and that was the case here. Unlock codes are keyed to IMEIs. In theory all you need in order to get the unlock code is the IMEI. It is certainly possible to buy a phone from this particular operator at full and unsubsidized price without having an account with them so you would expect that there would be provision for unlocking devices without reference to any particular account, right?

Well, not so fast there, cowboy! Whoever built this operators CRM system made the reasonable (although in this case not necessarily true) assumption that an operator's CSR would only be interested in talking to someone with an active account. OK, well, I have a number of SIMs from this GSM operator, but I use them in a variety of different phones. For me there is no link between a SIM and a phone that I stick it in, but I guess the assumption in some markets is a bit different.

OK, so after I tell the guy a phone number, a corporate demo account number, he of course needs the FAN (Foundation Account Number) which I don't have, nor do I have any of the magic words. Bummer. OK, plan two, grab my boss who has service throught the same operator and use his number. His plan is personal, he knows the magic words. So far, so good, we have now jumped what I felt to be the last possible hurdle.

Not so fast there, cowboy! Time to go on hold a couple times, be passed one place and another and then back to another CSR, who is yet another nice fellow who remains so despite suffering abuse from me because I have at this point spent a good 30 minutes on the phone trying to get the unlock for something that probably never should have been locked in the first place. After further back and forth I am then informed that a ticket has been opened on my case and that in the fullness of time, perhaps another 5 days, I would receive an email with the unlock code.

What does this have to do with IT and business rules? Well, a couple times the CSRs mentioned that they felt it was reasonable that they give up an unlock code and that they wanted to but that their system required certain things, one of them being a MSISDN (phone number). It would appear that fairly reasonable (but incorrect) assumptions were made when their systems were implemented and that those assumptions were still driving the way that calls were being handled.

Operators are understandably reluctant to make changes to back-end systems. Experience has shown that things that don't get changed tend to work and that the best way to break things is by starting to make changes. Certification can take a number of months and involves fairly rigorous testing and a lot of time and effort on the part of vendors and operator personnel. Thus it is of considerable operational advantage to be able to change the behavior of software without having to change the code.

As an example, let's say that you need to update the firmware on several zillion phones to fix some sort of bug - a fairly common thing, but not talked about much. Let us further suppose that the lawyers you have at the operator hear that you are doing outrageous things like fixing phones with no opportunity for legal to contribute, obviously a wrong and bad thing that would need to be fixed by some sort of long verbose, latinate, rambling EULA popup. Well, if you have a flexible MDM system, making that EULA popup happen (or making it go away after you fire the lawyers) is actually a pretty easy thing when you are workign with drag and drop workflows. If, on the other hand, workflows are hardcoded into the product, you are going to have to go back to your dev team, or your vendor, ask for code to be changed, which will take some time, and then go through recertification, which will also take some time, usually measured in months and long days and missed teeball games and the like.

Thus, more often than many would probably suppose, business processes and rules often get written by software vendors. Sure, change would be nice, but is often too expensive in terms of time, money or effort, unless, of course, you have drag and drop workflows....