Standing on the shoulders of giants

Actuarial applications are mostly written by actuaries and most of them are not giants, right? In addition, most of them would not appreciate having users standing on their shoulders. So what does it mean that PillarOne's architecture follows a „standing on the shoulders of giants“ approach?

Most users' interest in actuarial software is the actuarial / business content. But, counting the amount of code, this is a small fraction of the total application code. Larger systems are typically split into three parts:

• Application logic (which includes the user interface)

• Business logic (the actuarial methods and algorithms)

• Application infrastructure

Let's for the moment pretend that the application logic consists only of the graphical user interface. PillarOne uses a Java-Swing-based view technology; not pure Swing. In another blog I will explain some of the advantages of PillarOne's choice of view technology. All applications use some libraries for the GUI and these are usually massive libraries. So everybody seems to use this sort of a giant.

If applications are designed from ground up by business experts and not software engineers, then the typical weak spot is the application infrastructure.

• The first potential mistake is that the business logic is not really separated from the application infrastructure.

• The second potential mistake is that due to the lack of experience and knowledge about infrastructure components/frameworks, these are partially missing or lacking completely and their function is replaced by self-invented, non-standard bits and pieces.

These two mistakes, which according to my assessment have been made at least partially in currently available commercial actuarial software, makes systems hard to integrate, scale and maintain.

Let's look at each of these issues seperately:

Integration: Almost all insurance companies run some database infrastructure for their various applications. Services around database infrastructure are well organized and tested: access rights, scaling, back-ups, upgrades are just the most prominent ones. So why shouldn't actuarial applications use the same back-end? There is no reason - except that writing the glue code between the object-oriented application and business logic and the relational database is time consuming and error-prone if the code should be independent of the database product. Luckily there is an open source product which provides just this and has become an almost industry standard: Hibernate. In PillarOne we use it to map the object world to the relational database world; noteworthy this works with almost any well-known database product without changing any code.

Integration is also a big issue when it comes to authorization and authentication. Many companies have an infrastructure for authorization and authentication in place. If it is one of the standard products, then PillarOne can be integrated because our application infrastructure is based on a number of components from Grails' application framework. And Grails has plugins for this functionality.

Scaling: Scaling the business logic on multiple servers and the back-end again on different servers might be needed for large models or models with many concurrent users. Embedded in Grails is Spring, the de facto standard of a Java enterprise application stack. Apart from providing the plumbing of the different modules and components, Spring comes with all the bells and whistles to large scale applications on multiple servers.

Maintenance: The giants have their own development and global support teams. Hence, PillarOne can focus on the value-added actuarial and business logic. Yet, if one of the giants gets upgraded, PillarOne also gets upgraded.

So, how big are these giants? Really big. Walk into a bookshop with a sizable IT section and you will find plenty of material; one of them has been written by PillarOne's software architect Dierk König. Well-known IT consultancies build a global network of support services around these products; from training to implementation to maintenance. And finally, according to Ohloh, a group that provides software metrics for open source projects, a very modest estimation of the development cost of the giants included in the PillarOne platform is $20 Mio., not including the ongoing maintenance efforts.

--Markus Stricker