Architecture, Security, and Integration Requirements

7.1 Target Architecture Patterns: SaaS, Hybrid, On-Prem and Implications

Your first architectural decision is the deployment pattern you are willing and able to operate. The market will offer you three broad options: SaaS, hybrid, and on-prem. Each can be successful. Each also implies a different split of responsibilities, a different upgrade model, and a different set of constraints on customization and integration. The purpose of defining a target pattern is not to limit innovation; it is to prevent the selection from drifting into an architecture you cannot support once the vendor’s sales team has moved on.

SaaS: Vendor-hosted software operated primarily by the vendor. You configure, govern, and integrate; the vendor patches, scales, and manages the core runtime. SaaS typically accelerates time-to-value and reduces operational burden, but you trade away some control over release timing and deep customization. A SaaS-first stance only works if your operating model is comfortable with frequent vendor updates and if your integration and security standards can be met without placing the platform behind bespoke network constructs.

Hybrid: A SaaS or cloud platform combined with customer-managed components such as an integration runtime, on-prem agents, edge processing, or customer-controlled data stores. Hybrid is common when you must keep certain data or processing in your environment, when you need private connectivity, or when you have heavy legacy integration. Hybrid succeeds when the boundary is clean: what runs where, who patches what, and how end-to-end failures are monitored. Hybrid fails when teams assume “someone else” owns the boundary and when the vendor’s reference architecture does not match your standard tooling.

On-prem: Software you deploy and operate in your data center or in customer-managed cloud infrastructure. On-prem can be justified by strict isolation requirements, immature SaaS options in a category, or a need for very deep customization. The tradeoff is clear: you become the operator of record. That means patching, vulnerability management, performance tuning, backups, disaster recovery, and monitoring are your responsibilities. If your organization cannot run modern operations at scale, on-prem increases risk even if it increases control.

Whatever pattern you choose, document the shared-responsibility model in operational terms. For SaaS, clarify what the vendor owns (infrastructure, patching, baseline hardening) versus what you own (role design, configuration governance, data quality, integration security). For hybrid, define the split for each component: who patches the integration runtime, who renews certificates, who monitors queues, and who is on call when a transaction fails mid-stream. For on-prem, confirm you have a credible plan for vulnerability remediation windows, log retention, backup testing, and capacity planning. A simple responsibilities matrix—component by component with Owner: vendor/customer, Operator: who runs it daily, and Escalation: who is paged—will surface gaps early and prevent “we assumed you handled that” failures after go-live.

For selection, the decision is rarely “SaaS good, on-prem bad.” The decision is whether the vendor’s operating model matches yours. Convert that into a small set of architecture questions you will insist every vendor answer with evidence. These questions separate vendors far more reliably than generic “cloud readiness” claims:

• Release management: How often are releases shipped, what notice do customers receive, and can you stage or defer changes in a controlled way?
• Extension model: What can be done through configuration versus custom code, where do extensions run, and what happens to them during upgrades?
• Environment strategy: How many environments are supported, how are refreshes handled, and how do you test upgrades and configuration changes safely?
• Data location and residency: Where is data stored and processed, what regions are supported, and can residency be enforced for sensitive domains?
• Connectivity options: What network patterns are supported (public endpoints, IP allowlists, private connectivity), and what are the operational requirements for each?
• Key management: How is encryption handled, and are customer-managed keys supported (and if so, who operates rotation and recovery)?

Turn your internal standards into architecture tripwires. A tripwire is binary: if the vendor cannot meet it, they are not viable. Common tripwires include a required cloud region, a required identity protocol, a prohibited data flow (for example, PII into non-approved regions), and a mandated integration platform. Tripwires should be validated early through written responses and evidence, not interpreted from slideware. If you find yourself debating whether a vendor “sort of meets” a tripwire, your tripwire is not written tightly enough.

Also be explicit about tenancy and isolation expectations. Multi-tenant SaaS is normal and often secure, but your risk posture may require additional controls such as customer-managed keys, dedicated runtimes, or enhanced audit evidence. Conversely, demanding single-tenant by default can dramatically increase cost and reduce the vendor’s ability to deliver continuous improvements. Treat tenancy as a requirement only when you can tie it to a clear control objective or regulatory constraint, and require evidence of how isolation is enforced and tested.

The most useful artifact here is a short Architecture Decision Record (ADR) for selection. The ADR is not a detailed design; it is a written constraint set that vendors must respect and that steering committees can defend. Keep it to one page:

• Target pattern: SaaS, hybrid, or on-prem, with rationale tied to outcomes and constraints.
• Boundary statement: which domains remain systems of record elsewhere and which domains may move into the new platform.
• Non-negotiables: data residency, encryption, identity standards, and network constraints.
• Operating assumptions: release cadence tolerance, environment needs, and internal support model.
• Evidence required: architecture diagrams, assurance reports, reference validations, and contractual clauses.
• Exception governance: who can approve exceptions and what documentation is required.

Use the ADR as a decision accelerator. If a vendor’s proposal implies an architecture you cannot operate on, you can eliminate or de-risk it early rather than discovering the mismatch during implementation. This is also how you protect your future-state principles—especially “configure before customize”—because the extension and environment model determines whether configuration is sustainable and whether customization will poison upgrades.

7.2 Identity, Access, Audit, and Regulatory Requirements

Identity and access controls determine whether the platform is usable and defensible. If access is too loose, you invite audit findings and data leakage. If access is too rigid or too manual, users will route around it through shared accounts, exports, and offline work. In selection, you need requirements that test both control strength and administrative practicality.

Start with authentication and identity integration. The requirement is not “supports SSO”; the requirement is that your enterprise identity provider is the front door and that access can be provisioned and revoked reliably. For most enterprises, the baseline is SSO: SAML 2.0 and/or OpenID Connect, Provisioning: automated provisioning via SCIM (or an equivalent supported mechanism), and MFA: enforced through the identity provider with conditional access policies. If the vendor requires local passwords for any meaningful user population, treat it as a risk. If provisioning is manual, treat it as an operating cost and a control weakness.

Then define authorization in business terms. Most products will offer role-based access control, but you must test whether the model matches your roles, your data boundaries, and your segregation-of-duties needs. Specify requirements at three levels: Role definitions: roles by job function with least privilege, Data scoping: constraints by region, legal entity, channel, or partner/customer relationship, and Action permissions: create, approve, modify, export, and administer. For partner or customer access, require strong external identity isolation (no cross-tenant visibility) and delegated administration that does not require internal superuser privileges.

Include lifecycle controls that are often overlooked in early requirements. Specify Session controls: idle timeouts, re-authentication for high-risk actions, and device/browser constraints if your policy requires them. Specify Access reviews: the ability to report who has access to what, support periodic certification by managers, and capture attestations for audit. Specify Joiner/mover/leaver handling: access changes must propagate quickly through provisioning, and deprovisioning must revoke tokens, API keys, and sessions. If you expect service accounts for integrations, require least-privilege roles, key rotation support, and clear audit logging for service-account activity. These “boring” controls are what keep a platform safe at scale without drowning administrators in manual work.

Segregation of duties should be written as explicit “cannot” statements and tied to workflows. Examples include: a user cannot submit and approve the same transaction; a user cannot change pricing or incentive rules and approve exceptions to those rules; and an administrator cannot both grant access and approve payouts. Ask vendors to show how SoD is implemented, not just described: role design, approval routing, audit evidence, and reporting that can be reviewed periodically. If your organization uses privileged access management, require compatibility for administrative actions and service accounts.

Auditability is the control layer that makes access and configuration defensible. Require Audit events: logins, role changes, rule changes, approvals, data exports, and sensitive record views where applicable. Require Integrity: logs that cannot be edited by normal administrators. Require Retention: retention policies that match your compliance needs, with the ability to export for long-term storage if the platform cannot retain logs long enough. Require Exportability: streaming or export options to your SIEM and data platform so you can correlate across systems. “We have logs” is not sufficient; the question is whether your auditors and security teams can use them without vendor intervention.

A reliable way to test auditability is to include an “audit walk-through” in finalist demos. Using the demo system, require the vendor to answer three questions end to end: Who approved this exception and what was the approval path? Who changed this rule and what was the previous value? Who accessed or exported this sensitive dataset, and was it authorized? If the vendor cannot answer these in minutes with standard tooling, you should assume the operational burden will be high.

Regulatory and assurance requirements should be expressed as evidence needs and contractual commitments. List the standards and obligations that matter to your enterprise and treat them as tripwires when they are truly mandatory. Common requirements include third-party assurance reports (such as SOC 2), security management certifications (such as ISO 27001), privacy obligations (data deletion, retention, and subject rights support), and industry-specific controls where applicable. Avoid turning this into a checkbox catalog. Instead, define what proof you will accept and when you will review it.

Issue an evidence request list early so vendors cannot defer security answers until the end. A practical shortlist evidence checklist includes:

• Assurance scope: current security assurance reports or certifications with scope statements.
• Security architecture: encryption model, tenant isolation explanation, and subprocessors list.
• Identity support: SSO protocols, provisioning options, and MFA enforcement approach.
• Audit logging: sample audit fields, retention options, and SIEM export/streaming mechanisms.
• Incident handling: severity levels, response SLAs, and breach notification commitments.
• Data handling: residency options, backup/restore approach, and data export/deletion capabilities.

Security is also about safe administration. If your future state depends on business administrators configuring workflows and rules, require guardrails: change versioning, review/approval for high-risk changes, separation between config and production publishing, and rollback capability. Require that configuration changes are audited and that you can report on them. This turns “empower the business” into a controlled capability rather than an uncontrolled risk transfer.

Finally, ensure security and compliance requirements are reflected in contracting. Technical capability without enforceable terms is fragile. Work with legal and procurement to define non-negotiable clauses for data ownership, audit rights, subcontractor controls, incident notification timelines, and exit rights (including data export and deletion confirmation). If the vendor can meet the requirement only with a specific deployment option, region, or module, capture that explicitly so it cannot be “optimized away” later in commercial negotiations.

7.3 Integration Approach: APIs, iPaaS, Eventing, Batch, Data Lake/Warehouse

Integration is where enterprise platforms meet reality. Your new system will not replace CRM, ERP, identity, analytics, and a dozen specialty tools overnight. The integration model you choose determines whether the platform becomes the backbone of your process or an additional screen with manual reconciliation behind it. In selection, you want requirements that test integration feasibility, integration operability, and vendor honesty about limits such as rate caps and supported patterns.

Start by stating your integration strategy in plain language: which patterns are preferred, which are allowed, and which are discouraged. In many enterprises the default is API-first: real-time APIs for transactional needs, supported by asynchronous mechanisms where decoupling improves resilience. If your organization mandates an iPaaS, treat it as a constraint and evaluate vendor compatibility explicitly. If you rely on batch interfaces for legacy systems, define where batch is acceptable and how reconciliation will work so “batch” doesn’t become a synonym for “we’ll fix it later.”

Map integrations to a small set of integration styles so they are designed consistently. The styles below cover most enterprise needs and help you write requirements that vendors can answer precisely:

• Synchronous APIs: request/response interactions where the caller needs an immediate decision (for example, pricing lookup or credit check).
• Asynchronous events: publish/subscribe messages for state changes (for example, order created, partner approved) where eventual consistency is acceptable.
• Orchestrated workflows: multi-step routing and transformations managed in an iPaaS or workflow engine.
• Batch/file: scheduled transfers for high-volume updates or systems without reliable APIs.
• Analytics feeds: data replication or extracts into a data lake/warehouse for reporting and cross-domain analytics.

Integration quality improves dramatically when you standardize semantics, not just plumbing. Define a small canonical model for the objects that cross many systems (customer/partner, product, price conditions, order, invoice) and require that mappings are explicit, versioned, and testable. For eventing in particular, require Schema governance: published schemas, compatibility rules for changes, and a process to notify consumers before breaking updates. Also require testability: sandbox environments, stable test data, and the ability to simulate failures. If vendors cannot provide realistic non-production environments or if sandboxes lag production features, integration development becomes guesswork and defects escape into go-live rehearsals.

For each style, specify the operational behaviors that prevent integration incidents from turning into business outages. For APIs, define authentication methods, rate limits, timeouts, and idempotency so retries don’t create duplicate transactions. For events, define delivery guarantees, schema versioning expectations, and dead-letter handling so failures are contained and recoverable. For orchestrated workflows, define how transformations are configured, how secrets are stored, and how error handling is standardized. For batch, define cutoff times, encryption, and reconciliation outputs. For analytics feeds, define freshness expectations and how sensitive fields are protected when leaving the application.

Operational requirements matter as much as technical mechanisms. Require Traceability: correlation IDs that propagate through APIs and events so support teams can follow a transaction across systems. Require Error visibility: actionable error messages, not generic codes, and support tooling that allows support teams to see what failed and why. Require Recoverability: controlled retries, replay options, and clear idempotency behavior. Require Ownership: defined runbooks and escalation paths for integration failures, including which failures are vendor-owned and which are customer-owned in hybrid models.

Decide early how analytics will be served. Many organizations use a combination: operational dashboards in the application and enterprise analytics in a warehouse. If a warehouse is in scope, require reliable extraction patterns (incremental loads, CDC where supported, or timestamp-based extracts), consistent definitions aligned to your business glossary, and reconciliation checks so warehouse numbers can be trusted. If partners or customers will consume analytics, treat access control and export logging as part of the integration requirements, not as a reporting afterthought.

To make vendor responses comparable, document each critical integration as an Interface Card and include it in your evaluation pack. Keep the card short, but specific enough that a vendor must commit to an approach:

• Interface: name and business purpose.
• Systems: source, target, and owners.
• Objects: entities and key identifiers.
• Style: API, event, orchestrated workflow, batch, or analytics feed.
• Latency and volume: expected timing and peak ranges.
• Security: authentication, encryption, and data classification.
• Error handling: retries, reconciliation, and business notification needs.
• Release criticality: required for release 1 or deferrable.

Use the cards in vendor deep dives and insist on at least one failure walk-through. “Show me the happy path” is not enough. Ask: what happens when the downstream system is down, when an API call times out, when an event consumer fails, or when a mapping is missing a required field? The quality of the answer—especially around monitoring and recovery—often correlates strongly with implementation success.

For the highest-risk interfaces, consider a time-boxed technical proof during finalist evaluation. This is not a full proof of concept; it is a focused test of connectivity, authentication, throughput, and error handling using your network and identity standards. A few days spent validating the integration boundary can prevent a selection that looks strong on paper but collapses under real enterprise constraints.

7.4 Performance, Resiliency, and Observability Requirements

Performance and resiliency requirements are easy to under-specify and hard to fix later. Users judge the platform by the slowest screens and the most frequent failures, not by the vendor’s benchmark charts. Your job in selection is to define measurable expectations for the critical journeys, validate that the platform can meet them at your scale, and ensure you can observe and operate the platform when things go wrong.

Define performance targets for the few transactions that matter most: revenue-critical actions, peak-time workflows, and control-sensitive steps such as approvals and postings. Specify Response time: median and 95th percentile targets for those actions, Concurrency: expected concurrent users by role, and Throughput: transaction volumes and peaks. If you have uncertainty, specify ranges and require vendors to document relevant limits such as API throttles and batch windows.

Define resiliency as service objectives. Specify Availability: required uptime for production (and how maintenance windows are treated), RTO: how quickly service must be restored after a major incident, and RPO: how much data loss is acceptable. For SaaS, require clarity on redundancy, incident communication, and restore testing. For hybrid and on-prem, specify what you must provide (multi-zone deployment, backups, failover) and require vendors to supply reference architectures and automation support.

Where possible, frame reliability as SLOs with an error budget rather than a single SLA number. Ask vendors how they measure uptime, what is excluded, and how maintenance windows are communicated. Require synthetic monitoring for key journeys (log in, create, approve, integrate) so you detect degradation before users escalate to production support, especially in SaaS where changes ship often.

Observability turns these commitments into operations. Require Logs: searchable application and audit logs with export options, Metrics: latency, error rates, queue depths, and capacity indicators, and Tracing: correlation IDs and distributed tracing support where transactions span systems. Require integration with your monitoring and security tooling, whether that is centralized logging, APM, or SIEM. If the vendor offers native monitoring, validate whether it supports your retention and escalation needs.

Finally, require a support model that matches enterprise reality: severity definitions, response-time commitments, escalation paths, and post-incident reviews. When possible, anchor the most critical non-functional commitments in contracts or SOW acceptance criteria. A concise checklist that works well for finalists is:

• Performance SLOs: response-time targets for critical transactions at expected scale.
• Availability SLA: uptime commitments, maintenance windows, and remedies.
• Disaster recovery: RTO/RPO commitments and restore testing cadence.
• Telemetry: logs/metrics/traces availability and export integrations.
• Support: coverage hours, escalation, and go-live support options.

Validate claims through multiple lenses: vendor documentation, architecture deep dives, and references at similar scale. If you specify these requirements clearly, you will not only make selection more defensible—you will also hand implement a measurable definition of “ready,” reducing the risk that go-live becomes the first real performance test.