The business has selected a SaaS product. You are asked to review the integration architecture after the contract is signed. What do you do?
Show the full answer Hide the answer
Accept the position and be useful within it
The selection cannot be reopened, and arguing about the process will spend credibility for nothing. What can still change is how it is integrated, which is where most of the long-term cost lives anyway.
Review the things that are still decidable
The boundary. Build the integration behind your own interface, so the vendor sits behind an anti-corruption layer you control. Their model does not leak into yours, and replacing them later is a change at one boundary rather than everywhere.
Data flows. What personal data goes to them, where they process it, who their sub-processors are, and whether that is compatible with your residency and transfer obligations. This is the one that can still stop the launch, so it goes first.
Identity. Federated authentication rather than a separate user store. A vendor holding its own copy of your user directory is a lifecycle problem — leavers, particularly — and it is far cheaper to get right at integration time.
Failure behaviour. What your system does when they are unavailable, slow, or rate limiting. Their availability is now part of yours, and the degradation path is your design decision.
Data extraction. Can you get your data out, in what format, how often, and at what cost. Establish this now while the relationship is new and a request is easy.
Record what was not decidable
An honest decision record noting that the selection preceded the architecture review, what constraints that imposed, and what risks were accepted as a result. Not as a complaint — as the reasoning the next person will need.
The process point, made once and separately
Architecture involvement during selection would have surfaced the integration and residency constraints when they were still cheap. Raise it as a proposal for next time, to the person who owns the process, away from this project. Making it about this project makes it about blame.