Data application architecture guide

How do you turn business data into a customer-facing application?

Start with a customer decision or workflow, then build a governed application layer around the business systems and data required to support it. Do not expose an internal database and call it a customer experience.

Plan the application Jump to start with the job

Published 21 August 2026 · 13 minute read

The direct approach

Identify what a customer needs to understand or complete, then map the minimum trusted data and business actions required. Place a customer-facing application and API layer between the user and the source systems. That layer manages identity, customer scope, navigation, validation, workflow, resilience and support.

Keep each ERP, CRM, accounting platform, warehouse or specialist system responsible for the records and rules it owns. Create a customer-facing model rather than exposing internal tables, codes and process states directly.

Start with the customer job, not the dataset

Weak starting point	Stronger customer question	Possible application outcome
We have order data	How can customers understand and resolve order exceptions?	Order status, exception evidence and a structured query workflow
We have finance data	How can customers reconcile invoices and supporting records?	Invoice detail, statements, downloads and dispute submission
We have service data	How can customers see progress and provide missing information?	Case timeline, required actions, uploads and status
We have performance data	Which decisions should customers make from these measures?	Reporting, definitions, thresholds and follow-up actions
We have asset data	How can customers manage assets, incidents or maintenance?	Asset records, history, requests and notifications

Use data to support the outcome. Do not publish fields merely because they are available.

Assess whether the data is ready for customer use

Ownership: Which system and team are responsible for each field, status and calculation?
Customer mapping: Can records be associated with the correct customer, branch or account reliably?
Meaning: Are definitions, units, periods, codes and state transitions clear outside the internal team?
Quality: Which values are missing, late, duplicated, disputed or corrected manually?
Freshness: How current must the information be for the customer decision?
History: Does the source preserve the periods and changes the customer needs?
Sensitivity: Which fields require restriction, masking, approval or exclusion?
Interface: Can the source support safe APIs, events, extracts or controlled database access?
Volume: What record counts, filters, exports and peak usage must the application handle?
Correction: Who resolves inaccurate information and how is the customer kept informed?

Expose known limitations honestly. A portal can make data easier to access, but it cannot silently repair unclear ownership or unreliable business processes.

Choose an architecture pattern by the customer need

Pattern	Best for	Trade-off
Live source API	Current operational information and supported transactions	Customer experience depends on source performance and availability
Customer-facing read model	Fast search and coherent views across several systems	Requires synchronisation, freshness and reconciliation ownership
Data warehouse or reporting model	History, governed measures, trends and analytical queries	Often delayed and not designed for operational write-back
Queued workflow	Long-running, approval-based or failure-prone customer actions	Needs durable status, idempotency and exception operations
Hybrid	Applications combining current operations, history, reports and actions	Needs clear ownership and a consistent customer-facing model

The right application may use several patterns. Select per use case rather than forcing every customer screen through one data source.

Create a customer-facing application model

Internal systems often use technical codes, duplicated identifiers and states that only staff understand. The application layer should translate them into stable customer concepts without becoming an ungoverned new source of truth.

Identity

Customer and account

Map organisations, branches, contracts and users across source identifiers.

Resource

Customer object

Represent an order, invoice, case, asset or report with only useful customer fields.

State

Understandable progress

Translate internal events into clear status, history, next actions and known delays.

Action

Controlled workflow

Define what the customer may submit, approve, correct or query and which system responds.

Keep a mapping from customer-facing identifiers and states to their source records. Document which data is copied, derived or owned locally.

Information becomes a product when customers can act

Trusted customer context→Relevant information→Clear customer action→Business system and owner respond

Examples include querying a transaction, uploading evidence, acknowledging a delivery, correcting contact information, approving a quote or requesting a service change. For each action:

identify who may perform it and under which conditions;
validate inputs against business rules on the server;
decide whether the source response is immediate or asynchronous;
prevent duplicate actions;
show received, processing, completed and failed states accurately;
route exceptions to an accountable internal team;
preserve customer and source identifiers for investigation; and
measure completion and remaining manual handling.

Build a controlled boundary around internal data

Authenticate the user and resolve an active organisation membership.
Scope every query, object, file, export and action on the server.
Return the minimum fields needed for the customer task.
Hide internal schema, credentials, network details and error traces.
Protect source systems with timeouts, rate limits and controlled integration credentials.
Treat uploaded files and external input as untrusted.
Audit sensitive exports, approvals, access changes and support elevation.
Review customer access throughout the relationship lifecycle.
Threat-model cross-customer access and privileged operations.
Monitor application, integration and customer workflow health.

Read how to give each customer access only to their own data, how to secure the complete external data path, and how to design the customer-facing API boundary.

Deliver one useful application slice

Measure the current job. Capture customer effort, staff handling, delay, risk and repeated questions.
Select the first outcome. Choose a narrow customer decision or workflow worth improving.
Assess data readiness. Confirm ownership, mapping, quality, freshness, sensitivity and interfaces.
Prototype the risky boundary. Test customer identity, one difficult query and one source-system interaction.
Build the complete slice. Include customer experience, administration, failure, monitoring and support.
Pilot with representative users. Use real roles, data volumes, edge cases and at least one exception.
Measure before expanding. Improve completion, data trust and operational handling before adding breadth.

Use the client portal implementation checklist to cover discovery through operations.

Choose the smallest interface that solves the need

Customer need	Consider first
Periodic measures and trends	Scheduled report, embedded analytics or customer reporting portal
Read-only operational visibility	Dashboard or focused external customer data portal
Information plus requests, files or approvals	Customer self-service or broader client portal
Machine-to-machine data exchange	Partner or customer API with an administration surface
Highly standard workflow	Configured portal software before custom development
Distinct workflow across several systems	Custom customer-facing application and integration layer

Explore custom client portal development, compare a dashboard, portal and custom application, and review when to offer an API or customer portal before selecting the interface.

Questions

Frequently asked questions

What is a customer-facing application on business data?

It is a secure application that turns selected data from ERP, CRM, operational, finance or reporting systems into information and actions customers can use. The application provides customer identity, permissions, workflow and experience while source systems retain clear ownership.

Do you need a data warehouse first?

Not always. A data warehouse is useful when the application needs consolidated history, governed measures or analytical workloads. Current operational actions may be better served through source APIs or a purpose-built application read model.

Should customers access the internal database directly?

Generally no. Use a controlled application and API layer that authenticates users, enforces customer scope, validates actions, shapes responses and protects source-system availability and internal schema.

Can the application write back to business systems?

Yes, when a safe supported path exists. Validate and authorise the action, decide whether it is synchronous or queued, preserve audit context, prevent duplicates and show the customer an honest outcome state.

What is the smallest useful first version?

Choose one customer group, one high-value information need and one complete workflow. Include secure access, the minimum trusted data, internal administration, exception handling, monitoring and a way to measure the customer outcome.

Shape the application layer

Bring the customer task, data sources and current manual process.

LCR can help identify the smallest useful customer-facing application and the architecture needed to connect it safely to existing systems.

Plan the application Email hello@lcrtech.co.za