You may already know that SLOPE is a SaaS application. SaaS stands for “software as a service”, and it’s a type of software that differs from “software as a product”.
To help actuaries understand some of the potential uses of SaaS applications, we’re going to dive into this topic over a series of blog articles.
We’ll discuss what SaaS applications mean for actuaries as end users, whether that is for actuarial modeling, analytics, process flow, and even data storage.
And we’ll also give some principles of SaaS development that actuaries can apply to their own modeling practices such that the end users of actuarial models receive a better output.
In order to do that, though, we need to ensure that everyone has a set of common definitions. There are a lot of terms that end up in conversation with SaaS vendors, users, regulators, and even the bystanding public. Terms like “hosted”, “agile”, “sprints”, and “functionality” that might not be common in the actuarial dictionary, but should be.
Especially in a rapidly changing modern world in which not only the actuary but every business professional is now becoming data-driven, technology-adept, and forward-thinking.
This first article will set the groundwork for what’s to come by defining the dimensions we’re going to talk about in future articles.
With that, let’s get to it. We see three major dimensions of SaaS principles that should be considered.
What is it?
The first distinction we want to make is between the different types of software delivery methods: software as a Service (SaaS) and software as a Product
Traditionally, software was a Product. The software vendor produced a thing, and you bought the thing, and it was the responsibility of you, the user, to take care of the thing afterwards. It used to be that you bought a disk and installed that software on your local machine. A classic example is the Windows operating system. You may remember some big hullabaloos around releases of Windows 95, Windows Vista, and so on.
Whenever the vendor makes a new version of a software as a Product, users have to choose to upgrade in order to take advantage of any new functionality. This adds extra steps, and can lead to disconnect between what version users are actually using and what the vendor wants to maintain.
With SaaS, however, the software vendor takes on responsibility to push new features out to the end-user automatically. The vendor is also maintaining version control and ensuring things like backward compatibility with prior outputs from the system (such as spreadsheets).
This often happens in the background, without users noticing. An example is your iPad’s operating system (we’re a little behind, ours is still on version 12.something) or your phone’s messaging app or a downloaded game. When there is a new feature, or a fix to a bug, It just updates, and you get new features without doing anything.
Other non-actuarial examples you might have heard of are Salesforce (for customer relationship management) and Monday.com (for project management).
There are obviously tradeoffs between these two ways of delivering software, so the first post will be about pros and cons of these two methods, and the second will be about how actuaries can apply SaaS principles to their actuarial models.
[Don’t worry, we’ll come back and put in the links as we post articles. In fact, here’s the first one – Work Better: How SaaS Benefits Actuaries]
Where it is
The next dimension is where you access the software, whether it’s hosted or on-premises.
When you have on-premises software, you as the local user have the thing in your control.
It used to be that you bought a copy of the most recent version at Radio Shack and went home to “install” it on your machine. The modern example is that you have downloaded the newest version of Minecraft to your laptop because your 15-year-old can’t access it on his crappy older model. This happens generally because you’re too cheap to pay for the memory upgrade. [Wait, is that just us? TMI. Oops.]
In this situation, you are responsible for keeping up with the software and maintenance of whatever hardware is used to access the software.
The alternative is a hosted solution, in which the vendor “hosts” the platform for you, so you don’t have to maintain the hardware that supports it. This could be from a “cloud” provider (like Amazon or Microsoft’s Azure cloud), or it could be a specific bank of computing power that you build yourself and is behind some kind of firewall, sealed off from the screaming hordes out where there be monsters.
Either way, the software host takes care of the stuff underneath the hood, so to speak, and all you as the user have to do is just get behind the wheel and drive.
Generally, with hosted solutions, you access them through some additional interface. It might be proprietary and by the vendor or it might be a commercial web browser. Way back when it was a mainframe computer that was the central unit where all the good stuff happened, and users accessed it through a terminal at their workstation.
Either way, though, the end users don’t have the added headache of making sure their stuff works on top of actually using it for the things it’s supposed to do.
Typically, SaaS is a hosted solution as well, as it makes a lot of sense to combine the two dimensions.
How it’s made
Finally, the last dimension that often comes up is the difference between agile and waterfall methods of developing that software. These terms aren’t completely segregated, but they can get thrown around and sometimes people use terms that don’t really apply.
Traditionally, software has been developed using a waterfall methodology, in which certain requirements are defined at the beginning of the project. The amount of work to complete those requirements is estimated, work is done, and then it’s signed off as finished. This requires a lot of understanding up-front about what the final use-case is going to be for that solution.
It’s often called a waterfall because there is a lot of linearity in the way it progresses. Step #1 has to happen before Step #2 can begin. This is like a series of interconnected waterfalls, leading from the requirements to the final output.
More agile methods of software development, regardless of the specific name they go by [Lean Software Development, Extreme Programming, or Feature Driven Development, for example] will be more flexible in their process. They often include much shorter rounds of gathering requirements, development, testing, and feedback. The whole point is to deliver working software sooner and refine with end-user feedback earlier in the process.
One term you’ll often hear when talking with agile developers is the idea of sprints. These shorter rounds of development and feedback last from 2 to 8 weeks, and usually have a very regular cadence. There is often a lot of structure within a sprint, with a recalibration to the ultimate end goal after each one.
Short sprints like this allow for much faster feedback and quick correction if unanticipated errors come up.
What about us?
Just to be clear, SLOPE is:
Software as a Service, fully hosted, and developed according to agile methodologies.
We’ll get deeper into the pros and cons of each of these dimensions as we go along this series. Suffice it to say, there’s a lot here that’s applicable to actuaries, especially modern actuaries doing modern actuarial work.
The advent of the internet of things, more affordable hardware (servers and storage), and ever-accelerating growth in computing power mean that actuaries now have many more options than they did even five years ago.
And the pace of change is only projected to continue. There will be new technologies in five years that don’t exist today, that will be offering advantages to those who are willing to be early adopters and take a few risks.
There are plenty of pros and cons of each of these dimensions, and as such, each is worthy of its own post. Therefore we’re going to stop here and just say that we’re hopeful you’ll come along for the ride to understand how SaaS principles can benefit you as an actuary.
And how you can apply them to your own actuarial work product, to deliver better results.
Be well!
For your reference, here’s a list of terms we’ve defined above. We’ll also come back regularly as we introduce new terms in later articles and add them for a comprehensive glossary of terms
Definitions
Computing structure
Hardware – the hard, physical things of computers. Servers, processors, network cables, routers, laptops, disk drives, thumb drives, keyboards, etc.
Software – the stuff that runs on hardware and produces output results.
Types of software delivery
Software as a Product – The software itself is the product and requires end-users to maintain the product for any new functionality.
Software as a Service (SaaS) – The software incorporates new functionality automatically so that users simply use the service, without having to maintain it as well
Locations
Hosted – software is stored at a central location (usually maintained by the vendor) and end users access it remotely
On-premises – software is stored and maintained at the end-user’s location
Software Development Types
Agile – requirements, development, testing, and feedback are completed in short, iterative cycles
Waterfall – all requirements are defined at the beginning, then all work is scoped and completed in a linear fashion
Software Development Terms
Environments – the different “editions” of the software, which may have different functionality, permissions, etc.; traditionally these are “development”, “test”, and “production”
Functionality – what the software is supposed to do
Requirements – how the functionality will be created
Sprints – short periods of time in which small amounts of development are completed and delivered to users; many sprints make up a whole project
UI/UX – User Interface or User eXperience – how the end-user will interact with the thing and what they are supposed to think and feel while doing so