A practical architecture review: Integration observability
Why this deserves attention
A connected process needs end-to-end visibility across platform and team boundaries. Clarity here reduces both delivery risk and the long-term cost of ownership.
System-specific logs cannot answer which customer journey failed or whether a retry completed the original intent. On 2 December 2024, this archive entry records the principle as a practical design concern rather than a product announcement.
Review the evidence
Look at integration observability through the questions an architecture review should ask before approving the design. The objective is not to introduce more process; it is to expose the few decisions that determine reliability, ownership and future change.
Propagate correlation identifiers, record meaningful business states and alert on outcomes rather than raw technical noise. Record the decision close to the solution so that delivery, support and future architecture reviews work from the same intent.
What good looks like
Support teams move from searching for evidence to acting on a clearly identified failure. The team can describe the expected behaviour, the owner, the evidence of success and the response when reality differs from the design.
A useful next step is to review one live implementation against this principle, identify the largest unowned assumption and turn it into a bounded improvement with a measurable outcome.
Official reference
Salesforce Architecture: Integration Patterns