Wednesday, May 23, 2012

Wins! And more wins!

Almost every member of the uLinga product suite is now deployed as the customer take-up grows rapidly. Yes, there are options for NonStop users running ICE and SNAX!

The headlines of a number of recent posts do sum up how the uLinga product suite has been faring.  First there were the wobbly steps being taken by the new infant in the post of October 23, 2011, “
Steps that count!”, that was followed only a few months later, in the post of December 6, 2011, by now a lot more confident, as they begin to run strongly “uLinga! Turning the corner?”. The most recent post, however, gives the first indication that the product suite has gained enough strength to run with the leaders, as it was suggested in the post of April 10, 2012, “ uLinga? Moving into the straight!

In the previous post I wrote of the barbeque held at our home for the America’s sales and support team of comForte, and of how it was hard not to miss the
general enthusiasm this team had as it looked forward to the second half of the business year. And much of this enthusiasm had a lot to do with the customer acceptance of uLinga, following a month of wins.

Perhaps more importantly, the wins are proving to be a positive confirmation following a much earlier decision by comForte executives, seeing that a market opportunity did exist, to provide Infrasoft, the development company behind uLinga with financial support. The seed money for the past year and a half came directly from comForte and with the funding, comForte’s rights to sell into markets worldwide.  Central to what uLinga is providing today is network modernization – a message at the heart of much that HP is telling its own NonStop community.

As a message, modernization is not new. Modernization has been rigorously reinforced with every presentation HP has provided over the past two years. But when it comes to networks and to supporting many of the devices businesses rely upon, there is still a hotchpotch of older technologies in place – the most dominant of these is SNA. And modernization is encouraging change and for many companies, change has been long overdue. 

However, changing applications to modern TCP/IP, while retaining the same functionality (about which, few in a business may really understand) makes little sense. The risks involved are just too large to offset outages that would likely follow. But embracing TCP/IP without impacting the applications – that’s a different proposition entirely!

However, with the uLinga product suite the option exists to make redundant much of the legacy hardware that business has relied on way past their use-by-dates with minimal to no application changes – just tweaks to the configurations. Making uLinga perhaps even more relevant, something the upward count of wins is proving, is its value proposition. The code is completely new, written afresh, and pulling from the collective experiences of developers knowledgeable in SNA and TCP/IP.

Similar products that offer only a part of what uLinga provides today have been in the marketplace a long time, and are now proving extremely difficult to support with their vendors being forced to price above what is acceptable to many businesses. I have been around the software industry a very long time and what has always bothered me is that vendors rarely set aside the funding to ensure a product is completely rewritten every seven to eight years – yes, a decade is way too long.

Patchwork quilts may have their appeal to some within our society, but patchwork code is a cloth with altogether different properties. Inherent properties, that most in the software industry have learnt long ago to walk away from, fully aware of the potential lose – lose disadvantage. Yes, uLinga is winning simply because the value the product provides is higher than what has been in place for too long.

There will be even more wins for uLinga in the near future – the first uLinga for CICS has been deployed and with uLinga for IMS now also available, these two members of the uLinga product suite will likely see more interest – consider being able to transparently access NonStop SQL/MX tables directly out of CICS and IMS applications simply with a configuration change! As the costs of DBAs for DB2 and even IMS is not inconsiderable when compared to how little DBA overhead there is with NS SQL/MX, there may be a marketplace here even greater than simply being able to retire older communications controllers.

There could even be wins when it comes to embracing cloud computing – to many, just as the success of NonStop can be tied back to the ease with which IBM mainframe users could assign responsibility for ATMs, POSs, Kiosks, mobile phones, etc. to NonStop, perhaps too, with what NonStop has done with Pathway of late, IBM mainframe users could assign similar responsibilities for the cloud(s) to NonStop. And that may be an even bigger win than the others.

“No matter how you dissect the success of late for uLinga or to whom you give credit for these successes,” Infrasoft managing director Peter Shell told me as he prepared to go onsite for yet another Proof of Concept, “uLinga is winning.” Perhaps not every step taken will generate immediate responses, but corners are being turned and every sign suggests uLinga has entered the straight. Fortunately, the scope of the opportunities places the finish line a long way down the road and for comForte, that’s a good thing as well. Clearly, there’s room for many more wins in the coming months!


  1. Richard,

    Interesting comment about re-writing applications every seven to eight years. So should we expect to read about the uLinga re-write in 2016? Whilst I am one to espouse the virtues of starting again with 'Hello World' and taking it from there, economic realities would never allow it. Telling your customer's that the next version will be a re-write wont inspire any confidence in the version they currently have.

    And Patchwork quilts? A better notion would be used, tested, and fixed. Years of programming effort ensuring your product works.

    As the following (very old) article suggests, a re-write is potentially the biggest mistake a software company can make.

  2. Somehow, while I understand the intent of this comment, you may have missed the point. For this new company, Infrasoft, made up of some incredibly bright and experienced developers, there was no option other than to start from scratch and with a clean piece of paper. This is the very essence of a market-driven economy - bringing competitive products to market.

    I just happen to think with uLinga and with leveraging the experience of the talent now a part of Infrasoft, the NonStop comunity has an opportutnity to deploy a better product more fully supported.

    The most recent win for uLinga is a replacement for SNAX - and came through cooperation with the HP team ...

    Again, uLinga is not a rewrite - it's a new product family bringing completely new functionality (in support of CICS and IMS) to market with an overall better value proposition that embraces a modern architecture.

    Hope this helps clarify this situation / position.

  3. I'm not the one who posted the original comment, but I think your answer misses the point of the question. I think he was not saying that uLinga had a choice between upgrading existing code vs. new implementation. Theirs is a brand new product, so, of course, they had to write from scratch.

    But I think the point is to question your position that, according to your statement in your seventh paragraph, "... what has always bothered me is that vendors rarely set aside the funding to ensure a product is completely rewritten every seven to eight years – yes, a decade is way too long." He is questioning the wisdom of throwing away good, working code every seven or eight years. I tend to agree with him that that seems unwise.

    Code doesn't spoil overnight, or even over 20 years, if it was written well and not mangled during maintenance. And even somewhat mangled code that has been well-tested often works better than the first few releases of a rewritten product. The time that it is better to rewrite from scratch rather than enhance existing software is when attempts to enhance or fix bugs in the existing code show a high rate of new bugs getting introduced by the changes. Code that was well-written in the first place and gets maintained by highly-skilled programmers (ideally, the original developers) can maintain its viability well past your seven to eight years.

  4. And therein lies my problem - if only all the "ifs" you mention together with the proposition of having good working code. If it is well written ... (if) it is not mangled during maintenance, etc. And the big "if", should (or if) the files, tools and services remain relevant after all this time then yes, fine, I'm OK with code living longer ... but usually all these "ifs" have a hard time being satisfied. Particular should the code change hands over the years due to personnel changes for whatever reason.

    There's no hard and fast rule here and there's no firm timeframe. But all code with time degrades - some faster than others due to the diligence of those charged with its upkeep. But with more eyes looking at code and with more changes and updates made to satisfy changing conditions (and mandates), then yes, there is merit in taking another look at the requirements and redoing. And modernizing at the same time ...

    Just how many applications continue to run that were developed in assembler? The economics may push back on seven years for many and perhaps 25 years really is too far out there but I do contend there are financial incentives for revisiting applications within a decade and capitalizing on the changes that we see occurring within IT.