The slings and arrows of outrageous enterprise systems diagrams
To integrate, or not to integrate?
That is the question
Whether ’tis nobler in the enterprise to define
The slings and arrows of outrageous systems diagrams
And by stipulating, grasp them
We’ve all been there: someone plugs their laptop into the projector, and on the screen appears the enterprise integration “vision”. There’s a stack of boxes filled with acronyms: CRM, ERP, CMS, CMP, DAM, PIM, MDM, BI…..with seemingly countless arrows from one to the other, sometimes directed one-to-one, often one-to-many, some one-directional, others bi-directional. Dotted lines put some systems in a group, and lost in the dots it says “API". People nod, affirm, and say “YES! This is how we must integrate!”
But as Hamlet said (and with apologies to the Bard), this must give us pause.
Such diagrams are frequently the multi-thousand-dollar deliverables of big-shot consulting firms or the oft-misunderstood emerged-from-the-basement enterprise architect, but let’s be honest: they are often amorphous, ill-defined, and say nothing about how such integrations will actually happen.
Img 1., Law firm MarTech stack architecture. Comprehensive, but what happens in practice? Source: CustomerThink.com
Know Your Slings and Arrows
If you’re a digital marketer or a digital workplace business owner, your role in defining exactly what those arrows do, and precisely how the slings will catapult data from one system to another, is far more vital than you may think.
You need to ask yourself:
- Where is the single source of the truth for my content or assets?
- Which systems will “own” the content (and where & how can I modify it, in what interface), vs. where can I use that content or metadata in another system, to search, target, or re-use that content appropriately?
- How often and how will the destination systems “listen to” or check for updated content or assets in the source system?
- Will the destination system ever have to write back to the source system, and if so, what data, and how?
- How will you handle content dependency (i.e., "where-used") analysis and reports?
Example: PIM plus DAM
Let’s take a practical but simple example. A typical product company has a PIM (Product Information Management) system as well as a DAM (Digital Asset Management) system. PIMs manage granular product data such as ingredients, regulatory information, colors, sizes, etc. Often in a DAM, marketers want to be able to search for assets based on product characteristics that originate in the PIM. And so we ask ourselves:
- Will the PIM send the product data to the DAM, or will the DAM look up the product data in the PIM? Or both? What are the capabilities of the existing APIs to do either?
- How will the PIM record map to the appropriate DAM record? What data will it push/pull precisely?
- Will the data model match exactly? If not, how will it map?
- What fields will be indexed in the DAM search?
- If someone using the DAM notes some aspect of product information that is incorrect or needs to change, what is the process to get it updated, if that data isn’t writable in the DAM?
- If I change an asset in the DAM, what product records in the PIM will get impacted?
These are the questions I am often asking our subscribers, whether we’re talking on an advisory call or in an on-site workshop.
Integration: How Over What
When I’m helping subscribers plot themselves in our RealScore Effectiveness Model, oftentimes it becomes clear that what’s holding them back from better re-use, findability, usability and workflow is ill-defined integrations, that were set up without proper consideration of the how rather than just the what.
To integrate, yes — but to define, perchance: make it more than a dream. If you’re grappling with defining your slings and arrows, let us know how we can help.