The Oasis Loss Modelling Framework (LMF) is a way of dividing up the elements of catastrophe loss modelling into “plug and play” components as shown in the diagram to the right. Oasis isn’t a model or a front-end for users or an output analysis tool. It is instead a calculator that can be communicated with using webservices. The central part, shown in black, is termed the “kernel” as it sits agnostically behind “plug and play sockets” or connectors that relate the external actualised model and business data to the abstract structures used for the calculations.
The technical architecture of the Oasis LMF addresses three key criteria:
- Extensible - being able to cope with a very wide variety of models and business users within the paradigm of event-based loss modelling. It achieves this through the agnostic kernel, variable definition tables (called profiles) and connectors which are pieces of code that transform data into the Oasis agnostic format.
- Scalable - being able to run with a wide range of data sizes, from small coarse-grained models for a few properties right up to high-resolution models with hundreds of thousands of events for millions of properties.
Deployable. This means a couple of things. First, that the software can be readily run in a variety of environments, and second, that it fits into the technology estates of the main users as far as possible. To achieve the first aim of being able to run in a variety of environments, we have gone with an open-source set of components (the LAMP stack – Linux, Apache, MySQL and Python - and Django (a Python project) with most programming in Python). To achieve the second aim, we have adopted “Virtual Machine” solutions (Oracle’s Virtual Box and EMC’s VMWare) which are deployable on a wide variety of platforms as well as native Linux. For databases, many members have SQL expertise and either SQLServer or Netezza infrastructure estates, so we have developed for these two platforms as well as MySQL (as an open source solution as it comes with the LAMP stack). We can deploy other SQL-compliant back-ends as needed, including Hadoop engines, though the Kernel was designed for files not relational databases.
The new version of the Oasis Kernel runs entirely in-memory so the databases are there for persisting data to run and outputs, and can be replaced by file systems