MLS Systems and Gateways, Front, Back, and Middle

Jul 10, 2007 Michael Wurzer

There’s lots of discussion and confusion regarding NAR’s Gateway proposal. Is it an MLS or not? Whoops, there’s the first mistake. What’s an MLS? Clearly, the MLS is more than just the software that tracks the listing data, but the Gateway isn’t concerned with that, so I think it’s safe to qualify the dicsussion to MLS systems. But what’s an MLS system?

For this discussion, I think there are three major parts to an MLS system, the back, middle and front. The back-end is where the listing data and images are stored. The middle is where the business logic typically is stored. The front-end is what the end-user sees, typically through a browser of some sort.

Part of the confusion regarding whether the Gateway is going to replace the current MLS systems or not stems from the lack of distinction among these three core components to an MLS system. When the Gateway is mentioned as a replacement of the MLS, the whole enchilada is involved, front, back and middle. This expression of the vision entails a new web site that all agents would use for entering listings, CMAs, prospecting, and everything else MLS members do today with their MLS systems. People enamored with this vision see sites like Zillow and think it’s not far from what they might need for an MLS and so NAR, with all that member money, should be able to whip something up like it in no time, particularly since Move already has, Top Producer, etc., under their belt. Knocking off the MLS space should be a cinch. Well, that’s the theory anwyay, but I don’t think I’m going too far out on a limb to say that vision is long-term, at best. So, for now, we’ll give that the Warren Koeller chuckle and move on.

When proponents of the Gateway say that it won’t replace the MLS, they mean that it won’t replace the front-end, at least right away. In at least one vision, the back-end will be a RETS server capable of being accessed by any RETS-capable front-end. In this scenario, the local MLSs may continue to play a role in providing this front-end to their members, but the back-end will be one big data repository of all the listings, images, tax records and more.

Now here is where it gets interesting, and where I think the Gateway proposal may be flawed, fatally. First, when one software vendor creates the front-end and another creates the back-end (even a standardized back-end), you quickly end up with data in more than one place. The front-end vendor works with their clients to provide them with a competitive advantage, something new. Yet the repository is common for everyone. So, to create that advantage, they start adding data locally, accessible only to that front-end or the users of that front-end.

Here’s a simple example. Let’s say a repository is created and, as is common of big repositories, sets a limit on the number and size of photos that can be stored for each listing. Some clever software vendor will come along and create a system to allow users to store an unlimited number of high-resolution photos. Or perhaps the repository doesn’t allow for storage of listing flyers or large remarks fields or some key data field needed for a particular area. That need will get filled. But the result is that all of a sudden all of the data is no longer in the repository. Hmmmm. What was the point of the Gateway again?

I’ve written about this before, regarding Zillow, but the same analysis applies to the NAR’s Gateway proposal. The idea that all the data can be stored in a single repository is flawed. It will never happen, because there will always be some agent somewhere who wants to differentiate their service and they’ll start collecting data outside the repository. That’s what innovation and competition does, it differentiates. (This not to say that a national repository of core listing data isn’t useful. In fact, I’ve previously suggested that a distributed national repository could be very valuable and could foster competition instead of inhibit it.)

More important than content created by agents, however, is all the content related to properties created by others outside of the real estate sales industry. Every day, new information is being created and the creation of a repository won’t harness that creativity. Home owners, neighbors and more will create valuable information about specific properties. How do we harness that information?

Back to standards, this time highly focused. We need standards for identifying properties. With a reliable standard adopted widely, content created anywhere could be linked together simply by properly identifying the property. All the current systems (address, parcel number, latitude/longitude) have challenges. We need a reliable standard. Working to establish standards is something that large organizations like NAR can excel at where individual competition often cannot. Moreover, a reliable property identification system really is a necessary pre-cursor to a gateway of any kind. But, ironically, with a reliable property identification system, a gateway likely isn’t needed.