Thursday, July 15, 2010

Tear down this silo!

Transformation occurs in many different ways and is woven into much that intrudes on our lives. We are constantly bombarded with messages about the need for us to change our car, try a different restaurant, use a new tool – all directed at us with the expectation that items in our possession or we ourselves will be transformed. Usually, to something a lot better, perhaps more attractive, and often with the thought or expectation that we will derive some benefit as a result.

Wouldn’t it be nice to be able to push a few buttons and watch our servers, for instance, all transform into something more powerful and more flexible? Wouldn’t our capacity to support the business become so much easier if we could simply reconfigure the servers inside our computer rooms to be less memory-bound, have greater storage, and be simply more powerful whenever the business saw an attractive marketplace opportunity?

Once you get past the concept of convergence that has become central to HP’s marketing messages of late, then you bump into another theme strongly advocating transformation. In other words, dismantling the silos (e.g. servers, storage, networking, security, manageability) that have been created over many decades, and converging on a much smaller selection of infrastructure and middleware that embraces all of the applications and platforms utilized, will transform the way businesses pursue new marketplace opportunities. Legacy platforms and proprietary architectures will be gone from the computer rooms that emerge with pursuing convergence and transformation.

Of the key infrastructure architectures, perhaps no other “silo” has the potential to hold back the modernization, central to both convergence and transformation, than networking. After all, networks have been sustained for more than four decades and for many inside the computer room, there’s a lot of damage that can be sustained from “messing with the network!” Furthermore, proprietary networking architectures, like IBM’s SNA, continue to connect IBM’s proprietary mainframes with each other and with other platforms needing access to the data under the management of these mainframes. Replacing these networks has called for expertise not only in networking, but in the applications dependent on these network connections as well.

Surely, moving from IBM’s SNA to TCP/IP can’t really be all that hard! Build a small, raw sockets process and let it map between SNA and TCP/IP? “You would be surprised how many times this comes up when talking to prospects,” remarked Peter Shell, Managing Director of Infrasoft Pty Limited. Infrasoft has just reached Proof-of-Concept stage for their latest networking product, uLinga, and for more information, check out the December, 2009 post to Real Time View - Widening my options? Shell then talked of how “good programmers are telling me how easy it’s been to write a prototype that gets most of the job done! But who is going to support an in-house developed feature when it breaks or when IBM provides an updated release? What happens when the developer leaves the company which today is happening regularly?”

IBM comprehends the difficulty users will experience and is now packaging IMS Connect with IMS that provides such a mapping capability and more recently, has provided IP interconnectivity (IPIC) for CICS users. These new features allow SNA networks to be easily transformed into TCP/IP networks. “With our new uLinga for IMS and uLinga for CICS products, we have implemented the equivalent features on NonStop,” Shell noted before adding, “in most situations, we have removed the need to make any changes to the application code.”

Programmers developing their own sockets process routinely overlook the added complexity that comes with taking responsibility for the message handling associated with the traffic now flowing over the TCP/IP link, as well as the message authentication. To retain performance levels similar to those of past networks, support for multiple concurrent transactions is usually required and this makes it necessary for the programmer to deploy multiple connections, which in turn calls for the implementation of a workload manager.

Coordinating the traffic flowing across multiple connections is not something readily supported by open solutions and requires careful design. On this subject, Shell remarked “yes, they can go down this path and write a process for the NonStop and the IBM mainframe – but why would you go to all this trouble when IBM has already provided a solution within their key subsystems, CICS and IMS?”

“Now that we have completed the implementation of the first two modules of uLinga and can offer IMS and CICS users a low-risk way to upgrade their networks, by exploiting the new CICS work that mirrors earlier work undertaken by IBM in support of IMS with the IMS Connect product,” Shell suggested before highlighting how “NonStop users can mirror either the CICS or IMS client deployments that those working in the computer room are familiar with and step up to running a more modern infrastructure that is less costly to support.”

comForte is working very closely with Infrasoft to bring the uLinga products to market as part of comForte’s solutions for NonStop server access. All of the products that have been included within this grouping help with modernization - the key component before any business can seriously consider pursuing the kind of transformation HP is championing. “Converge!” and “Transform!” will take a business well down the path towards “Innovation!” the ultimate goal in pursing these undertakings; in the economic climate of today, bringing an end to having to support multiple networking infrastructures offer considerable value for all who elect to pursue this strategy, and to pursue it aggressively.

Transformation can only be achieved, and the silos demolished, when there’s a common networking architecture. Retaining IBM’s proprietary SNA networks runs counter to all that HP is encouraging; with an all-TCP/IP network in place in the computer room, business can reduce infrastructure costs and complexity, all while supporting open standards. Security becomes greatly simplified with a unified network and the skill-sets to manage the environment no longer need to be duplicated in order to support legacy SNA. With uLinga there may be more required than pushing a few buttons, but the element of risk has been significantly reduced and there’s finally a tool now available that transforms the network!


  1. Great blog post, Richard. In answer to a challenge you mention above - NO, moving from SNA to TCP/IP is not that hard - and can be achieved without having to incur the cost of replacing an entire legacy payment system. INETCO has been helping their customers achieve risk-free protocol conversions such as this for over 25 years. Their communication gateway products such as BankLINK and POSway enable customers to deal with the increasing number of transaction protocol variants in a cost effective manner. To learn more, check out:

  2. Thanks for the feedback – always appreciated! Just checked the web site (link provided in comment above) - and there's a good lot of work that’s been done, as you note. Quite impressive! But it was hard to identify which platforms / OS were being supported and checking the partnerships didn't help.

    In looking at HP's strategy I have focused on the NonStop platform - and just on hooking NonStop up with IBM's mainframe, where there's a lot of unique issues to be addressed. Disrupting these links has huge consequences. When it comes to NonStop, gateways (including all-software) have brought with them their own special issues but again, I welcome your feedback.

    As I noted in my post, I particularly like the approach taken by Infrasoft with uLinga as they are implementing IBM’s solution, as a peer, on NonStop and already early performance results are proving impressive and the NonStop customers who are in discussions with them appear to like this implementation. The Infrasoft team is made up of former Insession architects and engineers who were the first to market with an APPN stack on NonStop, so their pedigree speaks volumes to me.

    Again, I think what you have done looks great – I’m just not sure if it applies to payments solutions on NonStop in terms of having their SNA applications communicate with IBM mainframe SNA application over a TCP/IP network.

  3. One comment I would make back here is that although the INETCO solution works perfectly well and solves some of the problem, it still uses SNA (or X.25) for part of the end to end connection. What uLinga does is provide a fully TCP/IP based end to end solution. Makes management and support of the connection so much easier. No need to maintain (or hire) SNA expertise to diagnose issues. The message we are hearing is that customers want to remove SNA entirely from their networks but without having to make application changes.