author Inspired by Gregg Larson and Matt Cohen’s recent post on the Clareity blog, and many questions from our customers about Upstream and AMP, I decided to take my own shot at trying to explain how these concepts fit into the overall technology landscape for brokers and MLSs today.
First, here’s the diagram I put together. Second, please read the explanation below the diagram to get the full picture. (If you copy the diagram, please try to link back to the post so anyone else looking at it can have the benefit of the textual explanation. Thanks.)
Many Competitive Choices
Matt and Gregg did a great job at documenting the nuanced differences between the data provided and moved by Upstream, AMP, Trestle, and Corelogic, and so thankfully I don’t need to dive into those details.
Instead, my primary goal with this diagram is to show that brokers and MLSs have multiple competitive choices for technology solutions. In the case of Upstream and AMP, respectively, the key point being made by the diagram is that Upstream is a broker product/choice and AMP, in contrast, is an MLS product/choice. In both cases, there are competitive options available to both brokers and MLSs.
Undoubtedly, Upstream and AMP both have the goal of getting 100% of all brokers and all MLSs to choose their products, but the point of the diagram is that achieving that goal is subject to healthy competition from many companies and products. I think a lot of the fear and uncertainty about both Upstream and AMP is the unspoken sense that somehow these options will be forced or mandated on brokers and MLSs, thereby replacing everything else, but that simply is not (and cannot, without violating antitrust laws) be the case. Instead, there are and will remain many competitive choices and the battle for market share will be fierce, all to the benefit of brokers, agents, and MLSs.
Let The Data Flow
In addition to showing the choices available to brokers and MLSs, the diagram also shows some data flows. In particular, the diagram shows how Upstream is intended to allow a broker who chooses to use it to send their data (listings and more) to multiple MLSs as well as other software they use (back-office, forms, transaction management, advertising portals, etc.).
Importantly, Upstream is a broker product and so the data flow is specific to that broker and does not involve the MLS aggregation. Accordingly, the diagram shows that Upstream does not send data to IDX vendors or others needing the entire aggregation of MLS data for a given market. Of course, the good news is that MLSs and their vendors have already covered that need, allowing brokers many options for including their data in IDX feeds or to syndicate to a wide variety of portals.
Separating the Front and Back-Ends, Including APIs
The diagram also shows how AMP, by itself, is not a complete MLS system, but rather is only the back-endsystem (i.e., the MLS property database and the rules governing the database). If an MLS chooses AMP, they’ll also choose one or more front-ends (the user interface software the agents and brokers see in their browser or on their phone) to create a complete system usable by their members, similar to current offerings from companies like FBS, Corelogic, and Black Knight.
Of course, it remains to be seen whether MLSs or their broker and agent customers actually want to choose more than one front-end or not, but, as the diagram shows, there is lots of competition currently on the back-end through many competing API solutions. API stands for application programming interface, which essentially is a set of instructions for how software developers can program their system to interact with the back-end database or other service offered by the API provider.
For example, AMP will offer an API to the front-end developers so they can retrieve MLS and other data from the AMP back-end. Similarly, FBS’s Spark API offers a robust set of services to allow other developers to access listings, membership info, CRM data, saved searches, subscriptions, favorites, and any other data in the MLS system to eliminate duplicate entry and propriety lock-in.
Trestle from Corelogic and Retsly from Zillow also will offer some form of API to access the back-end databases they provide, which I understand include listings as well as public records. Both of these are relatively new offerings and undoubtedly will be positioned by their respective companies as capable of serving many different needs, just like Spark and AMP.
In fact, one of the key advantages of an API-first approach is that APIs can be used for whatever purpose the data owner (brokers) wants to authorize, resulting in innovation now and long into the future. So, while the diagram above shows the APIs in the current context of supporting the MLS front-ends, none of the APIs are limited to that particular use.
For example, a broker could easily use one of the APIs to power their public web site or better integrate their back-office, transaction management, forms, and other systems. In addition, the APIs also are not limited in where they can receive data from, so they could easily aggregate data from many MLSs and other data sources to provide new and innovative products.
RESO Standards to the Rescue
Looking at the chart above, one could easily get overwhelmed and say, whoa, how are all these different options going to work together? The good news is that the industry has thought well-ahead of this need with the creation of RESO, the data dictionary, and the new Web API specification.
A critical question brokers and MLSs should have for any vendor offering one of the solutions above is whether the solution is or will be compliant with the RESO standards. This is critical to ensure that your data can easily interoperate with any other system, which, in turn, is critical to ensuring you don’t end up choosing a system that locks you and your data into a proprietary solution.
Another critical benefit to RESO standards is that it should enable mixing and matching of various front and back-end solutions. I don’t want to make it sound easy or fool-proof (because it isn’t and won’t be), but, in theory, if a system like AMP follows the RESO standards for their API, then any front-end that also follows the RESO standards should be able to connect to and use that API. Again, this is in theory and the devil most certainly is in the details when it comes to developing on and implementing a standard, but the only hope of inter-operability and choice is through an industry standards effort like RESO.
From Concept to Reality, Only Time Will Tell
One last point here is that Upstream and AMP are still in development and likely won’t be in live usage for quite some time. As I wrote a few weeks ago, all the brokers and MLSs I’ve worked with in the past won’t (and shouldn’t) consider a solution until it is proven in the marketplace. This is all part of the competitive process and, as those concepts are developed, undoubtedly we’ll see many new and different offerings come to the market as well to further enrich the competitive landscape and the choices available to brokers and MLSs.