When Colt Telecom began to build out its European high-speed voice and data network in the mid 1990s, it adopted a classic data centre and systems architecture for the time: it put the same systems into every country, with each operating independently.
By the time its main expansion phase was complete – and before post-boom economics slowed things down – the company had a significant presence in the major business centres of UK, France and Germany, with smaller operations in 10 other countries.
That meant it had 13 instances of each of its numerous applications. Among Colt’s core systems are financials and sales and marketing (Oracle), fault management (Remedy), order handling (Remedy), billing (Ericsson’s Progressor), and configuration and inventory management (Granite Systems’ Xpercom), with only Oracle centralised.
Replicating all these was not necessarily the most cost efficient way of doing things – replication of data and licences could be high, and exchanging information between systems could be a problem – but it worked. As business development director Andrew Roberts said, “It was the tried and tested method.”
But really he had no choice: “When Colt was set up, we didn’t have the cities connected together [with high speed lines]. It made putting everything into a single centre unrealistic”.
Since then, however, things have changed. Reliable network backbones are now in place, customers are more demanding, and Colt itself has restructured several times in an effort to control costs. For all operators, business has become tougher and efficiency is critical.
To meet the demands of better but cheaper service, Colt has made two major changes to its architecture – with a third, towards the service oriented architecture (SOA), on the way.
The first step, in 2000-2001, was to link all the systems together using a messaging bus from webMethods. This provided reliable messaging between the applications in the three main centres in London, Paris and Frankfurt. It reduced the growing number of ad hoc links, data inconsistencies and errors, and sped up processes such as customer provisioning. Before this, a service order in three countries would go through three separate systems.
The second step was to centralise everything into one data centre, in London. There is now either one instance of each application, or many identical instances. The goal is to have just one of each. In addition, each application now owns its own data, which is then replicated and distributed by webMethods to those applications that need it. The new architecture is easier to manage, more consistent and more flexible.
Customers, in particular, are given much more data than before. But the third stage will be the most liberating. “At the moment, its still more complicated than it should be because we haven’t reached the service oriented approach,” says Roberts.
Once Colt has reduced each application to a single system, it will move to an SOA. At the moment, automating business processes is complex, requiring that architects and integration specialists have expert knowledge of each underlying application. Often, many interface calls have to be made to a single system – some of which have to be built.
In future, these functions will be exposed as complete services, which can then be re-used to build complete services. Where possible, these will be web services, but webMethods is capable of using other interfaces. It will then be possible to capture the process data using a business activity monitoring system, providing critical data to managers and customers.
