[NOTE: This is a post I wrote for a client, SIRMLS, and decided to cross-post to my blog because it tells so much of my personal involvement in it. Thanks to Tim Dain and to SIRMLS for the opportunity to tell the story, and granting me permission to cross-post to my blog.]
“Something hit me very hard once, thinking about what one little man could do. Think of the Queen Mary — the whole ship goes by and then comes the rudder. And there’s a tiny thing at the edge of the rudder called a trim tab.
It’s a miniature rudder. Just moving the little trim tab builds a low pressure that pulls the rudder around. Takes almost no effort at all. So I said that the little individual can be a trim tab. Society thinks it’s going right by you, that it’s left you altogether. But if you’re doing dynamic things mentally, the fact is that you can just put your foot out like that and the whole big ship of state is going to go.
So I said, call me Trim Tab.”
— Buckminster Fuller
Introduction
The dream of fundamentally improving the MLS technology platform has been one that the industry has talked about for years. We have seen a surge in credit-taking amongst the “thought leaders” within the industry in recent weeks, as RPR has started to shed light on their Advanced Multi-List Platform, aka AMP™. But the concept of a flexible MLS, powered by modern API’s (Application Programming Interface), which allows for flexibility and innovation has been around since at least the mid 2000’s when technology companies like Google, Facebook, and Salesforce debuted the concept of API’s and “mashups”.
As is said, success has many fathers. But in this case, many of those were absentee dads at best. The real story of what is possibly the biggest advance in the MLS industry since the advent of the Internet itself cannot be told without mentioning the central role of SIRMLS.
As I was the author and architect of this overall effort, I know better than most just how valuable SIRMLS and its leadership have been, and remain. I know that we would not be discussing AMP, RPR, and the overall concept of the modular MLS had it not been for SIRMLS, its Executive Director Tim Dain, the Presidents Brad Krueger, Rick Lauschke, and Lindsey Egner and the Boards they led. Without the courage to take risks, to support, and to invest in moving forward when everyone else wanted to wait and see, there would be no story to tell.
We thought it was worth laying out the journey from the start to where we are today. The future makes sense only in the context of how we arrived at the present.
Origins of the Concept
I began working with MLSs in 2009, when I started 7DS Associates. But even before, while at Coldwell Banker Commercial, and then at Onboard Informatics, I knew that the MLS industry suffered from archaic, unwieldy, and expensive technology platforms. I also started to realize that the vendors were unable to deliver quality products and quality support due to a number of reasons, least of which was that the MLS typically drove prices down to the point where the vendors simply could not deliver on what they promised. Unfortunately, most MLSs appeared to be stuck with these archaic systems, and spent enormous time and energy finding work-arounds.
I do not claim to be the first or the only person connected to the MLS industry to have noticed these things. Practically everyone with knowledge of the issues knew these were problems. Question was, what to do about them?
The core problem, as I saw it, was that MLS vendors were still operating under the “one proprietary system” philosophy where the vendor had to provide nearly every feature to the MLS to win the contract. That philosophy was necessary in the 80’s and 90’s when database technology, communications technology, and the Internet were in their early stages. In late 2000’s, after we had seen Google API’s transform mapping, had seen Salesforce transform development, and had seen the word “mashup” enter the popular lexicon, the overall strategy should have shifted with the technology advancements.
One of my early efforts to solve this problem was to try and create an Open Source MLS, under the name of Khepris. The idea was to develop MLS technology as an open source project, using volunteer developers, and distributing it as free software, with the source code published online. This way, each MLS, each developer, each vendor could use the technology as it wanted to use it, so long as the “certified” core technology remained consistent. That effort stalled due to the fact that the MLS market is tiny by the standard of technology developers.
My follow-up effort, as 7DS Technologies, involved financing MLS consolidation efforts, which included consolidating MLS data into a single data backend for the sake of efficiency and cost savings. But that data backend would need to be modular: the backend, the business logic, and front-end were all separated. Open API’s, modular architecture, and well-documented software developer kits would allow the MLS and vendors to mix-and-match user interfaces, websites, mobile apps, and productivity applications on top of that platform.
When that effort stalled due to the politics of the MLS world, I continued to pursue the basic concept of a modular MLS system. I believed that there were a few companies who had already built world-class databases, had fantastic data hosting capabilities, along with the core technologies — Search & Display and Email Gateways to cite two examples — that the modern MLS needed. And I reasoned that these companies all wanted to work with the MLS, needed the MLS, and wanted better relationships with the MLS for a whole host of reasons.
From Concept to Plan
Those companies I identified early on were Zillow, Trulia, Move (Realtor.com), and RPR. Each one had already sunk millions of dollars into developing the core technology. None of them were MLS vendors, and had not built their data technologies to sell to the MLS market. But having already built the technology, I thought they could provide it to the MLS at extremely low cost, or at no cost in exchange for partnerships (e.g., data feeds from the MLS).
In every case, with the exception of RPR (which I will address in depth below), the answer was No. But Zillow, Trulia and Move were not refusing out of hand; they just saw problems with the concept at the outset.
First, none of them saw an attractive business model in becoming a vendor to the MLS. The market was not large enough, the sales cycles far too long, and the entrenched vendors far too entrenched. None wanted to spend scarce development resources repurposing the technology that had been built for consumers to something usable by the MLS, since there was no prospect of a return on that investment.
Second, none of the companies wanted to spend time, money and developer resources to “localize” their systems. Truth is that the local MLS requires customization. Each MLS has different rulesets, different data requirements, different business customs, and so on. Even if 95% of the data and technology requirements were the same, that last 5% that needed localization took weeks and months of programmer time.
Third, none wanted to provide tech support to B2B clients. Their customers were consumers and agents, who didn’t really have tech support needs. But if they were to provide a system, a platform for the MLS, then they would need to provide ongoing tech support. None of these companies were setup to do so, and none wanted to make the investment to provide that support given the lack of ROI.
Through those discussions, my original concept evolved into an actual plan. These large technology companies, who had built systems that could be repurposed into the best, modular MLS platform the world had ever seen, did not see value in doing the necessary work of localization and tech support. The answer was to find someone else that did.
Systems Integrator, or VAR
The key idea was to use a third company, who had technology resources but not at the level or scale of the big tech companies, who would serve as a “systems integrator” or a “value added reseller” (VAR).
In the world of enterprise technology, for example, Oracle may be the database vendor, but companies such as Andersen Consulting and EDS do the heavy lifting of customization for a particular client. Oracle provides the “big iron” software that can run multi-billion dollar global companies, but these VARs and Systems Integrators make that software work for the end-user. And typically, these VAR’s provide the ongoing tech support to the client, freeing up Oracle and other “big iron” vendors to devote themselves to core product enhancements and R&D.
The plan, then, was to use any number of competent technology companies as VAR’s, while using one or more of the tech companies as the “big iron” software company.
If the technology companies in our space did not have to spent time, money, or developer resources doing localization, customization, and providing tech support, I reasoned that they would be more open to providing what they’ve already built: the database and the core technology assets.
I realized further that this structure — the VAR and the “big iron” vendor — actually benefits the MLS in significant strategic ways.
Benefits of the VAR/Big Iron Model
Having a VAR be responsible for day to day tech support, customization of the system for the specific needs of the MLS, and providing front-line support to the developer community, while the core technology was provided by one of the large tech companies in the industry leads to a few strategic benefits.
1. The MLS can contract exactly the level of support it requires.
In the existing model, the MLS negotiated one agreement for everything related to the MLS platform, from database to hosting to features to front-ends to tech support. Sometimes, the MLS bought too much support, requiring immediate telephone support 24x7x365 which never got used. But more often than not, the all-in-one approach meant that the MLS got too little support.
Because the price of the system is an “all-in-one” price on a per-member basis, the MLS drives the cost down as low as possible. The vendors, wanting to win the contract, would often promise phenomenal support, but then be unable to deliver it as the reality of scarce development resources met low profit margins.
The VAR model changed this dysfunctional business arrangement, because the VAR was paid for support, for as much or as little support as the client MLS wanted.
If the MLS wants absolute top of the line support, with a programmer on-site in the MLS’s office, a VAR can provide it at a premium price that would reflect the costs of having to hire, train, and assign a programmer permanently to one client. But if the MLS was smaller, didn’t need such rapid response and could live with someone on the telephone within four hours, the VAR could provide that at far lower cost. For that matter, if the MLS was confident in its in-house tech team, and wanted maximum cost savings, the VAR could provide email-only support, or a per-incident pricing model.
2. Rapid development and response time.
A critical part of tech support is modifications to the system upon request. Consider how the process goes today, with a typical MLS vendor:
- MLS makes a change request, perhaps something simple like adding a new “Certified Green” field.
- The Vendor puts that request into its development stack, along with all of the requests from all of its customers, then schedules development.
- Vendor needs to consider whether this change is something for that MLS only, or something for all of its customers. If the latter, then it needs to get feedback from all customers, rather than having to repeat the work.
- Since development resources are expensive and scarce, depending on the priority of the request, that change may take weeks or months, or have to wait for the “next scheduled update release”.
- Furthermore, should more urgent needs arise, the development calendar may start to slip. And in technology, emergencies, downtimes, and more urgent needs are always popping up.
End result is that the MLS waits for weeks and sometimes months to have a simple change implemented. A more complex change might take far longer.
With the VAR model, the VAR handles all of these change requests. It shares the requests and feedback with the Big Iron vendor, with whom it works closely, but the development schedule is specific to that customer’s MLS. The VAR’s developers are not working on the entire software system; they work only on the MLS’s local piece. Turnaround time and responsiveness to change requests and fixes will be vastly improved.
Incentives matter. In the case of the single vendor, there are no additional revenues for the vendor to make changes; all of the revenues are governed by the system contract. In the case of the VAR, it may (and likely will, to keep monthly support costs down) take on such change requests on a project basis, resulting in additional revenues. Again, services to the MLS are improved.
3. Avoid Lock-In.
A major benefit of the VAR model is avoiding the common problem of vendor lock-in. The MLS might take years, with committee meetings and Board meetings, to decide on a particular vendor and system. That vendor then spends huge amounts of time and money to customize the platform for that MLS, with revenues locked in to a per-person license. The only way to recoup that expenditure is to insist on extremely long contracts that are very difficult to terminate.
Furthermore, upon termination, the now-fired vendor has no incentive to assist in the migration process. And the migration task is complicated by the fact that most single-system vendors run a proprietary database that only works within its software system.
No wonder, then, that MLSs find themselves wedded to a MLS platform and a vendor they’re not happy with for years at a time.
With the VAR model, it is much easier to avoid lock-in.
Since there are two vendors, one handling the backend platform and one handling everything else, but both managing the MLS’s data, switching one or the other is far easier.
For example, suppose that the level of service from the VAR drops after personnel changes. Rather than having to wait for the entire Agreement to be over, or worry about alienating such an important vendor, the MLS can simply fire the VAR and hire another one. All of its systems, all of its data, are on the Big Iron vendor. Getting a new VAR up to speed should not be a time-consuming process, as having two separate companies means that documentation of processes and technologies must be up to date and on spec at all times. With the modular structure, the database is built to work with any front end or application that uses the data.
But the reverse is also true. Suppose that the Big Iron vendor fails to update its core technology platform, and a competitor offers a superior solution at lower cost. Since the VAR has always been in charge of managing the MLS’s data within the platform, and all platforms are built in a modular way, moving from one platform to another is a far easier task. The VAR is familiar with the MLS’s datasets, its business rules, its processes, and the API’s that its developers use. The VAR has not been fired, so it has every incentive to make the migration go smoothly and quickly.
4. Lower Cost, Shorter Terms.
We outlined why MLS contracts are so long. But with a modular system, each company specializes in its area.
The VAR has not incurred massive up-front costs that can only be recovered over long contract periods; it’s getting paid to provide services as it is providing them. It has no technology R&D costs, as it is merely modifying someone else’s platform and database. Therefore, it has lower costs of operation, which it can pass on to the client MLS, and be happy with shorter contract terms.
Furthermore, the Big Iron vendors are not doing much of anything at all; they’ve already built the system. The VAR did the heavy lifting of localization, customization, and tech support. There are very few sunk costs for the Big Iron vendor to recover. With less technology resources spent, it can offer the back-end component at lower cost, and on shorter terms.
In both cases, there is no reason why either should demand or get these five or seven year contract that are so common in the MLS space. And the overall cost should be far less to the MLS, as the financial model is different for both vendors.
After speaking with many of the people at both the Big Iron companies and with potential VAR’s, I felt this modular structure was the ideal way forward. The plan was in place.
Enter RPR
At the 2013 Swanepoel T3 Summit in Las Vegas, I met with Dale Ross and Jeff Young, CEO and COO of RPR respectively, and outlined the concept of the modular system, with RPR serving as the “Big Iron” vendor.
To its credit, while the other potential technology vendors raised objections and problems, RPR did not refuse out of hand. Both Dale and Jeff were receptive to the concept and the plan, but there were a number of issues.
First, RPR simply could not be seen as entering the MLS space, due to the complicated origins of RPR itself. Because the origins of RPR were in a NAR Presidential Advisory Group that studied a national MLS owned and operated by NAR, any move by RPR into the MLS space would be interpreted as a power grab by NAR. This, despite the fact that the national MLS idea was shelved, and RPR was launched as a service to provide data to REALTOR members, and as of 2011, financed from NAR’s Operating Budget via annual dues paid by REALTORS to NAR.
Second, both Dale and Jeff thought that as a company owned and operated by NAR, whose budgets were funded by member dues, it was appropriate for RPR to see if it could provide assistance to REALTOR-owned MLSs. However, for RPR to even pursue such a project, it would need to understand the size and scope of the demand and need. Would the local MLS want such a thing? Was this thing a pipe dream or something real? (Keep in mind that people have been talking about “front end of choice” and “modular MLS” for years and years, with no action.)
My suggestion to RPR was to have local Association-owned MLSs make formal requests to RPR for assistance. RPR could not approach the local MLS, but if the local MLS — whose members were dues-paying REALTORS — asked RPR for help, then the political concerns would be mitigated. Furthermore, by having the local MLS ask RPR for help, a level of demand would be established.
Enter SIRMLS
In July of 2013, SIRMLS decided to have three potential MLS futures explored by three different industry consultants. The consultants were required to write a paper providing a vision for their assigned scenario. The paper was to be written from the perspective of an MLS that has already made the necessary changes to have a successful outcome, one year or more removed from the proposed changes. These future scenarios depicted three different MLSs that made the choice to focus 80% of more of its time, talent, and treasure on one area. The three areas were Technology, Service, and Rules/Regulations.
I was the consultant assigned to “Rules/Regulations” scenario, and Project Trim Tab was born from the ideas of that paper. In the paper, I proposed separating database warehousing from the MLS infrastructure, provide a flexible modern internal programming interface (“Big Iron” vendor), and then partnering with a technology provider (a VAR) to provide an external programming interface, and build, maintain, then support the software developed to work with the database (otherwise called front-end/tool of choice). By leveraging these assets the MLS would then be free to focus on a robust Rules/Regulations platform that provided more carrot than stick and profit sharing for listing contributors who followed those rules, providing the pristine data.
[As a side note the other two papers led to SIRMLS becoming a 100% mobile MLS, launching a mobile partnership that became FIND Mobile by Move, Inc., and offering training service to neighboring MLSs.]
The resulting conversations at SIRMLS Board Meetings led the leadership to believe that the time was right for a courageous MLS to explore the possibilities of the concept. During the National Association of REALTOR 2014 Mid-Year meetings, SIRMLS hired Bob Bemis and Mitch Skinner to meet with several industry leading technology and MLS providers to share the concept and vision to see if there is mutual interest.
From those meetings, from those conversations, and many that followed in the next year, SIRMLS progressed to the point of conducting a tech audit, building out business plans, separating vendors into “Big Iron” and “VAR” potentials, and requesting proposals from various technology companies. Through SIRMLS driving the program forward, and RPR’s own efforts, RPR has decided to create a project titled Advanced Multi-List Platform™ (AMP™). Because of SIRMLS and its efforts, the whole industry is abuzz with the possibility that the long-held dream of a flexible, modular MLS that provides front-end of choice, speed of innovation, and modern applications for the REALTOR member might finally become reality.
Let us be clear on one thing.
If the real estate industry, if the MLS industry, embraces the concept of the modular MLS and makes the necessary reforms, SIRMLS and its leadership deserve all of the credit. The consultants like me or the vendors like RPR played a role, but until an actual local MLS stepped up willing to take the risk and explore/invest in the project, nothing ever happened and nothing ever will.
When the history of the real estate industry in the 21st century is written, it has to include the fact that the revolution began in a small corner at the southern tip of Illinois, with a MLS that saw the possibilities, embraced the vision, and turned dream into reality. Kudos, and congratulations, but… the world has just begun. You, and the rest of the industry, have taken merely the very first step in the journey. There will be setbacks, there will be barriers, and I know that SIRMLS may ultimately choose the more traditional direction due to industry consolidation, contract lengths, or politics. Still, the revolution has begun, and there are many MLSs now considering the future of their technology platforms because of the pioneering work of SIRMLS.
Here’s to seeing it through to fruition!
-rsh
Comments are closed.