SNA/IP Solution

Business Case

The Business Case for Integrating SNA and IP in the Enterprise Network

Purpose of This Document

This document describes a ubiquitous trend within many enterprise networks, the integration of two dominant network protocols and infrastructures: SNA and TCP/IP. The introductory section describes the potential phases of integration and coexistence. Next, the document discusses the major market trends within enterprise networks that are related to this trend. Finally, it provides a set of models for enterprises to use to quantify their potential return on investment (ROI) for various stages in the integration.

The goal of this document is to provide a thorough and comprehensive review of the major factors impacting the integration of SNA and IP and to offer a set of ROI models that are general enough to be useful to enterprises in a variety of industries and geographical markets. This document concludes with a brief case study that describes how an actual Cisco Systems customer tackled its SNA/IP integration project.

This document is written for two primary audiences—managers responsible for integrating SNA and IP in an enterprise, and integrators and other organizations providing services and products to these enterprises.

Executive Overview

At one time SNA prevailed as the standard architecture for enterprise networks. Since the 1980s, many organizations have also been implementing TCP/IP-based networks, initially to take advantage of certain technical benefits offered by TCP/IP and because the open nature of TCP/IP provided a wide set of multivendor solutions. Now, with the unprecedented success of the Internet, corporate intranets, and virtual private networks (VPNs), organizations are aggressively planning and implementing new business solutions that all center around a TCP/IP-based infrastructure.

But organizations still have a massive investment in SNA devices, software, and applications. Some experts estimate that the installed base of SNA-based applications alone is worth $20 trillion. These applications have a long useful life left, so the goal for enterprise organizations is to integrate the newer, TCP/IP-based environment with the legacy, SNA-based environment. Pioneering organizations began to integrate these two environments in the early 1990s. The technologies and products were still quite new at the time. Since then, the solutions have become mature and stable. Most research shows the rewards of integrating SNA and TCP/IP will outweigh the risks of such a project. Faced with IBM discontinuing its front-end processors (FEPs) and other SNA devices, organizations that stick with traditional SNA environments face higher costs and substantially lower benefits than their counterparts that have implemented TCP/IP and integrated the two environments. Most organizations are finding that this integration can also serve as the first building block toward a unified data center network that is faster, more scalable, more secure, and more resilient than separate legacy networks.

Cisco has helped thousands of enterprise organizations worldwide integrate SNA with IP. As the market leader in SNA/IP integration solutions, Cisco has the breadth of products and the vast experience to assist organizations of any size undertaking SNA/IP integration. Cisco has developed a five-phase integration model to describe a typical migration path. The Introduction section of this document describes the five phases and details the unique attributes, products implemented, and issues of each of the phases. This model can be used to articulate the current state of an enterprise network or its elements, to assist in defining an enterprise's goal state, and to identify potential solutions and issues.

International Data Corporation (IDC) has extensively studied the adoption rate of TCP/IP and the investment in SNA equipment and software. The Market Data section details some of the results of these studies, which will be useful to organizations formulating SNA/IP integration business cases. The data clearly shows that adoption of TCP/IP in enterprises is large and growing around the world, led by enterprises in the United States. Three drivers to the adoption of TCP/IP are discussed: the desire to extend enhancements such as VPN and high-speed Ethernet across the entire network (including SNA devices and applications), the move toward consolidated networks, and Internet business solutions.

The end goal for an organization putting together a business case for SNA/IP integration is to calculate the projected ROI. From a macro viewpoint, ROI is calculated by subtracting costs from benefits. But the elements of the cost part and the benefit part of the equation are different for each case, depending on what the organization is trying to achieve. For example, an organization building a business case for implementing Internet business solutions is going to have a vastly different ROI calculation than an organization trying to achieve simple file sharing using TCP/IP.

However, Cisco finds that there are some SNA/IP integration elements that are common across different types of business cases. These components can be analyzed and integrated into an individualized, total business case for an enterprise. There are three common components for which ROI models are provided in this document:

Cisco customers worldwide are finding ample financial benefits for undertaking SNA/IP integration. However, since the withdrawal of FEPs from the market, the argument for FEP replacement is no longer simply about reducing cost. A network that relies on FEPs is reliant on equipment that will eventually be unsupported. This poses a tangible risk to mission-critical SNA applications and devices. FEP replacement not only protects these investments, it enables you to extend the benefits of improvements in technology across the entire network.

This document closes with a brief case study of a Cisco customer, a large information technology firm, which completed a major project using Cisco SNA Switching Services (SNASw). This case study illustrates many of the concepts discussed in this document.

The evidence is clear. Organizations that attempt to cling to an SNA-only infrastructure in the enterprise network will be left behind. They will find it harder and harder to compete with competitors that offer new services over the Web and tightly integrate the supply chain using electronic commerce. They will pay more for, and receive less benefit from, their enterprise network than those that have an integrated SNA/IP infrastructure. SNA/IP integration is imperative. The only question is which vendor you will turn to for assistance in this endeavor. Only Cisco has the breadth of products and the vast experience at SNA/IP integration to minimize the risk and maximize the reward. And when you are done, Cisco has the products and expertise to take you to the next step: consolidation of data, voice, and storage networks.

Introduction

Just a decade ago, the term SNA network was synonymous with the term enterprise network. All mid-sized and large corporations, government institutions, and educational organizations ran their enterprises on applications resident on IBM (and compatible) mainframes and midrange systems, and on networks based primarily on SNA protocols and networking devices. Despite the prevalence of SNA, in the late 1980s large enterprises began to introduce TCP/IP—and, for a short time, Open Systems Interconnect (OSI)—protocols and equipment into their networks. These new protocols were developed because SNA had two major failings: it lacked dynamic definition and configuration, and it was a proprietary protocol.

In an SNA network, all resources needed to be predefined to one or more mainframes running Advanced Communication Function/Virtual Telecommunication Access Method (ACF/VTAM), the most powerful element in an SNA network. In addition, the network was unable to dynamically route around failures in the network. This lack of dynamic definition and configuration was an impediment to growth and change within networks. These dynamic aspects were later introduced in Advanced Peer-to-Peer Networking (APPN) and APPN/High Performance Routing (HPR), SNA's successors. However, TCP/IP, which is inherently more flexible and dynamic, had already gained an irreversible foothold.

SNA was defined, owned, and managed by IBM. In the late 1980s, major corporations were advocating open architectures and technologies, correctly stating that these would lead to falling prices and better interoperability between products from different vendors. Although APPN and APPN/HPR are more open than traditional, subarea-based SNA, neither can match the openness of TCP/IP and its related technologies. As a result, products based on SNA, APPN, and APPN/HPR were invariably more expensive, available on fewer products, and slower to market than the TCP/IP-based equivalents.

By the early 1990s, many large commercial, government, and educational organizations had begun to integrate TCP/IP products and technologies into their SNA networks. Since then, the solid business reasons for moving to a TCP/IP-based network have grown enormously, spurred by the unprecedented success of the Internet and corporate intranets. Today, the common denominator for electronic communication from one organization to another, or from consumer to company, is TCP/IP. As we will see in later sections, market research is showing that TCP/IP is prevalent in all market sectors and all geographies. As organizations continue to adopt corporate intranets, VPNs, and Internet business solutions, the movement to TCP/IP at all points in the enterprise network will only accelerate.

Many organizations have discovered an additional benefit of adopting a TCP/IP infrastructure. They have found that this is just the first logical step to creating a multiservice network that seamlessly accommodates data, voice, video, and storage networking. In the past, organizations had separate logical and physical networks to support traditional telephony traffic, time-division multiplexing (TDM) traffic, data, Internet connections, and remote access. Storage was internal to servers or directly attached to servers. In 2002, IDC, a respected research and analyst firm, compiled a study entitled "Mainframe Networking Opportunity Analysis" in which they polled network managers and found that almost 90 percent planned, or were implementing, consolidated networks. More than one-third of the respondents planned to unify all network functionality.

Although most large organizations have both TCP/IP and SNA traffic today, some have yet to integrate these two environments within the network. Some network managers still view this integration as a project fraught with risk and peril to the mission-critical network and systems. Certainly, a project of this magnitude does entail risk and therefore must be carefully planned and tested prior to implementation. But the organizations undertaking these projects today gain the benefits unavailable to some of the early pioneers who began integration projects in the late 1980s or early 1990s:

Gartner Group, in a Strategic Planning Assumption published in 1999 titled "The Last SNA Network," indicated that the rewards for integrating SNA and IP outweighed the risks of such a project. They contended that organizations that continued to use SNA as the primary mainframe access would spend more and derive less benefit than organizations utilizing integrated SNA/IP networks. Recent developments in IBM's SNA product lineup make that more true than ever.

IBM announced in 2002 that it would no longer sell its 3745 and 3746 controllers. These FEPs formed the backbone of an SNA networking infrastructure. Many organizations that at one time considered SNA/IP integration primarily an economic decision now realize that it is, in fact, a long-term strategy for protecting their mission-critical SNA applications and devices. Networks that are based on these FEPs will begin to atrophy, and eventually the controllers will no longer be supported.

Cisco is the leading supplier of solutions that provide integration of SNA and TCP/IP networks. It has assisted hundreds of customers around the world in managing the risk of integration, leading to successful implementations. Actual Cisco customers have experienced the following results from projects that implement Cisco's SNA/IP products:

After helping hundreds of large organizations worldwide integrate these environments, Cisco has drawn upon its experience to develop a model illustrating a typical integration path (see Figure 1). This model describes five phases common to most SNA/IP integration projects. Some organizations find that their network is completely represented by one of the phases, while others realize that they have two or more of the phases implemented in various sectors of their network.

The phases can be differentiated by the protocol that runs in each of four key elements in the network: the mainframe/midrange computer, the data center network, the network backbone, and the desktop. The characteristics of each of the phases are detailed below along with the problems solved, types of products and technologies implemented, and challenges.

Phase One: SNA Centric

An SNA-centric network has SNA, APPN, or APPN/HPR protocols running on one or more mainframe or midrange systems, in the network backbone, and at the desktop (see Figure 2). Traditional subarea networks that were widely implemented in the 1980s are built on ACF/VTAM in the mainframe, ACF/Network Control Program (NCP) in communication processors (that is, FEPs and remote concentrator processors), and cluster controllers with terminals attached via coaxial cable. The communication lines utilized were predominantly leased Synchronous Data Link Control (SDLC) and public or private X.25 lines.

In the late 1980s and early 1990s, traditional SNA networks evolved to meet the new demands for client/server computing and LANs. PCs running terminal emulation software replaced many of the fixed-function terminals. Token Ring LANs were widely deployed to bring higher speeds and support client/server computing. Remote concentrator processors were often replaced by a new generation of remote SNA devices—LAN gateways, bridge/routers, and Frame Relay Access Devices (FRADs).

Today's SNA-centric network is a very high-speed and dynamic network when compared to the traditional SNA network of the past. ACF/VTAM on the mainframe includes APPN protocols to support dynamic rerouting around failures and high-speed switching in the network. The mainframe complex, which is now composed of multiple CMOS processors, implements Parallel Sysplex to provide the ultimate in redundancy and session persistence. The FEP has often been replaced by a high-performance, channel-connected router or Open Systems Adapter (OSA). The network backbone is composed of high-speed switches (Asynchronous Transfer Mode [ATM] or Ethernet/Fast Ethernet/Gigabit Ethernet) and routers running SNASw, an evolution of the earlier APPN. Shared Token Ring LANs are being replaced with Ethernet switching to the desktop, offering a dedicated LAN segment and bandwidth to each end user. Most desktops have PCs running advanced SNA client emulation software. Routers provide support, via features like Dependent Logical Unit Requester (DLUR) and Downstream Physical Unit (DSPU) concentration, to transport the traffic from the remaining traditional SNA terminals and controllers.

The predominance of TCP/IP and the withdrawal of the FEP have stopped widespread new investment in SNA and APPN equipment in its tracks. Very few organizations and institutions remain that only support SNA or APPN protocols. And with the burgeoning growth of intranets and VPNs, the pure SNA-centric network that does not intermix or interoperate with a TCP/IP network and TCP/IP technologies will be rare indeed.

Phase Two: IP Transport

Beginning in the 1980s, large organizations began building TCP/IP-based networks to support client/server applications and systems. UNIX, a dominant operating system for client/server applications, natively supports TCP/IP. As the growth of TCP/IP-based systems continued, organizations often found that they had built parallel networks, one running SNA and one running TCP/IP. This is obviously very expensive because of the duplication of line costs, equipment, and personnel. To eliminate the duplication, organizations had a choice: run the TCP/IP traffic over the SNA backbone, or run the SNA traffic over the TCP/IP backbone.

For reasons already cited (SNA's lack of redundancy and openness), running TCP/IP over an SNA backbone was not feasible. Routers, which formed the core of the TCP/IP network, began to support the encapsulation of SNA in TCP/IP for transport across the TCP/IP network (see Figure 3). This encapsulation brought many benefits. First and foremost, while encapsulated in TCP/IP, the SNA traffic was dynamically routed around network failures. The encapsulation schemes also provided more flexible configurations for SNA devices and reduced polling traffic across the backbone. Cisco offered an early encapsulation scheme with remote source-route bridging (RSRB).

Since then, the industry has adopted a standard, DLSw, which has been very widely accepted and implemented. In many instances, DLSw+ is used in combination with SNASw (often in the same router), which allows SNA routing to the host. It is estimated that almost one million routers today are implemented in enterprise networks running one of these encapsulation methods. Routers also provide features to encapsulate other types of legacy traffic (async, bisync, and some proprietary protocols) in addition to SNA.

In this second phase of integration, many organizations find that the same end users who are running advanced SNA client emulators to access mainframe and midrange systems are also accessing TCP/IP systems. This means that each PC must run two different protocol stacks—SNA and TCP/IP—for access to host systems.

Phase Three: IP Integration

The third phase involves the removal of the SNA network from the data center. In the previous phase organizations used IP to transport SNA over an IP backbone, but within the data center they again used SNA networking to access the mainframe. With IBM's withdrawal of the FEP from marketing, many organizations would like to extend IP routing through the backbone and the data center all the way to the host and completely do away with SNA networking in the data center. IBM's OSA-Express adapters (an IP-only solution) in combination with Cisco Catalyst^® 6500 Series switches support Gigabit Ethernet, providing the transfer of huge amounts of data in record time. However, in many instances SNA applications and SNA desktop devices are still required, so how is SNA traffic to be sent to SNA applications over an IP-only network?

The answer is Enterprise Extender (EE), a function supported by z/OS and by SNASw. EE is the transport of SNA data over an IP network in the form of User Datagram Protocol (UDP) packets, with HPR providing the reliable transport and flow control (see Figure 4). In this way, SNASw EE can be positioned in the data canter along with DLSw+ (which can be left in place to transport over the IP backbone), or it can be placed in the branch to replace DLSw+ entirely. EE in the branch provides a high-performing, reliable solution because IP routing is used all the way from there to the SNA applications on the mainframe.

Phase Four: IP Client

In the fourth phase, organizations eliminate the dual protocol stacks at end user PCs by implementing emulation software that supports TCP/IP (see Figure 5). The same rich functionality that end users rely on in their emulation software remains, except that now it runs over a TCP/IP stack. TN3270(E) and TN5250 are widely implemented and widely accepted standards for achieving TCP/IP-based access to mainframes and AS/400s. In addition to eliminating a second protocol from each desktop, organizations reap enormous benefits by implementing a low-cost, standards-based solution like TN3270(E) and TN5250:

Phase Five: IP Centric

In the fifth and final stage of the logical progression from SNA to TCP/IP, the mainframe and midrange systems natively support TCP/IP (see Figure 6). They share files with and transfer data to other non-SNA systems. The corporate databases are securely accessed in a standard way from a variety of different end user applications. The remaining "legacy" applications that are based on traditional "green-on-black" character-based terminals are accessed transparently through standard emulation screens or through intuitive, user-friendly Web pages. These TCP/IP-based mainframe and midrange systems offer advanced redundancy and high-availability features similar to those provided to SNA-based applications. And these systems provide the tightest levels of security, the highest levels of manageability, and superior scalability when compared to other application platforms available on the market. With the full, native support of TCP/IP, the mainframe and midrange systems can be fully participating members in the corporate intranet of tomorrow.

The Cisco five-phase model of SNA/IP integration is based on Cisco's experience helping to integrate some of the world's largest and most complex SNA networks. In reality, very few organizations go through a step-wise, linear migration from SNA Centric, to IP Transport, to IP Client or IP Integration, to IP Centric. For example, many large organizations have run TCP/IP stacks on their mainframes for years, alongside ACF/VTAM, whether they have implemented TCP/IP in the enterprise backbone network or not. Indeed, most large organizations will find elements from all phases represented somewhere in their network. The model, however, is useful to describe the various issues of SNA/IP integration, the common solutions to those issues, and the characteristics of the network at various points in the change.

Market Data

The proof of the shift from SNA to TCP/IP in enterprise networks can be seen in a variety of data provided by industry analysts and market research firms. In this section, data drawn from a variety of sources quantifies the shift and details users' plans, the driving factors behind those plans, and issues they are attempting to resolve.

SNA and TCP/IP Investment

Until the 1990s, most large enterprises worldwide ran their networks with SNA protocols, SNA devices, and SNA-based applications. This represented a monumental investment in equipment, software, and training, not to mention the development of sophisticated processes and procedures for configuring, administering, and managing these networks. Some experts estimate that the installed base of SNA-based applications alone is worth $20 trillion. The extent to which these same organizations have moved away from SNA in favor of TCP/IP is quite dramatic.

A recent IDC study of large organizations in the U.S., European, and Asia/Pacific regions divided mainframe users into three main groups: those with pure IP or integrated IP/SNA networks, those who were moving toward pure IP or integrated IP/SNA networks, and those who were still using pure SNA networks. Not surprisingly, the last group was the smallest (see Figure 7). The number of enterprises depending solely on SNA fell from 32 percent in 1998 to just 9 percent in 2002. By 2004, that number is expected to fall to 6.8 percent.

Most SNA users are planning to phase out SNA, or are in the process of doing so. When those organizations that still had SNA components were queried about their plans for support of SNA in their networks, more than two-thirds of those polled (67 percent) planned (or had nearly completed) total elimination of SNA (see Figure 8). According to IDC, the largest group was composed of those organizations that had nearly completed their migration to pure IP. These tended to be smaller organizations with fewer than 1000 employees and their networks were already 95 percent reliant on IP. The second, and smallest, group also planned to phase out SNA altogether and was currently more than 90 percent reliant on IP. Even the third group, composed of organizations that had no immediate plans to discontinue SNA, was already using IP for about 85 percent of its networking needs. This last group was dominated by large companies with more than 6000 employees. Among the latter two groups, network managers envisioned steady decreases in the amount of SNA traffic over the next two years (see Figure 9).

Figure 8 SNA Support

With IBM's 2002 announcement of the end of sale for FEPs, and the Cisco announcement of the end of sale for Token Ring switches, it would seem that the writing is on the wall for SNA devices and applications. Networks that rely on FEPs are relying on a technology that will eventually be unsupported. Clearly, the future of SNA lies in its integration with TCP/IP. Fortunately, most organizations are already in the fourth (IP Client) or even fifth (IP Centric) phase of SNA/IP integration. This trend was already happening long before the advent of the Internet, corporate intranets, VPNs, Internet business solutions, and Web-to-host access. But these new initiatives, together with the increasing demand for bandwidth and the need to manage data across remote sites, provide a solid business imperative to the integration, because they all rely upon a basic underpinning of TCP/IP. In the following sections, this document outlines the increasing demands of new technology and the movement toward consolidation of networks in the United States and around the world.

Leveraging New Technology

As if protecting the trillions of dollars invested in SNA were not enough, integrating your SNA and IP networks allows you to extend the power of those applications by taking advantage of powerful IP technologies. The development of corporate intranets, once defined as an organization's internal network based on TCP/IP and Internet technologies (for example, Web browsers, Web servers), revolutionized the way organizations in the United States and around the world shared information and resources internally. The rise of the VPN has enabled organizations to extend this capability beyond their offices. IP VPNs enable users greater access to organizational data and applications, while offering better security than the Internet and at cheaper prices than leased lines. Not surprisingly, IDC projects that worldwide demand for VPN will more than double over the next five years (see Figure 10). Most of this growth will occur in the United States and Europe, but Asia Pacific organizations are expected to increase VPN spending during that time period by an annual average of 21 percent.

In essence, the demand for VPN mirrors the deployment rate of corporate intranets in the late 1990s. In 1998 IDC indicated that the rapid adoption of intranets was largely explained by the fact that most large organizations with intranets already had a TCP/IP infrastructure in place prior to the intranet deployment. So these large organizations already had an installed base of IP routers, LAN switches, and UNIX or Windows NT servers that were easily repurposed for the intranet. This fact may have helped explain the lag in European intranet adoption, because in general European companies typically have more SNA and less TCP/IP than their U.S. counterparts. Likewise, it may explain the difference in demand for VPN.

The popularity of other Internet technologies grows daily. Consumers and enterprises alike are fascinated with Voice over IP (VoIP), streaming media, and Web applications—all of which contribute to the ever-increasing need for WAN bandwidth. Network managers are responding by adopting faster connectivity. In two years, these managers expect Gigabit Ethernet, 10/100 Ethernet, and 10 Gigabit Ethernet to be the top three mainframe connectivity choices (see Table 1).

Source: IDC, October 2002

Network Consolidation

Although Cisco SNA solutions offer immediate consolidation of SNA and IP data networks, many enterprises are already looking ahead to the next step. As IT budgets shrink and concerns over security rise, network managers are increasingly seeking to consolidate all of their network functionality into a single multiservice network.

When IDC polled network managers worldwide about their companies' vision for the networks they run, an overwhelming majority envisioned some sort of consolidation (see Figure 11). Although it was not surprising that many network managers desired consolidated data networks, IDC reported that an astonishing 38 percent of respondents worldwide wanted one "grand unified" network to handle their voice, data, and storage needs. American companies are leading the charge for grand unification; however, the movement is strong in Europe and Asia as well.

A closer look at the numbers reveals some familiar trends. Among business sectors, service and financial industries are most interested in grand unification (see Figure 12). Likewise, when examined by size of company, medium and small companies expressed the most interest in unifying their voice, data, and storage networks (see Figure 13). Because large companies have the heaviest investment in SNA protocols, devices, and applications, it is not surprising that they have fallen behind in the consolidation race.

FIgure 13 Network Consolidation Vision by Company Size

Internet Business Solutions

Although many business-to-business companies did not survive the stock market shakeout of the last few years, the potential for the Internet as a business solution remains undiminished. Despite the shakeout, many companies are reaping enormous benefits from selling products and services over the Internet. Dell Computer and Cisco, both pioneers in Web-based e-commerce, currently book the majority of their sales over the Internet, and organizations can benefit from some of the lessons learned by these pioneers.

The business potential is still very attractive, and many organizations see one of the real gains in Internet business solutions as the ability to streamline their interaction with customers, suppliers, business partners, and employees through supply chain management, workforce optimization, and e-learning. At one time, it was thought that this interaction could be built on non-Internet technology. For example, business partners were able to automate supply chain management using their existing SNA networks for many years. However, those initiatives required a great deal of coordination between the two networks.

From a networking standpoint, implementers of Internet business solutions indicate that the same things that are required of internal enterprise networks are required of networks supporting Internet business solutions: reliability, performance, accessibility, ease of integration, investment protection, and security. The only difference, of course, is that a network problem is much more visible in a company that relies on Internet business solutions for day-to-day business, training, and workforce optimization.

Market Data Summary

The evidence is clear. Traditional SNA networks must be integrated with or replaced by TCP/IP-based networks. The most pressing reasons for the integration are technical advantages and cost savings. Traditional SNA cannot offer the same resilience, redundancy, and flexibility offered by TCP/IP. Many organizations have modernized their SNA networks with technologies like routers, LANs, and LAN switches to extend the life of those networks. Now that IBM has withdrawn its FEP controllers from the market, the need to protect mission-critical SNA applications and devices, coupled with the cost advantages of TCP/IP, are too compelling to ignore. As a result, most large organizations are well into integration phases four and five.

The new business drivers for wholesale TCP/IP adoption are related to the phenomenal success of the Internet and Internet technologies. Corporate intranets have been deployed at a very rapid pace and VPNs are following suit. Consumers and enterprises alike are demanding streaming media and an ever-widening suite of Web-based applications. At the same time, enterprises have indicated a real desire to consolidate all of their voice and data needs into one network. Internet business initiatives promise real bottom-line results to implementers. These new initiatives provide the added business justification for integration of TCP/IP.

The Return on Investment

Organizations that integrated their SNA and IP networks early did so primarily to achieve technical benefits lacking in the SNA environment (for example, rerouting around failures). Since then the technological benefits have become even more promising, and a more compelling argument for integration now exists. Because IBM will no longer sell FEPs, integration has become a means for protecting an organization's SNA investment. Cost savings, although a little more difficult to calculate when products were relatively young and the number of unknowns was large, have become more dramatic and easier to calculate.

The thousands of organizations that have already integrated their SNA and IP networks have been very encouraging, with organizations often experiencing results that were even better than expected. The new business that is possible by implementing Internet business solutions and Web-to-host solutions goes right to the revenue line of the financial statement and adds to the business case.

The many implementers have shown, however, that special care must be taken to put in place a network with sufficient bandwidth and quality of service (QoS) attributes to meet the new demands that a corporate intranet, VPN, and Internet business solutions places on the network. More important than ever is planning for a network that supports high capacity, redundancy, and availability.

A total business case for SNA/IP integration can thus be summarized as follows:

ROI = New Business + Cost Savings - Cost to Implement

It is outside of the scope of this document to quantify all elements of a total business case for building a corporate intranet or initiating Internet business solutions. However, there are common elements that are related to changing the network infrastructure from a traditional SNA network to TCP/IP, which are common pieces of these larger business cases. These elements are:

For each of these common elements of integration, this document details the types of products utilized and the factors in the ROI, and it provides an ROI model for that element. For costs and benefits that are recurring, a two-year period is used to calculate the return. At the end of this section, a case study involving a real Cisco customer that employed all of the elements in its integration of TCP/IP illustrates the benefits.

Line Consolidation

The primary motivation for a line consolidation project is cost reduction and simplification of the backbone. Many organizations have a large number of locations that support multiple different data lines. Consider a branch banking network, for example. As already stated, most branch banks support one type of line (bisync) for ATM machines, one or two (SDLC/X.25 and perhaps IP) for transaction data, and a separate line (async) for alarm traffic. Then, of course, there is another line for voice traffic. The initial step in the line consolidation is to consolidate all existing data onto a single line. This may involve purchasing a line with higher bandwidth than any of the existing individual lines, but the elimination of multiple lines will more than pay for the additional bandwidth. The final step in line consolidation is to support voice, data, and video across a single line. Many organizations have already taken this step, and most have considered it for the long term.

In a line consolidation project, the "center" of the network is a meshed, high-speed TCP/IP infrastructure. The entry portal from all sites onto the backbone is a device that encapsulates or converts non-TCP/IP traffic to TCP/IP. The backbone is typically built in a meshed configuration, providing redundancy and rerouting around failed components. Increasingly today, the backbone implements high-speed LAN and WAN switching to provide the ultimate in scalable bandwidth and high capacities. Network management systems that can manage both the SNA sessions and equipment and the TCP/IP elements are often deployed.

Products Deployed

Historically, the primary device that has been used, and is still deployed today, as the "portal" device is a multiprotocol router that is able to encapsulate and convert the legacy traffic. Cisco pioneered this capability in its routers with its RSRB feature of the Cisco IOS^® Software. Cisco later added the industry standard DLSw+ and SNASw EE to its routers. Cisco routers also support the tunneling of both bisynchronous and certain asynchronous protocols.

In networks with a large number of small remote or branch offices, an inexpensive branch router such as the Cisco 1700 or 2600 Series is deployed. Although low-cost, these branch office routers support all of the sophisticated features to transport legacy traffic over TCP/IP. The legacy devices (for example, cluster controllers) attach directly to the router using a branch office LAN or an SDLC or X.25 line. These branch routers then feed a backbone that is composed of distribution routers or even high-end data center routers.

Some organizations are augmenting this router-based design today with LAN and WAN switches. Switching, no matter the media type (Ethernet, Fast Ethernet, Gigabit Ethernet, ATM) provides higher speeds and reduced congestion within the workgroup, campus, or WAN environment. Switches support advanced features to ensure QoS, security, and virtual LAN support.

Business Case Elements

On the benefit side of the ROI equation for line consolidation are the reduction and elimination of multiple communication lines to each site, the elimination of equipment at each site, and the reduction in personnel costs related to managing several separate network infrastructures. On the cost side of the equation are the new routers and switches to implement the TCP/IP backbone and the personnel costs to plan, test, and deploy the new infrastructure.

Elimination of Communication Lines

Calculate the total current monthly costs of data communications lines to all sites that will be taking part in the migration and multiply by 24 months to arrive at a two-year total cost. Then calculate the anticipated new monthly costs, again multiplied by 24 months. The difference between these two figures should be positive, because it is assumed that the current costs exceed the costs after migration.

Rule of Thumb: Line costs, obviously, vary considerably from one geographic region to another and depend heavily on each customer's total volume, geographical reach, and so on. However, Cisco has found through its experience with hundreds of customers worldwide that a typical account can expect to save approximately 50 percent of its current line costs by eliminating duplicate lines and consolidating them onto a high-speed TCP/IP backbone.

For a branch-style network with multiple small locations, each supporting multiple different lines, you can estimate the new line costs as a percentage of old line costs as follows: new = (nl/cl * nc/cc), where nl is the number lines per branch location after the project, cl is the number of lines per branch location currently, nc is the average cost for the new branch lines (per month or other unit of time), and cc is the current cost for all current branch lines. So, for example, assume a branch network currently has two lines per branch location and will reduce that to one per location. The current average line cost is $1200 per month for both lines and the new cost will be $900 per month for a single high-speed line. The new line cost will be (1/2 * 900/1200)=0.375. Thus in this case, the new line costs will be 37.5 percent of the total current line costs. More complex networks will require a site-by-site and line-by-line analysis to determine cost savings.

Equipment Savings

In this section, determine the deferred investment that would have been spent in replacing old equipment had the integration project not occurred. Some examples are PC servers that are acting as branch office SNA gateways, new cluster controllers, and low-end, FRADs or TCP/IP-only routers. Then, calculate the total deferred or avoided upgrades to existing equipment. Some examples are LAN interfaces on cluster controllers, software upgrades for cluster controllers, and new FEP interfaces. Next, calculate the resale value (if any) of all equipment that will be eliminated.

Personnel Savings

Calculate the total estimated staff-hours that are saved because of the elimination of multiple disparate line types and protocols. It is likely that the savings will increase over time, so the model provides for different calculations for the first and second years after deployment.

Equipment Costs

Calculate the total equipment costs (after discount, but include any software charges) for the new infrastructure. Include all equipment and software that is directly related to the line consolidation project.

Personnel Costs

A line consolidation project is not something that is done quickly. Done properly, there is an up-front and detailed design, planning, and product selection phase. Training of personnel should be undertaken if new skills will be required. The network design should be tested and then deployed. The total effort of these personnel and training costs should be estimated up front.

ROI Model

Table 2 demonstrates a simplified model for calculating the ROI for line consolidation.

FEP Replacement

After a steady decline in demand for FEPs, IBM announced the end of sale for the 3745 and 3746 controllers in 2002. That means organizations that have not already begun a FEP replacement project must decide to initiate those projects now or face the atrophy, and eventual loss of support, for networks based on these controllers. Fortunately, a FEP replacement project not only means continued access to mission-critical SNA applications and devices, it is also the first step toward making these applications and devices available on a faster, more modern network.

FEPs provided excellent communication services for traditional, hierarchical SNA networks. They do not, however, support TCP/IP very well and they do not support very high throughput. As organizations move through the various phases of migration, they find that they need high-speed channel connections to the mainframe for TCP/IP file transfers and other TCP/IP-based traffic. In the past, a separate standalone interconnect controller or PC server with channel connections was deployed to specifically handle TCP/IP traffic. The popular Cisco Channel Interface Processor (CIP) and Channel Port Adapter (CPA) have been deployed in thousands of organizations to provide a high-speed, router-based channel connection. In recent years, many organizations have deployed the IBM OSA-Express to provide direct connection between the mainframe and the switched LAN network.

Cisco offers SNASw solutions that enable the effective removal of FEPs. The SNASw Branch Extender (BX) solution is designed for networks that have already implemented the early APPN technologies. BX solves the scalability, broadcast, and complexity problems associated with early APPN networks. SNASw EE is a solution that enables SNA traffic to be transported natively over an IP network. With EE, the applications and devices that have supported mission-critical operations for decades can continue to function, but the entire network is based on IP. As advances in IP-related technologies become available, the entire network can participate and benefit from the enhancements.

Some organizations have resisted elimination of FEPs because the FEPs were performing specific functionality that had no alternative in a router or other channel device. For instance, SNA Network Interconnect (SNI), or the ability to securely connect different SNA networks for transactional or batch exchanges, has traditionally been a function of the FEP. However, the Cisco EE solution, in combination with Extended Border Node (EBN) capability, provides a complete functional replacement for SNI. By utilizing EE, organizations can replace the FEP with a channel-attached router or OSA-Express, which enables the mainframe to be directly connected to the switched LAN infrastructure.

Products Deployed

The centerpiece and preferred solution for a FEP replacement strategy is a combination of the IBM OSA-Express and Cisco Catalyst 6500 Series Gigabit Ethernet switch. This solution enables the mainframe to directly attach to the very high-speed switched infrastructure and supports high-speed connectivity for TCP/IP applications. If SNASw EE is deployed for continued use of SNA or APPN applications, it can reside on any router attached to the network; however, in a typical FEP replacement project the router resides in the data center.

If the mainframe is not equipped to support the OSA-Express adapter, then an alternative is to directly attach a router to the mainframe using the Cisco CIP or CPA. These adapters support direct connection to the mainframe via one or more Enterprise System Connection (ESCON) interfaces. They run the necessary channel protocol software and, in some cases, special software designed to offload communication processing from the mainframe. For example, the CIP and Channel CPA both support TCP/IP Offload, TCP Assist, and TN3270 Server features to offload mainframe cycles. Unlike the FEP it is replacing, the channel-connected router supports both SNA and TCP/IP. Therefore, in many FEP replacement projects, additional special-purpose devices like interconnect controllers (for example, IBM 3172) or TN3270 gateways running on PC servers can also be replaced.

Additional equipment may be deployed to support the FEP replacement project. For example, if the FEP being replaced supports a large number of SDLC or X.25 lines, then additional distribution routers may also be deployed to concentrate these low-speed lines onto a high-speed, data center LAN to which the channel-connected router is also attached.

Business Case Elements

On the benefit side of the ROI equation for FEP replacement are the reduction or elimination of recurring software license fees, hardware maintenance, and FEP lease fees; the avoidance of new equipment and upgrades; and the reduction in personnel costs related to managing and maintaining FEPs and other channel-connected equipment. On the cost side of the equation are the channel-attached and distribution routers and switches and the personnel costs to plan, test, and deploy the new infrastructure.

Elimination of Recurring Costs

Calculate the total recurring costs associated with FEPs. First, calculate the current monthly ACF/NCP fees for all FEPs being replaced and multiply by 24 months to arrive at a two-year total cost. Next, calculate the reduction in ACF/NCP license fees for any remaining FEPs (for example, reduction in pricing tier due to fewer connections). Next, calculate the hardware maintenance fees for FEPs that will be eliminated. Finally, calculate the two-year savings of lease payments for leases that will come due over the course of the project and not require renewal. The total of all three recurring costs is the two-year recurring cost savings.

Rule of Thumb: ACF/NCP licenses are based on tiers, ranging from tier 1 to tier 5. IBM's U.S. list prices for monthly license fees are: tier 1 = $415, tier 2 = $620, tier 2.5 = $961, tier 3 = $1173, tier 4 = $796, and tier 5 = $2072. Annual hardware maintenance fees range from roughly $2600 to $6600 for each FEP (based upon model), approximately $200 per channel adapter and low-speed line scanner, roughly $350 per high-speed line scanner, and approximately $575 per LAN interface.

Equipment Savings

In this section, determine the investment that would have been spent in replacing or augmenting existing FEPs, channel gateways, and interconnect controllers had the replacement not occurred. Then, calculate the total deferred or avoided upgrades to existing equipment. Some examples are LAN interfaces on FEPs, ESCON interfaces for FEPs, and software upgrades for PC server-based TN3270 gateways.

Personnel Savings

Calculate the total estimated staff-hours that are saved because of the elimination of FEPs and ACF/NCP configuration. It is likely that the savings will increase over time because these personnel are difficult to find and keep on staff, so the model provides for different calculations for the first and second years after deployment.

Equipment Costs

Calculate the total equipment costs (after discount, but include any software charges) for the new channel-attached equipment and any distribution routers and switches required for line concentration.

Personnel Costs

A FEP replacement project can be a large undertaking, particularly if TCP/IP training must be conducted first. Proper attention should be paid to up-front planning. Training of personnel should be undertaken if new skills will be required. The new design should be tested and then deployed. All costs should be estimated in advance.

ROI Model

Table 3 demonstrates a simplified model for calculating the ROI for FEP replacement.

Desktop Consolidation

In a desktop consolidation project, the goal is to make each desktop within the scope of the project communicate to the host using TCP/IP instead of SNA. The driving force is to simplify the administration of each desktop and reduce unnecessary communication stacks and protocols (that is, SNA).

What a desktop consolidation project entails depends on what is currently running on the desktops. Most organizations will find that they have a variety of desktops to address. In the most extreme cases, fixed function terminals are replaced by PCs or network computers. In other cases, the project requires the actual replacement or upgrade of the existing terminal emulation software with similar software that supports TCP/IP. However, more commonly organizations "simply" need to reconfigure the existing emulators, which are often capable of supporting both SNA and TCP/IP connections to the host, to utilize a TCP/IP connection.

The final and ultimate step is to deploy Web-to-host solutions where possible. These solutions could be Java equivalents of the current emulators, providing seasoned users with the familiar "green-on-black" user interface. Or the solutions could provide a totally new, Web-style interface to the legacy applications.

Products Deployed

The centerpieces of desktop consolidation projects are the desktop and the gateways with which they communicate. Terminal emulation is, by definition, a client/server implementation. That is, PCs running terminal emulation software communicate with gateway software (located on a PC server, a router, or the host) using either a proprietary or a standard protocol that is at a higher level than the TCP/IP transport. These gateways then communicate directly with the host applications using standard SNA protocols. Most terminal emulators offer multiple choices of gateway connectivity. The common proprietary-over-TCP/IP protocols are those supported by Novell NetWare for SAA, IBM SecureWays Communications Server for NT, and Microsoft SNA Server. The only standard TCP/IP-based protocols for communication to mainframe and midrange systems are TN3270(E) and TN5250, respectively.

Most organizations are choosing to implement TN3270 and TN5250 because they are standards and they set the stage for Web-to-host solutions. The products that are deployed in a desktop consolidation project are primarily the desktop devices, desktop software, and possibly new gateway servers. Other products that may be considered for deployment are additional load balancing domain name servers, firewalls, and other security devices.

Business Case Elements

On the benefit side of the ROI equation for desktop consolidation are the reduction of software maintenance fees; the avoidance of new software, equipment, and upgrades; and the reduction in personnel costs related to managing and maintaining the desktops. On the cost side of the equation are the new software and equipment, and the personnel costs to plan, test, and deploy the new infrastructure.

Reduction in Software Maintenance Fees

Software maintenance is charged annually and is usually equal to about 15 percent of the published list price for the software. Because TCP/IP-only emulators are usually half the price or less of full-blown SNA emulators, the recurring software maintenance fees can be reduced as well. Calculate the net reduction in maintenance fees.

Software and Equipment Savings

Calculate the investment in new software purchases that can be avoided because of the desktop consolidation project. Include both emulator software and new gateway purchases. Next, add the avoided investment in software upgrades, both upgrades at the desktop and to gateway software. Finally, calculate the investment that will be avoided in PC servers to run the old gateway software.

Rule of Thumb: Full-stack SNA emulators from the leading vendors have a U.S. list price of $400 to $500 per end user. Traditional PC server-based LAN gateways have a U.S. list price of $20 to $65 per end user for software only.

Personnel Savings

Calculate the total first- and second-year savings related to the project. For migrations from SNA emulators to TCP/IP emulators, this savings will be related to the reduction of a second protocol stack. For migration to Java-based Web-to-host solutions, Gartner Group estimates that savings will be in the range of 60 percent when compared to traditional emulators because of reduced technical support and especially reduced administration.

Equipment Costs

Calculate the total investment in new desktop devices. Next, add in the total emulation software costs, new gateway hardware and software, new infrastructure devices such as DNSs or firewalls, and network management and other costs.

Rule of Thumb: TCP/IP-only versions of "fat client" emulators typically are much less expensive than the full SNA versions; the average U.S. list price for a TCP/IP emulator is approximately $200 per user. Web-to-host solutions are usually priced on a per-concurrent user or per-concurrent session basis, offering potentially substantial reduction in the number of users licensed. Most Web-to-host solutions are priced at $100 to $200 per concurrent user per session. TN3270 servers can cost as little as $3 per concurrent session.

Personnel Costs

A desktop consolidation project can be expensive in terms of personnel costs if software needs to be manually installed on each desktop. Java-based Web-to-host solutions drastically reduce this effort. Calculate the training and design, planning, and product selection costs. Next, add the testing and deployment costs.

ROI Model

Table 4 demonstrates a simplified model for calculating the ROI for desktop consolidation.

Case Study

To illustrate the business case elements in a real-world situation, this section summarizes an integration project that a Cisco customer, a large information technology service provider, underwent. Because sensitive financial information is discussed, the name of the customer is withheld.

The firm is one of Central Europe's largest information technology service providers for the finance industry. With thousands of network connections servicing remote bank locations, the company needed a reliable solution that would guarantee access to the financial sector's mission-critical SNA applications while improving transaction times. Cisco SNASw EE was the logical choice.

Along with common computing services such as system management and production control, the company also provides planning, management, and support of the LAN and WAN infrastructure; extensive banking telephony; and growing internal Internet Service Provider (ISP) operations for its client banks. Computer operations are distributed across three separate production data centers with more than 12,000 km of dedicated dark fiber cable connecting the sites. Approximately 15,000 MIPS of S/390 CPU power is required to process the 20 million online banking transactions each day for the clients' businesses.

The service provider's problem was twofold. First, the VTAM limit of 64,000 elements per subarea was too restrictive. Second, the firm was eager to implement Cisco Catalyst 6500 Series switches and the IBM OSA-Express with its Gigabit Ethernet connectivity, but the OSA-Express supported only IP.

The company's network planners devised some challenging criteria for their solution. They needed 100 percent application availability (especially for mission-critical applications based on LU 0, LU 2, LU 3 or LU 6.2), dual homing, and load balancing, and they wanted all hardware up and running with no equipment on standby. Furthermore, it was critical that the same design handle planned or unplanned failures in the network. Finally, they wanted the company's network to be ready for high-speed access (64 Kbps up to 1 Gbps).

The service provider considered other solutions first, such as DLSw+ with Frame Relay RFC1490 as a transport layer for SNA. But that solution transports SNA as is, within a tunnel or isolated using Frame Relay. Because the network planners' focus was SNA Priority, avoiding a single point of failure, and simplification of the network to support only IP transport, they decided the Cisco SNASw EE solution was the logical choice. It had the added advantage of eliminating the central FEPs and accommodating a Gigabit Ethernet interface.

With the support of Cisco experts from around Europe and the United States, the company soon had more than 1000 Cisco routers running SNASw EE. Small branch locations generally use a single SNASw EE-enabled Cisco 2600 Series router. In medium and large branches, two Cisco 2600 or Cisco 3600 Series routers are implemented. They are configured in a way that supports load balancing and redundancy, providing the branch with continuous connectivity and optimal performance. The production data centers and some large branch locations have replaced the FEPs and eliminated the 64,000 VTAM element limit by using SNASw EE-enabled Cisco 7206VXR routers.

Figure 14 Large Service Provider's Integrated Network

The service provider's two major clients use different versions of the SNASw EE solution. One uses the decentralized version, with SNASw EE at the branch level. Another uses the centralized version with Microsoft SNA Servers at the branch level transporting SNA over IP. In the production data center, a second Microsoft SNA Server translates this SNA over IP back into native SNA. The service provider uses SNASw EE to send this SNA into the IBM host. Because network experts at the service provider consider the decentralized version to be more powerful, they have an ongoing project to convert all branches to SNASw EE and save hardware and software costs by removing the central Microsoft SNA Servers.

Today, there are more 1200 SNASw EE-enabled Cisco routers across the company's branches and the next phase of the project, replacing SNI with SNASw EE and EBN, is well underway. According to a spokesman for the company, substantial dollar cost savings were neither the goal nor the outcome of the project. Nevertheless, the results have been astonishing: the faster, simpler, and more reliable network has resulted in improvements to typical banking transaction response times of up to 20 percent. This company is quite typical of many Cisco customers worldwide and is among those reaping the benefits of moving to a TCP/IP network, accommodating SNA and providing its users with a redundant, high-speed backbone.

Conclusion

Enterprise networks today look nothing like they did a decade ago. Based on SNA, the enterprise networks of a decade ago were hierarchical and, except for SNI connections to close business partners, were available to users within the enterprise only. The network was tuned to provide consistent response times to thousands of transaction-oriented end users. Network changes, additions, and deletions had to be predefined and preconfigured.

Today's enterprise networks are becoming a key delivery mechanism for business. No longer a utility, corporate intranets, VPNs, and Internet business solutions enable the corporation or entity to reach beyond its own borders to deliver products and services directly to the end customer or integrate business processes with partners and suppliers, thereby increasing productivity and profit. The TCP/IP protocol and products on which this network is based provide a self-healing and adaptive infrastructure, capable of delivering very high bandwidth, security, and QoS.

Recent developments in IBM's SNA product lineup heighten the need to protect mission-critical SNA applications and devices. This argument, coupled with the cost and technological advantages of TCP/IP, is too compelling to ignore. But organizations do not need to go through a drastic cut-over from the legacy network to the new one. Products exist to allow a stepwise migration, enabling each organization to determine the speed at which it is able to change. Cisco is at the forefront as the market leader in providing rock-solid solutions to integrate SNA a