February 16, 2012

Sunrise’ Rules Engine: Power and Flexibility

by Justin

You’ve heard us mention it…

It has been a busy Winter season for us, and we’ve been cranking out some great new features while we try to keep up with all the new park signups. But I promised in December to continue our technical blog with some details about our business rules engine, and I think it’s high time I do.

If you’ve ever spoken with one of us at one of the industry trade shows, you’ve heard us mention our “powerful business rules engine” at least once. We’re very proud of it. It is a core part of our system and it allows us to fit our software to the specific needs of each Campground. Sometimes, however, when we speak about it we either “geek out” a bit or gloss over it such that the true impact of the technology is lost. Let me try to explain just what all this means to campgrounds…

Fundamental truths and new technologies

A fundamental truth of all software is that it is only as flexible as it is written to be. Seems obvious, right? The question, “Build or Buy?” is based on this truth. Most people can’t afford to build their own software, or don’t know where to start, so “Buy” is the default answer for many, leaving software developers to identify a need and attempt to meet that need as broadly and flexibly as possible. Well, there are many methods we developers use to build flexibility into our software, and most software you use offers some way to alter the behavior of the application to suit the user. But as users, we’ve all experienced the confining frustration of finding the limits of a given piece of software. Like a ill-fitting piece of clothing, we are uncomfortable “wearing” software that just doesn’t fit.

When we set out to build our real-time reservation/campground management software system around our self-service kiosk and wireless utility control platform, we started looking at what software developers call the “problem domain”. That is, what do campgrounds and RV parks need their management software to do? What do they all have in common? What don’t they have in common? These are the questions every other vendor has asked themselves as they’ve built their products. What we identified early on, and it may seem like another no-brainer, is that no two campgrounds are just alike. Sure, many campgrounds operate in similar ways, and it is the overlap that allows us to build the bulk of our software logic to work consistently for all users. But what of the dissimilar ways in which parks operate? How do you address those?

In our case, we built our solution using an advanced software framework known as a Business Rules Management System (or BRMS). BRMS’s are often used in high-availability software systems involving complex financial scenarios often found in banking or insurance. While our needs are perhaps more modest, this demonstrates the power at our disposal. The more important thing, perhaps, is that this technology allows us to individualize the “business rules” of our campgrounds in two key areas, rating and site availability. Using our custom rules engine, then, we can establish an individual “rule set” for a given campground and deploy that rule set into our running application at any time, instantly altering the behavior of these two key areas. The benefits here should be obvious; we don’t need to make changes to our applications’ logic, which further bloat the software and restrict flexibility and future development. And this is why we have such a diverse group of parks using Sunrise — small, unattended parks, to large, multi-campground membership organizations with highly complex business rules.

Of course, the power and flexibility this technology affords us would be mostly useless without also having an expressive and elastic underlying data model. If you hear us talk about a “data model”, what we’re referring to is the way we’ve defined and connected things like “Reservations”, “Invoices”, “Guests”, “Sites”, “Amenities”, “Memberships”, “Vehicles”, etc. And when we describe ours as “expressive”, we’re referring to just how much data we collect for each of these items and how closely each are related. Our expressive data model allows us to define potential “facts” in a given reservation scenario and “grab onto” these facts while processing rates or determining which sites should be made available for booking.

So where do the rules fit in?

Our rating rules are engaged prior to booking a reservation, (to provide a real “estimate”) upon booking a reservation, (to create a new invoice and assess actual charges) and any reservation edits that might influence rating. (extending/shortening stay, adding guests, cancellation, etc.) This functionality is available in both Panorama and SunriseReservations.com, though reservations processed through either can have individual rating rules applied. (ie: assess additional fee for online reservations) Our rating rules handle guest discounts, taxes, weekly/monthly rates, surcharges, etc.

Our site availability rules are engaged whenever a user searches for available sites for potential booking. (but can be bypassed by managers) This acts as a sort of filter, further filtering the list of available sites after availability is first determined by looking at already booked sites for a given search criteria. This allows “available” sites to be further limited by any of the “facts” in a given case. Examples include restricting non-members from booking particular inventory, or limiting the visible online inventory to a percentage of actual available inventory.

Experience bolsters confidence

We like to say that we can make the system do almost anything, and we’ve certainly been tested on that point! Our experience has validated, not shaken, our confidence, however. If you can begin to imagine for yourself how access to information about a guest and their memberships, vehicles, occupancy requirements, previous reservations, preferences, etc. would be useful in determining both their rate and access to site inventory, you may be confident, too. This post could grow indefinitely if I were to provide further examples, so I’ll only mention one more possibility — Yield Management. You may define this in any number of ways, but however you do, the ability to establish rates based on capacity, etc. should be appealing.

I hope this has helped to explain not just how powerful and flexible our rules engine is, but at least a little of how it actually works. If you’re not a Sunrise customer, I hope you see the possibilities of this technology, and contact us to learn more. If you are a Sunrise customer, I hope you’ve gained a greater understanding of the technology you use each day and perhaps sparked an idea or two. We’d love to talk with you about your ideas. We get great satisfaction out of building new rules for parks that can help them be more efficient and in turn, more profitable.