Matt's Real Estate Tech Blog

RESO Standards Let MLSs Take Control in a New Way

For the past few months I’ve been a bit quieter than usual on the blog because I’ve been working on a number of time-consuming projects including MLS regionalization, MLS selection, strategic planning sessions, and information security audits. But one very interesting project that has been taking some of my time has been an opportunity to work toward a standard for expressing business rules inside RETS. The focus so far has been mostly on listing input business rules, but that focus could expand in the future. This project should be of interest to every MLS, and I strongly encourage MLSs to participate in the ongoing process at RESO.

I first submitted the value proposition for this effort to RESO as part of a business case worksheet back in April of 2010: “MLSs with well documented business rules can more efficiently and smoothly move to a new MLS system, add additional front ends with full functionality or integrate other software that requires use of business rules – without manual work and often inaccurate results. This will result in smoother conversions, more software choice, and enhanced competition and innovation.”  At that point it wasn’t prioritized but in late 2015 I was asked by the RESO Research and Development work group chair, Greg Moore, to lead the charge to come up with a standard for expressing business rules inside RETS.

As part of the process, I gathered knowledge to attack the problem by visiting with a number of MLSs. During that process, sometimes I saw things that made it even more clear how urgent it is to succeed in creating a standard – one that can be understood by MLS staff and not just technical people – and getting it adopted. For example:

• At several MLSs, when I unpacked what their vendor had ‘coded’ as their listing input business rules into plain English, we found implementation errors. “That’s not how our rule is supposed to work,” became a common refrain during several of my visits.
• At one MLS, I saw a ‘botched’ calculated ?eld that had been that way for years, simply because no one – not an analyst or an MLS staff person – could review the programmer’s work, looking at it in terms of the business rule that drove the calculation.

Also, because there’s no common way of expressing these rules, it’s hard for MLSs to talk about them, establish best practices, and discuss key differences in how data is validated during regionalization discussions.

Right now, the effort to come up with a standard for expressing business rules inside RETS is a work in progress, but it is moving quickly. So far, the group has agreed to continue down the path of using a well-established business rule language called RuleSpeak and developing a short-hand for the rules expressed in RuleSpeak in what we call REBR (Real Estate Business Rules) Notation. The RuleSpeak structured English notation is perfect for clearly and unambiguously expressing business rules, even complex ones, in non-technical language using business vocabulary. Expressions that MLS non-technical staff can read and validate are the single source of truth when it comes to business rules. Everything else is mediated by someone who is not the business owner, so errors can happen along the way. Following are just a few common RuleSpeak examples. Note that most examples use RETS Data Dictionary names for fields – but I could just as easily have used more user-friendly MLS field labels.

• An Expired Listing must accept user input up to 15 days after Expiration Date.
• A Closed Listing must not accept user input. Enforcement: MLS Staff may override this. Data field GarageSpaces must have a value if GarageYN has a value of “Y”. ListingContractDate must be on or before today’s date.
• YearBuilt must be on or after 1700.
• ParkingTotal must be greater than or equal to the value of RentedParkingSpaces ListPrice must be greater than or equal to 1, and less than or equal to 50,000,000
• Status of an Active Listing of Residential Property Type may only change to one of the following:“Active”, “Cancelled”, “Extended”, “Under Agreement”, “Temporarily Withdrawn”. Enforcement: MLS Staff may override.
•  Listing Status must be set to Expired on the Expiration Date if Current Listing Status is not Expired, Pending, Sold, or Leased.

The REBR Notation mentioned earlier divides all the MLS rules into about a dozen basic syntaxes and, with the documentation we’re working on, it should be easy for MLSs (and their vendors) to articulate the business rules and end up with rules that both people and computers can easily understand – rules that are not specific to one MLS system implementation and that would be documentation of the MLS organization’s intellectual property going forward.

Following is an example of a rule in both RuleSpeak and REBR Notation:

 

Rule stated in RuleSpeak “Structured English”	Same Rule using REBR Notation
An Expired Listing must accept user input up to 15 days after Expiration Date.	ALLOW_EDIT LISTING YES IF ListingStatus is Expired AND TODAY = ONORBEFORE (Expiration Date + 15 DAYS) ENDIF

  
None of this language is finalized yet: this is just research happening inside a business rules sub-group of the RESO Research & Development (R&D) group – but hopefully readers will see how valuable all of this can be to them and we’ll see more participation in this part of RESO. If you want to get involved in the group, please email Jeremy Crawford  and ask to be added to the business rules group. If you already belong to RESO, whether or not you are in the work group, you can just log into the RESO collaboration system and get involved with the discussions there too.