Eloqua Blog · Architecture
Part 2. Eloqua Architecture Document
Build a central Eloqua Architecture Document so backend programs, setup details, integrations and ownership knowledge do not disappear into silos.
📅 First published: May 24, 2022
⏱ Reading time: 6 minutes • 👤 Author: Greg Staunton • 🎯 Focus: Eloqua architecture, change history, implementation documentation
If you do not have an Eloqua Architecture Document you are going to have a bad time. You need to fully document everything before testing and release. Your Eloqua Architecture Document will detail all the customized backend parts of your Eloqua setup so, if there are problems or you need to make updates, you know exactly where everything is.
Greg Staunton
What Will You Do If Your Lead Eloqua Person Leaves?
I have rarely come across a client implementing or re-implementing Eloqua that already has a complete system architecture document. An Eloqua Architecture Document is a central repository for background programs, Eloqua setup information and integration details with other platforms.
It is best practice to create and maintain this document. Used correctly, your Eloqua Architecture Document will:
- Speed up marketing automation adoption
- Reduce costs associated with updating or improving processes
- Destroy Eloqua backend knowledge silos
- Increase the ramp-up speed of new marketing employees
When you create your Eloqua Architecture Document, store it in a central location so every Eloqua developer, administrator and agency partner can work from the same source of truth.
How To Use The Eloqua Architecture Document
The Eloqua Architecture Document should start as a skeleton template and then be updated at each subsequent step of your Eloqua implementation and continued support.
Save it somewhere central and give the right Eloqua developer users or Eloqua agencies access to it. During the initial implementation, a shared workspace such as Dropbox can help the implementation team collaborate before the document is released to the wider marketing audience.
Change History
The first section heading you will come to is the Change History. As the name suggests, Change History documents changes made while you are implementing or maintaining your Eloqua instance.
It lets you confirm that everyone is working from the most up-to-date version before any work is carried out. Once the document has been updated and released, the previous Eloqua Architecture Document is replaced by the new one.
Important
Keep a version of each released document. If you ever need to roll back, you will be thankful that the previous version still exists.
There are four headings for the Change History:
Version
The version number of the Eloqua Architecture Document. Use at least two decimal places so major releases and smaller updates are easy to track.
Date
The date field records when the document was modified, regardless of the type of update.
Description
The description details what was updated. Keep statuses consistent, such as Major Release, Update or New.
Author
The author is the person who created, updated and saved the section before replacing the existing document.
A major release should usually follow a planned release cycle or a significant update to the Eloqua backend. Smaller changes, such as an update to an explicit lead scoring model, can use the decimal place.
Why Maintain The Change History?
If you do not maintain a change history, you will not know the current state of your Eloqua instance at a glance. You should be able to see a high level overview of how the system has been architected and then drill into each individual backend custom solution.
Eloqua Architecture Navigation
Over time, your Eloqua Architecture Document will get very large. Each separate section should be given a chapter number, just like a textbook, and then a sub-chapter number.
This makes the document much easier to navigate and helps Eloqua developers describe exactly which area they are working on. When those sections are referenced in the change history log, you know precisely what has been added, updated or released.
The navigation should be interactive. Clicking on a section or subsection should jump directly to that area, saving the frustration of manually scrolling through the entire document.
Next Eloqua article
Part 3. Eloqua Marketing Systems Architecture
Once the document structure is in place, the next step is mapping the systems and data flows around Eloqua.
Read article