"We have a module for that": The plug-n-play CMS integration myth
Integrations in CMS projects often get complicated, but customers love simplicity. So are ready-made modules the perfect answer?
Plug-n-pray?
When CMS implementers answer RFPs or do sales pitches, integrating the CMS with another system always comes up. It could be a CRM, PIM, DAM or any other flavor of three-letter acronyms.
One thing is for sure: Implementers love to be able to answer "Integrate with [System X]? Sure, we have a module for that."
It lets us tick the box and move on to the next question, and most buyers happily accept such an answer.
The buyer's interpretation is something like:
- "We have a plug-n-play integration module that we can drop right into your project, it will work with the most recent version of System X, and is flexible enough to cover all your needs."
However, what the implementers really mean is more along the lines of:
- "We've integrated with an older version of System X in the past, and we hope the APIs haven't changed that much in the newest version."
- "We've integrated with System X before, but it's got loads of dependencies and isn't really a standalone module. Some of the code should be reusable, though."
- "We've integrated with System X before, but our module/framework only runs on [specific OS/Web Server/programming language]. Your technology stack needs to match that exactly."
- "We do actually have a standalone, reusable module that integrates with System X, but it's heavily tailored for a previous client's needs (that may or may not match yours)."
- "There is an official module for integration with System X from the CMS vendor, but it only allows a limited set of generic, basic actions and cannot be customized by us."
Transparency is key
Now, I'm not saying CMS implementers deliberately give misleading answers or unrealistic promises - RFPs and sales pitches don't always allow room for elaboration on every issue. There are times when the buyer's requirements are unclear. Sometimes, there are even obstacles that the implementer cannot yet anticipate.
But serious implementers should at least try their best to be as transparent as possible about the state and fit of any integrations they claim they can deliver. Obscuring such details might win the initial bid, but will be painfully exposed as the project gets underway.
Depending on how detailed and transparent the implementers choose to answer, this is a potential minefield that many buyers aren't aware they're walking into. Integrations are easily one of the most costly factors in a CMS project, if done wrong, and worst case, may lead to a failed project.
Whenever integration comes up, buyers shouldn't settle for one-liner answers. Make sure to ask some follow-up questions to the implementers. I'll get into those in my next blog post: 5 critical questions to ask your CMS integration partner