Integrated suite or best-of-breed systems: how to decide

Reference article · 8 min read

An agency usually faces this choice when a core system reaches the end of its support life, or when a budget cycle opens the door to replacement. One vendor offers a suite: finance, payroll, permitting, and a resident portal from a single company under one contract. Other vendors offer individual systems that each cover one of those functions, connected by interfaces the agency owns. Both patterns are in common use in the public sector, and both can work or fail depending on fit and on how the agency manages what it bought.

The argument is usually framed as simplicity against capability. A more useful framing is where the agency wants its complexity to sit: inside a vendor's product, where the agency has limited visibility and limited ability to change what it finds, or in its own integration layer, where the agency can see the problem and has to staff and fund the fix. Neither option removes the work.

The integrated suite

A suite is a set of modules sold by one vendor as a single product, usually with shared data, shared identity, and a common interface. Depth of integration varies. Some suites were built on a single data model. Others were assembled through acquisition, and the modules are connected to different degrees.

Where it fits. Suites fit where processes are ordinary across agencies and most of the value comes from records moving between functions without rekeying. One contract, one implementation partner, one support path, one upgrade schedule, and one security review reduce the number of relationships a small team has to manage. For an agency with a thin IT staff, that reduction can decide whether the portfolio stays supportable.

Where it fails. Three failure modes recur. The first is uneven module strength: few suites are the strongest available product in every function, so at least one module is likely to trail a specialist, and the people who use that module live with the gap. The second is process fit. Suites carry assumptions about how work should flow, and where statute, a labor agreement, an ordinance, or council policy conflicts with those assumptions, the agency either changes its process or pays for configuration and customization that can complicate later upgrades. The third is concentration: one vendor holds the core operations, the data, and the renewal price, and switching costs rise the longer the suite is in place.

A suite also does not eliminate integration. Agencies still exchange data with state reporting systems, banks and payment processors, courts, benefits administrators, and other jurisdictions. Those interfaces exist under either architecture, and they need the same ownership and monitoring.

Best-of-breed systems connected by integration

Best-of-breed means selecting a system for each function on its own merits and connecting them through documented APIs, an integration platform, scheduled file transfers, or a combination. The agency, or an integrator under contract to the agency, owns those connections.

Where it fits. It fits where a function is specialized enough that a dedicated product is meaningfully stronger than a general module. Computer-aided dispatch, law enforcement records, utility billing, permitting, and asset and work management are common examples. It also preserves the ability to change one part without changing everything: a system that underperforms can be replaced on its own, a poor vendor relationship stays contained to one function, and the agency keeps leverage at each renewal instead of concentrating it in one. For an agency that has staff or a contracted partner able to own interfaces, that control is usable rather than theoretical.

Where it fails. Three failure modes recur here as well. The first is that interfaces are permanent work: each one is a small product with its own error handling, monitoring, and reconciliation, and it needs a named owner after go-live. The second is upgrade coordination, since vendors set their own release schedules and a change on one side can break an interface on the other, so someone has to track release notes and test before each release lands. The third is divided accountability: when a record is wrong, each vendor may point to the other, and the agency is the only party that can see both systems. Interface failures are often quiet, surfacing through a failed reconciliation or a resident complaint rather than an alert, unless the agency builds monitoring for them.

How to decide

Each question below points toward one answer or the other. Work through them with the people who will operate the systems.

1. Where is the regulated or operational work? Functions governed by external rules or central to service delivery often justify a specialist. Functions that operate much the same way everywhere, such as general ledger, accounts payable, and payroll, usually do not.
2. Name the owner of each interface after go-live. Point to a position, a contract line item, or a specific vendor obligation, and confirm it is funded past the first year. If no owner can be named, weight the suite, because unowned interfaces fail without anyone noticing.
3. Score the functions separately, and set a floor. Evaluate each function with its own users and its own scenarios, and define a minimum acceptable score per function in advance. A suite that fails the floor in a function staff use daily should not be bought whole, and a specialist that cannot meet a stated integration requirement should not be bought either.
4. Look at the real data flows. For each pair of functions, write down what moves, in which direction, how often, and how current it must be. Constant two-way exchange raises the value of shared data inside one product. A nightly one-way file is inexpensive to integrate under either architecture, which narrows the suite's advantage.
5. Check the compliance scope of the data. Criminal justice information brings the FBI CJIS Security Policy into scope, federal tax information brings IRS Publication 1075, protected health information can bring HIPAA, and payment card data brings PCI DSS, an industry standard rather than a law. Those obligations follow the data across every interface and into every hosting arrangement, so more copies and more connections mean more to document and audit.
6. Price the whole picture over the expected life. Set the suite subscription and implementation against the sum of several subscriptions, the integration platform or middleware, the interface build, and the annual hours to maintain and test the interfaces. Compare totals over the expected term, including renewal increases, rather than license against license.
7. Write the exit path for each option. Describe what replacing one component would take, what data comes out, in what format, and at what cost. A suite concentrates that risk in one large exit; best-of-breed spreads it across several smaller ones. Decide which risk profile the agency can absorb.

Many agencies land on a hybrid: a suite for the administrative core, specialists for the operational systems, and a defined set of documented interfaces between them. That is a legitimate answer rather than an avoided decision, but only when the boundary is chosen deliberately and each interface has an owner.

What this means for your solicitation

• Do not name the architecture in the requirement. Describe the outcomes and the data that must move between functions, and let suite and best-of-breed proposals compete against the same criteria.
• Publish module-level evaluation criteria and minimum scores so that strong modules cannot carry a weak one through scoring.
• Make integration a priced deliverable rather than an assumption. For each interface, ask who builds it, who owns it after go-live, what happens when either side upgrades, and what it costs annually.
• Ask suite proposers which modules were built in house and which were acquired, and how the modules exchange data today. The answer shows whether the integration is a shared data model or a set of interfaces that the vendor maintains instead of the agency.
• Require data ownership and export terms: documented API access, bulk export in a usable format, and the right to extract agency data during the term and at termination. Public records and retention obligations come from state law and follow the data wherever it is stored, so these terms matter under either architecture.
• State security and accessibility requirements the same way for every proposer. Section 508 standards apply to federal agencies, and many states have adopted comparable requirements by statute or policy; both commonly reference the WCAG success criteria at a stated conformance level. Where federal funds are involved, grant conditions can add further requirements.

HQT offers technology advisory and systems engineering services, including integration architecture and pre-solicitation assessment for agencies weighing this choice.

Frequently asked questions