Frameworks are important for ISVs; without them, flexibility is lessened as is meeting changing customer requirements. aKuna is the framework at the heart of uLinga and Infrasoft reaps the benefits!
Everyone should experience building a home, at least once in a lifetime. But having experienced it, and enjoying the process, I am sure I can also add that when it comes to building a home, once is enough. Very quickly homebuilders learn that changes made when the design is on paper, with an eraser, carries little expense, but once framing commences, and the design leaves the architect’s drawings, the expense associated with changes can escalate quickly as “user requirements” are being addressed.
In a previous posting, where I had written about the uLinga product and how the folks from Infrasoft had quickly responded to different customer requirements by adding the support for DLSw, and how this had been made easier because of the investment made ahead of time with the creation of the framework, aKuna.
As Peter Shell told me in a recent email exchange, “TAL and COBOL essentially have no library code aside from a few utility functions that are provided by Guardian, whereas the C runtime library has so much more. Java and C++ however, provide an immense set of libraries, so much so that it is often difficult to decide which to use!”
Unfortunately, for ISVs like Infrasoft, the availability of these libraries for Java and C++, as rich as they are, can prove to be just as problematic as having nothing at all! As Shell was to inform me, “the emphasis of most of the Java and C++ libraries has been on ease of use rather than focusing on performance and, as such, is great for application code. However, for system level code where CPU and / or memory performance is critical, I often find them excessive. No one is writing a device handler, for instance, in Java any time soon!”
As a framework, aKuna is bringing value to Infrasoft by allowing functions required of a new feature to be introduced quickly and with greatly reduced risk, as much of what is required of the new feature has been debugged and tested extensively. What Shell then added was how, from his observations over the years, “my concept of a framework, or whatever we call them in the future, is that of a continuum.”
“Their development doesn’t stop at the simply utility functions, in fact it doesn’t stop at all! In time, everything it turned into libraries where the product is just a bunch of libraries bolted together,” Shell explained. “Because this adds a degree of pressure to really think hard about how to externalize the functionality, you end up with nice clean interfaces, clean design further encouraging code re-use.”
It’s also pretty easy to mix and match functionality while enjoying the benefits from not re-writing code, I suspect.
Today, uLinga is involved in PoCs and the list of requirements continues to grow through the customer exposure. The speed with which the uLinga product developers respond is not because of late hours poring over code listings and banging away at a keyboard, but rather through intelligent “assembling” relevant functionality into the features required.
It reminds me of my experience of building the house. The process may not be as simple as rubbing out the outlines of walls with an eraser or drawing in new ceiling embellishments, but the frameworks that modern software developers produce take the process of solving business problems a lot closer to satisfying changing user requirements than we have ever witnessed before, with far less risk than we could have ever imagined!