Our Roaming Billing Solution was deployed at Reliance Telecom Ltd, Bhutan Telecom, Africell (Gambia) and Dialog Telecom (Sri Lanka). It was an implementation of TAP 3.10. In Reliance, Bhutan and Africell, the solution was a part of our Post-Paid Billing solution suite – GABS. However, in Dialog, we had managed to sell only the Roaming Billing solution and it was integrated with their Post-Paid Billing solution – CCBS. Debashis used to support the solution and he was assisted by Avishek. They handled the customer well and there were never any cause for concern and so my concentration on this aspect was a bit less. However, I used to be surprised that for most of the customer requirements, they used to compile the code and send a fresh executable which customers would install and use.
Dialog gave us the order for the upgrade of the solution to implement TAP 3.11 as they were at that time launching their 3G network. Right at that time, Debashis resigned. Avishek had been working with the system for about 2 months. So, I inspected the system and realized that while the core functions of generation of TAP files and uploading of incoming TAP files worked fine, the system had very little amount of configurability and the user interface was not something great (The rating function was handled by GABS and the Mediation function was handled by Fulcrum in our solution, while Dialog provided us with rated roaming CDRs from CCBS). Also, the code set for Dialog was different from the other 3 installations. Also, the core TAP code having undergone so many changes that it was a piece of Maggi. Now, I definitely wanted to make the system more configurable and improve the GUI. This apart I wanted 2 adaptors which could be used to plug the system to any Billing System without having to change any internals. To do so, I realized that I needed to also change the core TAP generator and TAP Loader as they would need integrating with the Configurator and execution GUI and the adaptors. I calculated from the value of the order that I could deliver about 25% EBIT on the project if I redeveloped the system from the scratch. So, I procured the ASN.1 license from Objective System for .Net and set about writing the software. At that time, we were also developing the GPRS Billing solution for Reliance apart from some small changes for Bhutan Telecom.
As TAP Generation and Loading was primarily a batch function, I needed a batch processing engine and we had a software called Hungry Jack which could serve this purpose. However, I found that Hungry Jack was not entirely suitable for any batch processing jobs and was more suitable for report generation. So, first I decided to develop a batch processing engine. Thus, was born Gentle Jill. It was designed as a batch processing engine to which any batch process could be plugged in by configuring the same using the GUI of Gentle Jill. Also, Gentle Jill was a multi-processing system which could be scaled up and scaled down depending on the capacity of the machine where it was installed. As I developed Gentle Jill, I was more and more thrilled with the outcome and ambitions for the same started to grow. Once the core engine was ready and functional, I discovered WMI library and plugged in features for preventing breakdown of Gentle Jill due to any environmental conditions. I got Gentle Jill tested in Reliance as I included it as the core engine for running the GPRS Rating Engine which was developed by Anuj. However, developing Gentle Jill had eaten up fair part of the time for the development of the TAP solution.
With six weeks to go for the delivery, I started to develop the TAP Generator. At that moment, the GPRS deployment at Reliance just went live. As was the case with Reliance, there were many problems and this took up a lot of my time. In spite of the same, I developed the TAP Generator within 2 weeks as I had to just program for generation of one TAP file. Gentle Jill would take care of using this program for generating any number of TAP files for any set of parameters which could be set for the same. In the meanwhile, Avishek and Sovan with the help of Anuj had developed the Configurator and the Executor Web Interfaces besides the adaptors for CCBS. Also, Sovan developed the High Usage Report per FF04. I decided that we would not supply the RAP function as it was anyway not used in Dialog. So, I submitted this part of the software for testing with the understanding with the Quality Assurance Team that the TAP Loader would be supplied while they completed testing this scope.
When I started to develop the TAP Loader, I realised that it would be better if I had a general purpose file up-loader program. So, I developed another member in the Gentle Jill family and called it Gentle Fanny. Gentle Fanny could be configured to watch a directory and upload files when any new file was deposited there. Gentle Fanny would pick up an incoming TAP file and submit it to Gentle Jill for processing. This took up another 2 weeks. By this time, disturbance from Reliance had reached a peak. I strategize that to be able to deliver the Dialog project on time, I needed to get away from Kolkata, away from Reliance. So, I decided to go over to Sri Lanka and complete the TAP Loader part violating the contract with the Quality Assurance team. The plan was that by the time Dialog completed conducting user acceptance for the TAP Generator, I would complete the TAP Loader.
We, Avishek and I, arrived in Sri Lanka on a Sunday and we were met in Holiday Inn by Nishad, the Manager for Roaming Billing in Dialog. Avishek knew Nishad from before as I had sent him to Dialog once for support on the existing system while we were developing the new system. Nishad used to call him younger brother. For me, it was the first time I was meeting him face to face, though we had interacted over phone many times. Nishad is a tall and well-built person and he is extremely friendly.
Next day, we went over to Dialog office and soon were given the machine for the deployment. Avishek got down to work on the installing the software and making the needed changes for integrating the installation to the CCBS Billing System. I got down to writing the TAP Loader. No sooner had I done so, I got a call from Reliance and took a long time to explain and calm them down. This continues unabated. No sooner I got down write the TAP Loader, I would receive a call from Reliance. As Reliance was such an important customer, I could not refuse any of the calls as well. In any case, I never turned down any calls from any of our customers. So, this was a huge issue. Anyway, I used the evenings through nights to write the TAP Loader. The Dialog IT Team members possibly sympathized with us, as from the day 1 we were leaving office at around 2 or 3 in the morning and coming back by 8 AM next morning. They would arrange for nice food every night and we would all get together and have a wonderful dinner. Seeing me work like this, Nishad understood that the software was not ready. However, he did not say anything to me. What he told internally to his management is not known to me. However, nobody from Dialog ever questioned me about this or ever escalated to my management. Also, Nishad would stay with us in the office till we were there and drop us to our Hotel before going home.
From the 3rd day, we were ready to generate the TAP files and send them to the Data Clearing House for validation. Nishad took over this action as this was the main Acceptance Criteria. Avishek, in this process, also started to teach him how to use the new system. TAP Loader was still getting ready and I realized it would take time as I was getting so little time to develop it as I had to attend to calls from Reliance. Then, came the big blow when Mach returned all our TAP files with a number of errors. Studying the errors, I realized that everything was minor except for 2 errors whereby Mach could not interpret the MSISDN (the mobile number) and the IMSI (the most essential data for Roaming Billing). Now, I checked the TAP Generator and fixed the issues and found that there was nothing wrong in the code for encoding the MSISDN and IMSI. However, the next day, Mach again sent errors and MSISDN & IMSI errors were prominent. I left the work on the TAP Loader and fully focused on fixing the errors from TAP Generator. However, I was totally foxed as I could not find any error in the code for errors reported on MSISDN and IMSI encoding. After 3 rounds of rejection, I decided to write to Objective Systems for their help. Eathan Metsger was the support staff from Objective System. He suggested some changes and these did not work as well. Ultimately, I decided to send him a whole bunch of generated TAP files along with the code and raw data for inspection. The next day, Eathan came back telling me that there was a bug in the ASN.1 compiler and he would send the fix the next day. This was a huge relief. However, by the time, we had already used up more than one and half weeks of my two weeks stay and TAP Loader was nowhere near ready. So, I requested my boss to extend my stay by one week. With lot of reluctance and after a lot of explanation, he approved the same.
I calculated that I could still finish the TAP Loader by the end of the 2nd week of stay and then would it hand over to Nishad for testing. Further, I planned that as we had one extra week in Sri Lanka and we had worked on all days including the Saturdays & Sundays for more than 15 hours per day, we would take 1 day off and go to Galle on Saturday of the third week and then return back to India on Sunday. While I continued developing the TAP Loader, the fix came from Eathan and we again compiled our TAP Generator and sent files to Mach for verification. This time they came back clean and Nishad took over to verify the rest of the aspects. I completed the TAP Loader on the Friday of the 2nd week and tested it thoroughly myself and sent it to Sovan & Anuj to test in Kolkata. Also, I engaged Avishek to test the TAP Loader on Saturday and Sunday. While they were testing, I went out into the Colombo city and found Odel close to the Dialog office. I spent some time there and ended up buying a lot of stuff. So much I purchased on the first day that on Sunday, I had to also buy a new suitcase.
Nishad started to test the TAP Loader on Monday and he took his time. It was on Wednesday night that we decided to install the software in production on Thursday morning. We did so and as a result, now it was not possible for us to go to Galle anymore as we could not take a chance. Nishad made a demand that Avishek should stay for more 3 weeks to support the system from on site and I readily agreed though I knew very well that this would need another round of explanation and negotiation with my boss. On Thursday, I completed getting my boss’s approval for Avishek’s stay extension and on Friday evening, we sent our first lot of TAP files generated by the new system to Mach for dispatching to the partners of Dialog. There were no alarms on Saturday and Nishad took us around Colombo for shopping. I purchased a several items from the Handicraft Emporium. Saturday evening, we got the feedback from Mach reporting some errors. This was a surprise as I had to catch the return flight at 6 AM on Monday. Also, on Saturday, very near the Dialog Office, there was a bomb blast in which the extremists had tried to assassinate the Defence Minister. The Defence Minister escaped the attempt. I was a bit jolted. However, I came back to work on Sunday early morning to fix the issues. I fixed the issues and again we sent the files to Mach. Nishad got in touch with his counterparts in Mach and asked for a speedy feedback within the same day and Mach said they would try. We finally got a reply from Mach at about 10 PM and everything was okay. So, now I could go back to Kolkata as scheduled. I invited Nishad and his colleagues from Dialog, with whom we had spent so many several hours during the 3 weeks, to dinner at Holiday Inn. They agreed and we had a gala time till around 2 AM. Then I returned to my room and packed my luggage with the help of Avishek and started off for the Airport at around 3 AM. So, all I had seen of Sri Lanka was Holiday Inn and Dialog office and Odel and the Handicraft Emporium and the food court where we used to go for lunch every day. I did not even get to know that the sea was just 200m away from Holiday Inn in the opposite direction to my daily route to Dialog Office.
I reached the Airport at around 4 AM and found that it was jam-packed. With lot of effort, I got past the security check. When I reached the check in counter, I was told that the flight was full and I would have to wait for them to get back to me. I was surprised as I had a confirmed ticket. Then I realized that due to the bomb blast, lots of people, especially foreigners, were trying to get out of Colombo. Realising this, I quickly approached a Sri Lankan Airlines officer and pleaded him to the best of my ability with the best of reasons that I could imagine including how sick my wife was and how important it was for me to get back to her, etc. For whatever, reason, the officer took pity on me and asked the check-in counter staff to check me in. Soon I was on the flight on my way back to Kolkata via Chennai.
On returning to India, Vodafone called me and told me that my mobile bill was Rs. 86,400. I told them that my connection was a corporate connection and thus it was most important for me to keep in touch with the customers using this number and thus they should not disconnect the line. I also told them that Siemens would give me the amount when I submitted the tour claim and I would settle the amount. They agreed and increased my credit limit to Rs. 1,00,000. I then realize how expensive it was for me to go on tours leaving Reliance in Kolkata. When I submitted the tour claim, I was in for another surprise as it was not possible for anyone to approve the telephone expenses as it was beyond the documented norms of the company. I requested my General Manager and he assured me that he would help. In the meanwhile, I kept paying Vodafone the remaining months bills and not settling this amount. After 2 months of return from Sri Lanka, I got a call from a stranger asking all sorts of details about where I stay and what I do, etc. These calls repeated often and after some time this got me worried as I realized that these were agents employed by Vodafone to realize their Rs. 86,400. Siemens took 3 months to reimburse the amount and immediately I paid Vodafone and was relieved.
There were no major hiccups with the supplied software and Avishek came back after 3 weeks as we had planned. We had generated an EBIT of 20% on the project and the Annual Maintenance Contract was renewed.
So, I now went to Reliance and told them to upgrade to TAP 3.11 as they had also launched GPRS services. It was relatively easy (considering other deals with Reliance) as they decided to buy the upgrade. We quoted a higher price than what we had quoted Dialog and Reliance agreed. However, this time, all I had to do was to deploy Avishek and Sovan for 4 weeks and Reliance was up and running on TAP 3.11. Though we also supplied the RAP feature, Reliance never used the same. Another important aspect was that the Reliance Delivery was fully certified by the Quality Assurance Department.
In the meanwhile, I was in discussion with Bhutan Telecom for the upgrade and they also agreed. We quoted an even higher price and the deal was done. This time, I sent Sovan to Bhutan for 3 weeks and Bhutan Telecom was up and running on TAP 3.11.
Next, I got in touch with Africell for the TAP 3.11 upgrade and they also agreed. As nobody from Siemens had gone to Africell for many years, I decided to go to Gambia to implement the new TAP system and to pay a courtesy visit to them and to search for new business. My boss approved a 2 weeks stay in Gambia for the implementation. However, I had to negotiate a one week extension and completed the implementation in 3 weeks. It was another great customer that I met in Gambia and that was Riad. Apart from implementing the TAP upgrade, I also got assurance for NRTRDE solution supply to Africell and a few change requests. In due time, we got the NRTRDE order from Africell. However, that is another story.
The TAP 3.11 software produced the maximum percentage of profit among all that we had developed. This apart, we got Gentle Jill, using which we reduced the time to develop solutions by more than 5 times. There were people, who appreciated Gentle Jill. Also, there were some, who criticized it. However, the fact remained that from 2006 till 2010 (I left Siemens on 31May10), Gentle Jill was a part of all our solutions and this software did not undergo any change in the code and did not need any maintenance. I also submitted the software of Gentle Jill in our innovation forum as a potential platform for batch processing. It went through several rounds of evaluation and was forwarded for consideration for a patent. However, this proposal was killed.