convention In the last five years much of my work has involved spearheading a series of large convention management systems for national unions. By the time I started my third convention management system build, I had developed some strong opinions on how to approach a build like this. Each time my team built one of these systems, we’d create a complete green-field build from the ground up. Building this way allowed us to take lessons from our previous builds and apply them as we moved forward. Each build provided unique challenges, but more than a few common threads can serve as guideposts as you start a custom convention management system (CMS).  

1. Get Your Data Right

Data is the foundation on which any system is built, and there’s no exception here. In the case of a convention management system for a large organization, there’s a good chance that you will be combining whatever application data model you design with a pre-existing data source, consuming that data both as a reference point and an anchor for application records. In our case, there was always some degree of integration with the organization’s membership data.  

We explored several approaches to this data integration work over the builds. They included: 

• Accessing a warehoused version of the data. This approach was non-performant. Data warehouses were not designed for this kind of access, and we did not have good control over how the data was indexed. When we built a search feature on top of this data, it was way too slow.

• Building our application directly in the membership database. We used this approach for one of our convention management system builds, but we did not have any control over the schema outside of our application schema (even though we were directly reliant on them). This created issues where other applications’ needs or changes would cause issues in our system.

• Encapsulating the membership data in an API layer. We explored this one briefly on multiple builds. While I think it’s a viable approach given the suitable data model and requirements, I ultimately had concerns about performance and flexibility when trying to integrate data from two different API sources.

• Data sync from membership database (DB) to application DB. This was the sweet spot for us in terms of construction, flexibility, and reliability, and the solution we used in two of our builds. We created data sync jobs that would pull membership data over into our application database at regular intervals and translate it into a shape that was easily consumed by the application. This created a level of separation between us and the membership data, insulating us from changes to some extent and allowing us to continue our work even if there were changes to the underlying data. In addition, we gained full control over indexing and data fields, pulling over only what we needed to keep our data as lean as possible while retaining full functionality.

2. Design Your User Pattern Thoughtfully

In a system like this (especially if it’s member-facing), the user roles are going to get complicated. Our last convention management system build ended up with about seven user roles, each with a different (but sometimes overlapping) sets of data access rules. In addition, in more than one build, user accounts could be tied directly to membership records to facilitate things like convention registration, hotel accommodations, or in-person and virtual voting. Tying registrations to membership records, to user accounts, and then to data access permissions gets hairy fast – and while our most recent solution worked better than the ones before it, this is a place that I would focus more of the team’s initial design and discovery efforts on if we were able to work on another one of these builds. 

3. Become the Subject Matter Expert

You need someone on the development side who truly understands the rule set you’re dealing with. This will most likely come about as a natural consequence of the convention management system build, but over time both the business and the technical teams will need people who know both how the business rules work and how the system is applying the business rules from a technical standpoint.  

4. Document Everything 

The other side of the knowledge game is something we should all be doing anyways. It’s simple advice, but we all have trouble following through with it: write it down. By and large, these conventions are events that happen every year or every few years. There may be a full 24 months in between runs of the convention management system. Without proper documentation, you will  forget the obscure corner case you coded 36 months ago that you’re now being asked about. Whether it be rule interpretations, concessions made due to data or technology limitations, or changes to behavior – document all of it.

More than once, when asked, “Why does the system work this way?” I’ve been saved by a thoroughly documented Jira ticket or a well-written commit message or a technical document. Any system requiring a build of this size will always be complex, with many interacting parts. Documenting all the different side effects of the rules interacting is very important so that questions can get answered when they inevitably come up.  

I’m in a rare position. There are only so many developers who get to work on similar projects multiple times. The opportunity to truly iterate on my knowledge and apply what I’ve learned specifically from one build to the next has been a really illuminating experience and one that I’m unlikely to have again in my career. But for now, I’m through pushing this particular rock up this particular hill. So, I hope these lessons can serve as a stepping stone to a solid design for your next large integrated system build.