Production decision study

01 / PRODUCTION DECISION STUDY

Purpose of this decision study

This study helps SHARED owners compare choices before finalising the specification and assigning the development project. No application framework, database engine or analytics product is selected or recommended here.

Hosting preference, technology choice still open

An in-country primary with independent recovery is a proposed option. The client and operator must confirm hosting, residency, custody and costs under C07. The software stack, database, warehouse, reporting tools and recovery mode remain options for assessment.

Compare complete solutions against the same functional requirements, GIS workloads, security tests, recovery targets and three-year costs. Existing prototype technology is background evidence and a reuse consideration; it does not make that technology the production winner.

Use the comparison workshop and development-team handover sections below to record evidence, settle trade-offs and approve the final design. This page makes no infrastructure purchase or real-system change. Prototype previews do not establish production readiness.

02 / PRODUCTION DECISION STUDY

Current baseline and future selection

The current author issue is SRS Version 1.6. It describes required behavior and proposed logical boundaries. No installed application, real repository or operational service was inspected for this correction.

Area	Current specification	Decision still needed
Core access	Responsive, low-bandwidth user journeys and authenticated service interfaces.	C06 confirms devices, languages and accessibility journeys.
Application	A modular application with shared business rules, explicit contracts and controlled data access.	C07 selects a supported implementation and operator.
Data	Relational and geospatial records, protected originals, versions, transactions, source rights and history.	C02/C04/E01 confirm meanings, ownership and mappings.
Service targets	Use the existing numerical proposals and conditions in the NFR annex. Browser checks are separate.	C05/C06/C07/C08 approve the complete measurement configuration.
Additional channels	Offline operation and additional field-access channels are conditional options.	C01/C06/C07 confirm need, scope, cost and support.

Read the current SRS · NFR conditions

03 / PRODUCTION DECISION STUDY

Hosting options and trade-offs

Hosting, residency, operator, recovery and custody remain pending C07. Compare independent failure domains, support obligations and complete lifecycle cost using the same agreed workload.

Option	Meaning	Evidence needed
Institution-operated environment	Institution-managed facilities, application services, storage and independent recovery.	Facilities, staffing, monitoring, patching, recovery and funding.
Colocation or managed private environment	Institution-controlled service boundaries with contracted facility or operations support.	Exact site, responsibilities, capacity, support, custody and exit terms.
Managed hosting services	Contracted application, storage and recovery capabilities under an approved service boundary.	Residency, isolation, compatibility, recovery, charges and portability.
Governed hybrid arrangement	Approved operational and analytical boundaries with controlled data exchange.	Permitted data classes, identity, source rights, reconciliation, operating cost and independent recovery.
Reuse an existing institutional platform	Configure or extend an established service where it meets the accepted requirements.	Workflow fit, authority, permissions, integration, continuity and exit proof.

No supplier, technology product, hosting country or operating commitment is selected by this page. Obtain comparable offers only after the requirement and measurement baseline is agreed.

04 / PRODUCTION DECISION STUDY

Technology-neutral hosting layout

Logical interface separation does not require separate deployment. Select the hosting arrangement after workload, privacy, availability, support and recovery decisions.

Role	Boundary
Responsive interface	Uses authenticated service contracts and contains no data-store credentials.
Application services	Apply identity, institution and resource scope, validation, transactions and shared rules.
Relational and geospatial data	Use controlled operations, stable identities, versions and least privilege.
Document and object storage	Protect originals, approved derivatives, provenance and retention.
Integration adapters and jobs	Use approved source contracts, bounded retries, duplicate protection and reconciliation.
Recovery	Protect data, originals and keys independently. Measure restoration and continuity against the agreed service boundary.

Roles may share a deployment where the accepted operational requirements permit it. Stronger deployment separation remains a proposed option under C07.

05 / PRODUCTION DECISION STUDY

Application, database and complete-stack options

Compare capability approaches against the same approved requirements, representative data and acceptance cases. No product, supplier or implementation framework is selected.

Approach	Evidence needed
Extend an existing institutional platform	Demonstrate the complete retained workflows, source rights, authorization, reporting and exit.
Configure a supported modular application	Prove workflow fit, typed data, shared rules, governed configuration, tests and operator skills.
Build a governed extension using supported components	Explain the verified unmet need, contract boundaries, lifecycle cost and migration.
Add a specialist analysis adapter	Justify the approved scientific method, data volume, permissions and reproducible outputs. Do not replace the core without an accepted reason.

Record native fit, configuration, extension, integration or unmet need for every accepted Must requirement. Keep unknown evidence visible. Reuse institutional sources of record instead of duplicating their systems.

06 / PRODUCTION DECISION STUDY

Warehouse design for large data

The operational database records transactions and approvals. The warehouse stores governed historical facts for analysis. Large photos, PDFs, satellite rasters and source archives belong in versioned file/object storage with catalogue links, rather than being duplicated inside every reporting table.

Capture immutable source versions with institution, licence, classification, timestamps, place, unit, quality and original identifiers. A source record is not automatically approved institutional data.
Land imports in restricted staging/quarantine. Validate schema, duplicates, dates, units, geometry and safe file limits. Automated extraction proposes fields; a different authorized human verifies them.
Publish typed curated records after approval. Keep version and lineage links to originals. Corrections create traceable changes and update affected reporting partitions.
Extract through approved stored-procedure/export contracts. Consider CDC only after a controlled compatibility, permission and log-retention assessment; monitor lag and reconcile counts.
Build separate facts at explicit grains: station observation per timestamp/variable; reservoir reading per reservoir/time; farm-season crop result; project expenditure transaction; disaster impact by incident/place/report version. Never combine all meanings into one untyped value table.
Reuse conformed dimensions: institution, domain/entity/attribute, geography and boundary version, observation/report date, project, source/version, unit, classification and approval state. Use effective-dated dimension versions when names or boundaries change.
Load incrementally with watermarks, idempotent batch keys, late-arrival handling, rejected-row reports and reconciliation. Prove restart safety. Keep “missing” separate from zero.
Evaluate engine-appropriate columnar storage or indexes for suitable large analytical facts, date partitioning where data volume and pruning justify it, reviewed aggregates, statistics and query plans. Too many small partitions can hurt. Benchmark rather than promise a fixed speed-up.
Keep access decisions authoritative. Restricted warehouse rows, semantic models, cached results, exports and exact spatial data must remain scoped. Only explicitly approved public aggregates may enter a public cache. Current cross-request business-data caching rules are not silently relaxed.

[6] Columnstore design guidance · [7] Star schema guidance

Current implementation boundary: existing application framework runtime database access remains stored-procedure-only through software provider.Data.data-access adapter. That records the current code; it does not select the future stack. Any chosen alternative needs approved access contracts, equivalent authorisation/audit controls, migration design and an updated architecture decision before development.

07 / PRODUCTION DECISION STUDY

Data cubes and fast reporting

A cube is a prepared view of measures by dimensions, such as institution, district, crop and month. It can make repeated summaries easier and faster. It cannot fix incorrect source data, missing indexes, a slow network or unsafe joins. A modern tabular semantic model may meet the need without a traditional multidimensional cube.

Analytics option	Advantages	Disadvantages	Use when
Relational star-schema warehouse + summary tables	Familiar relational modelling; governed API queries can serve charts.	More care is needed to govern shared measures and complex ad-hoc analysis.	Compare engine-specific summary performance and maintenance effort against the other approaches.
SSAS Tabular / governed semantic model	Shared measures, relationships and reusable analysis; familiar relational modelling.	Extra memory, model refresh, permissions, deployment and licensing.	An option for a compatible software provider analytics environment; compare licences, refresh, security and operating effort.
SSAS Multidimensional cube	Rich mature dimensional analysis for specialist requirements.	More specialised skills and model maintenance; hosting choices differ from tabular models.	Compare when specific dimensional features or an existing estate are relevant.
reporting service / Fabric warehouse and semantic models	Integrated pipelines, warehouse/lakehouse and visual analysis.	Capacity/licensing, residency, refresh behaviour, provider dependence and export controls.	Cloud analytics allowed and a costed proof of value succeeds.
analytical data store analytical service	Column-oriented analytics for high-volume event/time-series workloads.	A second engine, ingestion path, security model and specialist operational burden.	Benchmark as a later analytical sidecar; it does not replace the operational SQL system.
Object lake + Parquet/Iceberg + query service/Spark	Open-format history and large mixed-source processing.	More engineering, catalogue, file compaction, governance and support work.	Large files or varied historical workloads justify a lakehouse; do not add it for fashion.

[8] Tabular and multidimensional models · [9] Fabric warehouse and lakehouse decision guide · [19] analytical data store analytical database · [20] query service Iceberg connector

Example reservoir measure: storage utilisation = usable current storage ÷ usable capacity × 100. Both values must refer to the same reservoir, compatible units, definition version and time context. For several reservoirs use SUM(storage) ÷ SUM(capacity) × 100, not an unweighted average of percentages. A zero or missing denominator gives “not available”, not zero.

Do not sum reservoir stock across dates. Compute rainfall for an agreed station/area and time interval; do not add station totals to represent an area without a reviewed method. Count distinct project IDs after many-to-many joins. Ratios, stock, distinct counts and monetary values need different aggregation rules. Store formula version, parameters, source IDs, unit conversion, review decision and refresh time with every published measure.

08 / PRODUCTION DECISION STUDY

Fresh data, charts and maps

Workload	Proposed path	Required controls
Official warnings and recent gauge observations	Validated recent-record store through the API; dedicated connector workers.	Show issue time, validity, observed time, fetched time and stale state. Never call an empty feed an all-clear.
Operational review and status	Authoritative operational API.	Read-your-work correctness and real identity; no warehouse delay hidden as current status.
Institution dashboards and trends	Incremental warehouse and optional semantic model.	Proposed refresh every 15–60 minutes or daily by use case; agree freshness targets and display successful watermark.
Long historical and spatial analysis	Scheduled warehouse/lake processing and governed map services.	Queue heavy work; timeouts/cancellation; coordinate and licence checks; reusable results scoped to the right audience.

Use the existing geography/layer catalogue, stable IDs and boundary versions. Generate tiled/simplified map products for large public views instead of sending millions of raw features. Keep full precision in protected storage. Serve large rasters as suitable tiled/overview products with approved providers. Recheck access for map queries and downloads; a hidden legend is not security.

Spatial options include relational data store spatial, relational and geospatial data stores and governed GIS services, with open-source or commercial service tools. Compare supported spatial operations, scale, licence, disclosure controls and local skills. Reuse the canonical geography catalogue; map/chart filters must share stable place, period, source and record identities.

09 / PRODUCTION DECISION STUDY

Backup and recovery choices

Choose backup and continuity arrangements against the existing proposed NFR conditions, then obtain C07/C08 approval. A publication mirror is not automatically a recovery service.

Arrangement	Required proof
Independent recoverable backups	Restore records, originals, configuration and keys into an isolated target. Reconcile counts, versions, permissions and evidence.
Prepared recovery environment	Measure change lag, activation, protected access and complete recovery. Prevent duplicate scheduled work.
Managed recovery service	Confirm the service boundary, site independence, retention, custody, support and tested recovery terms.
Exit or supplier replacement	Demonstrate portable data/metadata export, documented dependencies and receiving-team restoration.

Retain copies independently from the primary failure domain and protect them against unauthorized alteration. Agree retention, alerts, response and recovery authority. A successful browser demonstration cannot establish these operational controls.

10 / PRODUCTION DECISION STUDY

Security and data protection

Control area	Production requirement	Proof to collect
Network	Private database and storage networks; TLS; VPN/bastion for administration; WAF/rate limits; restricted service egress.	Network diagram, firewall review and denied-path tests; no exposed SQL or unrestricted administration.
People and accounts	Compare identity components suitable for each stack. Preserve the SRS access policy, require privileged MFA, and separate human/service identities. Current framework details do not preselect future identity technology.	Join/move/leave tests, independent privilege approval, session revocation, break-glass procedure and periodic access review.
Data and encryption	Encrypt traffic and stored data/backups; separate key custody; classify source and derived data; generalise sensitive coordinates.	Key rotation/recovery exercise, cross-institution/classification denial, retention and export tests.
Files and document processing	Quarantine, malware scan, safe parsers, file limits and immutable originals. Treat uploaded text as untrusted input to any automated extraction.	Malicious-document tests, human correction, extraction confidence/lineage, no automatic privilege or approval from document content.
Analytics	Apply scope before rows, counts, aggregates, model refresh, downloads and cached results. Test inference/small-cell disclosure.	Denied aggregate/export tests, identity-to-model mapping, cache isolation and withdrawal/reclassification invalidation.
Supply chain	Signed/versioned releases; dependency and secret checks; reviewed migrations; separate environments.	Software inventory, patch plan, authorised penetration test and resolution of critical/high findings.
Operations	Central monitoring and protected audit, on-call cover, incident response, backup administrator separation and recovery drills.	Alert delivery exercises, reviewed logs with no sensitive content, named owners and documented response times.

[21] OWASP security verification standard

For reporting service, “Publish to web” exposes content publicly and must not be used for private institutional data. Use an appropriately licensed secure embedding and identity model, or keep chart rendering within the authorised SHARED API path.

[23] reporting service public sharing warning

Sri Lanka hosting alone does not settle privacy compliance. Verify applicable law, institution rules, purpose, lawful handling, retention, subcontractors and cross-border transfers with the authorised privacy/legal reviewer. Check the exact location of backups, telemetry, support access and automated document-processing services as well as the main database.

[24] Sri Lanka Data Protection Authority

11 / PRODUCTION DECISION STUDY

Capacity planning and measurement

User count, file growth, sensor frequency and retention are not yet agreed. The following are workload envelopes for testing, not predictions, procurement sizes or proof that a server can meet them.

Scenario	Planning workload	Infrastructure evaluation
Controlled launch	100 concurrent users; 10 million analytical rows/year; 1 TB initial files.	Separate application, database and protected storage roles. Pilot a reporting instance rather than one shared VM.
Institution expansion	300 concurrent users; 100 million analytical rows/year; 10 TB files.	Independent reporting compute, incremental processing, object/file tiering, map tiling, warm recovery capacity and load testing.
High-volume monitoring	1,000 concurrent users; 1 billion analytical rows/year; 100 TB files/rasters.	Partitioned warehouse/lake evaluation, specialised ingestion and spatial services; benchmark distributed analytics only if needed.

Count actual rows/day and bytes/row, including indexes, history, audit, staging, rejected rows, temporary working space and headroom. Stored files, warehouse copies and backup retention need separate estimates. A source snapshot is not the complete annual dataset.

Illustrative node ranges for a pilot only: Web/API 4–8 vCPU and 8–16 GB RAM per instance; operational database 8–16 vCPU and 32–64 GB RAM; independent warehouse 8–16 vCPU and 32–128 GB RAM; workers 4–8 vCPU and 16–32 GB RAM. These are starting benchmark candidates, not capacity guarantees. Reserve physical-host overhead, storage IOPS, backup bandwidth and recovery resources; do not place all roles on one undersized host.

Simple sizing check

Illustrative defaults. Edit them; no values are saved or sent.

Rows per dayAverage bytes per rowYears retainedIndex/history allowance ×Database or file transfer size (GB)Usable link speed (Mbps)

Decimal GB/TB. Analytical size = rows/day × 365 × years × bytes/row × allowance. This excludes originals, replica copies, backups and temporary space. Ideal transfer hours = GB × 8,000 ÷ Mbps ÷ 3,600. Real transfers take longer.

For example, 2 TB over a fully available 100 Mbps link takes at least about 44.4 hours before overhead. A remote VPS is not a four-hour recovery plan if the full dataset must first be copied during an incident. Pre-seed and verify the standby, then measure change rate and catch-up time.

12 / PRODUCTION DECISION STUDY

Costs and procurement

No supplier quote has been obtained. Compare three-year total cost, not the monthly VPS price alone. Amounts below are entered by the reviewer in one chosen currency; they are not live prices or a bill of materials.

Three-year cost worksheet

Currency labelOne-time hardware, setup and migrationAnnual licences and supportMonthly primary-site operationMonthly VPS, backup and connectivityContingency %

Enter quotes to estimate cost.

Enter every cost line, including an explicit zero where justified. A blank is unknown and does not produce a comparable total. Base cost = one-time + 3 × annual + 36 × (monthly primary + monthly recovery). Total = base × (1 + contingency/100). Include each expense once; taxes, inflation and exchange-rate changes are separate unless included in your entries.

Cost line	What to include in the quote
Hardware and facility	Servers, storage, switches/firewalls, UPS/generator, rack/cooling, spares, replacement and warranty; colocation instead if applicable.
Software	Selected OS/database/virtualisation, reporting or semantic-model rights, security/backup tools, GIS and document-processing licences; production and standby rights.
Recurring service	Electricity, cooling, ISP/VPN links, VPS, off-site immutable backups, monitoring, security, traffic/egress and vendor support.
People	DBA, systems/network administrator, security/on-call cover, data engineering, application support and leave/incident backup.
Delivery and exit	Migration, cleansing, load/security/restore tests, training, deployment and rollback drills, external review, data export and provider exit.

Require two or more comparable written offers. Ask every supplier for actual country/site, independent failure domain, guaranteed/reserved CPU/RAM, sustained IOPS and latency, uplink limits/fair use, restore rights, database edition/licensing, backup retention/immutability, root access and patch responsibilities, DDoS response, escalation times, data ownership, audit evidence and exit/export terms. A published product page is not a signed service commitment.

13 / PRODUCTION DECISION STUDY

Compare from every decision angle

Run a structured decision workshop before awarding development. Apply the same requirements, representative data, hardware budget and test scripts to every complete-stack candidate. No scores or ranks have been invented.

Decision angle	What every candidate must demonstrate
SRS and user experience	Entry/upload/review, institutional workspaces, reports, library, multilingual accessibility and mobile flows.
Data integrity and GIS	Transactions, duplicates, historical versions, stable geography, coordinate/spatial operations and source lineage.
Performance and analytical growth	Same dataset and mixed workload; p95/p99, imports, query plans, storage growth and reporting freshness.
Security and privacy	Institution/classification denial, MFA, files, sensitive locations, exports, aggregation and audit; mandatory risks cannot be traded away.
Availability and recovery	Tested database/file/key recovery, standby lag, real RPO/RTO, power/network failure, failover and failback.
Delivery and team capability	Scope to rebuild/reuse, migration risks, development/test effort, verified local skills and team continuity.
Operations and maintainability	Patching, monitoring, incident cover, automation, supported versions, documentation and vendor/community support.
Whole-life cost, ownership and exit	Licences plus staff/hosting/DR; institution-owned source and data; portable exports, replacement supplier and exit costs.

Agree pass/fail gates first: required functions, lawful data handling, access isolation, critical security findings, required GIS behaviour, recoverability, data/source-code ownership and a supportable operating plan. A high weighted score cannot compensate for a failed mandatory gate.
Ask for evidence: a small common prototype, independently checked security cases, timed load/import tests, a real isolated restore and a comparable three-year quote. Include licence, support, migration and exit assumptions.
Agree weights before viewing results. A possible scoring method is 1–5 per criterion, with written evidence: total = SUM(weight × rating) ÷ (5 × SUM(weights)) × 100. This is a method option, not a product recommendation. Zero total weight or missing ratings means no comparable total.
Only compare complete, gate-passing candidates. Record failed and untested gates, uncertainties, different confidence levels, reviewer names and dates. Do not silently score an unknown capability as zero or treat a vendor claim as a passed test.
Review sensitivity: change reasonable weights, consider growth, loss of key staff, supplier exit and a primary-site outage. If the order changes easily, document that uncertainty and run another targeted test.
The commissioning institution approves the final choice and its trade-offs. Publish the agreed decision and update the SRS/architecture before the development team commits to delivery.

Download the blank decision comparison worksheet. Ratings, weights, mandatory-gate results, evidence and approval fields are intentionally blank.

14 / PRODUCTION DECISION STUDY

Phased implementation and release gates

Phase	Deliverable	Acceptance before moving on
1 · Confirm the workload	Institution inventory, file/sensor growth, critical workflows, data classification, hosting residency, owners, budget and recovery tier.	Signed assumptions and measures. Pilot dataset authorised. No production purchase from prototype counts alone.
2 · Build an isolated production-like platform	Logical interface, service, data, job, storage and monitoring boundaries, controlled deployment and protected backups.	Real identity and private files work through the API; approved least-privilege data-access contracts and denied-scope tests pass.
3 · Prove the warehouse	One rich institution pilot, typed facts, conformed dimensions, incremental loads and reviewed measures.	Reconcile source/approved/warehouse counts, corrections and units. Benchmark the shortlisted warehouse and semantic approaches under the same workload.
4 · Prove recovery and security	VPS seeded, independent immutable copy, key recovery, full failover/failback rehearsal and authorised security review.	Measured end-to-end RPO/RTO; no unresolved critical/high security findings; duplicate jobs prevented.
5 · Institution acceptance	UAT in English/Sinhala/Tamil for entry/upload/review/charts/maps/reports/library/access; training and operating guides.	Real users approve workflows and calculations. Providers approve data use; support team accepts runbooks.
6 · Controlled release	Approved migration window, reconciled cutover, rollback criteria, progressive traffic and hypercare.	Named go/no-go authority, tested rollback, alert delivery and incident cover. Preserve historical IDs and records.
7 · Grow from measurements	Add resources, partitions, semantic models or specialist analytical engines only when justified.	Cost/performance evidence and an approved architecture decision; no silent core-database replacement.

A delivery calendar follows workload approval, supplier lead times and a scoped pilot. This report does not promise a production completion date. The prototype demonstrates the intended experience; it does not close the engineering, legal, security, institutional or operational acceptance gates.

15 / PRODUCTION DECISION STUDY

What to hand to the development team

Turn the approved study into a clear development brief. Keep open decisions visible; do not let a prototype screen or supplier assumption become a hidden contractual requirement.

Handover item	What must be agreed
Scope and acceptance	Versioned business SRS, priorities, institution workflows, prototype links, exclusions and testable acceptance criteria.
Selected architecture	Approved framework, database, hosting/DR, analytics and identity decisions with alternatives considered, supported versions, licences and reasons.
Data and calculations	Canonical IDs and hierarchy, migration mappings, typed schemas, warehouse grains/dimensions, source rights, units and reviewed formula versions.
Interfaces and integration	API contracts, import/export formats, connector credentials/approval process, retries, ownership and real versus demonstration behaviour.
Security and operations	Access matrix, privacy/data location, file handling, audit, secrets/key custody, monitoring, patching, incident and backup/restore responsibilities.
Measured service targets	Accepted load, growth/freshness assumptions, p95/p99 goals, availability and end-to-end RPO/RTO with a common verification plan.
Delivery and commercial terms	Milestones linked to evidence, cost assumptions, change control, source-code/data ownership, institution-controlled repositories and build/deploy access.
Transfer and support	Documentation, automated tests, operating runbooks, team training, warranty/support, recovery drills, supplier replacement and usable exit exports.

Approval of a technology choice is separate from acceptance of delivered software. Require institution UAT, independent security/recovery evidence and a named production go/no-go decision before launch. No development contract or production approval is issued by this page.

16 / PRODUCTION DECISION STUDY

Responsibilities and open decisions

Owner role	Must decide or prove
Product owner / institution stewards	Critical workflows, source ownership, review authority, retention, freshness, accepted outage/data loss and validation of measures.
Solution architect and application lead	Keep module/API contracts, prove integration boundaries and record approved design changes.
Database and data-engineering leads	Measure data growth and queries; design warehouse grains, incremental loads, permission-safe measures and recovery chains.
Systems/network operations	Facilities, host/storage sizing, redundant links, patching, certificates, workers, monitoring and standby activation.
Security and privacy leads	Threat model, MFA, scoped access, audit, safe file/automated processing, classification and supplier/residency review.
GIS/scientific experts	Spatial definitions, boundary versions, scale/precision, map service rights and scientific calculation validity.
QA and release authority	Performance/security/restore/UAT evidence, unresolved-risk review and final go/no-go.
Finance and procurement	Comparable three-year quotes, licence entitlements, maintenance coverage, support contracts and exit rights.

Outstanding: actual user/load growth; exact primary premises; VPS country/facility and independence; critical-service recovery tier; restricted data allowed on DR/analytics services; staffing/on-call coverage; vendor and licence quotes; institutional acceptance and measured load/restore results.

17 / PRODUCTION DECISION STUDY

Sources and review basis

Research references include additional framework, database and recovery references for this neutral decision study. Official documentation supports feature descriptions. Candidate stacks, sizing envelopes, schedules and the comparison method are planning inputs, not supplier promises or selected products. Recheck versions, licences, region availability and prices before contracting.

Current basis: SRS Version 1.6, its calculation appendix, acceptance annex, source register and Institution review. Platform, permissions, workload, costs and operational acceptance remain pending.