Procurement: Data Platform
What this is and who it’s for
This runbook tells you how to buy data-platform tooling — a warehouse or lakehouse, ingestion/ELT, BI, and governance — on a Maryland contract vehicle without signing up for an unbounded consumption bill or a proprietary lock-in. It’s for an agency tech lead, the procurement officer who has to put it on a contract, and the data owner accountable for classification and retention. It assumes you’ve already settled your data architecture; the job here is converting that into a defensible requirement, the right vehicle, a SOW you can stand behind, and an evaluation that picks a tool on merit. If you can’t yet describe your data volume, who consumes the data, and how it’s classified, stop and read the prerequisites first.
Prerequisites
- You’ve read the Reference Data Platform Architecture and can name your warehouse/lakehouse, ingestion path, and BI layer. You cannot write a defensible requirement for an architecture you haven’t drawn.
- You’ve settled hosting through the Cloud Hosting procurement runbook, because most data-platform tooling rides on or beside a cloud-hosting contract and inherits its authorization posture.
- Your data owner has classified the data in scope — what is public, what is sensitive, and what is PII — and stated the retention obligation by policy or regulation [VERIFY: Maryland records retention schedule]. Classification narrows the vendor field before you start, and retention drives storage cost, so settle both up front.
- You know, roughly, your scale: stored data volume, query concurrency, and how many people actually consume the data. Consumption-based pricing means usage, not features, usually decides the bill.
The practice
Run this as four moves in order: define the requirement, pick a vehicle, write the SOW, evaluate. The delivery model is the hinge decision — it changes the vehicle, the SOW, and the cost shape — so make it explicitly rather than letting a vendor make it for you.
Define the requirement
Write down five things before you talk to anyone: data volume, query and concurrency profile, who consumes the data and how, the data classification including PII, and the retention obligation. State consumption as outcomes (“analysts run ad-hoc queries against two years of case data,” “nightly batch loads from three source systems”), not product features. Capture the classification per dataset, because a single PII column can move the whole platform into a higher compliance tier. Write retention per dataset against your records schedule [VERIFY: Maryland records retention], since it sets both storage cost and exit obligations.
Choose a delivery model
Integrated managed-cloud suite
One vendor provides warehouse, ingestion, BI, and governance as a single managed platform. Fastest to stand up and the least to operate, with one vendor relationship and usually one inherited authorization [VERIFY]. The trap is the cost shape: consumption or compute-credit pricing scales with every query and load, not with your budget, so an unbounded clause is a budget event waiting to happen. Procurement-wise this is a service subscription that often maps cleanly to an existing cloud or software vehicle — but the budget cap belongs in the SOW.
Best-of-breed assembled tools
You pick the strongest tool in each category — warehouse, ingestion/ELT, BI, catalog — and integrate them. Best capability per layer and no single-vendor lock-in, at the cost of more contracts, more integration, and more authorizations to verify [VERIFY]. Each tool carries its own pricing model, so the consumption trap can hide in any one of them; price every layer at projected scale, not just the warehouse. Procurement-wise this is several buys, possibly on different vehicles, so confirm each in Procurement notes.
Open-source self-hosted stack
You run the stack on your own infrastructure — for example a columnar warehouse engine, an open ingestion framework, and an open BI tool. No per-query licensing and full data control, which simplifies the compliance story because the data never leaves your boundary. The cost moves from license to labor and infrastructure, so the procurement is for implementation and managed-operations services plus compute — not for the software. Budget for the people who will run it; “free software” is not free to operate.
Map to a vehicle
Match the model to the smallest vehicle that fits. A single SaaS subscription under the small-purchase threshold [VERIFY] may not need a full RFP; a multi-year enterprise suite will. Best-of-breed and self-hosted work spread across several buys, some of which may be services rather than software. Confirm the candidate vehicles in Procurement notes before committing.
Write the SOW
Fork the skeleton in Reference implementation. Keep the data volume, classification, retention, and budget cap as explicit, testable requirements — not preferences. Put data ownership, format portability, and exit in writing every time, regardless of model.
Evaluate
Score against the published rubric, not against the demo. Weight authorization and data exit/portability as gates: a tool that fails either is out, however good the dashboards look. Run your scale numbers through each vendor’s consumption model and evaluate cost at projected volume, with a cap, not at pilot volume.
Map the capability to a component category
Managed cloud data warehouse / lakehouse
The store and query engine for analytical data, run as a managed service. Procurement angle: this is where the consumption trap lives, so the deciding terms are the pricing model and a budget cap — require both in writing at your projected scale, and confirm the storage format is open enough to export without re-platforming [VERIFY authorization for any PII in scope].
Ingestion / ELT tooling
Moves data from source systems into the warehouse and transforms it. Procurement angle: pricing is often per-connector or per-row, which scales with source count and volume, so price it at projected scale and confirm the connectors you actually need exist before award rather than assuming the catalog covers them.
BI / visualization
The consumption layer where people read dashboards and run queries. Procurement angle: this is usually priced per seat, and the common waste is buying seats for everyone when only a few people author — separate authors from viewers and confirm viewer pricing before you size the buy.
Data catalog / governance
Catalogs datasets, tracks lineage, and enforces classification and access policy. Procurement angle: easy to defer and the most expensive to add late, because without it the platform becomes a swamp — fund it in the same buy and require it to enforce the classification your data owner already set.
Reference implementation
Fork this SOW skeleton. Every bracketed item is a decision you must make or a value a human must verify; do not ship it with placeholders intact.
# STATEMENT OF WORK — DATA PLATFORM
### 1. Scope
The Contractor shall provide [integrated managed-cloud suite | best-of-breed assembled tools | implementation and managed operations of an open-source stack] covering a data warehouse/lakehouse, ingestion/ELT, BI/visualization, and data catalog/governance for [AGENCY / SYSTEM]. Estimated scale: [N TB stored], [N concurrent queries / peak], [N source systems], [N BI authors / N BI viewers]. Term: [base period + option years].
### 2. Data Volume and Pricing Model
The platform is priced on a [consumption / compute-credit / fixed] model. The Contractor shall state pricing at the scale in Section 1 AND at [+50% | +100%] of that scale. Budget cap: a hard not-to-exceed of [FILL IN: NTE amount per agency budget authority] per [month / quarter], with [alerting / throttling] at [80%] of cap, so a bad query is not a budget event.
### 3. Security, Classification, and Authorization
The service shall hold [FedRAMP | StateRAMP authorization at IMPACT LEVEL] for the term for any component that stores or processes agency data. Data shall be classified per [AGENCY] policy; any dataset containing PII shall be [encrypted / tokenized / masked] and access-controlled. Data residency shall be [continental US | Maryland-specific requirement].
### 4. Data Ownership, Exit, and Format Portability
All data is the property of [AGENCY]. The platform shall store data in, or export to, [open columnar format] so no proprietary format prevents export of raw data. On termination the Contractor shall, within [N days], export all data and schema at no additional charge and certify deletion of agency data from its systems.
### 5. Retention
Each dataset shall be retained per [AGENCY] records schedule: [dataset → N years]. Retention shall be configurable per dataset without re-contracting, and archival tiers shall remain queryable or restorable as policy requires.
### 6. BI Seats
The Contractor shall price [N author seats] and [N viewer seats] separately. Viewer access shall not require an author license. Seat reassignment shall be self-service without re-contracting.
### 7. Service Levels
- **Platform availability:** [e.g. 99.9%] measured monthly.- **Query performance:** [target] at the concurrency in Section 1.- **Support response:** [severity tiers and response times].
### 8. Support and Onboarding
The Contractor shall provide implementation, source-system integration, catalog/governance setup, dashboard configuration, and knowledge transfer sufficient for [AGENCY] staff to operate the platform unaided by end of [period].Score every responsive bid against this rubric. Treat the two gate rows as pass/fail: a failure on either eliminates the bid regardless of total score.
| Criterion | Weight | Notes |
|---|---|---|
| Authorization for in-scope data (gate) | Pass/fail | FedRAMP/StateRAMP at required level [VERIFY] |
| Data exit and format portability (gate) | Pass/fail | Open-format export, no proprietary lock-in |
| Cost at projected scale with cap | 30% | Scored at +50%/+100% scale, with NTE cap |
| Capability coverage | 20% | Warehouse, ingestion, BI, catalog completeness |
| Governance and classification fit | 15% | Catalog, lineage, PII access controls |
| Operational burden | 15% | Staff effort to run and maintain |
| Integration fit | 10% | Works with source systems and current cloud |
| Support and onboarding | 10% | Response SLAs, knowledge transfer |
Common pitfalls
- Consumption pricing with no budget cap. If the contract bills per query or per credit with no not-to-exceed, a single bad join is a budget event. Require a hard NTE cap with alerting in SOW Section 2 and make cost-with-cap a scored line.
- Vendor-proprietary storage format. If the platform stores data in a format only it can read, the vendor owns your leverage at renewal and re-platforming is a project. SOW Section 4 requires open-format export; make portability a rubric gate.
- BI seats for everyone. If you bought author seats for an agency where only a handful of people build dashboards, you overpaid before launch. Separate authors from viewers in SOW Section 6 and size to actual consumption.
- No governance, so it becomes a swamp. If the catalog and classification were deferred, nobody can find or trust the data within a year. Fund the catalog in the same buy, as in the component category above, not in a later phase.
- PII in a SaaS warehouse with no classification. If sensitive columns land in a hosted warehouse before classification, you have a compliance incident, not a platform. Require classification and authorization in SOW Section 3 before any data flows.
- Retention ignored. If you priced storage without the records schedule, your cost and your exit obligations are both wrong. Set retention per dataset in SOW Section 5 against [VERIFY: Maryland records retention] before award.
Procurement notes
Candidate Maryland vehicles depend on the delivery model and dollar value, and must be confirmed with your procurement officer.
- Integrated managed-cloud suite: [FILL IN: Maryland contract vehicle — e.g. COMMBUYS master contract # / NASPO ValuePoint cloud vehicle].
- Best-of-breed assembled tools: [FILL IN: vehicle(s) per component — software and/or IT services master contract #].
- Open-source self-hosted stack: [FILL IN: Maryland IT master services vehicle #] plus compute on the Cloud Hosting contract.
Thresholds decide the path. Below the small-purchase threshold [VERIFY] you may avoid a full solicitation; above it you run an RFP against this runbook’s SOW and rubric [VERIFY]. A typical timeline runs roughly [VERIFY: e.g. 4–8 weeks for a small purchase, 3–6 months for a competitive RFP] — confirm against current Maryland procurement guidance before you commit a date to anyone.
Budget the platform differently from a fixed subscription. Consumption pricing means the contract value is an estimate, not a fixed sum, so set the not-to-exceed cap as your real budget control and reconcile actuals against it monthly [VERIFY: agency budget-authority rules for consumption-based contracts].
For SOW drafting mechanics beyond this skeleton, see How to write a good SOW.
Maintenance
Owner: [FILL IN: runbook owner] · Last reviewed: 2026-05-31 · Next review: 2026-08-31