Architecture, Integration, and Interoperability

Introduction and Context

Supply chain management (SCM) software rarely operates as a single, self-contained application. A manufacturer may use an enterprise resource planning (ERP) system for financials and production, a warehouse management system (WMS), a transportation management system (TMS), supplier portals, customer platforms, IoT devices, and analytical tools. These systems create value only when relevant information can move between them accurately, securely, and at the required speed.

Architecture describes how software components are organized and deployed. Integration describes how those components exchange data and coordinate processes. Interoperability is the broader capability of different systems, organizations, and technologies to work together despite differences in design, ownership, or implementation. Interoperability therefore includes technical connectivity, common data meanings, compatible processes, and appropriate governance.

For supply chain managers, architecture is not merely an information-technology decision. It affects implementation speed, total cost, resilience, scalability, cybersecurity, data ownership, process visibility, and the ability to collaborate with customers and trading partners.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Compare on-premises, cloud, SaaS, platform, and composable architectures.
2. Distinguish APIs, EDI, middleware, event-driven integration, and IoT connectivity.
3. Explain the role of canonical data models, standards, master data, and semantic interoperability.
4. Evaluate integration patterns for customers, suppliers, logistics providers, and other partners.
5. Analyze architectural trade-offs involving cost, control, resilience, security, and scalability.
6. Design a practical integration approach for a multi-enterprise supply chain.

1. Architectural Foundations

1.1 Layers of an SCM technology architecture

A useful architecture separates several layers:

• Device and edge layer: sensors, scanners, telematics units, RFID readers, programmable controllers, and mobile devices.
• Connectivity layer: networks, message brokers, gateways, and secure communication protocols.
• Integration layer: APIs, EDI translators, middleware, orchestration services, and event brokers.
• Application layer: ERP, WMS, TMS, order management, supplier relationship management, and planning systems.
• Data and analytics layer: operational databases, data warehouses, data lakes, master-data services, and analytical models.
• Experience layer: employee screens, customer portals, supplier portals, mobile applications, and dashboards.
• Governance and security layer: identity, access control, auditability, data quality, privacy, retention, and compliance.

The layers are conceptual rather than strictly physical. A SaaS provider may supply application, data, security, and integration capabilities together, while a platform architecture may expose services used by several applications.

1.2 Deployment and architectural models

#### On-premises architecture

In an on-premises model, the organization owns or directly controls servers, databases, networks, and application installations in its facilities or dedicated data centers. This model can support extensive customization, direct control of sensitive data, and integration with legacy equipment. It may be appropriate where regulatory restrictions, low-latency plant control, or specialized processes are important.

Its disadvantages include high capital expenditure, internal responsibility for upgrades and cybersecurity, slower provisioning, and difficulty scaling rapidly across regions. Hardware failure, staffing shortages, and aging software can become strategic risks.

#### Cloud infrastructure and cloud-hosted applications

Cloud computing provides shared or dedicated computing resources through a network. Infrastructure-as-a-Service (IaaS) supplies virtual machines, storage, and networks. Platform-as-a-Service (PaaS) supplies managed runtime environments, databases, integration tools, and development services. Cloud-hosted applications may be operated by the customer or by a provider.

Cloud models generally improve elasticity and geographic availability. However, they do not automatically guarantee resilience, security, or interoperability. Poorly designed interfaces, excessive data transfer, provider dependence, and misconfigured identity controls remain possible.

#### Software as a Service (SaaS)

In SaaS, a provider operates the application and commonly manages infrastructure, maintenance, upgrades, and much of the security responsibility. Customers usually subscribe rather than purchase a perpetual license. SaaS is attractive for standardized processes, rapid deployment, predictable budgeting, and access to continuous innovation.

Trade-offs include limited control over release timing, dependence on provider APIs, possible configuration constraints, data-residency questions, and the risk of vendor lock-in. A SaaS implementation still requires customer-owned governance for roles, data quality, process design, and partner coordination.

#### Platform architecture

A platform provides reusable capabilities upon which multiple applications or extensions can be built. Examples include identity services, workflow, integration, analytics, data management, and application development tools. A supply chain platform may connect planning, execution, visibility, and collaboration applications while maintaining shared services.

Platforms can reduce duplicate development and support ecosystem innovation. Conversely, platform governance is demanding. Poorly controlled extensions can create inconsistent data, security vulnerabilities, and dependencies on proprietary services.

#### Composable architecture

Composable architecture organizes business capabilities as modular, replaceable components. Instead of adopting one monolithic suite, an organization may combine best-of-breed services for inventory, transportation, forecasting, fulfillment, and supplier collaboration. Components are connected through APIs, events, and shared data contracts.

Composability supports rapid adaptation and selective replacement. It also increases integration complexity, testing effort, observability requirements, and the risk that a process becomes fragmented across vendors. Composability is therefore a management capability, not simply a procurement strategy.

1.3 Monolithic, layered, service-oriented, and microservice designs

A monolithic application contains many capabilities in one deployable unit. It can be efficient to operate initially but difficult to change selectively. A layered design separates presentation, business logic, integration, and data responsibilities. Service-oriented architecture exposes relatively independent business services, such as inventory availability or shipment booking. Microservices take this modularity further by making services independently deployable, often with separate data stores.

Microservices are not automatically superior. They can improve independent scaling and release autonomy, but they introduce distributed transactions, network failure, version management, and operational observability challenges. For many organizations, a well-designed modular suite is more manageable than a highly fragmented microservice landscape.

2. Integration Mechanisms

2.1 APIs

An application programming interface (API) defines how one software component requests data or action from another. A REST API commonly uses HTTP methods such as GET, POST, PUT, and DELETE, with JSON or XML representations. GraphQL allows a consumer to request selected data fields. gRPC and other remote-procedure approaches may be used where efficient service-to-service communication is important.

A robust supply chain API should specify:

• endpoint and operation;
• authentication and authorization;
• request and response structure;
• identifiers and units of measure;
• validation rules;
• error codes and recovery guidance;
• rate limits;
• versioning policy;
• idempotency behavior; and
• monitoring and audit requirements.

Idempotency is important in logistics. If a network timeout causes a client to retry a shipment-booking request, the provider should not create two bookings. An idempotency key allows the receiver to recognize that repeated requests represent one business action.

APIs are appropriate for real-time queries, transaction submission, partner portals, mobile applications, and orchestration across modern services. They are less effective when a partner has no technical capability to consume them or when large, scheduled batches are more efficient.

2.2 Electronic Data Interchange

Electronic Data Interchange (EDI) exchanges structured business documents between organizations. Common transaction types include purchase orders, purchase-order acknowledgments, advance shipping notices, invoices, shipment status messages, and remittance information. Standards such as ANSI X12 and UN/EDIFACT define document structures and codes, although trading partners frequently impose implementation guides and proprietary variations.

EDI often uses a value-added network, secure file transfer, or an integration provider. It remains important because it supports predictable, auditable, high-volume B2B transactions and is embedded in many retail, manufacturing, and logistics relationships.

EDI’s limitations include batch orientation, complex onboarding, difficult human readability, rigid mapping, and inconsistent partner interpretations. EDI and APIs are not mutually exclusive. A company may accept EDI from a retailer, transform it internally, and expose an API to a warehouse or analytics application.

2.3 Middleware and integration platforms

Middleware is software that mediates communication among applications. An enterprise service bus (ESB) historically centralized routing, transformation, protocol conversion, and orchestration. Modern integration-platform-as-a-service (iPaaS) offerings provide connectors, workflow, monitoring, mapping, API management, and cloud-to-cloud integration.

Middleware commonly performs:

1. protocol conversion, such as EDI to HTTPS;
2. data transformation, such as converting a partner’s item code to the enterprise item code;
3. routing, such as sending a shipment event to the TMS and customer portal;
4. enrichment, such as adding location or carrier information;
5. validation and rejection handling;
6. retry and dead-letter processing; and
7. audit logging and operational monitoring.

Centralization can improve governance, but a single integration hub may become a bottleneck or a critical point of failure. Distributed integration requires stronger standards and observability.

2.4 Event-driven integration

In an event-driven architecture, a producer publishes a record that something has occurred, while interested consumers subscribe to it. Examples include OrderAccepted, InventoryAdjusted, ShipmentDeparted, and TemperatureThresholdExceeded. A message broker or event stream distributes events.

An event is different from a command. A command requests an action, such as “create shipment.” An event reports a completed or observed fact, such as “shipment created.” This distinction supports loose coupling: consumers need not know the internal implementation of the producer.

Event-driven integration is useful for real-time visibility, exception management, IoT telemetry, and scalable workflows. It requires careful treatment of ordering, duplicate delivery, schema evolution, replay, retention, and eventual consistency. In many systems, a consumer may receive a message more than once; business processing should therefore be idempotent.

2.5 IoT connectivity

Internet of Things (IoT) integration connects physical objects and operating environments to software. A cold-chain sensor may record temperature, a vehicle telematics unit may report location, and a warehouse scanner may confirm a pick. Connectivity can use cellular networks, Wi-Fi, Bluetooth Low Energy, industrial protocols, or low-power wide-area networks.

A typical IoT architecture includes a device, edge gateway, ingestion service, event broker, time-series store, rules engine, and SCM application. Edge processing may filter or aggregate data before transmission, reducing bandwidth and supporting action when connectivity is intermittent.

IoT data requires more than connectivity. The organization must define calibration, device identity, sampling frequency, time synchronization, battery management, data ownership, alert thresholds, and maintenance responsibility. A sensor reading without a trustworthy association to a product, shipment, location, and time is often operationally useless.

3. Data Models, Standards, and Semantic Interoperability

3.1 Syntactic and semantic interoperability

Syntactic interoperability means that systems can parse exchanged data. Semantic interoperability means they interpret the data consistently. A field called quantity may be syntactically valid but ambiguous unless the systems agree whether it means pieces, cartons, kilograms, or pallets.

A useful hierarchy is:

• Connectivity: systems can communicate.
• Syntax: messages follow a recognizable structure.
• Semantics: terms and relationships have shared meanings.
• Process interoperability: organizations agree on sequence, responsibility, and exception handling.
• Governance interoperability: participants agree on ownership, security, accountability, and change control.

3.2 Canonical data models

A canonical data model defines common enterprise representations for key objects such as item, location, party, order, shipment, inventory balance, and forecast. External messages are mapped into and out of the canonical model rather than every system being mapped directly to every other system.

If n systems require direct two-way mappings, the number of pairwise relationships can approach:

where M is the number of directed or undirected pairwise relationships under the relevant integration design assumption and n is the number of systems. This expression illustrates potential growth in mapping complexity; it is not a universal measure of implementation effort. A hub-and-spoke model can reduce direct relationships, but the hub’s canonical model and transformations become critical dependencies.

For example, an enterprise may define one item record with item identifier, description, base unit, packaging hierarchy, hazardous-material classification, dimensions, weight, and lifecycle status. A supplier’s item code and a retailer’s product code are then maintained as cross-references rather than treated as interchangeable identifiers.

3.3 Master data and reference data

Master data represents relatively durable business entities, including products, customers, suppliers, locations, carriers, and equipment. Reference data provides controlled values, such as country codes, units of measure, incoterms, shipment status codes, and currencies. Transaction data records events or documents, such as orders and receipts.

Integration fails frequently because master data is inconsistent. Two systems may use different location identifiers, packaging units, time zones, or product hierarchies. Master-data management should establish ownership, approval workflows, duplicate detection, effective dates, survivorship rules, and synchronization mechanisms.

3.4 Standards

Standards reduce ambiguity and onboarding effort. Relevant standards may include EDI syntax standards, GS1 identifiers and barcodes, ISO country and currency codes, UN/LOCODE location codes, standardized units of measure, OpenAPI descriptions, OAuth-based authorization patterns, and industry-specific data models.

Standards do not eliminate mapping. A standard may permit optional fields, industry extensions, different code lists, and partner-specific interpretations. Conformance testing and implementation guides remain necessary.

4. Integrating Customers and Partners

4.1 Partner segmentation

There is no single best integration method for every partner. Partner segmentation should consider transaction volume, technical maturity, strategic importance, regulatory exposure, data sensitivity, and required response time.

4.2 Customer integration

Customer-facing integration may include order capture, available-to-promise inquiries, order acknowledgment, shipment tracking, proof of delivery, returns, invoices, and service cases. The organization must define the system of record for each fact. For example, the TMS may be authoritative for carrier status, while the ERP remains authoritative for invoicing.

A customer-facing promise should not be based on stale or poorly synchronized inventory. If availability is calculated from multiple locations, the calculation must account for reservations, safety stock, lead time, and allocation rules. The interface should also communicate uncertainty, such as an estimated delivery window rather than an unjustifiably precise timestamp.

4.3 Supplier and logistics integration

Supplier collaboration commonly involves forecasts, purchase orders, confirmations, shipment notices, quality documents, capacity information, and invoices. Logistics integration may involve tendering, booking, pickup and delivery milestones, freight documents, tracking, claims, and freight settlement.

Partner integration must address organizational as well as technical questions: Who owns the data? Who corrects an error? What constitutes receipt of a message? What happens when a partner changes a code or endpoint? What service level applies to a missing status? These questions belong in trading-partner agreements and operating procedures.

5. Integration Design and Governance

5.1 A disciplined design process

A practical integration program can follow these steps:

1. Map business capabilities and processes. Identify order-to-cash, procure-to-pay, plan-to-produce, and transport processes.
2. Identify authoritative sources. Assign ownership for each master and transactional data element.
3. Classify integration requirements. Distinguish real-time, near-real-time, scheduled batch, and human-assisted interactions.
4. Select patterns. Choose APIs, EDI, events, files, portals, or a combination.
5. Define contracts. Specify schemas, identifiers, units, errors, security, service levels, and versioning.
6. Build observability. Track message status, latency, failures, duplicates, reconciliation, and business outcomes.
7. Test across organizational boundaries. Use realistic volumes, invalid data, delayed messages, duplicate messages, and partner outages.
8. Operate and improve. Review incidents, data-quality metrics, change requests, and partner performance.

5.2 Reliability and reconciliation

Technical delivery does not guarantee business completion. A message may be delivered but rejected by a receiving application, or accepted but fail to update a downstream process. Reconciliation compares records across systems and investigates differences.

Important controls include unique business keys, correlation identifiers, timestamps with explicit time zones, retry policies, dead-letter queues, duplicate detection, end-to-end audit trails, and manual exception workflows. For financial or inventory transactions, reconciliation should be scheduled and risk-based rather than assumed unnecessary.

5.3 Security and governance

Integration expands the attack surface because data crosses applications and organizational boundaries. Essential controls include least-privilege access, strong authentication, encryption in transit and at rest, secrets management, network segmentation, API throttling, vulnerability management, logging, and incident response.

Governance must also cover privacy and commercial confidentiality. Customer addresses, employee information, shipment contents, supplier pricing, and production data may be subject to contractual or legal restrictions. Data minimization, retention limits, regional processing requirements, and purpose limitation should be considered during interface design.

Supply chain resilience requires concentration-risk analysis. Dependence on one cloud provider, one integration broker, or one identity service may create a common failure mode. Continuity plans should identify recovery priorities, backup communication methods, data restoration procedures, and partner notification protocols.

5.4 AI and integration

AI can assist with interface mapping, anomaly detection, document classification, demand or delay prediction, and natural-language access to operational data. However, AI-generated mappings or transformations require validation. An incorrect unit conversion or product-code match can create physical and financial consequences. AI systems should therefore operate within controlled data contracts, with traceability, human review for high-impact decisions, and monitoring for drift and bias.

6. Illustrative Case: Northstar Components

Background

Northstar Components, a fictional mid-sized manufacturer, sells through two major retailers and a network of industrial distributors. Its ERP is hosted on-premises, its WMS is SaaS, and carriers provide inconsistent tracking through EDI, spreadsheets, and proprietary portals. Customers frequently report that promised delivery dates do not match actual shipment status.

Problem

Northstar has three item-code systems, inconsistent location identifiers, and no common definition of “shipped.” The retailer receives purchase-order acknowledgments through EDI, while the customer-service team manually checks carrier websites. A duplicated shipment notice once caused a retailer to believe that two deliveries were in transit.

Analysis

The problem is not simply the absence of an API. It includes weak master-data governance, ambiguous event semantics, inadequate correlation identifiers, and fragmented operational ownership. The company also lacks visibility into failed messages and has no formal partner onboarding process.

Approach and solution

Northstar establishes a canonical model for item, location, order, shipment, and carrier status. It appoints data owners and creates cross-reference tables for partner item and location codes. Existing EDI connections are retained for retailer documents. An iPaaS translates EDI into the canonical model and publishes validated events such as OrderAcknowledged, ShipmentPacked, ShipmentDeparted, and Delivered.

The WMS publishes packing and dispatch events through an API. Carrier feeds are normalized into the same event vocabulary. Each order line and shipment receives a correlation identifier, while an idempotency key prevents repeated processing of duplicate messages. Customer service receives a dashboard showing message failures, stale shipments, and mismatches between promised and actual milestones.

Northstar also introduces partner implementation guides, automated conformance tests, encryption, role-based access, and a reconciliation report comparing ERP shipments, WMS dispatches, carrier events, and retailer acknowledgments.

Outcome

The architecture does not eliminate every delay, but it distinguishes physical delay from information delay. Customer service can identify whether a shipment is late, whether the carrier has not reported, or whether an interface failed. Retailers receive consistent notices, and onboarding a new carrier requires one canonical mapping rather than multiple point-to-point transformations.

Learning points

1. Integration effectiveness depends on data meaning and process ownership, not only connectivity.
2. Legacy EDI can coexist with APIs and events.
3. Canonical models reduce duplication but become important governance assets.
4. Idempotency, correlation, monitoring, and reconciliation are operational necessities.
5. Architecture should be evaluated against business outcomes such as reliable promises and exception resolution.

7. Critical Evaluation and Best Practices

Managers should avoid assuming that the newest architecture is automatically the best architecture. A composable model may be strategically attractive but uneconomic for a small, standardized operation. A SaaS solution may be secure and resilient, but only if the organization configures identity, roles, integrations, and continuity arrangements properly. An event-driven design may improve responsiveness while making reporting and transaction consistency more complex.

Best practices include:

• begin with business capabilities and information responsibilities;
• use open, documented contracts where feasible;
• distinguish commands, queries, and events;
• standardize identifiers, units, time zones, and status definitions;
• design for duplicate, delayed, missing, and out-of-order messages;
• make interfaces observable and auditable;
• use versioning and backward compatibility;
• test partner and failure scenarios before production;
• minimize unnecessary data collection and sharing;
• assess vendor concentration and exit options;
• treat master data as an executive governance issue; and
• measure business outcomes, not merely interface uptime.

Useful performance measures include integration success rate, message latency, duplicate rate, reconciliation discrepancies, partner onboarding time, percentage of transactions using standards, mean time to detect an interface failure, and mean time to recover. These measures should be connected to supply chain outcomes such as order-cycle reliability, inventory accuracy, delivery visibility, and customer satisfaction.

Chapter Summary

SCM software architecture determines how applications, infrastructure, data, devices, and users are organized. On-premises systems provide control and customization, while cloud and SaaS models improve elasticity and reduce infrastructure responsibilities. Platforms provide reusable services, and composable architectures provide modularity, but both require governance. No model is universally optimal.

Integration mechanisms serve different purposes. APIs support interactive and service-based exchange; EDI remains important for standardized, high-volume B2B documents; middleware transforms, routes, validates, and monitors messages; event-driven architectures distribute facts asynchronously; and IoT connectivity links physical operations to digital processes. Effective interoperability requires more than syntactic compatibility. Shared semantics, master data, process agreements, security, and accountability are essential.

Canonical data models, standards, identifiers, units of measure, and reference codes reduce ambiguity. Integration with customers and partners should be designed according to volume, technical maturity, risk, and required response time. Reliability depends on idempotency, correlation, reconciliation, observability, and controlled exception handling. Finally, architecture is a managerial decision involving resilience, cost, flexibility, compliance, vendor dependence, and business value.

Key Terms

API: A defined interface through which software requests data or actions from another component.

Canonical data model: A shared internal representation used to normalize information from multiple systems.

Cloud computing: On-demand access to computing resources delivered through a network.

Composable architecture: An architecture assembled from modular, replaceable business capabilities.

EDI: Electronic exchange of structured business documents between organizations.

Event: A record that a fact or state change has occurred.

Event-driven architecture: An architecture in which producers publish events and consumers react to them.

Idempotency: The property that repeating an operation produces the same business result as performing it once.

Integration: The coordination and exchange of information among software systems or organizations.

Interoperability: The ability of systems and organizations to work together effectively.

IoT: A network of connected physical devices that collect or exchange data.

Master data: Durable information about entities such as products, suppliers, customers, and locations.

Middleware: Software that mediates communication, transformation, routing, or orchestration between systems.

On-premises: Software and infrastructure operated under the organization’s direct control.

Platform: A set of shared services and capabilities supporting multiple applications or extensions.

SaaS: Software operated by a provider and delivered to customers as a managed service.

Semantic interoperability: Agreement on the meaning of exchanged data.

Service level: An agreed performance or availability expectation for a service or integration.

System of record: The authoritative system for a defined data element or business transaction.

Trading-partner agreement: A documented agreement defining technical, operational, and governance responsibilities between organizations.

Review Questions

Short Answer Questions

1. What is the difference between an API and EDI?
2. Why is semantic interoperability more demanding than syntactic interoperability?
3. Define a canonical data model.
4. What is the purpose of idempotency in shipment integration?
5. Name two governance issues associated with IoT data.

Long Answer Questions

1. Compare on-premises, SaaS, platform, and composable architectures for a multinational manufacturer.
2. Explain how middleware supports integration among ERP, WMS, TMS, and partner systems.
3. Discuss the advantages and risks of event-driven architecture in supply chain execution.
4. Explain how master-data governance affects customer and supplier integration.
5. Design a partner-integration strategy for a company working with retailers, small suppliers, and logistics providers.

Analytical / Application Questions

1. A company has eight systems and is considering direct point-to-point integration versus a canonical hub. Use M = n(n − 1) / 2 to explain how relationship complexity may grow, and discuss why the formula is only an illustration rather than a complete cost model.
2. A carrier sends the same delivery event twice and sends it after the customer portal has already displayed a later exception. Propose controls addressing duplication, ordering, reconciliation, and customer communication.
3. A cold-chain company wants to share temperature data with customers and regulators. Evaluate the architecture, data-quality, privacy, security, retention, and accountability requirements before implementation.

Multiple Choice Questions with Answers

Question 1

Which architectural model generally gives the customer the greatest direct control over servers and application infrastructure?

A. On-premises

B. SaaS

C. Public platform service

D. Managed iPaaS

Correct Answer: A. On-premises

Question 2

What is the primary purpose of a canonical data model?

A. To eliminate all data storage

B. To provide a shared representation for exchanged business data

C. To replace cybersecurity controls

D. To ensure every partner uses identical software

Correct Answer: B. To provide a shared representation for exchanged business data

Question 3

Which statement correctly distinguishes an event from a command?

A. An event requests an action, while a command reports a completed fact

B. An event reports a fact, while a command requests an action

C. Both terms always mean exactly the same thing

D. A command can only be sent through EDI

Correct Answer: B. An event reports a fact, while a command requests an action

Question 4

Why is idempotency important when integrating shipment-booking services?

A. It increases the physical capacity of a warehouse

B. It prevents a retry from unintentionally creating duplicate business transactions

C. It converts all APIs into EDI messages

D. It removes the need for authentication

Correct Answer: B. It prevents a retry from unintentionally creating duplicate business transactions

Question 5

Which technology is most associated with structured business documents such as purchase orders and advance shipping notices?

A. EDI

B. RFID only

C. A time-series database

D. A spreadsheet macro

Correct Answer: A. EDI

Question 6

What is semantic interoperability?

A. The ability to transmit data over a network cable

B. The ability to parse a file’s syntax only

C. The ability of systems to interpret exchanged data with consistent meaning

D. The ability to operate without master data

Correct Answer: C. The ability of systems to interpret exchanged data with consistent meaning

Question 7

Which activity is most directly associated with middleware?

A. Physical picking of products

B. Protocol conversion and message transformation

C. Setting customer prices without business rules

D. Replacing all trading-partner agreements

Correct Answer: B. Protocol conversion and message transformation

Question 8

A company has six systems and considers undirected pairwise relationships. Using M = n(n − 1) / 2, how many relationships are illustrated?

A. 6

B. 12

C. 15

D. 36

Correct Answer: C. 15

Question 9

Which practice best supports reliable partner integration?

A. Allowing every partner to define units independently without mapping

B. Using correlation identifiers, monitoring, and reconciliation

C. Suppressing failed messages from operational staff

D. Changing schemas without version control

Correct Answer: B. Using correlation identifiers, monitoring, and reconciliation

Question 10

What is a major governance risk of a highly composable architecture?

A. It cannot use APIs

B. It always requires on-premises hardware

C. It may create fragmented processes and complex dependencies among components

D. It prevents modular replacement

Correct Answer: C. It may create fragmented processes and complex dependencies among components