If you are considering becoming a 1M/1M premium member and would like to join our mailing list to receive ongoing information, please sign up here.

Subscribe to our Feed

Thought Leaders In Cloud Computing: James Dunlap, President of Cycle30 (Part 3)

Posted on Sunday, Sep 19th 2010

By Sramana Mitra and guest author Shaloo Shalini

SM: Can you talk a bit more about what these GCI order to cash components are, what vendors do they come from, and what the organizing principle of this environment is?

JD: Let us start with the most basic components. You need to get an order from the customer – that is the order management system. Our vendor for that is Comverse. We use their technology for order management and billing. Next, you are required to be able to roll a truck out to a customer site. That involves a couple of things – trouble ticketing and order trouble management. We use BMC Remedy as part of that process. Next, you need to activate and provision the service. We have several kinds of activations in provisioning engines depending on what network component we are actually activating, whether it is a mobile phone, landline phone, cable set-top box, or cable modem. Each has its own activation-provisioning engine. We wrote some of these in-house and we host them in the cloud.

In addition to these, we have other components that we acquired from another vendor.  One such product is from ETI – a company based out of Atlanta that does much of the activation and provisioning in the cable space. From there we have the actual billing and rating engine. That is the key in the Comverse scheme, in the billing suite. From there we use other components in the billing and rating engine such as taxation. Vertex is the taxation engine; it sits in the cloud in our case. We use Vertex out of the cloud environment. From there we integrate both in and out of the cloud for all sorts of services. For example, if you are ordering wireline and wireless services, you have all sorts of things such as CNAM and other E911 services that you have to register with as you are producing an order and a workflow. The end product of this step is a print ready file which goes to a print and mail vendor in order to produce hard copies of the invoice. Then it goes to our own EBPP platform, which is a hosted platform. This allows the customer to get a bill from the self-service perspective, via the Web. Those are probably 50% of the systems I mentioned of the order to cash infrastructure, and of those I would say 90% are vendor-supported hardware that we have procured and that we run in the cloud environment.

SM: This sounds like an environment based on a different architecture from the one you have now, which is cloud based. As you were running the IT for GCI, what did the nonhosted, noncloud environment look like?

JD: We had two data centers located in Alaska. One of those data centers was our primary data center; it was in our office tower in Anchorage. This is about a 5,000 square foot facility that has improved over the course of ten years. It included all traditional data center infrastructure from a power, lighting, air conditioning, and cooling point of view. It had raised floors and all the other traditional stuff, especially when we had transitioned our mainframe computer into our current infrastructure.

About two miles away we had a disaster recovery (DR) backup facility. I know you are thinking, why you would have a DR site two miles away. It was one of those decisions made by someone else. It probably made sense at that time. We were in a large bank data center for our DR facility. What we ended up doing that was using that environment more as flex space and sort of had two data centers in the same facility. One of the issues we were trying to solve was to begin to distribute the data center environment and truly get DR in a geographically dispersed environment, rather than simply having two data centers within two miles of one another. In this case, we are running five data centers: two in Anchorage, one in Phoenix, one in the in main data center in Aurora and then the cloud computing facility, which is a SunGard cloud-based facility in Philadelphia – that is the current configuration.

SM: If I go back to the old configuration, where was all the software coming from? You described an entire set of software vendors that are currently in the configuration. How has that changed from what it used to be in the old configuration?

JD: I do not know whether it has changed much. I am going through the list in my mind. Well, with the addition of some new activation and provisioning components, I don’t think the list has changed much.

SM: Are these the same vendors that were providing this environment in the beginning?

JD: They are the same software vendors. A couple of small new components or products came in as we brought in new services. However, I would say that the majority, if not nearly all, were existing software vendors that moved into our new environment.

SM: Now let us dig into that move. What are the implications of introducing a cloud computing–based delivery model as you made this transition at GCI? What change did the software environment need to go through and what was the process of managing that with your software vendors?

JD: Interestingly, in a normal project where we run our processes to bring up additional environments, whether it is for a conversion from one line of business on one billing platform on to the recommended one; we have been centralizing billing platforms for years, trying to get rid of extraneous platforms. As we have done those conversions, traditionally we have had active involvement with the vendors of software products for each of the applications we use. What I found fascinating in this case was that we did not have such significant involvement from the vendors, nor did SunGard. I learned something interesting in the process about our personnel and how we work. We believed we had to have those software providers intimately involved in our configuration and in our integration efforts, but what I did not see happen with SunGard was that they did not seem to need that same degree of involvement with those vendors. We handed them software and told them the sizing of the environments that we needed. It truly was a black box. We did not hear or see much from them, nor did we get many requests for assistance from our software vendors to work with them. Now I do not know that is particular to SunGard or particular to the software that we run. However, we would normally have internally seen a great deal of involvement from those software vendors. May be that is due to my staff, and they are dependent on those vendors. I am not sure why SunGard did not need same level of access to those vendors.

This segment is part 3 in the series : Thought Leaders In Cloud Computing: James Dunlap, President of Cycle30
1 2 3 4 5 6 7

Hacker News
() Comments

Featured Videos