System integrator evaluation runs in four sequential stages: architecture and platform fit, regulated depth at the integration boundary, who actually does the work, and integration-code ownership and exit. When stages conflict, ownership and exit override the others, because weak architectural fit can be remedied by replacing the vendor while vendor lock-in at the integration layer cannot.
Key Takeaways
System integrator evaluation runs in four sequential stages: architecture and platform fit, regulated depth at the integration boundary, who actually does the work, and integration-code ownership and exit. Ordering matters because early failures make later stages moot.
When stages conflict, ownership and exit override the others. Weak architectural fit can be remedied by replacing the vendor. Vendor lock-in at the integration layer cannot.
Architecture answers should justify the specific integration patterns against rejected alternatives and explain how the choices align with your existing systems and skills. A design that would have arrived unchanged for any client is a template, not architecture.
Compliance answers strong enough to hold up in a review reference specific control identifiers (not just framework names), describe data location at each transition point, and specify what the integration layer itself records.
Confirm that interface definitions, configurations, and credentials sit in repositories you control from project start, not just at handover. Ownership decided at handover is ownership the vendor has controlled for the length of the engagement.
Why the Order of the Questions Matters
Every system integrator proposal reads the same way. The differentiator is not the deck; it is what happens when a specific question is answered and the answer either holds up or does not. Four stages of questions, sequenced deliberately, do that separation. Skipping a stage does not compress the evaluation: it postpones the finding to a phase where the finding costs more.
Stage 1: Architecture and Platform Fit
Determines whether the proposed design originated from your specific environment or reflects the vendor’s standard offering. The test: ask the vendor to justify a specific integration pattern in the design against a rejected alternative, and to explain how that choice aligns with your existing systems and skills. A design that would have arrived unchanged for any client is a template. A design that names your systems, your data classifications, and your team’s skills is architecture.
A design that would have arrived unchanged for any client is a template.
What “produced” looks like at this stage: a redacted architecture decision record from comparable work showing the alternatives considered and the reasoning for the one chosen. What “asserted” looks like: an assurance that the design fits, unaccompanied by a decision record. What “absent” looks like: the question is answered in a slide about the vendor’s methodology.
Stage 2: Regulated Depth at the Integration Boundary
Compliance answers at the platform level are common; compliance answers at the point where data actually moves between systems are rarer. This stage tests whether the vendor can describe compliance at the boundary rather than in the abstract.
Strong answers cite specific control identifiers rather than framework names alone. They describe data location at each transition point: where the data physically sits when it is in flight, when it is in transformation, when it lands. They specify what the integration layer itself records, because the integration layer’s log is the evidence a review reads afterwards.
An answer that says “we’re SOC 2 compliant” is not an answer to this stage’s question. An answer that maps CC6.1 to the specific control that enforces access on the integration layer, and names the log that records enforcement, is.
Integration Depth Is the Scarcest Microsoft Skill
Logic Apps, Service Bus, and API-led architecture are specialist territory, and product knowledge does not substitute for it. i3solutions’ integration specialists are senior-level, 100% US-based, and have wired enterprise stacks for 30 years.
The staffing pyramid is where integration programs quietly change shape between contract and delivery. Senior architects appear in the proposal; junior developers appear in the standup. This stage’s questions establish who is committed by name and how their availability is preserved.
Senior architects appear in the proposal; junior developers appear in the standup.
Ask for named team members with weekly allocation figures across specific dates. Ask for overlapping work hours where cross-team decisions have to happen. Ask for documented decision records (see Stage 1: the artifacts overlap deliberately). Ask for explicit knowledge-transfer exit criteria: what your team knows on the last day that they did not know on the first day, and how that knowledge was captured.
A vendor that can name the people, allocate their time, and describe how knowledge stays with your team is describing an engagement. A vendor that answers with role titles and organization charts is describing a proposal.
Stage 4: Integration-Code Ownership and Exit
The most expensive vendor-lock-in in integration work is not license lock-in; it is code-and-configuration lock-in at the integration layer. When the engagement ends, whatever runs between your systems has to be operable by your team or by whoever you engage next, and the ownership that decides that is decided at project start, not at handover.
Confirm that interface definitions, configurations, and credentials sit in repositories your organization controls (your source control, your key vault, your CI/CD tenants) from day one. A vendor that develops in its own repository and hands over at the end has controlled the artifacts for the entire engagement, and the handover is a transfer of a state you never saw evolve.
Documented decision records (again from Stage 1) belong in the same repositories. So does the runbook: what runs on a schedule, what breaks it, what to check first, and who was called last time.
When Stages Conflict
Ownership and exit override the others when the stages disagree. The reasoning is asymmetric: weak architectural fit can be remedied by replacing the vendor later, because the code and configurations sit in your repositories and can be rebuilt on a different design. Weak ownership and exit cannot be remedied by replacing the vendor, because there is nothing to hand to the replacement.
When the Full Evaluation Applies, and When It Does Not
The full four-stage evaluation suits multi-platform environments, regulated data flows, or interfaces expected to outlast the vendor relationship. Single-platform, low-complexity, unregulated scenarios may only require stages 1 and 4: architecture fit to establish that the design is reasonable, and ownership and exit to establish that the result is yours.
How i3solutions Answers These Questions
i3solutions has integrated Microsoft estates since 1997, with senior, 100 percent US-based teams. On the four stages: architecture decisions travel with the engagement in decision records; compliance answers reference the specific controls the integration layer enforces; the people named in the proposal are the people who arrive; and interface definitions, configurations, and credentials sit in the customer’s repositories from day one. Ask any firm for the same evidence; the ones that can produce it are the ones you can build a program around.
Michael Branson
Founder/COO
Michael Branson co-founded i3solutions 30 years ago and brings executive, operational, and technical perspective to organizations working in complex, secure, and mission-critical environments. His insights focus on business process consulting, automation, data analytics, collaboration, secure operating models, and the operational discipline required to turn technology investments into practical business systems with measurable value.
In four sequential stages: architecture and platform fit (whether the design originated from your environment or the vendor's standard offering), regulated depth at the integration boundary (compliance answers at the point where data moves, not in the abstract), who actually does the work (named team members with weekly allocation and knowledge-transfer criteria), and integration-code ownership and exit (repositories you control from project start). Ordering matters because early failures make later stages moot.
Ownership and exit. Weak architectural fit can be remedied by replacing the vendor later, because the code and configurations sit in your repositories and can be rebuilt on a different design. Weak ownership and exit cannot be remedied by replacing the vendor, because there is nothing to hand to the replacement.
Specific control identifiers rather than framework names alone, data location described at each transition point, and what the integration layer itself records named explicitly. 'We're SOC 2 compliant' is not an answer to this stage's question. Mapping CC6.1 to the specific control that enforces access on the integration layer and naming the log that records enforcement is.
Ask for named team members with weekly allocation figures across specific dates, overlapping work hours for cross-team decisions, documented decision records, and explicit knowledge-transfer exit criteria. A vendor that answers with role titles and organization charts is describing a proposal; a vendor that names people, allocates their time, and describes how knowledge stays with your team is describing an engagement.
You should, from project start rather than at handover. Confirm that interface definitions, configurations, and credentials sit in repositories your organization controls (your source control, your key vault, your CI/CD tenants) from day one. A vendor that develops in its own repository and hands over at the end has controlled the artifacts for the entire engagement, and the handover is a transfer of a state you never saw evolve.
Three Configured Products Are Not an Integrated System
When business processes cross system boundaries by hand, the integration was promised and never architected. i3solutions' senior integration advisors work with enterprise IT leaders ready to scope the architecture that connects the stack.
