Why Point-to-Point Integrations Are Evil
Investing in P2P integration solutions is a recipe for long-term systemic problems
Salesforce has been growing at approximately 30% year over year. Sustaining that level of growth while supporting the business has required IT to make deliberate trade-offs. In many cases, those trade-offs have involved deferring foundational infrastructure and architectural investments in favor of speed and near-term delivery. While effective in the short term, this approach inevitably introduces long-term constraints—ultimately positioning IT as a bottleneck, or worse, a blocker to delivering value to customers.
The diagram below reflects the current state of point-to-point (P2P) integrations within Salesforce at the time of this writing. It represents the underlying integration fabric supporting a multi-billion-dollar business—an architecture that, while functional, highlights the systemic risks of incremental, uncoordinated integration strategies.
P2P integrations can be expedient to implement, but they quickly become unmanageable and costly. When environments are small, P2P integrations appear to be a lightweight and efficient way to connect systems. However, as the organization scales, this approach does not remain sustainable. What begins as simplicity evolves into fragility—creating an integration landscape that is brittle, difficult to maintain, and increasingly misaligned with evolving business needs.
No organization sets out to create integration complexity. Rather, P2P architectures emerge organically over time, often driven by shifting business priorities and the absence of a cohesive, enterprise-wide integration strategy such as SOA or API-led design. Delivery teams, under pressure to meet deadlines, frequently prioritize immediate outcomes over long-term architectural integrity. In many cases, more sustainable solutions are deferred due to perceived cost, complexity, or risk. It often takes a significant disruption—escalating IT costs, widespread system instability, or a critical failure triggered by a single change—for organizations to fully recognize the extent of the problem.
The Hidden Cost of P2P
The limitations of P2P integration are not always immediately visible in smaller environments. However, the number of connections required to integrate systems grows exponentially as new components are added. This becomes particularly problematic for organizations that depend on an expanding ecosystem of internal systems and external partners.
For example, integrating three systems requires only three connections (assuming unidirectional flows). Expanding to five systems increases this to ten connections. At scale, the number of required connections follows the formula N(N-1)/2, where N represents the number of systems. A network of ten systems requires 45 = 10(10–1)/2 distinct connections—each one introducing additional development, testing, and maintenance overhead. The P2P cost model increases exponentially as the size of the network increases linearly, as illustrated by the cost curve in the diagram below.
Every connection represents time and resources diverted away from innovation and net-new business capabilities. In practice, many organizations lack the capacity to adequately maintain or modernize these integrations. The result is often a complex, poorly documented web of dependencies that becomes one of the most mission-critical—and fragile—components of the enterprise architecture.
At a project level, P2P integration can appear cost-effective. This aligns with how IT has traditionally measured success—optimizing for immediate delivery within constrained budgets. However, at the enterprise level, the cost dynamics shift dramatically. Each additional P2P connection contributes to a non-linear increase in total cost of ownership. While the value of the network grows linearly, the associated costs scale exponentially, creating a widening gap between investment and return. This dynamic underscores a fundamental challenge in traditional IT funding models.
Security Concerns
Beyond cost, P2P architectures introduce significant security and governance risks. In the absence of centralized control, it becomes increasingly difficult to track data access, enforce compliance, and respond to potential breaches. As multiple teams independently establish direct integrations across cloud and on-premise systems, visibility into data access patterns diminishes.
This fragmentation often leads to the proliferation of API user accounts and credentials, increasing the organization’s attack surface. From a risk management perspective, each additional access point represents potential exposure.
Additionally, a lack of coordination can result in conflicting data interactions. For example, in one case involving Workday Market Segment data, multiple teams unknowingly updated the same data attribute, leading to data overwrites, confusion, and rework. This issue persisted for years, driving productivity losses and introducing avoidable business risk—illustrating how integration architecture directly impacts data integrity and operational trust.
Budget Constraints
From a funding perspective, P2P integration reinforces inefficiencies. Each new application—whether mobile, web, or enterprise—requires access to data, and each project typically allocates budget to build or extend integrations. This project-level (microeconomic) approach diverts investment away from differentiated business functionality and toward redundant integration efforts.
At scale, this results in a significant misallocation of resources. Rather than repeatedly funding bespoke integrations, organizations should consider investing in shared, reusable data access capabilities that reduce duplication and improve long-term efficiency.
Limited Capabilities
Another consequence of P2P integration is the embedding of business logic within integration code. Under delivery pressure, teams often hard-code business rules alongside data transformations. While expedient, this approach creates long-term challenges by obscuring business logic and increasing maintenance complexity.
A representative example involved new hire processing within Workday. Critical business rules embedded within integrations were not visible to application development teams, limiting their ability to deliver new functionality effectively. A more sustainable model separates business logic from integration layers, enabling greater transparency, flexibility, and speed of change.
Mergers & Acquisitions
Salesforce’s growth strategy includes frequent acquisitions, often integrating acquired companies as distinct business units. This model increases the importance of scalable integration capabilities, as both front- and back-office systems must be connected efficiently.
In some cases, integration may involve straightforward data migration. More often, however, acquired systems must be integrated into an existing ecosystem. In a P2P architecture, this process becomes time-consuming, costly, and operationally complex—limiting the organization’s ability to rapidly realize value from M&A activity.
Lost Opportunities
Over time, P2P environments become increasingly difficult to support. As complexity grows, teams become more risk-averse, hesitant to implement changes due to uncertain downstream impacts. At this stage, IT transitions from an enabler of business innovation to a constraint on it.
The consequences are tangible: slower time-to-market, reduced agility, and missed revenue opportunities. In a competitive landscape, these delays can have material business impact.
Supportability & Scalability
At enterprise scale, the limitations of P2P integration become unmistakable. These architectures are inherently difficult to support and do not scale effectively.
A clear example comes from an initiative to upgrade Oracle Financials from 10g to R12. At the time, the IT landscape included approximately 55 P2P integrations. Introducing just four new data fields—Business Unit, Market Segment, Company, and Primary Coverage Country—required updates across a vast network of connections. Applying the N(N-1)/2 model, this resulted in 1,485 integration touchpoints, over a year of development effort, and approximately $1 million in cost—simply to accommodate a relatively modest change.
This example underscores a broader reality: without a scalable integration strategy, even small changes can carry disproportionate cost and risk.