We talk a lot about how fast technology moves, but it’s harder to notice how quickly our expectations of technology change. That is until we pull out our iPhone 12 to look up the top smartphones from ten years ago.
When we started building Rhythm, we knew your expectations from technology - from an AMS - were higher than ever. Here are some of the decisions we made to surpass them.
Reduce or Eliminate Customization
Many AMS platforms are built to be customized. You might find that the online experience for your members as well as other processes requires custom development time. This might seem odd that a function you would deem critical to your operations requires custom development, but it’s a consequence of early design decisions.
Customizations are definitely frustrating. They add time and expense to implementations. By definition, they’re a deviation from the standard system usage. This means as the base system changes over time, they’re more likely to break. And as your needs evolve, you might find yourself having to go through the time and expense again to have it changed. Or you might decide it’s not worth the effort and so customizations become an anchor holding you back from other changes you want to make.
At Rhythm we try to reduce the number of customizations you need - ideally to zero. That’s not to say we’ve closed the door on customization, they’re still possible. Easier in fact. But we haven’t had a customer need one yet.
We do this by working with customers early in our innovation process to build a product that’s flexible enough to exceed their expectations without needing customization.
When they needed to be able to handle membership join, renewal, and reinstatement differently, we didn’t customize. We created membership processes.
When they needed the ability to change the data they collect from members who interact with different areas of the portal, we created configurable forms.
And when they needed full control to change any part of the member experience at any time, we didn’t create custom portals, we gave them a composable portal.
When you are waiting on a new feature or a bug fix, every second counts. Ten years ago, waiting a few weeks sounded good. A late-night outage for a release was acceptable. And you tolerated the all-too-common chaos the next day. It was better than checking the mail for a new CD. But the times and the technology have changed.
Today, most high-performing technology teams release several times a day. In fact, once a change is completed, if it takes more than 15 minutes to get it into production, that is considered unacceptably slow. Sound impossible? It absolutely would be if we still built and released software the way we did 10 years ago.
You might have run across a few technical buzzwords like “DevOps,” “microservices,” or “continuous deploy.” These are some of the tools and techniques we have available to us today that make this a reality. In the end, it’s about breaking something big and complicated down into tiny parts so you can change one, test it, and release it without changing anything else. And then automating that process so you can do it quickly and reliably.
If it seems obvious, it might be. When we need an oil change, we take it to a mechanic and get a new oil filter. We don’t buy a new car. But getting this right in software can be challenging. It’s much easier to build it in from the beginning than to try to migrate an existing system. Especially one as big and complicated as an AMS.
You might think releasing several times a day is a recipe for trouble. If a release every month causes problems or downtime, imagine that every day. That would be a nightmare - nobody wants that.
A funny thing happens when you design a system from scratch to be changed easily and often. It ends up more reliable, too. You see, it’s just not possible to release at that rate without an automated deployment process. This takes human error out of the equation.
And since only one little piece changes at a time, it’s easier to test to make sure it works as expected before it gets to production. Once it’s in production, it can be monitored and rolled back if anything goes wrong. All of this happens automatically, too.
This is why in the State of DevOps 2019 report, teams that released several times to production per day didn’t just deploy 208 times more frequently and 106 times faster. At the same time, changes failed 7 times less often and they recovered from incidents a whopping 2,604 times faster.
Focus on You
Technology teams have a lot competing for their time. We hear ideas from you that we’re excited to build for you. We want to fix things quickly when you run into issues. We want to extend the ecosystem with more integrations. We want to give you technical support when needed. These are the activities that define us, make us an AMS, and make us a good partner to you.
But there are a lot of other tasks that need tending to. These are below the surface. Servers need to be provisioned, security patches need to be applied regularly, usage needs to be monitored, capacity needs to be added when needed, and much more. These are important activities, but they don’t create any new value for you. There’s nothing unique here. They just need to be done and done right, or systems go down.
When the cloud was first introduced, some of the best teams in the world at these activities (AWS, Microsoft, Google, etc) offered to take over a few of these tasks. This was a huge breakthrough, but it still left a lot of this work to builders. Builders who were left to split focus between building value for you and keeping things running well. Both suffered.
Over time, cloud providers offered to take more of this over. Today, “serverless” systems like Rhythm take them up on this offer to the maximum extent possible. AWS worries about all of these concerns so we can focus entirely on building the AMS you’ve always wanted.
If you were to compare the first iPhone with the latest, the improvements in technology would be obvious. With association management software, the advancements can be hard to recognize underneath all of the jargon. You don’t necessarily need to know the technical definitions of microservices and serverless (although, it’s certainly helpful), but it’s good to understand the benefits they provide as you evaluate potential AMS partners.