Technical Thoughts: Moving Towards Transition Of The MLS

Little did I realize the hidden blog treasures to be found in Maureen’s Carnival of Real Estate #35 winning choices this week…the following article is a bit technical so I apologize in advance.

 In a different posting from his winning Carnival post, the FBS blog talks about the ideal layout of the MLS (emphasis his): “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.”

He goes on  to say:

“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. ”

An Alternative Suggestion

A virtual single repository that exists only in the form of a set of standardized national interfaces might be an alternative approach that may work just as well as a physical single repository. Is a physical national data repository really needed? The national repository could just as easily be virtual in nature (much like a webservice) that would only need to have a minimal physical presence; in fact it could be as simple as an standardized interface, some format and location metadata as well as some transaction history. This alternative approach seems (on the surface at least) more efficient for all parties, less labor-intensive both upfront and on an ongoing basis, leverages existing standards work, would remain virtually transparent to the end-user, and fits well with a transaction based revenue model. 

The specific suggestion would be to have a national data interface that knows where to find, transform, and consume local data when called by a user.  There would not be any specific national datastore just a set of “national interfaces”. The national interface would function just as local interfaces do today – the difference is that the national datastore would only be single virtual version of all local data.  In short, the national system would store only a minimal amount of data and would be focused more on 1) where to find requested data and 2) transform that data into the standardized format for consumption by the end user – classic middleware.

We use such a system today within the ForSaleByLocals infrastructure for our 2GB of geolocation data that sits unchanged in its original format (which is only 60% usable by us) but is transformed into a format that usable only upon request and is then consumed in the transformed format. 

Advantages of This Suggestion:

- Traditional Advantages: All of the advantages listed in the FBS blog that argue for remaining with a distributed local architecture (Speed of implementation, Scalability and Redundancy, Persuasion)

- Storage: Local data would be remain local. Data from a local MLS would only be transformed into a standardized format as part of the request for transit via the national interfaces. In one scenario, the national interfaces would only be a conduit for local information.  Operational metadata (requests, data passed, etc.) would also be stored at the national level.  However, I can think of another scenario where any additional data or metadata required by the National system would be stored locally.  Why pay to store data twice?

- Transactions: Data transactions would remain strictly within the local system and the national system would be just another consumer of local data (much like any other website or app). Data would only be moved when it is needed (how I despise moving data!).  There would be no need for a constant data pump to update a centralized location or any of the resulting issues with distributed transactions, locking, etc. Bandwidth charges would only be incurred only when data is moved as part of a consumable and verifiable transaction rather than just as part of regular system updates. Any additional incremental costs of such a system would be easily trackable and chargeable based on historic data.

- Implementation and Legacy Support: Software service providers would simply call the appropriate data interface for the job (a standardized national or the legacy local interface).  The national interface would be used for any data outside of one’s local area.  There would be no change to existing apps or sites that rely on legacy interfaces.

- International Scability: As other associations such as the Dominican Republic, Mexico and others bring national MLS-like data online, they’ll easily be able to plug into an existing system that will make such properties accessible via the same interfaces that I am suggesting. You knew that I had to bring international into this somewhere, right?

We are not a player in the MLS debate so this post is only some thinking about the technology itself and does not deal with any other issues that might not have to do with technology. All things are easy for those that dont have to execute  Hopefully, this post can at least add to the body of discussion forming around the MLS technical issues with FBS, Greg Swann, NAR, Trulia, and others.