SNA as a networking protocol is rapidly approaching its end of life, but this fact in no way lessens the importance or viability of these SNA applications or the SNA application programming interfaces (APIs) to which they are written. It also does not extend the elapsed time since Year/2000 when many large investment decisions were made and the technology was expected to be productive for at least a decade. IBM’s Communications Server’s Enterprise Extender support provides the function necessary to transport SNA application flows over IP networks in a highly efficient and effective way. Real consideration must also be given to the placement of your SNA endpoints; alternatives include the branch office, regional center, or data center. We will discuss these topics later in more detail.
The decision is whether or not to scrap these SNA applications that have served so long and so well and develop replacements on IP. During these times of budget tightening and consolidation, it is not a pleasant thought to have to redevelop applications that are already serving reliably in your network. Yet, the aging SNA infrastructure and the need to maintain networking infrastructure currency would appear to force this consideration. Additionally, since parallel SNA and IP networks have proved to be expensive to maintain, it is necessary to consider alternatives for transporting SNA data across your IP networks. These considerations become especially important in light of the eventual end of service for front-end processor (FEP)- based solutions, such as the IBM 3745 or Cisco CIP.
Rewriting an application is a major undertaking, but the considerations surrounding that application may be far more involved and costly in terms of both time and money. The development of any large application is an expensive proposition, but when that application is intertwined with the corporate processes and procedures, that expense can rapidly mushroom. Many existing SNA applications grew with the business they serve, and the business processes and procedures were developed based on the information provided by the applications. Ensuring that no facet of your current business logic is neglected is very challenging. That, coupled with the development of a new application that will ensure the continued interoperation with all the remote operation centers and branches in your corporate network, as well as those of your business partners and suppliers, is indeed a daunting task. The testing and deployment challenges associated with such an undertaking would merit a significant and equally expensive prototyping or staged deployment effort, contributing to the cost of developing replacement applications.
Rewriting an SNA application to IP requires careful planning and an understanding of the differences in the two environments. Many of these applications exploited features such as accounting, billing, diagnostics, and class of service provided with the SNA product set. When moving the application to IP, this functionality must be replaced by multiple offerings. These offerings require coordination on top of IP, and this extends the scope and cost of the redevelopment effort. In some cases, the necessary SNA function does not even exist on IP.
An obvious and significant cost of developing a new application is thorough testing. This is a major financial consideration, but more important and perhaps frightening, is the potential disruption of business operations during early deployment. Time will permit new applications to become as stable and reliable as the SNA applications are today, but the cost over this period is very difficult to estimate, especially when a minute of downtime can cost a corporation more than the total estimate of the development cost.
If the technical and financial requirements of redeveloping SNA applications on IP have been met, the next set of issues to be considered are those that deal more directly with the employees who manage, maintain, and use these new applications.
CONSIDERATIONS FOR THOSE WHO USE AND SUPPORT SNA APPLICATIONS
SNA-based management procedures, which enable operations to quickly recognize a problem has occurred, must be replaced with IP management tools and processes. Many such tools are available today, but they are usually provided as a separate package, which requires routine maintenance and a new set of skills. This requires retraining the operations staff in addition to the cost of the new management product. The cost of the product and development of the new management applications may seem low when compared to the cost of retraining corporate employees who are welltrained on the existing SNA management tools, but will have to start anew with the new tools.
Preparing the operations staff and tools is a significant investment, but that expense pales in comparison to the costs associated with having to change the processes and procedures used by the majority of the company’s employees. Since many such processes and procedures are tied directly to the logs and features available with SNA, this is a very real consideration. Of course, the new applications can be developed to closely imitate their predecessors so that the non-computerized processes and procedures of the corporation do not need to change. But then, you might ask, what has been accomplished by the costly redevelopment of the applications?
If the answer to this question is simply that the applications are now resident on IP networks, and therefore are enabled to take advantage of all the latest networking technology, then there is certainly a better way to accomplish that. If the Jurassic applications are providing the business logic needed to operate and grow your business, then IBM’s Communications Server on z/OS and Linux on zSeries can provide the needed networking support to connect them to your IP networks. This consolidation will not only minimize networking costs but also help avoid new application development and keep IT managers from having to retrain their workforce or losing their systems during an early deployment.