A warehouse people query, with access rules your identity team can explain.
We build data platforms on Snowflake, Databricks and Microsoft Fabric, model the data so analysts can use it, and tie every grant back to a group in Okta or Entra ID. CRM, ERP and claims data are where we start most often.
Data and analytics covers how a company collects, models, governs and reports on its data.
Cohash designs and builds data platforms on Snowflake, Databricks and Microsoft Fabric, writes pipelines with dbt, Fivetran and Airflow, models data for analysis, and sets up access control tied to your identity provider. We then build the BI and analytics that sit on top.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Data & Analytics, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · where you end up
incident board · data & analytics3 open
openFinance and operations bring different customer counts to the same meeting.
recurringWarehouse access is granted by hand to individual users. Ask for a list of who sees what and nobody can produce one.
blockedCRM, ERP and claims data only meet in a spreadsheet someone rebuilds each month.
exposure
Data strategyData engineeringData modelingGovernance and accessData integrationBI and advanced analytics
ready to hand over
The disagreement has a known cause and a single owner.
When someone leaves the identity provider, they lose warehouse access too.
chapter 01 · where it hurts
Why teams reach out
Finance and operations bring different customer counts to the same meeting.
Warehouse access is granted by hand to individual users. Ask for a list of who sees what and nobody can produce one.
CRM, ERP and claims data only meet in a spreadsheet someone rebuilds each month.
chapter 02 · what we change
How we solve it
Data strategy
Data engineering
Data modeling
Governance and access
Data integration
BI and advanced analytics
chapter 03 · where you end up
What changes
The disagreement has a known cause and a single owner.
When someone leaves the identity provider, they lose warehouse access too.
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
A plan that starts from the decisions the business needs to make, and works back to the sources, platform and team it takes.
We build ingestion and transformation pipelines on Snowflake, Databricks or Fabric and test and deploy them like application code.
Dimensional models first. Where history and auditability matter, Data Vault 2.0. On top, a semantic layer so each metric is defined once and only once.
We set up roles, row access and masking policies in Snowflake and Unity Catalog and provision them from Okta or Entra ID groups.
We bring CRM, ERP, claims and SaaS data into the platform. Managed connectors where they exist, CDC or APIs where they don't.
Governed reporting on the warehouse, plus forecasting, segmentation and machine learning models that feed back into operations.
capability 01 / 06in production
Data strategy
A plan that starts from the decisions the business needs to make, and works back to the sources, platform and team it takes.
Dimensional models first. Where history and auditability matter, Data Vault 2.0. On top, a semantic layer so each metric is defined once and only once.
We pieced these together from Data & Analytics situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Three data platforms and three different revenue numbers
composite · not a client story
Beforethe situation
Finance reports from Snowflake. Data science trains on Databricks. One business unit moved its Power BI workspaces onto Fabric. Revenue differs by a few percent depending on which platform you ask, and each one has its own grants.
What we dothe work
We trace the revenue metric through each platform's pipelines back to the ERP tables and write down where the logic forks. Then we pick one place to define it, feed the other platforms from there through data sharing or Fabric mirroring, and map access on all three to the same Entra ID groups.
Afterwhere you end up
The disagreement has a known cause and a single owner. Analysts keep the platform they prefer, but revenue comes from one definition and access follows the same groups everywhere.
case file 02
A warehouse that works, and an audit finding about who can query it
composite · not a client story
Beforethe situation
The Snowflake account has run for years and the pipelines are fine. Internal audit found that many analysts hold roles granted straight to their user, and several leavers still have active Snowflake users.
What we dothe work
We pull every grant from the GRANTS_TO_USERS and GRANTS_TO_ROLES account usage views, match users to the identity provider and disable orphans first. Then we design functional and access roles, move provisioning to SCIM from Okta, and put grants into Terraform so every change gets reviewed.
Afterwhere you end up
When someone leaves the identity provider, they lose warehouse access too. Grants live in code. The next time audit asks, the answer is a query and a pull request history.
How a governed data platform fits between your sources and your users
Operational data from CRM, ERP and claims systems is ingested and modeled on Snowflake, Databricks or Fabric. Access is provisioned from your identity provider's groups, and BI and models read only what each user or service is allowed to see.
01 · Sources
CRMSalesforce · Dynamics 365 → Data platform · connectors
ERP and financeledger · orders · inventory → Data platform · CDC
Claims and payer dataTriZetto Facets → Data platform · extracts
02 · Data platform
Data platformSnowflake · Databricks · Fabric → BI and reporting · governed tables→ Analytics and ML · feature tables
Transformation and modelsdbt · Spark · semantic layer → Data platform · models
03 · Access
Identity providerOkta · Entra ID groups → Data platform · SCIM groups
04 · Consumers
BI and reportingPower BI · Tableau
Analytics and MLforecasts · scores → CRM · scores back
Put these to anyone bidding on your Data & Analytics work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which engineers on your team will write our pipelines, and can we meet them before we sign?
Snowflake, Databricks and Fabric fail in different ways. The people in the sales meeting are often not the ones doing the work, so ask to talk to the engineers who will be.
Q2
How will you measure what our platform costs today before you propose changes?
Cost advice without a baseline is guesswork. Warehouse metering, cluster usage or Fabric capacity metrics should show which jobs and users drive the bill before anyone resizes anything.
Q3
Where will access be defined, and how will it stay in sync with our identity provider?
Most warehouse audit findings come from grants made by hand. Ask whether roles are provisioned from Okta or Entra ID groups and managed as code, or clicked together in the console.
Q4
What will our team be able to change without you six months after handover?
Tests, CI/CD, runbooks and naming standards decide whether your engineers can maintain the platform. A vague answer usually means a long support contract.
Q5
How do you decide what not to migrate?
Most estates carry reports, tables and pipelines nobody uses. A partner that moves everything spends your budget carrying dead weight to a new platform.
01Snowflake, Databricks or Microsoft Fabric?
It depends on your workloads and what you already run. Heavy SQL analytics teams often start with Snowflake. Teams with large Spark, streaming or ML workloads often choose Databricks. Organizations deep in Microsoft 365 and Power BI often look at Fabric. We compare cost, skills and existing contracts before recommending one.
02Can you work with the platform we already have?
Yes, and that's most of our work. We start by reviewing pipelines, models, costs and access, then go after the thing causing the most pain.
03What drives the cost of a data platform project?
Mainly how many sources there are and how messy they are, how fresh the business needs the data, and how many governed data products you want at the end. We measure those in discovery before giving an estimate.
04Do you handle access control, or just pipelines?
Both, every time. If analysts can't be let into the warehouse safely, nobody uses it.
05Can you stay on after the build to help run the platform?
Yes, if you want that. Some teams want a period of shared support after go-live, others want a clean handover. We agree which pipelines, models and access processes are covered and how incidents reach us before the build ends.
related
Often paired with
Projects on Data & Analytics usually end up touching one of these, so they're worth a look.
