By James K. Munene
In 1994, my company installed its first LAN, covering two main buildings in the company head office campus in Kenya. This was a token ring network using 3Com Superstack TR II hubs with a fiber backbone linking the two buildings. The original number of users connected was less than 100.
Within five years, the number of users had grown to more than 400, and the number of applications supported on the LAN had more than tripled. The 16-MB token ring network became a bottleneck and could not cope. We had also hoped to link up to the network users in other buildings who needed e-mail communication. But the token ring technology was no longer being developed, and future prospects for expansion were discouraging.
To address the growing demands, we decided to install an ATM backbone based on Bay Networks Centillion 100 switches. The existing token ring hubs hooked directly to the ATM switches, and all new connections were done using Ethernet technology. We standardized the cabling infrastructure to Siemon CAT 5e system, which made it possible to run any technology for both voice and data, with no changes whatsoever.
But how did we make it all work? By identifying our needs and constraints, using third party resources to help us get the plan in motion, and finalizing and approving all plans in advance to be sure all parties involved had a clear understanding of what needed to happen when.
We had an OKI NE 1200 PABX that catered to the entire head office and also two other stations (six and eight kilometers away) via long distance extensions. The administrative task of maintaining these extensions was massive.
The sales office, 16 km away, was served by a newly installed Alcatel 4400 PABX. An OKI NE30 and Siemens Hicom 150E PABXs served two other stations (over 500 km away), respectively.
Communication in the head office and the other six stations was extremely poor, particularly because the external connectivity, including the external extensions, was provided and managed by the local telecom using a very old infrastructure.
Following the successful implementation of the ATM backbone in the head office, and the consequent improvement in services—particularly e-mail services—there was mandate from within the company to address the voice communication problems and to link up the other local stations.
IT identified the following requirements that had to be addressed.
- Reliability: We needed a reliable voice and data network to provide services to all the stations across the country.
- Capacity: We had to provide a network with enough capacity to cater to the current number of users (over 1,000) and accommodate future growth.
- Speed: We would require a high-speed network that could cope with operational demands, particularly for application access.
- Integration: We needed an integrated digital network that incorporated both voice and data traffic across the company’s stations in Kenya.
Constraints on the project path
We’d identified the requirements, so we next sat down and came up with a list of the constraints we faced:
- Resources: We needed a competent network engineer to provide technical input into the ideal solution, and we didn’t have anyone in-house. We decided to hire a consultant to provide technical competence in the design of the network, the drafting of a technical document forming part of a request for proposal (RFP), and the vendor evaluation.
- Telecom services provider: A single service provider (who is a government vendor) provides our infrastructure. Decisions take time, and commitments are rare. To ensure the project’s success, we approached the service provider at the highest level, thanks to our top management support.
- Regulatory inhibitions: The regulatory authority prohibited voice over IP over certain technology. However, this was not clarified until later in the project, which caused serious budget and time issues.
Putting the solution in place
Following the hiring of the consultant, we held a high-level meeting involving our executive director in charge of IT and the CEO of the telecom service provider. This was a strategic meeting that defined our need and achieved commitment from the telecom CEO to provide a solution.
A technical team was consequently set in motion, comprised of the telecom company personnel, the consultant, and myself, and we took charge of the project. The objective of this team was to work out the technical design of the network to provide links for both voice and data for intrastation communication and communication to the external world.
The output design would be the input to the internal network design. To ensure commitment, we required that the team provide a progress report on a regular basis to the top management of both companies.
A draft solution, based on 64 Kb and 128 Kb interstation links, was agreed on. This was then used as the basis for vendors to propose a solution covering the active equipment for voice and data communications across the stations in the country.
The telcom supplier later changed the design, however, citing government restrictions on the use of the 64 Kb or 128 Kb lines. This caused a significant variation in cost and timescales. The new design was based on 2 Mb E1 links.
Vendor selection process
We created a comprehensive RPF, covering all project details including the evaluation process, project deadlines, and expected deliverables. We then advertised this in the local daily papers.
The RFP required prospective suppliers to:
- Provide a voice solution covering the replacement of the old OKI and Siemens equipment and provision of new equipment for three stations that had no previous voice switching equipment.
- Provide a seamless internal voice network, completely hidden from the user.
- Integrate the existing Alcatel 4400 to the new PABXs.
- Integrate data with the voice network.
- Provide resilience of links between the different stations.
- Manage the network once completed.
We outsourced the project management to a company that provided an onsite project manager to run the project for the intended eight months with an option to extend the period.
Twenty-eight vendors provided solution proposals. Three—Alcatel, Nortel, and Siemens—were short-listed. Following intensive presentations and demonstrations, we chose Nortel as the best technical offer and the overall best value for money.
The Nortel solution was completed with the exception of one station. The project costs increased by 15 percent and the time overran by four months due to the change in design caused by regulatory restrictions. But overall, it was a success. We’ve realized the following benefits:
- The productivity of the company has improved significantly through faster and seamless voice communication.
- E-mail, which is a major productivity tool, is now available under the same domain name to all employees across the stations.
- Applications are now available efficiently from the main data center to users across the stations.
- As an airline using a remotely hosted reservation system, the stations are now able to cut down connection costs by having a single gateway through the country.
- We’ve achieved higher reliability through the multiple links, which are switched automatically if a failure occurs.
I now have a reliable and efficient network. As an IT operations manager, I can finally concentrate on future plans without being caught up in daily troubleshooting of a problematic LAN.
I have learned several valuable lessons from this project. First, it’s critical to seek and get top management support, particularly where government organizations are involved. This should happen from the start of the project.
Second, you don’t necessarily have to employ or have internal resources. Third-party professional resources can be outsourced for the purpose and work well. Third, you must ensure clear understanding and get formal approval from all parties involved. This will ensure that each party understands the implications of their part in time, cost, and other aspects of the project.
And finally, any project, however well thought out, can suffer from unforeseen circumstances. While these can’t be fully anticipated, they should be managed quickly when they occur.
James K. Munene is an IT operations manager for an international airline carrier.