The Information Age interview

   
 

 
 

 

About the company

Virgin Mobile USA (VMU) is the first mobile virtual network operator (MVNO) in the US – meaning that it doesn’t operate its own network. Instead, it piggybacks on the network of its 50% shareholder, Sprint Communications.

VMU was set up in late 2001, complementing two similar companies, Virgin Mobile UK (VMUK) and Virgin Mobile Australia (VMA). But because these companies are organised very differently, VMU had to build its IT systems from scratch.

VMU set itself a hectic timetable to build a complete infrastructure for handling hundreds of thousands of very active new customers. The goal: to offer services within seven months and to be ready for the Christmas rush the following year.

To do all this, Virgin turned to a team of real experts: Mike Parks, a former VP at Wells Fargo and Sabre, came with a ready built team – and a string of successes with large scale Siebel implementations and major integration projects.

 

 
   

IA: When you started up, why didn’t you save money and time by replicating Virgin Mobile’s UK system, which was already up and running?

MP: We did visit Virgin Mobile in the UK (VMUK) and in Australia (VMA) to understand their experiences, but there were differences. VMUK is GSM [global system for mobile communications], we are CDMA [code-division multiple access]. VMA owns some of the SS7 network [switching systems] and they do pre-pay and post pay phone calls. We only do pre-pay.

When VMUK launched three or four years ago, the application server platform didn’t really exist, so you couldn’t have architected it the same way. And we saw that in the UK, a lot of what Virgin Mobile does is dictated by the partner (currently One2One).

Our starting point was: Decide what we want to do and run it, and decide what other parties should do. We decided we wanted to own the customer experience – we felt that was important. Oher functions, such as credit cards and content, could go into the cloud [meaning it could be provided as services over a network]. For example, we have no catalogue of ringtones.

So from the IT point of view, it was blue sky – I had nothing but a requirement and a spec.

IA: Web services is at the core of your architecture [integrating six to seven off-the-shelf applications and many external services]. Why did you pick that architecture?

MP: I’m not sure it was a conscious decision to use web services. It just seemed that this was what you should do. There was no debate.

Internally, we use web services to get our six systems to talk to each other. All the applications all work together as peered applications. You truly do not have a stack.

Externally, there are lots of clouds [standard interfaces to remote services where the details of the partnering system do not need to be understood]. For example, we have links to credit card companies and content providers. This is a perfect opportunity to have a web services environment – I ask them to send a service and we pass it on to the customer.

Overall, we have 27 to 30 companies [products or services] that we are integrating using web services. They include point of sale, order management, product fulfilment and service provisioning. We also engineered seven additional interfaces to legacy systems using proprietrary interfaces – for things like networking provisioning, call accounting and back office functions.

IA: What do you use to link all this together?

MP: We needed a platform for all this that would give us an application server, integration capabilities and support for WAP (wireless application protocol) and web services. Ultimately, you’re down to BEA WebLogic or IBM WebSphere. Relative to BEA, I thought IBM was more of an integration project in itself. But WebSphere absolutely positively would have worked.

IA: How well has it all worked? What is the business impact of using web services?

MP: There are huge benefits in implementing web services, in terms of reduced implementation times, ease of use, code re-use, and building industrial strength systems. Early adopters of web services realise benefits that outweigh waiting for finalised standards.

It gives us greater flexibility. For example, we only see the Siebel desktop once – in the call centre. All the rest of the time, we use BEA [the BEA WebLogic application server suite lies at the heart of the VMU architecture, linking most of the applications together and interfacing using web services technologies and standards such as XML, SOAP, WSDL and UDDI].

That means that if we use Siebel 7.5 [the latest web services-enabled version of Siebel], we can link to BEA through XML or web services. Then, we could change Siebel if we found a better product.

One supplier of content tried to charge too much a month prior to the launch date. I don’t think they thought we would walk away, but we did. Pinnacore, the new supplier, uses XML. It’s a credit to the architecture and to the business decision that it worked. In retrospect, it wasn’t a great thing to do – I wish we hadn’t had to do it. But it couldn’t have happened two to three years ago. Its pretty amazing that we pulled it off.

[With our architecture] we can swap people out very rapidly – a supplier of ringtones, for example. From an IT perspective, that used to be very high risk.

IA: How difficult is it to use web services?

MP: It isn’t easy to use, but we were able to put together a strong team without having to go to a bunch of special integrators or consultants.

IA: What about reliability? Have there been performance issues? Customers in telecommunications are used to very high reliability.

MP: For the most part, if we have down-time, we can hide it from the customer. For example, we can queue the orders to Sprint [which runs the phone services].

BEA runs on multiple clusters – if we lost a cluster, it would carry on. With this system, we can get close to telco reliability – but its not eight nines [99.999999% uptime – the standard expected of phone operators]. We’re running millions of transactions a day through the application server and we’ve had no problems.

But we will freeze all applications in June because we’re changing the BEA clustering – putting in new hardware, new memory, and new Siebel servers. That is because of what happened in December.

IA: What exactly did happen in December?

MP: We knew we’d have a Christmas rush but it was beyond anything we’d experienced before. Everybody opened their packages on Christmas Day and we were smashed. We handled it very well for our customers, but we realised we have a lot of work to do. We’ve got to get ready for December this year.

An activation [to register to begin using the phone] usually takes eight minutes on the phone, five on the web. At Christmas we allowed activations to queue – we had pre-planned to go to queuing on Christmas morning. The important thing is to let people know. We told people when they came in to activate that it would take a day or so – we didn’t have a choice and we told them up front. And we didn’t lose any data.

In June, we’ll eliminate any bottlenecks etc – but next Christmas we’ll probably still queue.

IA: What is your experience of Siebel? Many people have found it difficult to implement?

MP: Its really frustrating for me when I hear people dump on Siebel. I’ve have two great successes with Siebel. Siebel was the thing I was least worried about.

IA: How do you make sure it succeeds?

MP: We don’t use integrators. We are micro-managers. We work with people who know what they are doing.

Systems integrators tend to change an awful lot. They tend to use solutions over and over again without considering the differences. And they tend to be application-oriented, not run-oriented. You can build Siebel to be a real pig. But when the big five (systems integrators) have left, who runs it?

Avatar photo

Ben Rossi

Ben was Vitesse Media's editorial director, leading content creation and editorial strategy across all Vitesse products, including its market-leading B2B and consumer magazines, websites, research and...

Related Topics