--- title: "16 — Enterprise Platforms — SAP, Salesforce, Dynamics, and the Rest" uid: enterprise-platforms tags: ["enterprise-software", "roadmap:software-architect", "ibm-bpm", "ms-dynamics", "dms", "sap", "salesforce"] excerpt: "SAP, Salesforce, Dynamics — not applications you install but platforms with their own data models, APIs, and limits. Treating them as 'just another system to call' is how integration projects fail." date: 2026-08-13T03:27:39+0000 source: https://www.aveshina.my.id/en/blog/enterprise-platforms --- SAP, Salesforce, Dynamics, IBM BPM, EMC/DMS — the enterprise cluster read as a boring list of vendor names until one reframe. The model that organized it: **these aren't just applications you install; they're platforms with their own data models, APIs, and limits, and integrating with them is a distinct architectural concern** [1]. The roadmap lists them last for a reason — they're the brownfield reality an architect in a large enterprise inherits and has to design around, not a greenfield choice. Treating them as "just another system to call" is how integration projects turn into multi-year failures. Enterprise software refers to applications designed to meet the needs of large organizations — typically complex, scalable, and capable of integrating with other systems to support a wide range of business functions [1]. ## SAP: ERP, HANA, Business Objects **SAP ERP** is a widely used enterprise resource planning system managing core business processes across large organizations — finance, supply chain, HR, and more [2]. **SAP HANA** is the in-memory database platform that powers faster processing for SAP applications, and **SAP Business Objects** provides business intelligence and reporting on top of that data. Architects in large enterprises often need to design integrations connecting custom systems to this SAP landscape [2]. The architect-relevant concerns are the SAP data model (deeply normalized, domain-specific), the integration options (IDocs, BAPIs, OData, RFCs), and the reality that SAP is usually the system of record (the single authoritative source of truth) for finance — you don't push to it casually. ## Salesforce: CRM-as-a-platform **Salesforce** is a cloud-based customer relationship management platform that also supports custom application development through its **Apex** language and **Lightning** platform [3]. Many organizations extend Salesforce beyond CRM into custom business applications built on top of its platform. The architect needs to understand Salesforce's data model, API options, and — critically — its **platform limits** (governor limits on queries, CPU, and rows) when integrating it with other enterprise systems [3]. Salesforce is the lesson in "platform, not application": teams that treat it as a generic database hit limits and patterns they didn't know existed. ## Microsoft Dynamics: the Microsoft ecosystem play **Microsoft Dynamics** is a suite of ERP and CRM applications managing business processes like sales, finance, and operations [4]. It integrates closely with other Microsoft products, making it a common choice for organizations already invested in the Microsoft ecosystem. Architects working with Dynamics need to understand its data model and integration options when connecting it to other systems [4]. The Dynamics decision is often downstream of an existing Microsoft standardization — once an org is on Azure, Active Directory, and Office 365, Dynamics is the path of least resistance for CRM/ERP. ## IBM BPM: process automation on IBM middleware **IBM Business Process Manager** is a platform for modeling, automating, and monitoring business processes within an organization [5]. It provides tools for both business analysts and developers to design workflows and integrate them with existing enterprise systems. Architects encounter IBM BPM in enterprises that have standardized on IBM's middleware stack for process automation [5]. This ties back to the BPM/BPEL notes — IBM BPM is one concrete implementation of the business-process-management discipline, sitting on top of IBM's broader middleware. ## EMC and DMS: document management at scale **EMC's document management systems** (now largely under OpenText Documentum) provide enterprise-level tools for storing, organizing, and controlling access to documents and records at scale [6]. These systems focus on **compliance, versioning, and retention policies** important for regulated industries. Architects integrating with EMC DMS need to understand how document workflows and metadata fit into a broader enterprise system [6]. The defining characteristic is that a DMS isn't a content store you treat casually — the retention and compliance rules govern how, whether, and when documents can be modified or deleted, and the architecture has to respect them or the org fails an audit. ```figure SAP ERP · HANA · Business Objects finance system of record IDocs / BAPI / OData Salesforce CRM + Apex / Lightning extendable platform watch the governor limits MS Dynamics ERP / CRM suite tight Microsoft integration ecosystem fit drives choice IBM BPM process automation on IBM middleware workflow + integration EMC / DMS document management compliance · versioning retention rules govern design ``` ## The single thread What connects all five is that none of them are systems you "just call." Each is a platform with a strongly opinionated data model, a specific set of integration mechanisms, and hard constraints (governor limits in Salesforce, retention rules in a DMS, the finance-system-of-record status of SAP). The architect integrating with any of them has to learn that platform's model on its own terms — treating it as a generic endpoint is how data models clash, limits get hit, and compliance rules get violated. The work is mostly about respecting the platform's constraints, not about your own system's elegance. ## How I use this When I encounter one of these platforms in an enterprise, the first question is "what is this the system of record for, and what are its integration constraints?" SAP usually owns finance; Salesforce owns the customer and CRM-extended business logic; a DMS owns regulated documents and their retention. The architecture defers to the platform's ownership of its domain and integrates through the platform's preferred mechanisms (OData for SAP, the Salesforce APIs with governor limits in mind, the DMS's workflow and metadata model). I never design a custom system that tries to replicate or bypass the platform's system-of-record role — that's the integration failure mode I see most often, and it's always expensive. ## References [1] "Enterprise Software," Wikipedia. [Online]. Available: [https://en.wikipedia.org/wiki/Enterprise_software](https://en.wikipedia.org/wiki/Enterprise_software) [2] "SAP ERP, HANA, Business Objects," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/sap-erp-hana-business-objects](https://roadmap.sh/software-architect/sap-erp-hana-business-objects) [3] "Salesforce," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/salesforce](https://roadmap.sh/software-architect/salesforce) [4] "MS Dynamics," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/ms-dynamics](https://roadmap.sh/software-architect/ms-dynamics) [5] "IBM BPM," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/ibm-bpm](https://roadmap.sh/software-architect/ibm-bpm) [6] "EMC and DMS," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/emc-dms](https://roadmap.sh/software-architect/emc-dms) ```quiz Q: What do SAP, Salesforce, MS Dynamics, IBM BPM, and EMC/DMS have in common from an architect's view? - They are simple applications you can treat as generic API endpoints - They are platforms with opinionated data models, specific integration mechanisms, and hard constraints correct: 1 explain: Each is a platform with its own model, APIs, and limits (governor limits in Salesforce, retention rules in a DMS, finance-system-of-record status in SAP). Integrating means learning the platform on its own terms. Q: Why is "governor limits" a phrase an architect integrating with Salesforce must know? - They cap queries, CPU, and rows per transaction, shaping how integration code must be written - They are a marketing term with no technical meaning correct: 0 explain: Salesforce enforces governor limits on resource use. Integration code that ignores them hits runtime errors, so the architecture has to respect them — bulkify calls, batch where needed. Q: SAP is most commonly the system of record for which domain? - Frontend UI rendering - Finance and core business processes like supply chain and HR correct: 1 explain: SAP ERP manages core business processes — finance, supply chain, HR — and is usually the authoritative source for financial data. Custom systems integrate with it rather than replacing it. Q: A DMS (document management system) in a regulated industry primarily governs… - how fast documents can be rendered to the screen - compliance, versioning, and retention — when and whether documents can be modified or deleted correct: 1 explain: A DMS enforces compliance, versioning, and retention policies. The architecture must respect those rules or the organization fails an audit; you can't treat it as a casual content store. Q: Microsoft Dynamics is often chosen because… - it has no data model of its own - the organization is already invested in the Microsoft ecosystem (Azure, AD, Office 365) correct: 1 explain: Dynamics integrates closely with other Microsoft products, so in a Microsoft-standardized org it's the path of least resistance for CRM/ERP. The ecosystem fit, not standalone features, typically drives the choice. ```