When contemplating the future of museum software, just consider how radically all software has changed in just the past decade or so. Remember when installing new software involved running a series of installation discs? Today most laptops don’t even have a CD drive to install with. Software is either downloaded or offered as web-based “Software as a Service” (SaaS) platforms. While the delivery and installation of software has changed considerably, there are yet more radical ways that software development has changed.
Back in the day software vendors competed to have the most extensive offerings of features and capabilities. Feature “one-upmanship” was the name of the game. This resulted in software so bloated that it required certification just to use it. Think about it, what percentage of all the available features of Microsoft Word have you ever used? There are multitudes of untouched capabilities tucked away under all those menu options. Competition among software providers resulted in an escalation of features and a corresponding increase in their cost. Then along came “web-based software.”
The Google Doc Revolution
Web-based applications like Google Docs started to erode the dominance of boxed-software solutions. Not only were web-based options cheaper (often free), but the benefits of internet-based access and the ability to share and collaborate in real time was a true software revolution.
But the first wave of web-based software followed a similar competition path as their desktop predecessors. While the delivery and usage of these platforms were quite different, the race was still on to match feature sets as closely as possible. Online software never quite matched all those features, but by getting close enough, and offering the benefits of ease of use, portability, shareability, and real-time collaboration, the licensed software world was shaken.
Consider how Salesforce shook up the CRM (Customer Relationship Management) marketplace by being one of the first web-based CRM alternatives to traditional enterprise level systems.
Disrupters Getting Disrupted
Salesforce was not just a disrupter because they offered a web-based CRM alternative, they were also an early adopter of APIs. An API (Application Programming Interface) allows a website or web service to share data with another in real time. Because Salesforce was a pioneer in cultivating API partners, a huge ecosystem of highly specialized Salesforce add-ons has grown up around the Salesforce platform.
Salesforce is a powerful platform but they do have a liability inherited as one of the early web-based platforms. Since early web-based systems were trying to go toe-to-toe, or feature-for-feature with traditional software, products like Salesforce soon became just as bloated as Microsoft Word. These days you need a consultant just to set up and configure a Salesforce installation.
But more recently Salesforce, and almost every other web platform, have adopted the latest iteration of API technology, something referred to as the REST API.
For the purpose of this article, I’m not going to offer a technical explanation, you can always Google that. In layman’s terms, and to understand this shift in software development, all you really need to know is that a REST API allows one website or web service to offer up its information to any other in a simple, flexible, and useful way. When you see websites displaying posts or streams from social media platforms like Instagram or Twitter you’re likely seeing the use of a REST API. Any platform that offers a REST API enables web developers to easily build tools that can push and pull data from one website into another in real time.
In a museum context, a REST API enabled website would allow other websites to pull in some of your collection data, and display it in other contexts. Or, within your own ecosystem (if your collection management system offers an API) you could pull in all your object data from that system into your public facing website. This would allow you to display and relate objects in context on any page or post.
But there’s something even more radical about how REST APIs are disrupting how we buy, use, and work with software.
REST APIs Are Putting Bloated Systems on a Diet
Let’s consider CRM systems again, particularly in a museum context. These foundational back-office systems manage all your donor, member, visitor, event, and ticketing data and transactions. Providing a comprehensive and integrated system for all these functions requires serious software horsepower. Historically museum CRM systems required enterprise-level evaluation, enterprise-level implementations, and enterprise-level budgets. Under the old paradigm, software solutions were siloed platforms that had to offer all the features you might ever need in one product.
But what if we were to break out each of the features that an enterprise CRM offers into their unique component parts? And then, what if you could identify a suite of online software services that did a great job of managing each of those disparate parts independently? Suppose you could swap out the events management part of your enterprise CRM with a much more flexible and customizable system like Events Calendar Pro, or leverage EventBrite’s system but smoothly inside your main website? With the availability of REST APIs, these alternative options are ready today. So instead of having to identify one enterprise level software system that has all the bells and whistles, providing every imaginable feature, REST API enabled solutions can offer simple, slim, specialized sets of functionality. Rather than relying on an all-in-one solution, you can choose from a buffet of options, choosing the best resources for each aspect of your institution’s various needs.
And when you isolate the key components that you need out of a CRM, and then compare those features to the offerings of smaller providers that specialize in just those functions, you’ll find that often the smaller specialists offer better features than the enterprise level software. In the past, organizations had to lock into one source to manage all their information and transactions. But as long your systems are API enabled, you can now combine, mix-and-match, and put together a much more focused set of tools, and keep them in sync with each other.
Futurize Your Software With a Zap
If you’d like to get an idea of just how vast and powerful the software ecosystem of specialized curated tools already is, just check out Zapier.com. Zapier is a system that simply helps you to wire up connections between various REST APIs offered by various software platforms. Explore around a bit and you’ll see that not only are there over 1,000 different services supported, but the combinations between all these options create a massive set of possibilities for coordinating smaller, simpler, specialized software solutions to fit your very customized needs.
You can now wire up a host of specialized products, rather than getting locked into a long-term contract with one enterprise solution. Your website can become the glue that holds together a variety of lightweight specialized solutions into a cohesive experience.
WordPress as an API Control Tower
WordPress is the world’s most used website content management system. And it is itself REST API enabled. Not only is WordPress accessible via API, it also has a robust ecosystem of plugins, many of which are likewise API enabled. For almost any custom need, there is a WordPress plugin, or API enabled web-based software solution available.
Take our website for example. It’s built on WordPress, and we offer this newsletter via email subscription. The popup offer utilizes the WordPress “Popup Maker” plugin. But the form is built with the Jumplead marketing automation service that improves our visitor insight. When the form gets filled out it uses a “zap” to update our Copper CRM solution. We used to wire up Cooper with MailChimp, but we swapped that out for Jumplead when we implemented automation.
And that’s another huge benefit of a lightweight, specialized, coordinated suite of solutions rather than all-in-one enterprise level systems. If you find a better product for a particular function, it’s far easier to swap out that piece than it would be to transition from one major comprehensive system into another.
A couple other examples from our ecosystem. When our clients use our support form to request an update or change to their website, that form info not only gets sent via email—it also automatically creates a task in our Teamwork project management system and triggers a Slack message to our support channel—all enabled through APIs.
A Better Set of Incentives for Software Developers
The ease with which we can now swap out alternatives for discrete specialized functions puts good healthy competitive pressures on the providers of these software platforms. Since they can’t rest on the laurels of a client base that’s been locked in through expensive long-term contracts and license agreements, they need to keep their R&D and customer support services well-honed.
And since this new generation of software providers is not trying to replicate every feature offered by the old all-in-one systems, they are able to specialize and get really good at doing just their specialized function. I’d put the best Software as a Service options up against the same set of functions in an enterprise system any day. And if a particular SaaS option lacks a desired feature, just wait a minute, or suggest it, and these smaller, more lean and competitive developers may add it in short order.
A Better Future for Museums
Since museums have so many different departments with various needs, and since their missions and their audiences are so broad, you might be in a prime position to benefit from a transition away from the locked up, bloated, all-in-one enterprise solutions toward a more flexible, lightweight coordinated ecosystem of many specialized products.
There will still be a few mission-critical enterprise systems in your ecosystem. Collections Management and Digital Asset Management Systems will still likely be bedrock systems. But even these systems (at least the best ones) are quickly implementing REST APIs. Piction, the DAM system we wrote about last month, and TMS (through their eMuseum offering) are examples of API enabled bedrock museum platforms around which museums can customize their other functions with a variety of coordinated specialized systems.
Cuberis always keeps an eye out for such opportunities that can benefit our museum clients, so if you’re looking for a new set of solutions for your customized needs get in touch with us, we may have already evaluated some of those tools, or put them to use. We’d be happy to be your guide through this new and exciting world of REST API enabled specialized systems.
