Choosing an Association Management System (AMS): Some Web Considerations

October 4, 2010 | John Berndt

As TBG (The Berndt Group) has become a major national developer of association websites, we’ve increasingly become involved with the selection and implementation of Association Management Systems (AMS). Association Management Systems are large software packages that potentially handle every aspect of an association’s business, from managing membership and renewals to eCommerce, event registration, fundraising, and collaboration. They come in all shapes and sizes.

Organizations face a complex set of considerations when deciding to adopt one of these systems, driven by variables like features, reporting, and, of course, cost. Further, since the systems are a core part of an association’s infrastructure, there is a focus on secondary issues like the stability of the company and its approach to software distribution—in other words: hosted or installed.

Though these considerations jointly tend to dominate the selection process, there are a number of other considerations that are important and tend to get overlooked. These days, most AMS systems are web-based, but many still have limitations and problems when it comes to integration with a public website. Many vendors still think that their clients will be satisfied by a few forms hosted on the AMS server that can only vaguely be made to look like the website. Others think that providing a few rigid “web parts” that can be plugged into a website will do the trick. These expectations are far out of sync with the expectations of associations and their members, who expect AMS-centric functions to appear in an integrated way throughout the entire website, to have extremely custom forms embedded with managed content, and who expect content-centric applications to routinely key off of secure member data from the AMS.

The more sophisticated AMS vendors recognize this by having invested in the development of rich “Web Services” format API’s, based around a well-documented and rational use of XML and object-oriented programming. This provides an open interface for developers to create systems and websites that leverage the AMS system in a wide variety of ways, without running into roadblocks or “black boxes” that can’t be penetrated. However, to develop such an API takes time, and also may reveal old technologies or poor data structures in the vendor’s system. For those reasons, the depth and prevalence of web services in the world of AMS systems is not yet completely satisfactory.

There is another trend that is disturbing, where AMS vendors will announce the existence of an API, but not actually have one, or have only a very rudimentary set of web services that is insufficient to the task of a large website. This is unfortunately not a rare occurrence, as is the retort, “What do you need? We’ll build it for you.” Vendors sometimes confuse the possibility of building something with actually having built something. In this regard, there is no substitute for extremely direct, piercing questions about aspects of the API, since the AMS vendor may be guilty of wishful thinking. A related problem is the over-optimistic salesman, who on principle believes the product to have all of these capabilities, and who is himself is shocked when he discovers it doesn’t—one might say a disturbing tendency to believe one’s own marketing.

Given that the web and other internet-based services (RSS, Apps, etc.) are increasingly the site of nearly ALL member interaction, organizations must look very carefully at these aspects of AMS systems, making sure that the design for a specific report or method of event registration doesn’t outweigh the ability to expose core AMS functions to members on the website. This will be complicated by sales people who will stress the value and flexibility of “modules” and “web parts” that, though useful in some situations, often create limitations that are unacceptable to an association’s members. The devil is in the details, but the more one knows about what one is getting into, the better the chances of having a successful outcome.

You’ll notice that we haven’t mentioned any of the AMS vendors by name in this overview. There is a good reason for that—beyond the fact that we have to work with many of these vendors on a daily basis and to have good relations with them. The pressure is on for AMS vendors to address these issues, and so any list of names and capabilities is likely to date quickly. Hopefully, within a year of publication, many of the points we’ve mentioned here will cease to be relevant, as vendors roll out complete, well-documented, rational API’s for their products. However, we suggest that you’ll want to keep your wits about you when discussing these issues with them—and in the process, not to hold your breath.

About the Author

John Berndt

I'm CEO of TBG and I've been thinking about the Web in creative ways since the year it began.

Leave A Reply

comments powered by Disqus