India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Cloud Data Strategy & Target Architecture for Analytics Platforms
Data strategy and architecture is the work of deciding which business questions an analytics platform must answer, which data domains feed it, which cloud pattern (warehouse, lake or lakehouse) hosts it, and who owns each dataset. NTSPL runs this as a 6-8 week engagement for Indian enterprises, ending in a target-state design, an operating model and a costed, sequenced roadmap.
Delivered on
In scope
Why Analytics Estates Drift Without a Target State
Most analytics estates we review grew one request at a time: a Power BI workspace here, an Athena bucket there, three copies of the customer master and a finance team that still closes the month in Excel because no one trusts the dashboards. The real cost is a 40-day wait for a new KPI, two versions of revenue in the board pack and data engineers spending most of their week on reconciliation.
NTSPL starts from decisions, not tools. We list the 30-50 recurring decisions the business makes, trace each to its source systems and owners, and only then compare platform patterns against your volumes, latency needs and skills. Within eight weeks you get a domain map, a platform choice with written reasons, and a roadmap where every phase ships a usable data product.
Signals Your Organisation Needs a Data Strategy Reset
Signals you need Data Strategy & Architecture
- Teams report different numbers for the same KPI (revenue, active customers, AUM) in leadership reviews
- A new governed metric takes more than 4 weeks because every request needs fresh pipelines
- Two or more analytics stacks run side by side (say Redshift plus Fabric) with no convergence plan
- Analytics spend has crossed INR 50 lakh a year with no owner or business case per workload
When to choose something else
- You only need an inventory of databases to migrate: our Data & Database Assessment in the Cloud Assessment family is the faster, cheaper engagement.
- The platform is already chosen and funded and you need it built: go straight to Cloud Data Warehouse or Lakehouse Architecture and fold design decisions into sprint zero.
What the Strategy Engagement Covers
Decision and KPI inventory
Workshops with finance, sales, operations and risk heads to capture 30-50 recurring decisions, their KPIs, refresh needs and current source of truth.
Source and domain mapping
Trace each KPI to ERP, CRM, core and SaaS systems, then group data into 6-12 business domains with named owners and stewards.
Platform pattern selection
Score warehouse, lake and lakehouse patterns on volume, latency, semi-structured share, skills and licence position, with a written recommendation.
Operating model
Central platform team versus domain teams, RACI for data products, intake process and funding model, with DPDP purposes and RBI/SEBI residency rules recorded per domain.
Costed roadmap
An 18-month plan in 3-month increments, each ending with a named data product, team size, and indicative INR run and build cost.
Decision-to-Domain Architecture Blueprint
Decision-to-Domain Data Platform Blueprint
Business decisions are traced to KPIs, KPIs to source systems, and sources are grouped into owned domains. Domains then land on a chosen platform pattern with shared governance and a phased roadmap.
Select any component
Decision-to-Domain Data Platform Blueprint: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
How the Target State Maps to AWS, Azure and Google Cloud
We usually design an S3-centred lake with Redshift for curated marts, and use Lake Formation tags so domain teams publish without central tickets. Mumbai primary, Hyderabad for DR copies.
For Microsoft 365-heavy organisations we model domains as Fabric workspaces on OneLake, with Purview for the catalogue. Capacity is sized per domain so one team cannot starve another.
On Google Cloud the warehouse and lake converge in BigQuery with BigLake tables over Cloud Storage; Dataplex lakes and zones mirror the domain map directly.
Architecture Choices We Settle in Writing
Warehouse, lake or lakehouse
If over 80% of analytical data is structured ERP and CRM data under 20 TB, a cloud warehouse is simpler and cheaper to run. If semi-structured logs, IoT or documents exceed roughly 30% of volume, or data science needs file-level access, choose a lakehouse on Iceberg or Delta. Pure lakes without a table format are rarely justified in 2026.
Centralised team or data mesh
Under about 15 data engineers, a central platform team with domain-aligned squads beats full mesh. Move a domain to self-serve only when it has a business owner, at least two engineers and a published data contract. We stage it: central build in phases one and two, federated ownership from phase three, reviewed quarterly against delivery lead time.
Primary cloud and region
Pick the cloud where your ERP and identity already live unless a hard capability gap exists; egress and skills outweigh list-price differences. Fix India regions early (Mumbai or Hyderabad on AWS, Central India on Azure, Mumbai or Delhi on Google Cloud) and document which datasets must never leave the country.
Semantic layer ownership
Decide whether KPI logic lives in the BI tool (Power BI semantic models, LookML) or in transformation code (dbt, Dataform). With more than two BI tools or heavy API consumption, put it in a tool-neutral layer. Whatever you choose, no KPI may be defined in two places, and the glossary must point to the one location.
Six-to-Eight-Week Strategy Sprint Plan
Executive alignment and decision capture
Interviews with 10-15 leaders and a decision workshop to build the KPI register and agree priorities.
Source discovery and lineage sketch
System-by-system walkthroughs, sample extracts and lineage for the top 15 KPIs.
Domain and operating model design
Domain boundaries, owners, data product canvases and the team model agreed with HR and finance.
Platform scoring and reference architecture
Weighted pattern scoring, a short proof of concept where scores are close, and the reference design.
Roadmap, costing and board pack
Quarterly roadmap with INR build and run estimates, risks and a decision paper for the steering committee.
What you receive
Measures That Prove the Strategy Is Working
| KPI | Typical target |
|---|---|
| Time to deliver a new governed KPI | Under 10 working days within two quarters |
| Top-25 board KPIs with one definition | 100% |
| Domains with a named business owner | All, before phase two |
| Analytics spend mapped to a data product | Above 85% |
Where Data Strategies Fail and How We Prevent It
| Risk | How NTSPL prevents it |
|---|---|
| Strategy becomes a tool-selection exercise driven by a vendor demo | Scoring weights are signed off before any platform is scored, and every recommendation cites the decision it serves. |
| Roadmap is too large to fund, so nothing starts | Phase one is capped at one domain and one data product deliverable in 12 weeks with a fixed budget. |
| Domain owners are named but never act | Owner duties are written into the RACI with a monthly 30-minute review and quality metrics they must sign off. |
Data strategy consulting vs a data platform proof of concept: which should come first?
Strategy first, if more than one business unit or platform is involved. A proof of concept shows whether a tool can run your queries; it cannot tell you which 15 KPIs matter, who owns the customer master or how to fund domain teams. We have seen PoCs succeed technically and programmes stall for a year on ownership. With a single team, source and use case, skip strategy and run a 4-week PoC. Otherwise run a short strategy sprint and use the PoC only to break ties.
Key facts: Data Strategy & Architecture
Data Strategy & Architecture in Practice
2 Data Strategy & Architecture scenarios, from Mutual fund (asset management company) and Decorative paints manufacturing, plus related platform case studies.
Mutual fund house moves from 4 reporting stacks to one roadmap and a single AUM number
Paints maker builds a dealer-tinting data strategy that ties shade demand to production
Agri-inputs company sees dealer secondary sales daily instead of 45 days late
Dairy cooperative sees milk procurement by collection centre within 15 minutes
Data Strategy & Architecture: Frequently Asked Questions
How long does a data strategy and architecture engagement take?
Typically 6-8 weeks for a mid-size enterprise with 10-25 source systems; groups with several business units take 10-12 weeks. Most engagements are fixed-price, between INR 18 and 45 lakh, and include the roadmap, reference architecture and steering-committee paper. Optional proofs of concept are quoted separately.
Will you recommend a specific cloud or tool?
Yes, but only after the scoring is agreed. We work across AWS, Azure and Google Cloud and record the reasons in architecture decision records. Where your ERP, identity and skills already sit on one cloud, that usually wins unless a specific capability gap is proven.
How does the DPDP Act 2023 affect our data architecture?
It requires you to process personal data only for stated purposes and to erase it when the purpose ends. Architecturally, that means tagging personal data at ingestion, keeping a purpose register per dataset, designing for deletion across lake and warehouse copies and logging access. We bake these into the domain and zone design.
Do we need a data mesh?
Usually not on day one. Mesh pays off when several domains have their own engineers and clear owners. Most Indian mid-market firms do better with a central platform team and domain-aligned squads, federating once two or three domains publish stable data products. That usually happens in phase three.
What do we get at the end that we can act on?
A decision-ready board paper, a reference architecture, a domain map with owners, an operating model and a quarterly roadmap with costs. Phase one is specified in enough detail to raise a purchase order or brief an internal team the following week, without another discovery round.
Can the strategy cover our existing on-prem warehouse?
Yes. We assess its fit in the target state and decide whether to retire, migrate or keep it for a defined period, usually 12-24 months. If migration is chosen, the detailed move is planned and executed under our Data Modernization & Migration service.