About The Author
Andrew Ross is a Lead Consultant on the Software team.
This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
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).
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:
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.
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.
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.
Andrew Ross is a Lead Consultant on the Software team.