HubSpot Integration Architecture: A Reference for the Commercial Stack

Abstract

Most writing about HubSpot integrations is written at the level of the tool: which connector to install, which platform to subscribe to, which endpoints to call. This reference is written at the level of the architecture, on the view that the tool choice is the last decision in a well-run integration programme rather than the first. It sets out the coordination problem that makes commercial stacks fragment; the four architectural options available for connecting systems to HubSpot — the native connector, the general-purpose iPaaS, the managed integration layer, and custom middleware — with the conditions under which each wins; and the three design layers that any of the four must get right: record identity, field-level ownership, and movement mechanics. It closes with the ways an integration breaks that determine whether it is still trusted a year after go-live, and with the limits of the reference itself. Throughout, the argument draws on the organisational and information-systems literature rather than on vendor marketing, because the recurring finding of that literature — that integration is an organisational achievement before it is a technical one — is the single most useful thing a buyer of integration work can know (Lawrence and Lorsch 1967; Umble, Haft, and Umble 2003).

1. The Coordination Problem Beneath the Tool Problem

Commercial software estates fragment because the departments buying the software face different problems, not because anyone was careless.

Lawrence and Lorsch (1967) named the pattern after studying ten organisations across three industries. They called it differentiation: the tendency of departments facing different parts of the environment to develop different goals, different time horizons, and different ways of working. In their data these differences were large and measurable. Research departments worked against scientific uncertainty on horizons of years. Sales worked against customer demand in weeks. Production worked against plant throughput in days, under far more formal procedures than either. None of this was dysfunction. Each department had adapted to the part of the world it actually dealt with, and that adaptation was what made it competent.

The problem they identified is that differentiation makes integration harder in direct proportion. Integration, in their usage, is not software. It is the quality of collaboration achieved between departments that must work together. The firms performing best in uncertain environments were not the least differentiated ones. They were the firms that sustained high differentiation and high integration simultaneously, and they did it by assigning explicit responsibility for coordination rather than leaving it to goodwill between managers.

Software estates reproduce this pattern because they are bought the same way. Marketing acquires a platform organised around campaigns and anonymous visitors. Finance acquires a ledger organised around invoices and recognised revenue. Service acquires a system organised around tickets and response times. Each purchase is locally correct, and each encodes its department's definition of the customer. What no single system can then answer is any question that crosses a departmental boundary — what one customer bought, what they owe, and what they have asked for — because no one system holds all three.

Galbraith (1974) supplied the mechanism. His argument was that the volume of information an organisation must process while doing a task rises with how uncertain that task is, and that a firm has only two families of response available. It can reduce the information it needs to process, by holding slack resources or by making units self-contained so they depend on one another less. Or it can raise its capacity to process information, by building formal reporting systems or by opening lateral channels that let units coordinate directly instead of routing everything through the hierarchy.

An integration is a lateral channel in exactly that sense, and this has a consequence vendor materials rarely state. Opening a channel does not by itself produce coordination, because the units at either end can still disagree about what the arriving data means. Dougherty (1992) called these thought worlds: departments that interpret the same information differently because their daily work has taught each of them to attend to different things. Carlile (2002) examined the same difficulty as a problem of boundary objects — artefacts concrete enough for each side to use in its own work, and flexible enough for both sides to accept. A synced field whose definition is contested is not integration. It is a faster way to circulate a disagreement, which is why the architectural work described below includes deciding who owns each field, what a stage means, and when a record is considered to exist (Kahn and Mentzer 1998).

The same research warns against the opposite error. Studies of enterprise-system implementations through the 1990s and 2000s repeatedly found that success depended more on organisational conditions — the accuracy of the data, sustained involvement from executives, training, and governance that continued after go-live — than on any technical variable (Davenport 1998; Umble, Haft, and Umble 2003). There is little reason to think a CRM-centred stack behaves differently, and the case evidence on this site suggests it does not: the HubSpot–QuickBooks study attributes its margin-accuracy improvement chiefly to identity reconciliation and governance cadence, with the moving parts themselves described as technically unremarkable.

2. Definitions

A small vocabulary carries most of this reference, and each term has a precise meaning here.

System of record — for a given field, the one system whose value wins a disagreement. Ownership is assigned per field, not per object; a company record routinely has finance-owned and sales-owned fields side by side.

Synchronisation — the ongoing propagation of changes between systems, as distinct from a one-time migration. A sync has a direction per field, a schedule or trigger, and a conflict policy.

Join key — the stored identifier that asserts two records in two systems are the same real-world entity. The join key is an architectural decision, not an implementation detail, because every flow depends on it.

Webhook — a push notification a platform sends when an event occurs, documented for HubSpot in the Webhooks API guide. The alternative is polling: asking on a schedule whether anything changed.

Idempotency — the property that applying the same operation twice produces the same state as applying it once. Retries are unavoidable in distributed systems; idempotency is what makes them safe.

iPaaS — integration platform as a service: a general-purpose tool in which users compose triggers and actions across many applications, typically priced per task or operation.

Managed integration layer — a service in which the integration is designed, built, monitored and maintained for the client as an ongoing obligation, rather than assembled by the client on a general-purpose platform.

3. The Object Model as the Unit of Analysis

The most consequential technical fact about a HubSpot integration is not an endpoint or a limit but the shape of the object model on each side. HubSpot's CRM is built from objects — contacts, companies, deals, tickets, and custom objects on Enterprise subscriptions — carrying typed properties and connected by associations, which since version 4 of the API can carry labels distinguishing, for example, a billing contact from a decision-maker. The external system has its own model, built for its own purpose, and the two models almost never correspond one to one. An accounting platform has customers, items, invoices and payments but no concept of a deal; a project tool has tasks and phases but no concept of a company; a CRM has none of the obligations — period close, audit trail, tax treatment — that constrain what a financial system may let an integration write.

Parnas (1972) demonstrated why that shape matters, using a small program that produces a keyword index. He wrote out two different ways of splitting it into modules. The first divided the work by processing step, which is the intuitive approach: one module reads the input, the next sorts it, the next formats the output. The second divided it so that each module hid one design decision behind an interface — how the lines are stored, how the sorting is done — and exposed only what its neighbours needed to call.

Both versions worked. The difference appeared when something changed. In the first, altering how the text was stored required editing nearly every module, because they all knew the storage format. In the second, that change touched one module and stopped there. Parnas's conclusion was that modules should be organised around the decisions they conceal, so that neighbours depend on an interface rather than on internals.

An integration is exactly this kind of boundary, drawn between two systems whose internal decisions are hidden from each other. The design question is which concepts are permitted to cross it. Syncing every available field is not a design decision; it is the absence of one. The method that holds up is to write down the questions each side genuinely needs answered — can sales see whether the invoice was paid, can finance see what was contracted — and pass only the fields that answer them. Every field that crosses becomes a maintenance obligation and a possible contradiction between two systems. Every field that stays where it is costs nothing.

The mismatch is easiest to see drawn. Two systems agree about very little at the level of entities, and the places where they agree by accident are more dangerous than the places where they plainly differ.

Soh and Sia (2004) studied what happens when an organisation adopts packaged software built for a business that does not quite resemble it. Their finding was that a package carries an embedded model of how a generic company operates: what entities exist, how processes run, what data is held about each. Where the adopting organisation differs from that model, a gap opens, and the firm can close it in only three ways — change how it works, modify the package, or build something at the boundary between them. They also separated the gaps that come from the vendor's design choices from those that come from the adopting firm's country, industry or regulatory setting, which no vendor could have designed for.

A packaged connector carries an assumption set of the same kind, in miniature. Where a firm's structure matches it, the connector is simply correct, and the comparison below says so plainly. Where the structure does not match — a contractor who needs costs held at project level, a subscription business that needs revenue schedules visible against the deal — the gap follows from the connector having been built for the general case. That gap is what identifies where custom work is justified, and it is the only reliable way to tell necessary custom work from the kind that is sold to a client who did not need it.

4. The Integration Spectrum

Connecting a system to HubSpot is a choice along one spectrum, ordered below from the cheapest option upward. What varies across it is not capability — every option below can move a record — but who carries the obligation afterwards and whose infrastructure the data comes to rest on.

The native connector. HubSpot's marketplace carries vendor-built and HubSpot-built connectors for the common commercial systems — the QuickBooks Online integration is representative — which sync the standard objects in the standard ways. Where the requirement is covered, the native connector wins on every axis that matters: it costs least, it is maintained by someone else, and the ways it breaks are shared with thousands of other portals rather than unique to yours. The correct first question in any integration engagement is not how to build but whether the native connector's assumption set fits, and a consultancy that skips that question is selling you work you may not need. The connector's characteristic weaknesses are equally worth naming: matching behaviour on first run is take-it-or-leave-it, field-level ownership is whatever the vendor decided, and when a sync fails the evidence is often a support ticket rather than a payload you can inspect.

The general-purpose iPaaS. Platforms in this category let a technically minded operator compose flows across hundreds of applications without a codebase, and for a handful of well-defined, low-volume flows they are genuinely quick. Their structural costs surface with scale and with criticality. Per-operation pricing punishes exactly the volume that makes an integration valuable; error handling across dozens of scenarios is distributed rather than centralised, so observability degrades as the estate grows; and the flows are typically owned by whoever built them, which is how a departure turns into an outage. The category suits automation at the edges of an estate. It does not suit the primary connection between a CRM and the system that holds financial record.

The managed integration layer. Between the packaged connector and the bespoke build sits a category in which the integration is designed and operated for the client as a service — the model of RevOps Connect, which this consultancy uses where an engagement needs object-model mapping the native connector cannot express. The economic argument for the category is an argument about obligations rather than features: rate limits, pagination, retries, monitoring and schema drift are permanent operational burdens, and a layer whose operator carries them converts an unbounded internal liability into a bounded subscription. The argument against is symmetrical and should be stated: it introduces a vendor dependency at the centre of the stack, and a firm with a capable internal platform team may reasonably prefer to own the middle.

Custom middleware. A bespoke service gives full control over matching, transformation, ordering and error semantics, and it is the only honest answer for genuinely unusual requirements — regulatory constraints on where data may travel, real-time obligations, or transformations with business logic too specific to express in configuration. Its cost is not chiefly the build. It is that the firm has acquired a small software product with no vendor behind it, which must be documented, monitored, patched and understood by more than one person for as long as it runs. Umble, Haft, and Umble (2003) catalogued what determines whether an enterprise-system implementation succeeds or fails: data accuracy, sustained executive involvement, training, and a governance structure that outlasts the project itself. A custom build concentrates every one of those requirements inside the adopting firm. The packaged alternatives spread them across a vendor's entire customer base, which is most of what the price difference buys.

The build in your own cloud account. Beyond bespoke middleware running wherever it happens to run, a firm can compose the integration from its cloud provider's own primitives — a managed queue, serverless functions, a secrets manager, the provider's monitoring — in an account the firm controls. What this buys is custody: the payloads, the credentials and the logs sit inside an account already covered by whatever agreements and controls the firm has negotiated, and no further organisation enters the data path. What it costs is that cloud primitives are not an integration. Somebody still writes the matching, the retries and the schema handling, and now owns the infrastructure underneath them as well.

The self-hosted deployment. At the far end the integration runs on infrastructure the firm operates directly. This is rarely chosen for engineering reasons and often chosen for regulatory or contractual ones — a data residency commitment, a customer's security schedule, a sector rule about where records may come to rest. It carries the highest engineering cost of any option listed here and gives the firm the most complete control over where its records reside. Both follow from the same fact: nothing has been delegated to anyone else.

The selection rule that falls out of the six is short. Fit the native connector if its assumptions fit; use an iPaaS for peripheral automation rather than for the spine; put unsupported object-model mappings in a managed layer whose operator carries the operational burden; and reserve custom middleware for requirements that are genuinely custom, not merely unexamined. Hasselbring (2000) frames enterprise integration as a problem spanning business architecture, application architecture and technology; the rule above is that framing applied with a budget.

5. The Identity Layer

Every architecture in section 4 depends on one question being answered correctly and permanently: is this record here the same entity as that record there? The platforms give no help by default — no two commercial systems share an identifier space — and the integration must therefore construct identity rather than assume it.

The construction has a reliable shape. Each side's immutable internal identifier is stored on the other side in a dedicated property, created before any automation runs, and every flow joins on that key from then on. Names, however tempting, are display data: they are edited, abbreviated, rebranded and duplicated, and any matching rule built on them decays. The initial population of the join key is reconciliation work — export both sides, match on the most stable signals first, review every ambiguous candidate by hand — and it is properly finished before continuous synchronisation is switched on, because every unmatched record at that moment becomes a decision the machine makes unsupervised. The QuickBooks case study documents this sequence in full, including the QuickBooks name-uniqueness constraint that turns unresolved identity into silently rejected writes rather than visible duplicates.

Identity work is also where data quality stops being an abstraction. Duplicate and inconsistent records are a measured, chronic condition of operational databases, with costs that surface downstream in decisions rather than at the point of entry (Redman 1998; Haug, Zachariassen, and van Liempd 2011). An integration multiplies those costs, because it propagates whatever identity errors exist at machine speed into a second system — and HubSpot's own merge operation, the usual remediation tool, is permanent, which makes the merge plan a checked artefact rather than a casual cleanup. The practical standard is not zero duplicates, which is uneconomic to hold, but a rate low enough that no automated decision is taken against a duplicate; the theoretical literature on quality dimensions supports treating accuracy, completeness and timeliness as separately managed properties rather than one virtue (Wand and Wang 1996; Batini et al. 2009).

6. Ownership and Direction

After identity, the second layer is ownership: for every field that crosses the boundary, which system wins a disagreement, and what happens to the losing value. Davenport (1998) identified this as the real content of enterprise-system work two decades before the current stack existed — deciding what the organisation's data means and who may change it — and the observation transfers without modification. A sync direction is easy; a conflict policy is the design.

The artefact that makes a conflict policy real is a field-level map, and its discipline is that every field carries exactly one arrow. A field drawn with arrows in both directions is not a bidirectional sync; it is an argument nobody has settled, and it surfaces later as a value that appears to change on its own.

The assignment follows obligations rather than convenience. Fields that appear on legal or financial documents — legal name, billing address, payment terms, tax treatment — belong to the system that carries the corresponding obligations, which is never the CRM. Relationship data — trading name, owner, lifecycle, notes — belongs to the CRM, which is built to hold it. For each contested field there are exactly three honest policies: overwrite the loser, preserve the loser in a secondary field, or refuse the write and surface an exception for a person. Silent overwrite is the common default in sync tooling, and it is the mechanism by which a billing address corrected in finance quietly reverts overnight; an integration with no written answer to which system wins does not have a design, it has a default someone else chose.

Direction discipline has one rule worth elevating, because it recurs in every engagement: forecasts do not enter systems of record. A deal is a prediction; an invoice is a fact; pushing predictions into a financial system blurs the boundary that makes the record auditable. The request to see pipeline inside the accounting platform recurs constantly, and refusing it is easier when the refusal is stated as this principle rather than as a connector limitation.

7. Movement Mechanics

The third layer is mechanics: how changes actually travel. The choices are few, and each trades latency against operational simplicity.

Push delivery through webhooks gives near real-time propagation and consumes no quota while nothing changes, at the price of running an endpoint that must be available, verify payloads, and tolerate redelivery — because webhook systems promise at-least-once, not exactly-once, delivery. Polling is operationally simpler and arrives batched, at the price of latency bounded by the schedule and of consuming API budget even when nothing happened. A defensible general pattern uses push for the few events where minutes matter — a closed deal creating a financial object — and scheduled reconciliation passes for everything else, with each write designed to be idempotent so that redelivery and retry are safe rather than duplicative.

Rate metering shapes all of this. HubSpot meters API usage per portal in short-window and daily allowances that vary by subscription tier and product add-ons, and search endpoints are metered separately from object reads; the current numbers are maintained in HubSpot's API usage documentation and change often enough that hardcoding them into an architecture document is how the document rots. The durable design consequences are number-independent: bulk work belongs on batch endpoints rather than record-by-record calls, integrations should budget their consumption against everything else sharing the portal's allowance, and month-end volume — the moment the finance calendar concentrates writes — is the load case to test, because it is the one a normal week never rehearses.

8. Failure and Observability

Integration failures divide into the visible and the silent, and the silent class dominates the damage. A validation rejection is an event; something can alert on it. The failures that end trust are absences — an expired credential, a paused schedule, a retired API version — in which records simply stop moving while both systems continue to look healthy. The design response is to monitor expected activity rather than observed errors: a connection that has moved nothing across a window in which the business certainly generated changes is alarming even though nothing has failed. Error monitoring answers whether the machinery broke; absence monitoring answers whether the business is still flowing through it, and only the second question protects the integration's credibility.

Three further practices separate integrations that survive contact with production from those that do not. Rejected writes are retained with their full payloads and routed to a queue a named person reads, because a rejection reduced to a log line is a record that silently never arrived. A scheduled reconciliation job counts records and sums key values on both sides and reports the difference to a person, converting drift from a rumour into a number. And every retry path is examined for idempotency, since an unguarded retry is the standard mechanism by which a timeout becomes a duplicate.

The reason to invest in observability is ultimately behavioural rather than technical. The sales-technology literature documents how quickly operational tools are abandoned when early experience disappoints — favourable first reactions giving way, within months, to rejection and workaround (Speier and Venkatesh 2002). An integration's users cannot see its architecture; they see whether the number on the record was right the last three times they checked. Trust, once lost to a silent failure, does not return with the patch, and the finance team's private spreadsheet — the artefact integrations exist to retire — reappears within weeks (Hunter and Perreault 2007).

9. Data Custody and the Security Review

Every architecture in section 4 answers a second question the selection rule does not ask: which organisations end up holding the firm's customer data, and what each of them retains. That question is asked in earnest twice — by a customer's security review, and by an insurer writing a cyber liability policy — and an integration chosen only on capability and price tends to be discovered at the point where one of them is waiting for an answer.

The middle zone is the one the architecture choice moves, and it is consistently the one a review under-weights, because it holds no records of its own. What it does hold is credentials for both sides, payloads while they are in flight, and the retry queues and error logs where those payloads accumulate — which means a component nobody thinks of as a database may retain more sensitive material, for longer, than either system it connects. The cloud security literature has made this point about service delivery models since the category was young: the security properties that matter are the ones inherited from the provider and the ones the customer remains responsible for, and the division between them is the thing to establish rather than assume (Subashini and Kavitha 2011). The same division has been framed as a multi-tenancy and trust-management problem, in which outsourcing a function does not outsource accountability for it (Takabi, Joshi, and Ahn 2010).

Four questions make the difference concrete, and each can be answered before a contract is signed rather than during an incident. Which organisations hold the data, in a list that names every party in the path and not only the vendor on the invoice — each boundary crossed in the diagram is a subprocessor a customer may reasonably ask to see. What is retained after delivery, since a payload log holding contact records for ninety days is a data store whatever it is called. Where the credentials live and who can read them, because a token with broad scope in a shared automation account is the most valuable object in the estate. And where the data physically rests, which is a contractual question wherever residency commitments or sector rules apply, and one the spectrum's right-hand end exists to answer.

Security spending has an economic optimum, and it sits lower than intuition suggests. Gordon and Loeb (2002) built a model relating money spent protecting a set of information to the loss expected if it were left unprotected. Their result was that optimal spending is bounded. It rises with the value at risk, but past a certain point each additional unit of protection costs more than the loss it prevents, and in their model that ceiling fell well short of the full expected loss. Self-hosting an integration to protect a contact list is that error made in the expensive direction.

The empirical work points the same way. Romanosky (2016) examined a decade of recorded security incidents and found that typical costs were far below the figures usually quoted, while the worst cases remained severe. Sen and Borle (2015) found that breach risk was not uniform but varied with the state, the industry, and the controls already in place. The question worth asking is therefore not how much protection can be afforded, but which specific exposure this particular integration creates. The custody map answers that directly.

Three practices follow, and none require a platform team. Scope each credential to the objects and operations the flow actually uses, then verify by attempting a write it should not be able to perform — a rejection is the passing result. Set an explicit retention period on payload logs and error queues, because the default in most tooling is to keep them until somebody notices. And record the custody map as a document rather than a diagram in a slide, since it is the artefact a security questionnaire is answered from and the one that shows, at renewal, whether anything moved.

This is architecture guidance, not legal or insurance advice. Whether a given design satisfies a policy's conditions, a regulator's requirements or a customer's contractual schedule is a question for counsel and for the underwriter, on the specific facts. What an architecture can do is make the answer cheap to produce: a firm that can name every organisation in its data path, and what each retains, is answering from a document rather than from memory.

10. Sequencing an Integration Programme

Architecture is a set of decisions; a programme is the order in which they are taken. The order that works runs small and accumulates: identity first, one authoritative flow second, bidirectionality later if at all, and derived data — rollups, margins, scores — only once the flows beneath them are trusted. Each stage produces something a person can verify before the next begins, which matters because verification is what converts an integration from a project into an institution.

Sequencing is also where governance either exists or does not. The implementation literature is blunt that sustained cross-functional involvement discriminates between success and failure (Umble, Haft, and Umble 2003), and the mechanism is visible at integration scale: field ownership, exception queues and reconciliation reports are all agreements between departments, and agreements need a standing forum — a data-health review, a monthly owners' meeting — or they decay into whatever the software's defaults happen to be. Kahn and Mentzer (1998) drew the distinction that applies here: interaction, the exchange of information, is not collaboration, the sharing of goals and work; a stack can be fully synced and organisationally unintegrated. The integration programme that produces durable numbers is the one that treats the standing forum as part of the architecture, not as ceremony around it.

11. Limits

This reference has boundaries a reader should hold onto. It is written for the commercial mid-market stack centred on HubSpot; very large estates with dedicated platform engineering, event-streaming infrastructure and formal data contracts face the same principles under different economics, and this document does not advise at that scale. It deliberately avoids hardcoding vendor limits, prices and connector capabilities, which change on the vendors' schedules; the linked documentation, not this text, is authoritative for current numbers. Its case evidence is drawn from this consultancy's own engagements, published pseudonymously on this site, and carries the interest and selection effects of practitioner reporting; it is offered as illustration of the principles, not as independent proof of them. And the peer-reviewed literature it cites was developed largely on ERP-era systems and sales-force automation; the transfer of those findings to CRM-centred integration is an argued analogy, plausible but not itself empirically tested here.

12. Conclusion

The recurring result across five decades of organisational and information-systems research is that integration is an achievement of coordination, and the software is the instrument rather than the achievement (Lawrence and Lorsch 1967; Galbraith 1974; Davenport 1998). Applied to the HubSpot stack, that result yields a short discipline: choose the cheapest architecture whose assumptions fit, and spend the savings on the three layers no architecture supplies — constructed identity, written ownership, and observability aimed at silence. Firms that do this find the tool decision becomes almost boring, which is the correct emotional register for infrastructure. The interesting decisions were never in the tools.

References

Batini, Carlo, Cinzia Cappiello, Chiara Francalanci, and Andrea Maurino. 2009. "Methodologies for Data Quality Assessment and Improvement." ACM Computing Surveys 41 (3): Article 16. https://doi.org/10.1145/1541880.1541883

Carlile, Paul R. 2002. "A Pragmatic View of Knowledge and Boundaries: Boundary Objects in New Product Development." Organization Science 13 (4): 442–455. https://doi.org/10.1287/orsc.13.4.442.2953

Davenport, Thomas H. 1998. "Putting the Enterprise into the Enterprise System." Harvard Business Review 76 (4): 121–131. https://hbr.org/1998/07/putting-the-enterprise-into-the-enterprise-system

Dougherty, Deborah. 1992. "Interpretive Barriers to Successful Product Innovation in Large Firms." Organization Science 3 (2): 179–202. https://doi.org/10.1287/orsc.3.2.179

Galbraith, Jay R. 1974. "Organization Design: An Information Processing View." Interfaces 4 (3): 28–36. https://doi.org/10.1287/inte.4.3.28

Gordon, Lawrence A., and Martin P. Loeb. 2002. "The Economics of Information Security Investment." ACM Transactions on Information and System Security 5 (4): 438–457. https://doi.org/10.1145/581271.581274

Hasselbring, Wilhelm. 2000. "Information System Integration." Communications of the ACM 43 (6): 32–38. https://doi.org/10.1145/336460.336472

Haug, Anders, Frederik Zachariassen, and Dennis van Liempd. 2011. "The Costs of Poor Data Quality." Journal of Industrial Engineering and Management 4 (2): 168–193. https://doi.org/10.3926/jiem.2011.v4n2.p168-193

Hunter, Gary K., and William D. Perreault Jr. 2007. "Making Sales Technology Effective." Journal of Marketing 71 (1): 16–34. https://doi.org/10.1509/jmkg.71.1.016

Kahn, Kenneth B., and John T. Mentzer. 1998. "Marketing's Integration with Other Departments." Journal of Business Research 42 (1): 53–62. https://doi.org/10.1016/S0148-2963(97)00068-4

Lawrence, Paul R., and Jay W. Lorsch. 1967. "Differentiation and Integration in Complex Organizations." Administrative Science Quarterly 12 (1): 1–47. https://doi.org/10.2307/2391211

Parnas, David L. 1972. "On the Criteria To Be Used in Decomposing Systems into Modules." Communications of the ACM 15 (12): 1053–1058. https://doi.org/10.1145/361598.361623

Redman, Thomas C. 1998. "The Impact of Poor Data Quality on the Typical Enterprise." Communications of the ACM 41 (2): 79–82. https://doi.org/10.1145/269012.269025

Romanosky, Sasha. 2016. "Examining the Costs and Causes of Cyber Incidents." Journal of Cybersecurity 2 (2): 121–135. https://doi.org/10.1093/cybsec/tyw001

Sen, Ravi, and Sharad Borle. 2015. "Estimating the Contextual Risk of Data Breach: An Empirical Approach." Journal of Management Information Systems 32 (2): 314–341. https://doi.org/10.1080/07421222.2015.1063315

Soh, Christina, and Siew Kien Sia. 2004. "An Institutional Perspective on Sources of ERP Package–Organisation Misalignments." Journal of Strategic Information Systems 13 (4): 375–397. https://doi.org/10.1016/j.jsis.2004.11.001

Speier, Cheri, and Viswanath Venkatesh. 2002. "The Hidden Minefields in the Adoption of Sales Force Automation Technologies." Journal of Marketing 66 (3): 98–111. https://doi.org/10.1509/jmkg.66.3.98.18510

Subashini, S., and V. Kavitha. 2011. "A Survey on Security Issues in Service Delivery Models of Cloud Computing." Journal of Network and Computer Applications 34 (1): 1–11. https://doi.org/10.1016/j.jnca.2010.07.006

Takabi, Hassan, James B. D. Joshi, and Gail-Joon Ahn. 2010. "Security and Privacy Challenges in Cloud Computing Environments." IEEE Security & Privacy 8 (6): 24–31. https://doi.org/10.1109/MSP.2010.186

Umble, Elisabeth J., Ronald R. Haft, and M. Michael Umble. 2003. "Enterprise Resource Planning: Implementation Procedures and Critical Success Factors." European Journal of Operational Research 146 (2): 241–257. https://doi.org/10.1016/S0377-2217(02)00547-7

Wand, Yair, and Richard Y. Wang. 1996. "Anchoring Data Quality Dimensions in Ontological Foundations." Communications of the ACM 39 (11): 86–95. https://doi.org/10.1145/240455.240479