16 — Enterprise Platforms — SAP, Salesforce, Dynamics, and the Rest

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.

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

[2] "SAP ERP, HANA, Business Objects," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/sap-erp-hana-business-objects

[3] "Salesforce," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/salesforce

[4] "MS Dynamics," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/ms-dynamics

[5] "IBM BPM," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/ibm-bpm

[6] "EMC and DMS," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/emc-dms