Associations are increasingly adopting multiple software systems to obtain the best of breed for each focus area. They are moving away from integrated systems that have multiple modules that manage varied IT functions but only excel in one or two. That means most associations use a multitude of IT systems – including a Customer Relationship Management (CRM), Learning Management System (LMS), Content Management System (CMS), Event Management, and Abstract Management systems. Any time a new system is introduced, it’s important that the new system integrates and “talks to” other systems already in place. In a vast majority of cases, these integrations are being developed on an ad-hoc (as needed) basis.
That’s the reason one of the most common issues we encounter is the number of point-to-point integrations that are in place at any large association. Technically this is referred to as “tight coupling”, where systems are highly dependent on each other.
Changes in one system often require changes to multiple systems.
When implementing a new software system, migrating all of the current integrations can be a project in itself. One that involves multiple stakeholders and vendors, and is not only complex and expensive but can result in project delays and issues post-go-live. The project cost and timeline are at the mercy of multiple vendors since changes need to be made in multiple systems to accommodate any change.
One that gets us away from this quagmire is to implement loose coupling between systems. Loose coupling is a coupling technique where two or more system components are interconnected but non-dependent on each other. We can achieve this by introducing a separate integration layer that facilitates all integration across the enterprise.
Source: Daily Fin Tech
When it’s time to change one of the systems, only the link between the integration layer and that one system needs to be re-implemented. All of the other IT systems and applications across the enterprise can continue to function as if nothing has changed.
This is a good technical architecture to implement for future scalability and stability. But this is also a good opportunity to implement to streamline processes and to extract business value. The integration layer can also be leveraged to house business processes and enterprise data. We can put such organization-wide business rules, such as membership tiers, in one common repository – one which is owned by the organization. This way, no one vendor or system controls your data or business processes.
For example, when customers’ membership information is saved in the CRM or AMS, any system that needs to know the current membership level of a user needs to integrate with the CRM. With an organization-wide User Data Service, any system that needs that information will just communicate with the business hub. By eliminating direct coupling with the CRM, we can also ensure the User Data Service is based on the organization’s view of a “User” and not any particular CRM’s.
In subsequent blog posts, we will explore the business hub in greater detail, and also come up with an implementation view of how this can be implemented in your association with existing tools.