The only publication dedicated to OSS Volume 1, Issue 9 - February 2005 |
|
Mergers Drive Problems Before they Deliver Benefits (cont'd) Standards and Commonality “We took a ‘scorched earth' philosophy,” says Paul Duda, System Architect for Vericenter. “We developed our criteria for monitoring by determining the services our customers wanted and needed. In addition, any solution had to be scaleable since we are growing so fast,” he said. The Houston Business Journal identified Vericenter as one of the fastest growing technology companies in 2002, and in 2004 Vericenter achieved record revenues. When Vericenter began operations, the decision was made to use industry standard tools. This allowed it to start generating revenue much faster than if it had created its own tools. When Vericenter acquired the additional six data centers, it knew it was a good opportunity to re-examine its tools and solidify or improve current standards to enhance its capabilities. For older, larger companies it's usually a different situation. With MCI, for example, it was quite common for each service to be managed in its own “silo”. The service was self contained. All provisioning, monitoring and fault correction was done for that service and only that service. This meant that each tool was designed in-house, specific to each service. There were, however, no standards for databases, for the language in which the tool was written, for terminology definitions, or for field definition. This made it nearly impossible to apply tools across a variety of services because there was no commonality to facilitate integration. Customer Migration For companies such as MCI or Sprint, or any of the large mobile operators undergoing mergers, it is a radically different situation because they have many legacy systems. It may be cost prohibitive to migrate away from their old trouble ticketing and monitoring systems. In these cases it can be a better choice to put a front end on the monitoring tools so that all services have the same look, but all the legacy systems remain intact. Sprint uses this approach when it acquires new companies. It is a much simpler process to add a front-end rules engine that queries users for fault information and takes them to the correct trouble ticketing system based on the service being provided. This isn't the most efficient method, but it is less risky than trying to migrate to a new tool. If trouble tickets are lost and faults aren't fixed the result could be thousands or even millions of dollars in lost revenue.
© 2005, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law. |