Thursday, August 4, 2011

Engineering for longevity [Part 1]!

The problem with frameworks is that “everyone has one” but where there’s a need to modernize, what’s underneath the code can be very important. For new product families, such as uLinga, it’s doubly important …

Readers of my other blogs will be familiar with the Corvette that I routinely take to the track and with the difficulties I have been experiencing of late. The flexibility designed into the car from the very outset ensures that Corvette owners can customize the car in any which way they want, and optimize it for wherever they plan to take the car. And the good news here is that the engineers at GM did a marvelous job of designing a structure where everything about the car can be easily replaced or remolded.

Yes, almost every modern car today has a frame, but what the GM engineers put into the design of the frame of the Corvette supports a rich variety of body shapes including many that come from third parties.

In talking with the development team at Infrasoft, the company behind the uLinga product suite, an alternative to ACI’s ICE and HP’s SNAX products, it’s hard to miss the energy going into the support of frames, for a new company making a fresh start, it’s very encouraging to me that from the very outset considerable thought has gone into the underpinnings of the products being built. You will not find a data sheet, nor will there be a manual you can reference, but the framework that supports uLinga is called aKuna.

This is another Australian aboriginal word with several translations including “flowing water” and perhaps more importantly, “the way forward”. Readers may recall that I touched on this topic late last year in the post of December 18th, 2010 “It's OK - we are being framed!” and where Infrasoft Managing Director, Peter Shell, described aKuna more succinctly when he said that the “concept of a framework, or whatever we call them in the future, is that of a continuum.” The way forward, indeed!

“Frameworks are like our navels, everybody has one,” suggested Infrasoft CTO, Neil Coleman, before adding “and a lot of people may actually think ‘so what’ while others may simply ask ‘why bother, just use something already out there.’” True, almost every modern software product developed today relies on frameworks of one sort or another, but what the Infrasoft engineers designed into the aKuna framework now supports an increasingly richer number of feature combinations.

Infrasoft distributor comForte has developed many products for the NonStop server and while they address different business issues, “you will still find code that is shared among nearly all of the products,” according to comForte CTO Thomas Burg. “I think the amount of code re-usage between different products of the same company will correlate highly with the efficiency of the company – and that should translate directly to competitiveness and quality of the products.”

There’s rarely any discussion about frameworks, however outside of a close-knit community of hard-core developers, many in business are oblivious of the frameworks presence and totally unaware of the value they provide. Yet the strength and durability of any car we drive today is only as good as the frame supporting it; software products are no different! For many developers, simply adopting one of a growing number of standard frameworks may be the right approach and for developers’ fresh out of college and new to the industry, they represent an attractive alternative.

“aKuna is not NonStop-centric and great care has been taken to specifically make it inclusive of other OSs. aKuna provides a large array of commonly required services, which all sit on top of an OS-abstraction interface,” Infrasoft head of R&D, David Finnie explained, and digging a little deeper, added “there is certainly OS-specific functionality in aKuna that are obviously only activated when running on that particular OS – checkpoint and backup takeover for NonStop deployments being one example.”

If you could visualize a framework as a simple cube with the top surface providing interfaces to subsystems and applications while the surface underneath sits as close as possible to the operating system (OS), you begin to see the role that frameworks play. In the case of aKuna, this has led to a framework with the ability to let developers refocus the components that are utilized so that new products can be rapidly created. Not that aKuna represents all the code that is uLinga and each product within the uLinga family is just a different configuration of aKuna, but rather aKuna is at the heart of each uLinga product and represents the core of its code.

When the uLinga family was first conceived, the focus was on helping move off legacy SNA networking protocols and onto modern TCP/IP networks, but the early prospects wanted an alternative solution, the DLSw, that traditionally would have involved the development of a substantial body of code. However, with aKuna, the new uLinga for DLSw was ready for first trials in a matter of months.

And the upside is that with uLinga for DLSw now in production, the large part of the uLinga code, which is aKuna, is in production as well. A small point but far from trivial! Prospects now pursuing Proof of Concept’s (PoC’s) of uLinga for CICS and uLinga for IMS are a lot more comfortable being assured of the product’s quality and stability, knowing that the heart of uLinga is alive and beating very strongly. The visible flexibility of uLinga can be traced back to the inherent flexibility of the aKuna framework.

It’s as if the top of my imaginary cube, the face that it presents to us if we look down on it, are simply being rearranged, Rubik’s-cube like, to support each new product – a series of red squares for DLSw, and a series of green squares for CICS, and so on! I will leave for a later post the flexibility inherent with the easily changed colors on the bottom as the ability to do this opens the door for uLinga packages of the future to run on different OSs – a circumstance that some vendors are quickly recognizing.

You rarely see the chassis of a car and you rarely stop to consider the chassis within a software product. But with all the emphasis being places on modernization, shouldn’t we all be a tad concerned about products we run with frameworks decades old? Business managers may not be aware of the significance of frameworks today but as we push deeper into modernization initiatives, it’s probably a very good time to check with your vendors just how ancient the framework is and move onto something more robust!

No comments:

Post a Comment