2015-06-03

Can of worms

The new "Notice of Transfer" system demanded by OFCOM really is being a pain. However we think we are on course to be ready for 20th. I am not sure how other ISPs are doing!

In principle it is simple - the ordering of migrations no longer needs a MAC. That is basically it. Oh, and the lead time is 10 working days now, which is a pain for everyone concerned.

The problem is the processes OFCOM have insisted regarding notices to customers, including the need to provide details of "early termination charges".

We have changed the whole way we do things. Instead of a simple minimum term, we now have an "Early termination fee" which is a monthly rate for the remainder of the term depending on the line type and tariff. It applies separately for each broadband line or copper pair. This means we are able to work out what the early termination charges is on each notice we send separately, which meets OFCOM rules nicely. Of course, that has led to all sorts of knock on effects in billing, and credits. And credits mean knock on effects in terms of refunding Direct Debits. It is a nightmare, and the reason we have been doing so much billing work over the last month. I do apologise to those few people that suffered some billing errors as a result, and needed corrections.

We have made a central clearing house module for all of the OFCOM mandated notices. It ensures we meet all of the requirements, and handles the notices, early termination charges, and even the anti-slamming logic.

Now we are integrating the existing processes we have to allow us to track the transfers (migrates in and out) and use this new system. But we have three separate systems (Openreach, BT Wholesale and TalkTalk), and we are tracking four types of order (Migrate in, Migrate out, Unsolicited Cease, Normal Cease) and three states (Start, Complete, and Cancelled), so 36 scenarios to code. We included ceases as the notices and early termination charges all fit together nicely with migrates and it is nice to send these to customers anyway.

For Openreach the whole system uses a B2B (Business to Business) gateway that involves signed XML passed each way. This allows orders initiated by either side to be tracked cleanly and has allowed the integration of the new reporting system with ease - only took me a day! Well done Openreach. Bloat of a protocol but it works.

Then we start with TalkTalk. That is not so easy as they have not "push" to us. Instead we have a system to poll orders we sent them, and a system of ftp updates of orders they initiated. We are close to that all being integrated thanks to one of my staff, Stuart.

But BT Wholesale is where the can of worms really starts. Some of the code is 15 years old. The way we handle broadband has changed over those 15 years (it started with us filling in forms, which we generated as PDF and emailed), and went on from there. We have a load of polled reporting systems (one called BBCR which even BT want to retire), and lost-migration reports and so on. We have the ordering, which was split between 20CN and 21CN until recently, and now is finally a B2B XML gateway - except that does not cover orders BT started such as outgoing migrations and unsolicited ceases. We have had a lot of defensive code to allow for the B2B not providing quite the same information as the BBCR reporting on some occasions, so a lot of duplication just in case.

So my job this week is untangling BBCR - deciding exactly what parts of it we still need, and what is now entirely covered by the B2B stuff, and getting the new Notice of Transfer stuff integrated before the 20th June deadline. In principle it is simply picking the key events and calling the new system, but I think I need to unravel the whole need for BBCR in the first place. It is a lot of tired and old code to mess with.

It is just a matter of how deep in to the rabbit hole I want to go. I do wonder how other ISPs are coping. We are pretty confident that we are on target for this, but it is not simple.

And it is all OFCOM's fault!

3 comments:

  1. From your description it does indeed seem like a large, complex rabbit hole. Legacy / old code does tend to cause such a rabbit hole, in this case at least the primary cause is something else.

    ReplyDelete
  2. I suspect other ISPs will muddle through doing things by hand until they realise this isn't viable.

    Why do you even have both Openreach and BT Wholesale? They're both selling BT lines surely, or is there some difference in what lines you get from them?

    ReplyDelete
  3. Is it worth working with other ISPs to perhaps build a mid-way system? All "small/mid-sized" ISPs authenticate against it, send the request and then the system works out where to send it, how to send it etc. It's got a database of lines/ISPs and when a port/cease request comes in, it's read by FTP, XML etc and then "standarised" before going to the ISP. Everyone benefits and it saves lots of smaller companies having to reinvent the wheel (which is more expensive for them compared to the larger players).

    ReplyDelete

Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

Missing unix/linux/posix file open option

What I would like is a file open option for "create replacement file". The idea is that this makes a new inode in the same mount p...