Embracing The Paradigm of Open Software
The Wolf In The Assessor’s Office
The other day I had the chance to enjoy one of my favorite movies, “The Wolf of Wall Street”, starring Leonardo DiCaprio. It first came out in 2013 and if you’ve not seen the movie, the main storyline is about a young stockbroker named Jordan Belfort, who ends up starting and leading an infamous stock brokerage. As his business grows, he initiates and participates in numerous fraudulent financial schemes and morally corrupt behavior. Think “Wall Street” on steroids.
One of the most famous scenes is when Belfort, at his first job working for a famous stock brokerage, has lunch with his boss, Mark Hanna. The conversation the two have is surreal and includes the following doozy of a dialectic exchange:
Mark Hanna : The name of the game, moving the money from the client's pocket to your pocket.
Jordan Belfort : But if you can make your clients money at the same time it's advantageous to everyone, correct?
Mark Hanna : No.
“The Wolf of Wall Street”, Directed by Martin Scorsese, Paramount Pictures, 2013
I saw that scene and, as something of a non-sequitur, I thought of the state of assessing software; sometimes it seems like CAMA companies are like Mark Hanna, not necessarily caring about making sure the client is succeeding using their products and more concerned about getting money into their own pockets.
A case in point - not too long ago I was with a client that had transitioned over to a major CAMA provider. Bundled with the CAMA system was a new mobile data collection system. Unfortunately, the mobile data collection system was a joke - the battery on the windows computer didn’t last long, the size of the fonts and graphics in the application were small enough that even a person with 20/10 vision had to put on glasses to see everything. In short, the mobile data collection system was not what the client needed. When the client asked if they could integrate a different solution, like the CIDARE Capture system or DataCloud’s MobileAssessor system, they were told yes, that was possible, if the client was willing to pay a price equivalent to the conversion cost of switching from their old CAMA system to the new CAMA system (i.e. tens of thousands of dollars)! Clearly, the needs of the assessor did not align with the needs of this CAMA company, so the assessor was subjugated to the needs of the CAMA company.
Why was integration so expensive? Because the CAMA company’s software was not open; there was no documented application programming interface (API), no access to source code, no ability for a third-party to perform the integration at a lower cost, not even the ability to view the database directly. We come to the crux of a major problem in assessing: the software systems that assessors depend on are not open, so the ability to innovate, to make life easier by connecting to other systems, is closed. As a result, assessors are completely dependent on the software companies that serve them, have little choice, and often have to work harder instead of smarter to accomplish their jobs.
Open software is software that is modular and can be upgraded over time through choices offered by third-parties. It is easy to integrate with other systems because it has an SDK, or an extensive API, or because source code is available.
Making Open Software
CAMA companies have every right to make money, but shouldn’t the needs of the customer come first? There is no problem being dependent on a company if the needs of the company and the needs of the client align and the needs of the client take primacy. Ideally, however, assessors shouldn’t need to depend on a single company.
Open software is the answer. Open software is software that is modular and can be upgraded over time through choices offered by third-parties. It is easy to integrate with other systems because of it has an SDK, an extensive API, or because source code is available.
An example of the most open software is open source software, where anyone can see and modify the source code so that the software can be customized and shared.
An example of proprietary software that is open is Google Workspace with its productivity applications Docs, Sheets, Slides, and Drive (amongst others). Google publishes an extensive API for each of the productivity applications that allows third-parties to build function specific modules for each application in Workspace. That’s why there’s the Google Drive app from Google and apps like InSync, which performs the same functions as the Google Drive app plus an extensive set of additional functions.
Open software creates ecosystems that benefit both the user and the company, which is the norm, at least for consumer facing software. In assessing, open software is the exception rather than the norm.
Getting Open Software In Assessing
Assessors can get the same benefits that normal people enjoy from open software. They just have to actively seek open software.
Open software requires three main things:
1. Well-documented, open data structures. How is data saved? What is the structure of the format of the data? An example of a well documented data structure is a pdf file. Essentially any writing software can write a document to pdf because how a pdf is structured is well-known and because the standard is open. In assessing, sketch and images are the key files that really need data structures that are well-documented. Vision Government Solutions, Inc. is one of the few CAMA providers that does this with their sketches, which are saved in the xml format, a format that is well-known and easy for an engineer to understand and write to.
2. Well-documented Software Development Kits (SDKs) or APIs with lots of functionality. A software development kit allows a software engineer to use the core components of an existing application to create a new application. Every application you use on your phone is built using an Apple or Android software development kit so that programmers utilize the phone’s operating system properly.
APIs allow applications to talk with each other through a structured method of communication. As an example, think of your CAMA system. A CAMA system API would give instructions on how to identify a parcel and pull out the exterior wall information for the parcel from the CAMA database. Another set of instructions in the API might explain how to update the exterior wall information for a parcel by sending specific information to the server and obviating the need open the main CAMA application. To the best of my knowledge, most of the major CAMA systems don’t have well-documented, robust APIs. If they do, the APIs aren’t public, which defeats the purpose of being able to integrate easily with their system (maybe that's a business choice so that assessors need to depend on the CAMA company?).
3. Community. Community means that CAMA providers (both their engineers and their support staff), third-party application providers, and assessors talk about the functionality they need in the CAMA system and share how the CAMA system works. These three groups need to work collaboratively to develop the CAMA system's necessary improvements. To have a community you must have numbers 1 and 2 in this list. Most CAMA providers have user groups, but the user groups are not helpful. CAMA providers don’t have enough engineering resources to attack all requests from assessors, so features get put into the long list of “future development” needs. On the support front, many CAMA providers don’t have enough support staff, so it’s difficult to give the high levels of service promised. If CAMA providers provide numbers 1 and 2, then the community can help develop additional capability and provide additional support, often at a lower cost, and make the CAMA platform more valuable to both the users and the CAMA provider.
The best way that assessors can get open software is by demanding numbers 1 and 2 in the request for proposal (RFP) they issue when they’re switching to a new CAMA system. When discussing the capability of a new CAMA system with a vendor, ask them about the data structures they use (are they well-known, well-documented, and open?) and about the system’s API (ask to see documentation and let your IT department or your partner, like CIDARE, review the documentation for you). If they can’t give you this information, the CAMA system is probably very closed and you would do well to think twice before you switch to that particular CAMA provider.
Dispatching The Wolf
Until CAMA providers have an incentive to create open software, assessors will continue to suffer - their CAMA software will evolve at a glacial pace, support from the CAMA provider will often be wanting, and CAMA software will be expensive. The biggest way to change the market is to dictate the needs in the RFP and require the right kind of data structures and SDKs or APIs and then reward the provider that delivers the what you outlined in the RFP. If there is no option in the market, talk with other assessors that have similar needs. The IAAO community or your local assessor association are good places to start; use your own community to put together a list of must-haves then pool your resources to build what’s needed. The cost upfront may be more expensive, but you’re building a system that will be used for more than a decade, so the total cost is most important. Partners like CIDARE, third-party providers that don’t build CAMA systems but need to interact with them on a daily basis, are good sources of information and can help you develop both a cost model and list of technical capabilities.
Pretty soon the money you’ve got in your pocket won’t leave unless both you and the CAMA provider are benefiting.
