Technical Architecture for Modern Sourcing
Learn how sourcing platforms integrate with enterprise systems, manage data, and ensure security and compliance. For procurement and IT professionals.
Course Overview
Duration
45-60 minutes
Level
Advanced
Lessons
8 lessons
What you'll learn:
- Enterprise systems integration patterns and best practices
- Identity and access management (SSO, SCIM, RBAC)
- Data model design and integration requirements
- Audit logging principles and compliance
- Security and compliance requirements
- Extensibility and customization options
- Deployment models and non-functional requirements
Enterprise Systems Integration
Modern sourcing platforms don't operate in isolation. They integrate with multiple enterprise systems to enable end-to-end procurement workflows and ensure data consistency across your technology stack.
Common Integration Points
Figure 1: Enterprise systems integration architecture
ERP Systems
Integration with ERP systems (SAP, Oracle, Workday) for financial data, cost centers, budget validation, and purchase order creation.
Contract Lifecycle Management (CLM)
Integration with CLM systems (DocuSign, Icertis, Agiloft) for contract storage, versioning, compliance monitoring, and renewal management.
S2P Suites
Integration with Source-to-Pay platforms (Coupa, Ariba, Jaggaer) for purchase order creation, supplier master data, and invoice processing.
ITSM Platforms
Integration with IT Service Management platforms (ServiceNow, Jira Service Management) for IT procurement intake and service catalog integration.
SSO/IdP
Integration with identity providers (Okta, Azure AD, Ping) for single sign-on, user provisioning, and access management.
Data Warehouse and BI
Integration with data warehouses and BI tools (Snowflake, Tableau, Power BI) for reporting, analytics, and spend analysis.
Pro tip: Start with high-value integrations (SSO, ERP) and add others based on business needs. Prioritize integrations that improve user experience and data accuracy.
Integration Patterns
Three main integration patterns connect sourcing platforms with other systems. Each pattern has specific use cases and trade-offs. Understanding when to use each is critical for effective integration design.
Figure 2: Integration patterns comparison
API-First Integration
What it is
RESTful or GraphQL APIs for real-time, synchronous data exchange. Direct API calls between systems with immediate responses.
Best for
- User authentication and authorization
- Real-time budget checks
- Immediate contract updates
- Interactive workflows requiring instant feedback
Benefits
- Low latency (immediate responses)
- High reliability (direct communication)
- Real-time data consistency
- Standard protocols (REST, GraphQL)
Event-Based Integration
What it is
Message queues or event streams for asynchronous communication. Systems publish events that other systems consume.
Best for
- Audit log replication
- Notification systems
- Data synchronization
- High-volume, non-critical updates
Benefits
- Handles high volume efficiently
- Loose coupling (systems don't need to be available simultaneously)
- Scalable (can handle bursts)
- Resilient (messages can be retried)
File-Based Integration
What it is
Scheduled file transfers (CSV, XML, JSON) via SFTP or cloud storage. Systems exchange data files on a schedule.
Best for
- Bulk data imports
- Supplier master data sync
- Periodic reporting
- Legacy system integration
Benefits
- Simple to implement
- Works with legacy systems
- Batch processing efficiency
- No real-time dependency
Example: Use API integration for SSO (user needs immediate access). Use event-based for audit logs (high volume, can be processed asynchronously). Use file-based for monthly supplier data sync (bulk operation, not time-sensitive).
Pro tip: Most modern platforms use a combination of patterns. API for real-time operations, events for notifications, and files for bulk operations. Choose the pattern that matches your use case requirements.
Identity and Access Management
Modern sourcing platforms should integrate with your identity provider for seamless access control. This ensures users have the right access without manual user management and improves security.
Figure 4: Identity and access management architecture
Single Sign-On (SSO)
SAML and OIDC
Industry-standard protocols for single sign-on. Users authenticate once with your identity provider and access multiple systems without re-entering credentials.
SAML (Security Assertion Markup Language): XML-based protocol, widely adopted, good for enterprise SSO.
OIDC (OpenID Connect): Modern, JSON-based protocol built on OAuth 2.0. Simpler than SAML, better for modern applications.
Example: User logs into Okta, clicks sourcing platform link, automatically authenticated. No separate password needed. If user is deactivated in Okta, access is immediately revoked.
SCIM Provisioning
Automatic User Management
SCIM (System for Cross-domain Identity Management) enables automatic user provisioning and deprovisioning. When users are added or removed in your IdP, the sourcing platform updates automatically.
Provisioning: New user added in IdP → automatically created in sourcing platform with appropriate roles.
Deprovisioning: User removed in IdP → automatically deactivated in sourcing platform.
Updates: User role changed in IdP → automatically updated in sourcing platform.
Role-Based Access Control (RBAC)
Permission Management
Permissions based on roles rather than individual users. Supports fine-grained access to projects, documents, and functions.
Common Roles
- Procurement Manager: Create projects, manage suppliers, view all data
- Evaluator: Score proposals, view assigned projects, add comments
- Legal Reviewer: Review contracts, redline documents, approve terms
- Finance: View budgets, approve spending, access financial reports
- Requester: Create requests, view own projects, limited access
Common mistake: Not implementing SSO or using manual user management. This creates security risks, user frustration, and administrative overhead. SSO should be a requirement for any enterprise deployment.
Pro tip: Ensure RBAC supports both role-based and project-based permissions. Users may need different access levels for different projects. For example, a user might be an evaluator on one project but only a viewer on another.
Data Model Basics
Understanding core data entities helps with integration design and reporting requirements. A well-designed data model supports both operational workflows and analytical needs.
Figure 3: Core data model and entity relationships
Core Data Entities
Projects/Events
Sourcing projects or events (RFP, RFQ, etc.) with metadata like category, budget, timeline, status, owner, and stakeholders.
Requirements
Structured requirements with types (functional, non-functional, technical, business), priorities (must-have, nice-to-have), and traceability to evaluation criteria.
Suppliers
Supplier master data including company info, capabilities, compliance status, performance history, and relationship data.
Scoring
Evaluation scores, criteria, weights, evaluator assignments, comments, and scoring history. Links to requirements and suppliers.
Documents
RFX documents, supplier responses, contracts, attachments with versioning, metadata, and access controls.
Approvals
Approval workflows, approver assignments, status, comments, and audit trail. Links to projects, documents, and decisions.
Data Relationships
Understanding how entities relate helps with integration and reporting:
- Projects have many: Requirements, suppliers, documents, scores, approvals
- Suppliers participate in many: Projects, evaluations, contracts
- Requirements link to: Evaluation criteria, scoring, documents
- Documents belong to: Projects, suppliers, or both
- Approvals relate to: Projects, documents, or decisions
Pro tip: Ensure the data model supports both operational needs (workflow execution) and analytical needs (reporting, analytics). Consider denormalization for performance in reporting scenarios.
Audit Logging Principles
Comprehensive audit logs are essential for compliance and governance. Every significant action should be logged to create a complete record of who did what, when, and why.
What to Log
Who
User identity (username, email, user ID) and role. Essential for accountability and compliance.
What
Action performed (e.g., "Updated evaluation score", "Published RFP", "Approved contract"). Use clear, descriptive action names.
When
Timestamp with timezone. Use UTC for consistency, display in user's timezone. Include millisecond precision for high-volume systems.
Why
Context or reason (optional but valuable). User comments, system triggers, or business justification.
What Changed
Before and after values for modifications. Enables audit trail reconstruction and change analysis.
Audit Log Examples
2024-01-15 14:23:45.123 UTC
User: john.doe@company.com (Procurement Manager)
Action: Published RFP
Entity: Project ID: PRJ-2024-001
Details: RFP "Enterprise Software Selection" published to 5 suppliers
2024-01-16 09:12:33.456 UTC
User: jane.smith@company.com (Evaluator)
Action: Updated evaluation score
Entity: Score ID: SCR-001, Project: PRJ-2024-001
Details: Criteria: "Technical Capability", Score changed from 7 to 8, Comment: "Reviewed additional documentation"
Audit Log Best Practices
- Immutable logs: Audit logs should be write-only. Once written, they cannot be modified or deleted (except per retention policy).
- Separate storage: Store audit logs separately from operational data. This protects logs even if operational data is compromised.
- Retention policies: Define retention based on regulatory requirements. Some regulations require 7+ years of audit logs.
- Searchable: Logs should be searchable by user, action, entity, date range, and other relevant filters.
- Exportable: Support export for compliance reviews and investigations.
- Performance: Logging should not significantly impact system performance. Use asynchronous logging where possible.
Pro tip: Consider using event-based integration to replicate audit logs to a separate data warehouse. This provides redundancy, enables advanced analytics, and supports long-term retention without impacting operational performance.
Security and Compliance
Sourcing platforms handle sensitive procurement data including financial information, supplier details, and strategic plans. Security and compliance are non-negotiable requirements for enterprise deployments.
Figure 5: Security and compliance architecture
Security Certifications
SOC 2 Type II
Service Organization Control 2 Type II certification demonstrates controls over security, availability, processing integrity, confidentiality, and privacy. Annual audit required.
ISO 27001
International standard for information security management systems. Demonstrates systematic approach to managing sensitive information.
Other Certifications
Depending on industry: HIPAA (healthcare), PCI DSS (payment processing), FedRAMP (government), GDPR compliance (EU data protection).
Encryption
Encryption in Transit
Data encrypted while being transmitted over networks. Use TLS 1.2 or higher (TLS 1.3 preferred). All API calls, web traffic, and file transfers should use encryption.
Encryption at Rest
Data encrypted when stored on disk or in databases. Use AES-256 or equivalent. Encryption keys should be managed securely (key management service, hardware security modules).
Access Controls
- Multi-factor authentication (MFA): Require additional verification beyond password (SMS, authenticator app, hardware token). Essential for sensitive data access.
- Session management: Secure session handling, timeout policies, concurrent session limits, session invalidation on logout.
- IP restrictions: Option to restrict access to specific IP addresses or ranges. Useful for high-security environments.
- Password policies: Strong password requirements, password expiration, password history, account lockout after failed attempts.
Data Retention and Residency
Data Retention
Configurable retention policies aligned with legal and regulatory requirements. Some data may need to be retained for 7+ years. Support for data deletion per retention policies.
Data Residency
Options for regional data hosting to meet compliance needs (GDPR, data sovereignty laws). EU data in EU region, US data in US region, etc. Consider latency implications for global teams.
Common mistake: Not verifying security certifications or assuming all platforms meet enterprise security requirements. Always request current SOC 2 or ISO 27001 reports and review security documentation before deployment.
Pro tip: Security is not just about technology. Ensure the vendor has strong security practices: regular security audits, penetration testing, incident response procedures, and security training for staff.
Extensibility Concepts
Modern platforms should support customization and integration without requiring code changes to the core system. Extensibility enables organizations to adapt the platform to their specific needs.
Webhooks
Outbound Notifications
Webhooks send outbound notifications when events occur in the platform. Your systems can subscribe to events and react accordingly.
Common events: RFP published, evaluation completed, contract signed, approval required, supplier added
Use cases: Trigger workflows in other systems, send notifications, update dashboards, sync data
Implementation: Configure webhook URLs, select events, handle retries and failures
Example: When an RFP is published, a webhook notifies your notification system to send emails to stakeholders. When evaluation is completed, a webhook triggers contract creation in your CLM system.
SDK and API
Programmatic Access
Software Development Kit (SDK) and Application Programming Interface (API) provide programmatic access for custom integrations and automation.
REST API: Standard HTTP-based API for CRUD operations. Well-documented, easy to integrate.
GraphQL API: Flexible query language for efficient data fetching. Request only needed data.
SDK: Pre-built libraries in common languages (Python, JavaScript, Java) that simplify API usage.
Use cases: Custom integrations, automation scripts, data synchronization, bulk operations
Custom Fields
Extend Data Models
Add organization-specific fields to core data entities without modifying the base system. Enables customization while maintaining upgrade compatibility.
Common custom fields: Internal project codes, cost center mappings, custom classifications, organization-specific metadata
Field types: Text, number, date, dropdown, checkbox, multi-select
Use cases: Capture organization-specific data, integrate with internal systems, support custom reporting
Workflow Configuration
Configure Without Coding
Configure approval workflows, status transitions, and business rules without writing code. Enables business users to adapt processes.
Approval workflows: Define approvers, conditions, escalation rules, parallel vs sequential approvals
Status transitions: Define valid state changes, required conditions, automatic transitions
Business rules: Conditional logic, data validation, automatic assignments, notifications
Pro tip: Evaluate extensibility options before selecting a platform. Organizations have unique needs, and extensibility ensures the platform can adapt as requirements evolve. Avoid platforms that require vendor changes for every customization.
Deployment and Non-Functional Requirements
Understanding deployment models and non-functional requirements helps with security, compliance, and performance planning. These factors significantly impact total cost of ownership and user experience.
Deployment Options
Figure 6: Deployment architecture options
Cloud (SaaS)
Software as a Service delivery model. Platform hosted and maintained by vendor, accessed via internet.
Considerations: Internet dependency, data residency, vendor lock-in, customization limitations
Single-Tenant vs Multi-Tenant
Single-Tenant
- Dedicated instance per customer
- Data isolation
- Customization flexibility
- Higher cost
- More control
Multi-Tenant
- Shared instance
- Cost efficient
- Faster updates
- Logical data separation
- Less customization
Regional Hosting
Data residency options for compliance (e.g., EU data in EU region). Consider latency implications for global teams. Some platforms offer multi-region deployment.
Non-Functional Requirements
Availability
Uptime SLAs (e.g., 99.9% = ~8.76 hours downtime/year). Consider maintenance windows, planned vs unplanned downtime, and SLA guarantees.
Performance
Response times for common operations (page loads, searches, document uploads). Consider peak load handling and geographic distribution.
Scalability
Ability to handle growth in users, projects, data volume. Consider horizontal scaling, database performance, and storage limits.
Disaster Recovery
RTO (Recovery Time Objective) and RPO (Recovery Point Objective). How quickly can the system recover, and how much data can be lost?
Backup and Recovery
Regular backups, backup retention, recovery procedures, and testing. Ensure backups are tested regularly.
Pro tip: Create a non-functional requirements checklist before vendor evaluation. Document your specific requirements for availability, performance, scalability, and disaster recovery. Use this to compare vendors and negotiate SLAs.
Course Complete
You've mastered technical architecture for modern sourcing platforms. Ready to explore other Academy modules or start applying these concepts?