Regionals, Part II

Mar 15, 2007 Michael Wurzer

First, a confession: I wrote Raging Regionals pretty late last night from my hotel room in Roanoke, VA, and, upon reflection, realize I could have been more succinct and clear. Part of the problem was that I’m very new to this blogging thing. I had seen earlier in the day that Mark Lesswing, Greg Swann, and Jonathan Dalton had posted about the FBS Blog. I was both excited and terrified. I was excited that some of the people I had been reading regularly for months were now reading what I was writing and I was terrified because now I knew I really had to bang out the rest of my ideas on this question of the life (I’m done talking about the death) of the local MLS.

My challenge was that I had been traveling through Virginia all week visiting some of our MLS clients (talking about MLS data sharing, among other things) and hadn’t had the time to write as much as I wanted. So, instead of going to sleep early to get some good rest before my 7:00 a.m. flight, I decided to start writing. After I finally hit the “Publish” button, I was so wound up that sleep was pretty much out of the question. I tossed and turned for hours but finally gave up and wrote some more in a state of exhaustion. So, there it is, newbie blogger run amok.

What I aim to correct with this post is to live up to my promise in Part I to say which of the regionalization solutions I think is best. Though I emphasized that data standards (RETS listing definitions, in particular) are critical to any solution, I should have gone further and said that I think the best approach is a combination of a national data repository and the data exchange approach. Each MLS should send data to a national repository and, in exchange, each MLS should then be allowed to download all or part of the repository to their local MLS system. Perhaps it could be called MDX for MLS Data Exchange.

This is similar to the approach recommended by NAR’s Presidential Advisory Group, except I’m pretty sure that recommendation contemplates the repository being the sole data repository and the local MLSs will only have their local data and front-end software clients to connect to the repository for the national data set. (I say “pretty sure” because I don’t have the complete recommendation readily available, only summaries.)

I suggest the concept of a data “exchange” (where the local MLSs can retain a local back-end repository of all the data they need) is better, at least in the near term, than a single repository for several reasons:

  • Speed of implementation. There are lots of MLS systems in place and in use now (including ours) that are satisfying users. Making use of that code set is much easier if you’re writing an import as opposed to re-writing the system to hit the new repository.
  • Scalability and Redundancy. Utilizing the existing investment in the infrastructure of the current MLS systems, there is built in scalability and redundancy that doesn’t have to be reinvented in the national repository. Instead, the repository only has to serve the data back to the individual MLSs.
  • Persuasion. Persuading local MLSs to contribute to a national repository may be easier with the promise that they’ll get something significant in return.
  • There certainly are advantages to a single, national repository, too. Pulling data back to the local MLSs is going to introduce some latency to the data, i.e., it won’t be live. However, the data exchange should be able to update every five to ten minutes relatively easily, so the latency isn’t that critical, particularly when the local data will be live. In fact, the repository won’t necessarily be live either, as the update from the local MLS will likely have some latency, at least in the beginning until everyone builds to RETS or some other upload spec. Another advantage of a single repository is security. It’s easier to keep track of data in one place than in many. Of course, the brokers, agents and others will have clients grabbing the data all the time, so it’s still going to be distributed and there will be lots of security challenges there, too. Also, the existing MLS systems are being trusted (whether they’re trustworthy or not) with the data now (though less of it) and making those systems more secure is already a focus. Some proof of security for the local systems could be made a requirement of participation.

    Although there are advantages to a single repository and I certainly recognize that a single repository may be the most elegant long-term solution, I believe the data exchange model would allow the industry to move towards a national repository system faster and so is the right next step. There is a lot of money being spent now on large regionalization efforts. A realistic approach to a national repository could save a lot of time, money and agony by alleviating those efforts.

    I also recognize that this MDX approach will only work if there are broad and deep listing data standards. If the bulk of the data differences for the 700 or so MLSs remain widely disparate, then the costs of implementing an MDX approach would likely be prohibitive. That’s why I focused so much in my Part I post on the need to work hard on the RETS 2 listing payloads. If we can get the listing payloads finalized by the August RETS meeting, that would lay a great foundation for a national repository and data exchange.

    Importantly, this MDX suggestion has absolutely nothing to do with public portals, listing aggregators, IDX, or advertising of any kind on any publicly accessible web site anywhere. None. Zero. Rather, MDX would be solely for the purpose of serving the MLS members in the private side of the MLS system. The problems being solved with this suggestion are not the advertising related issues but rather are single listing entry and reduced rules, regulations and fees, which should flow naturally from this approach, because every MLS could be an entire, national MLS, so there is no need to belong to more than one MLS unless you want a different user interface.