Michael Wurzer 
“And the one system vendor with great longevity and respect in the industry pooh-poohed the idea saying it would never work.”
— Bob Bemis, recalling my reaction to his idea for a new national MLS database back-end
Last year at the NAR MidYear conference in D.C., Bob Bemis asked if I’d be willing to get together to discuss an idea he wanted to bounce off me. I readily agreed as I loved brainstorming ideas with Bob when he was CEO for ARMLS (FBS’s largest customer) and was interested in what he was working on now. When I met with Bob, he was accompanied by Tim Dain, Executive Director of SIRMLS, and Mitch Skinner (MLS attorney extraordinaire).
We chatted for about an hour regarding a topic near and dear to my heart and one discussed here on the FBS Blog for many years now: The Future of the MLS. More specifically, Bob outlined for me much of what he’s now written about at length in a four-part blog post series here, here, here, and here. You should read all four parts but, for convenience, I’ll summarize the core idea as “plug-and-play” MLS, where the MLS would support multiple “front end” systems and offer MLS members more choice and less lock-in.
As Bob mentions in his posts, the idea of plug-and-play MLS isn’t new. What Bob and Tim were proposing was to bring this idea to life by creating a new national database back-end (and relevant APIs), and they were looking for vendors (like FBS) who might be interested in writing front-end software to this new back-end. In part 3 of his series, Bob recalled that I “pooh-poohed the idea saying it would never work.” I can understand how Bob reached that conclusion from our conversation, because I did say FBS wasn’t willing to commit at that time, but I think it’s important to the overall discussion to lay out my response in a bit more detail, so that’s what I’m going to do here.
First and foremost, my recommendation was that the best way to get industry-wide cooperation on writing software to a common API was through RESO, which was then and still is making great strides in moving industry standards forward both with the Data Dictionary and the new Web API. When Bob described their desire to set up a new national database, I thought one of two things would be true from such an effort:
- To deliver the game-changing evolution they’re seeking, the new organization would need to build a critical mass of customers and developers, thereby becoming the de facto standard, which is what RESO was already busy doing; or
- The new MLS offering would be just another vendor offering among the many of us already competing in the market for MLS software.
If the first was true, then I didn’t know why this new effort was needed when RESO was already well along the path of building consensus around the data dictionary and the new Web API. If, on the other hand, the new effort was just another MLS system, re-writing our software to work with their back-end wasn’t compelling until they reached critical mass, which would be a long time, if ever. This is likely the point where Bob concluded that I was pooh-poohing the idea and saying it would never work, but really what I was saying was that RESO was already trying to build consensus and create the standards, innovation, and competition among vendors they were seeking and so their support of that effort seemed like the best approach rather than creating yet another MLS system.
Of course, all of that could have just been me being a competitor in the space and looking out for our own self-interest, but I don’t think so. First, I am on the RESO Board of Directors and believe strongly in the long-term strategies and benefits of standards in our industry. There is no question that the implementation of the Data Dictionary over the coming year will provide incredible benefits to the industry as a whole and for many years to come. Similarly, having a modern API will be very helpful as well. All of these issues RESO is already working on will increase innovation, lower costs, and provide broker, agents, and real estate customers more choice, largely fulfilling the vision outlined in Bob’s four-part series.
However, let’s dig in a bit more on that vision, because I think there’s some reality-checking that’s important here. The proposal is that RPR will create some APIs (presumably RESO-standard APIs) that other vendors will then use to write front-end software. As Bob writes in part four, the vision is:
“For vendors, new markets will open into which they can sell their products and services. Gone will be the closed monolithic system where only the primary vendor in a market was permitted to offer services. With some slight modifications to conform to the data and schema standards and to use the APIs for access, the CMA module from an FBS system, the farming system developed by Paragon, the CRM system developed by Stratus, the prospecting and lead management system in Matrix all could run just fine on the new, open and accessible database. Third party, non-MLS system vendors would no longer be challenged to write new code for every MLS system that comes along or convert their products when the MLS changes system vendors. The database would be the same across all systems.”
I’d like to challenge two parts of this vision:
First, though improvements can be made through more and better standards (see above), MLS systems of today generally are not closed. In fact, most MLS systems, including ours, integrate any and every product the MLS desires. Want a different CMA? No problem, choose from Cloud CMA, Toolkit, Top Producer, etc. Public records system? No problem, choose from CRS, RPR, Monsoon (Arizona), MMT (Florida), Realist, RPR, and likely soon Zillow or others. IDX vendors? Dozens and dozens of choices. Want a native mobile app? Check out Mobile Realty Apps, Goomzee, Homesnap, Flexmls, and likely many others. So, this old mantra that there’s a dearth of products or competition in the real estate tech space is overblown at best and deceptive at worst. To be clear, will data standards and better APIs reduce some of the complexity and cost involved in developing real estate software? Sure. But I don’t think there’s a revolution or even much of an evolution that’s going to happen there, no matter who hosts the back-end MLS database.
Second, re-writing a front-end to work against a different back-end is no “slight modification” to the software. Even the best architected systems, using all the latest MVC and object-oriented frameworks to ensure proper code re-use and reduced coupling of the back and front-end requires a LOT of work to re-write. Put simply, plug-and-play here is just a myth and the likelihood of FBS’s CMA and Paragon or Stratus’ CRM plugging into the same system are little to none, because re-writing those systems to work on some new back-end is not practical.
What is practical is what happens every day in the MLS world: The data gets replicated from the MLS RETS server to the third-party software server so that the third-party software can do its thing on its own copy of the database. There are many reasons replication is necessary, here are just a few:
- To differentiate their offering, IDX vendors want to supplement the data with demographics, etc., and yet they need the data in the same database for efficient queries;
- Broker portals and sites like Zillow or Realtor.com simply won’t contemplate having their systems and company performance dependent on something they don’t control;
- Vendors doing statistical and other analyses need local copies to do their thing;
- The many, many vendors who have already written their systems to work against a local copy of the database have little to no incentive to re-write their systems against a new API; and
- Many, many other reasons.
The point simply is that replication of the MLS database is the overwhelmingly dominant method of writing third-party software today, there are many good reasons for that, and the practical reality is that isn’t going to change anytime soon.
If you want proof of this proposition, let’s look at the poster-child for the plug-and-play vision, Cloud CMA. Cloud CMA is one of the few apps in the industry today that doesn’t replicate data to power its solution. However, when Dan Woolley set out to build their latest project, Cloud Streams, they quickly concluded the only way to do that was to have a local copy of the database. Once they had that local copy, a brain-storming session they had raised the possibility of building a lightweight MLS front-end, but that project was built on the replica, it wasn’t hitting an API. From conversations with Dan, I know he’d love for Cloud MLX to work as a front-end for every MLS system, but my guess is that, to do that, they’ll need to replicate, even if there were awesome APIs available today. (See below regarding innovation.)
I know many in the industry have a vision for forcing all third-parties to use an API and ending replication, but I’d suggest that isn’t practical and should not be a strategic focus. Without a doubt, new vendors just getting started writing software will find all sorts of interesting and creative uses for well-designed APIs and standardized data sets from MLSs. RESO is dead-right in focusing on those issues, especially standardized data. There may even come a time when the new APIs become the pre-dominant method of creating new products and delivering software, but I doubt it, and, even though this post already is really long, I want to explain why as I believe the answer is central to the innovation (and evolution) question at the heart of Bemis’ four-part series (as well as the recent missives from Rob Hahn on the same topic).
Innovation and competition go hand-in-hand. At the heart of competition is differentiation. You compete by offering something different and hopefully better than your competitors. In the real estate software world, that might mean better data, better user-interface, better service, or better ideas. When you want to innovate and compete, that often means you need an API service that allows that and, frankly, it means you need that API service to be different than it is today. This need is a weakness in both the “one backend to rule them all” approach being urged with RPR-MLS as well as with RESO. The practical reality is that an API from a single source will never be able to innovate fast enough to support all competitors and so those competitors will need to create their own APIs.
I’ve written before that this very reason is or should be a death-knell to the idea of a monopolistic back-end MLS, as it will surely squash innovation and competition instead of creating it. A more important and less obvious question, however, is what does this need for differentiation say about RESO and the attempt to create standards? Does that effort also hurt innovation? My answer is no.
The only way standards would hurt innovation and competition would be if they somehow were seen as a pre-requisite to new development. The reality, however, is that standards, when developed properly, are a reflection of best practices among existing competitors that lower costs and friction for others. Sometimes the “standard” is a de facto standard because one vendor has prevailed but, in the case of real estate software, the standards process is a cooperative effort among competitors. The objective is to reduce barriers (and costs) wherever possible, not to dictate how competitors implement their solutions.
This is why RESO has been and continues to be so focused on getting data standards implemented. Data standards are the foundation for any other standard, such as saved searches, which will open the door to easier vendor conversions, more integrations and data transportability. Without standard data, the costs of implementing software in the real estate industry will be higher than they need to be and time to market will be longer for existing and new solutions. With standard data, solutions will be less expensive and faster to implement. Those are the objectives outlined by Bob Bemis, Rob Hahn, and now RPR-MLS, and it is for that reason I urged Bob to focus on RESO instead of creating yet another MLS vendor.
With all that being said, I welcome RPR-MLS to our MLS vendor competitive landscape and look forward to their first launch. But they are just that, yet another competitor and the real industry-wide evolutionary innovations will continue to be pushed by RESO and supported by all competitors. That’s nothing to pooh-pooh.