CommNet Cellular Implements a Service-Based Architecture
CommNet Cellular, a regional cellular phone company based in Denver, Colorado, provides cellular phone service across an eight-state area in the midwest and western United States. In April of 1994, the Information Systems department consisted of four permanent employees and 18 contractors.This situation came from the technological demands that accompany high growth in a fiercely competitive business, a poorly managed department, and the lack of a coherent Information Technology (IT) strategy. Today, this same department has a full-time staff of 20, a strong IT strategy, and standard interoperability from the desktop to the servers and is actively developing client/server applications to capitalize on a technology infrastructure that spans eight states.
On the technology side, the company's battle scars 18 months ago included outdated equipment, a tangled web of undocumented network wiring, a wild profusion of desktop systems and software, eight technology platforms, consistent interoperability problems, and production systems crashing on a regular basis. On the business side, the technology problems were manifest in many of the usual ways, including slow responses to customer calls, inaccurate reporting, a frustrated user community, and permanent crisis-mode operation for the IT staff.
What started out as a short-term project to correct production-system problems quickly evolved into a complete re-engineering of the corporate IT strategy. With a forward-thinking CIO and the blessing of the corporate officers, a solid IT plan emerged that focused on several major goals:
- Physical network cleanup and upgrade
- Identification of enterprise-wide IT services
- Reduction of platform complexity and networking protocols
- Platform standards for hardware, software, and administration
- A strong commitment to training and personal productivity
A Service-Based Information Architecture
In a rare and unusual opportunity, the system engineers were given free rein to start from the beginning, with no mandate to accommodate decisions made by a previous regime. While there are many methods for creating an information architecture, in this project the design began by posing the following five questions:
- What are the corporate computing services?
- What are the service-provider platforms?
- Which platforms provide which services?
- How are the services accessed?
- What tools are needed to support access?
As the answers to these five questions emerged, a service-based architecture began to appear.
Several up-front decisions guided the design process. The design team, in which I participated, chose Ethernet as the communications medium--serial connections were history. CommNet Cellular would ultimately connect servers with fast Ethernet and install hubs and routers to segment traffic and ensure reliable wide-area network (WAN) connectivity. We selected TCP/IP as the standard networking protocol across all target platforms, along with Simple Mail Transfer Protocol (SMTP) for enterprise email delivery and Simple Network Management Protocol (SNMP) for network management. And we decided to reduce the number of supported platforms and standardize connectivity from the desktop to the servers.
When the design process began, file sharing, remote access, printing, and application access were inconvenient and unreliable at best. In an all too familiar scenario, large numbers of dumb terminals forced the whole company to rely on character-based email. Server logins and file transfer were managed by several terminal-emulation packages, some graphical and some character-based, using outdated software and incompatible protocols. You could not access a given printer from all corporate applications and the desktop, and the same printer had different names depending on the platform it was connected to.
Clearly, computing services had to be distributed in a consistent way across the network, rather than restricted by platform or application. Data needed to be easily transferable from the desktop to the servers and back again. The final architecture had to present a consistent, logical view of the network with a standard graphical interface to every workstation.
A strong commitment to standards guided the design process. In a parallel effort, a standards group composed of systems, applications, and support personnel worked hard for eight months to create standards for hardware configuration, software platforms, naming conventions, and platform administration. The resulting standards smoothed the implementation, from the assignment of subnetworks and IP addresses to usernames, computer and printer names, file and device sharing, and graphical connectivity.
A final goal was to achieve 95% user satisfaction with the resulting implementation. Non-conforming legacy systems, with their inherent restrictions and compromises, had to be accommodated until CommNet Cellular could implement an architecture-compliant replacement. Legacy systems were not allowed to negatively impact either the design or the implementation of the final service-based architecture.
Corporate Computing Services
Because CommNet Cellular is a service-based company, it was easy to begin identifying computing services. We defined a corporate computing service as a feature or function required by the majority of users in the company for corporate communications or platform-independent access to data.
The services making the final cut, shown in Figure 1, are typical for a distributed computing environment. They are meant to be available from every desktop, independent of the platform they are located on. With the corporate network expanding to an eight-state WAN and hundreds of remote business partners, the ability to move data easily and reliably across the network was paramount.
Service Provider Platforms
Next, the team evaluated the existing server platforms to see how well they would fulfill the service requirements. Three server platforms made the final four: Digital Equipment's OpenVMS, IBM's AIX, and Microsoft's Windows NT. Existing VAX/VMS production databases and financial applications were migrated to OpenVMS, while AIX continued to support real-time telephone-switch monitoring and maintenance. Windows NT was selected as the desktop server.
Windows NT Server was chosen because of its internetworking capabilities, security features, and network monitoring and management tools. With its ability to function as a gateway for Novell's NetWare, NT provided access to NetWare resources during the migration. Via TCP/IP and Data Link Control (DLC) protocols, NT supported network printing services for all users in the company. Because CommNet Cellular has a large number of traveling employees, the Remote Access Services (RAS) running Point-to-Point Protocol (PPP) was considered a bonus.
On the workstation side, all PCs were upgraded to Windows for Workgroups (WFW) 3.11 with the Microsoft 32-bit TCP/IP stack and the Reflection TCP/IP package. Microsoft Office Professional was selected as the application suite that best met the business needs of the majority of users. Custom desktop applications were strongly discouraged and prohibited in cases where a business task could be accomplished with standard desktop tools. After selecting the service providers, great care was taken to standardize service definition and graphical access for corporate users across all platforms.
Which Platforms Provide Which Services?
With corporate computing services and service-provider platforms identified, we needed a model for providing distributed services that met CommNet's requirements. At this point, we evaluated the advantages and disadvantages of three distributed models, as shown in figures 2, 3, and 4.
Model 1 consisted of a smart server and a dumb workstation, which mimics mainframe-style computing to a great extent (see Figure 2). In this model, the server provides all computing services, has high performance, reliability, and redundancy requirements, and supports many concurrent network connections. However, heavy reliance on the server introduces a single point of failure that directly impacts desktop productivity. On the workstation side, because applications run over the network, each workstation has high connectivity requirements, little access to local tools, minimal local storage demands, little or no sharing of local resources, and little local control over the desktop computing environment.
Model 2 is a mirror image of the first, a dumb server coupled with smart workstations, very much akin to peer-to-peer computing (see Figure 3). In this model, computing resources are located primarily on the desktop. Because the server provides few resources, the server has low performance and reliability requirements, few network connections, and minimal central control and administration tasks. On the workstation side, all applications are local, which gives users great control over their computing environment. This local flexibility translates into a need for high-performance desktop systems, high local sharing, and many local network connections. In this model, users bear most of the responsibility for creating and maintaining their network computing environment.
Model 3 is a compromise between Model 1 and Model 2, where computing resources are allocated to servers and workstations based on how often and the manner in which they are used (see Figure 4). In this scenario, the server provides performance-intensive or widely used applications and services that require carefully managed access controls. On the workstation side, each desktop has daily-use applications, the ability to share and control access to local resources, and moderate control over the computing environment. Compared to the first model, the server has more moderate performance requirements and less network traffic. This model permits distributed control, allows great flexibility in how services are managed, and carries moderate user-support demands.
The last model is the one chosen for CommNet Cellular's distributed service architecture. To complete the design, we created a set of guidelines for determining where to place host resources and services resources. With three server platforms and a target of 350 clients, we knew guidelines would be important when it was time to implement the design.