Questions to Ask a System Integrator

An audit just flagged point-to-point connections nobody owns, and now three firms are proposing architectures to replace them that read almost the same. You have to run the evaluation yourself and then defend the choice: to the assessor who flagged it, to a finance lead who asks why the winning bid was not the cheapest, and to your own team when somebody asks who actually owns the integration code the vendor built.

Quick answer. Questions to ask a system integrator group into four stages: architecture and platform fit, regulated depth at the integration boundary, who actually does the work, and integration-code ownership and exit. A vendor who will not answer the ownership-at-exit question in writing has not been vetted.

A questionnaire written for general IT vendors is not aimed at the failures that are specific to integration work: a pattern chosen from the vendor’s habits instead of your estate, an audit trail that stops at the platform without reaching the interface, and interface definitions that turn out to be the vendor’s property on the day you want to move. If you want the diagnostic view of why integration breaks at regulated enterprise scale before you shop for anyone to fix it, that sits on Microsoft System Integration for Enterprise IT: How Regulated Enterprises Connect Disparate Microsoft Platforms Into a Governed Architecture. The broader question of whether an estate needs integration sits on Unifying Enterprise Operations Through Microsoft System Integration & Data Management. The four stages start after both of those, at the point where the decision is which vendor.

The decision rule, stated before the questions. When two stages disagree about a vendor, integration-code ownership and exit outranks the other three. A vendor strong on architecture and weak on ownership at exit leaves your team unable to operate what was built without calling that vendor back. A vendor weak on architecture and strong on ownership at exit leaves you holding artifacts you can hand to somebody else. The first situation is the one you cannot buy your way out of later, so it settles the tie. Within a single stage the questions are not weighted against each other: a vendor who answers three of four well and one badly has one unresolved question, and the honest handling is to put that one back to them in writing instead of averaging it away.

Stage 1: Architecture and platform fit

Four questions. The job of this stage is to find out whether the proposed design came from your estate or from what the vendor already builds. If the estate in question runs on older systems that cannot be taken offline while the work happens, the approach to that case sits on Legacy System Integration Consulting for Microsoft Environments: How i3solutions Approaches the Systems That Cannot Go Down.

Ask: which integration pattern are you proposing for each interface, and which pattern did you reject for that interface? Look for the vendor to name the pattern per interface and the rejected alternative, tied to the specific property of your estate that ruled it out. Applying one pattern across every interface, or naming a pattern with no rejected alternative, leaves you unable to tell whether an alternative was ever considered.

Ask: are you proposing native Azure integration services, an iPaaS such as MuleSoft or Boomi routed through Azure, or both, and which parts of our estate drove that? The answer should start from your existing licensing, your team’s skills and how you operate, and should name which parts of your estate the choice does not fit, rather than starting from what the vendor already builds on. If your integration surface is mostly Dynamics 365, this question narrows fast, and the mechanism-level criteria for that case live on Best Dynamics 365 Integration Partners: The Rubric to Rank Your Own Shortlist.

Ask: where does Dataverse sit in what you are proposing, and what does that decide for us later? A strong answer says where Dataverse is the system of record and where it is a staging surface, and what that constrains. A weak answer puts Dataverse in the architecture diagram without saying what it owns.

Ask: which of our interfaces are you treating as contracts, and where is each one defined? The answer to look for points at a definition that exists as an artifact, in a location you can open, and says who is allowed to change it. A weak answer describes interfaces in the proposal narrative and defines them nowhere.

Stage 2: Regulated depth at the integration boundary

The failure pattern this stage tests is a vendor whose compliance answers stop at the platform and never reach the interface. General compliance familiarity is common; a control-implementation statement or a log-retention specification tied to a named control identifier at the point where data crosses between systems is not, and that is what the four questions below test.

Ask: which control identifiers in our own regime will this design produce evidence against, and who writes the evidence? A strong answer names the identifiers your compliance function gave the vendor, and names the artifact that carries each one, such as a control-implementation statement or a log-retention specification. A weak answer names the regime and not the identifiers, or claims that a platform is compliant, which is a statement about the platform.

Ask: where does our data sit at each hop between systems, and which hops leave our tenant? A strong answer is hop by hop, and it says out loud which hops leave the tenant and what governs them there. A weak answer is a residency claim about the platform rather than about your interfaces.

Ask: what is recorded when a record moves between two systems, how long is it kept, and who can read it? A strong answer describes the audit trail the integration itself writes, its retention, and who has access to it. A weak answer points at platform-level sign-in logs and audit logs, which record who signed in and not what the interface did.

Ask: when an interface fails partway through, what happens to the half-written record, and where does our team see it? The vendor you want names the retry and dead-letter behavior and the log or dashboard your own team watches. A weak answer treats failure as a support question rather than a design question.

The determination for your own contract is not the vendor’s to make. Take the clause and the design to your compliance function or your contracting officer; a vendor who tells you their product makes you compliant has answered a question nobody in your organization is allowed to accept.

Stage 3: Who actually does the work

Delivery quality on integration work is a function of who is in the room when the interface decisions get made. Four questions get you the names. If the decision in front of you is the wider one of which Microsoft delivery partner to engage, rather than which integrator for this build, the selection mechanics for that sit on Microsoft Delivery Partner Selection Mechanics.

Ask: name the people who will do this work, their seniority, and what else they are assigned to. A strong answer names them and says who is accountable when an interface breaks after go-live. A weak answer names a delivery model but not the people, or produces a proposal team that turns out not to be the delivery team.

Ask: which hours does the delivery team overlap with ours for the decisions that need us in the room? A strong answer is a number of overlapping hours and the named decisions that require your people. A weak answer routes your architects through a coordination layer, which is where interface decisions go to get made without you.

Ask: who makes an architecture decision when your team and ours disagree, and where is that decision recorded? A strong answer names a decision owner and an artifact that holds the decision record. A weak answer escalates to a project manager with no architectural authority.

Ask: what will your team be doing that ours has to keep doing after you leave, and what have you built to make that possible? Here the right answer treats knowledge transfer as a deliverable with its own exit criteria. A weak answer has knowledge transfer as a phase name with nothing underneath it. If the work in question is SharePoint development instead of integration, the partner-evaluation criteria for that case live on How to Evaluate a SharePoint Development Partner.

Stage 4: Integration-code ownership and exit

This is the stage that settles a tie, and its four questions are about artifacts rather than assurances. The reason it settles ties is that the integration layer is the one part of a build a vendor can hold without you noticing, until the day you try to leave.

Ask: who owns the interface definitions, and where do they live on the last day of the engagement? A strong answer puts them in a repository you control, from the first sprint rather than at handover. A weak answer promises documentation at the end, which is a different thing from ownership.

Ask: who owns the connector configurations and the credentials the integrations run on, and how are they handed over? A strong answer describes credentials held in your own tenant throughout, and a named handover of the configuration. A weak answer has the vendor’s own accounts running your integrations.

Ask: who owns the pipeline and orchestration definitions, and are they version-controlled in a repository we control? A strong answer is yes, with the repository named. A weak answer is that the vendor maintains them, which is the same answer as no.

Ask: if we terminate the day after go-live, what exactly do we hold, and what would we still need you for? What you want back is a specific inventory and an honest short list of what would be hard without them. A weak answer is that termination will not be necessary.

When the Same Firm Also Builds the Application

A contract can say that all work product belongs to the client while the repository, the build pipeline and the cloud accounts the application runs on all sit with the firm that wrote it. The four questions above test the integration layer. When the same engagement also builds a custom application on it, the same exit test applies one layer up, still inside this stage, and a general work-product clause does not answer it.

Ask: who owns the application source code, including any components the firm brings from earlier work, and which repository does it live in from the first sprint? A strong answer puts the code in a repository your organization controls from the start, and names the firm’s pre-existing components in writing, with the terms under which you may keep using them, change them and hand them to another firm. A weak answer says you own everything written for you and leaves the firm’s own libraries and frameworks unnamed, or delivers the code as an archive at the end.

Ask: who owns the build and release pipelines and the infrastructure-as-code definitions, and whose accounts do they run under? A strong answer is that they live in your repository, run under your accounts, and let your own team deploy without the firm. A weak answer has a build server or a cloud subscription registered in the firm’s name.

Ask: which credentials, certificates, keys, service accounts and third-party subscriptions does the application run on, and whose name is each one in? A strong answer is an inventory, with each item held in your own tenant or registered to your organization throughout the build. A weak answer leaves something production depends on in the firm’s accounts, or in one developer’s personal account.

Ask: if the engagement ends the day after go-live, could another team build, deploy and support this application from the repositories, accounts and documents the client holds, and what would that team still be missing? A strong answer points to build instructions, architecture and decision records, and runbooks that exist during the build, plus a candid list of the parts another team would find hard. A weak answer is that documentation will be provided at handover.

These answers belong in the contract before it is signed, in the part that says who owns the work product, how any material the firm owned before the engagement is licensed or assigned to you, and what is delivered at termination. That part works through definitions of what counts as work product, what the firm keeps as its own and what is handed over at the end. What it should say for your organization is for your counsel to determine and, on a government contract, the contracting officer. The security requirements for how the application is built are a separate section of the same contract.

Where the application is small, runs entirely inside your own tenant and your own pipeline, and the firm brings no reusable components of its own, the first and last of these questions are enough.

How i3solutions answers these questions

Put in the same order as the stages, so you can hold this against what other vendors tell you. Read each one against the artifact its stage asked for: a control-implementation statement or a log-retention specification for a named control identifier, interface definitions and connector configurations in a repository you control, and the retry and dead-letter behavior your own team watches.

Architecture and platform fit. i3solutions designs Azure integration architecture and builds and operates Azure Logic Apps workflows for enterprise clients, including running them on an ongoing basis rather than only building them.

Regulated depth at the integration boundary. i3solutions took ownership of the control architecture against AC.L2-3.1.1 and the audit-log design against AU.L2-3.3.1 and delivered the evidence the C3PAO required. The regulated-depth stage asks a vendor to point at exactly that: control identifiers and the evidence, not a framework name.

Who actually does the work. i3solutions delivers through its Expert Delivery Model, a four-phase methodology (discovery, architecture, build, and knowledge transfer) with explicit exit criteria and delivery assurance at every handoff. i3solutions typically takes ownership of architecture and governance first, while existing augmented teams continue execution inside the new standards.

Integration-code ownership and exit. i3solutions unified identity and automated provisioning across systems for 125,000 users by treating the interfaces as owned, governed contracts. An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in.

When a lighter pass is the proportionate one

A four-stage evaluation is not always the right amount of process, and running one where it does not belong costs you time and buys nothing. If your environment is single-platform, if the integration surface is a handful of touchpoints, and if no regulatory regime bites at the interface layer, then stage 1 and stage 4 are enough on their own: get the pattern right and get ownership in the contract, and skip the rest. The full pass earns its place when the estate is mixed, when a regime reaches the data in transit, or when the interfaces will outlive the vendor relationship. If none of those three is true for you, the honest advice is to run the short version.

What a first conversation is about

Bring your shortlist and the answers you have already collected. The conversation is about where those answers are thin and which stage you have not tested yet. The discussion is technical and about your estate, not a qualification call. Talk to a senior integration architect about the questions your shortlist has not answered yet.

Key Takeaways

Questions to ask a system integrator group into four stages: architecture and platform fit, regulated depth at the integration boundary, who actually does the work, and integration-code ownership and exit.
When two stages disagree about a vendor, integration-code ownership and exit outranks the other three, because it is the failure you cannot buy your way out of afterwards.
These questions are paired with what a strong answer contains and what a weak answer sounds like, so the evaluation produces a record you can defend, not an impression.
Control evidence is tested at the integration boundary: control identifiers, hop-by-hop data location, and what the interface itself records. A framework name is not an answer.
A single-platform, low-touchpoint, unregulated environment does not need the full pass. Stage 1 and stage 4 are enough on their own.

Frequently Asked Questions

Who should own the integration code after a vendor engagement ends?

You should, and it belongs in the contract before the work starts rather than in a handover conversation at the end. Ask which repository the interface definitions, connector configurations and pipeline definitions live in, who holds the credentials those integrations use, and what you are left holding on the day the engagement ends. A vendor that treats the integration layer as its own intellectual property will not release the interfaces at the end, and that is discoverable before the contract is signed.

MuleSoft or Boomi, or native Azure integration services: what should we ask a vendor about the choice?

Ask which parts of your own estate drove the choice, and which parts it does not fit. A vendor proposing an iPaaS routed through Azure should be able to say what it adds over native Azure integration services for your specific interfaces, and what it asks of skills your team does not currently have. A vendor proposing native Azure integration services should be able to answer the same question in reverse. An answer that begins with the vendor’s own default stack is an answer about the vendor, not about your estate.

What questions belong in an RFP for a system integrator at a regulated enterprise?

Group them by decision stage, because the stages fail differently. Architecture and platform fit asks whether the proposed pattern came from your estate or from the vendor’s habits. Regulated depth at the integration boundary asks which control identifiers in your own regime the design produces evidence against, and who writes that evidence. Who actually does the work asks for named people and for accountability after go-live. Integration-code ownership and exit asks what you hold on the day the engagement ends.

How do we tell whether a vendor’s regulated experience reaches the integration boundary?

Ask for control identifiers, not for the name of a regime. A vendor that has done regulated integration work can say which controls the audit trail across integration touchpoints was designed against, where the data sits at each hop, and which of those hops leave your tenant. A vendor whose compliance experience is general answers with a framework name and a certificate. The determination for your own contract goes to your compliance function or your contracting officer and the clause itself; a vendor cannot make it for you.