This is a fictional but realistic Solution Architecture Document for an internal employee directory at Meridian Financial Services. It demonstrates the ADS standard at Recommended documentation depth, appropriate for a straightforward Tier 4 internal application heading to production.
Use this as a reference when completing your own SAD. The structure, field names, and enum values follow the standard exactly.
This SAD describes the architecture of the Employee Directory application, a simple internal web application that allows Meridian Financial Services staff to look up colleague contact details and organisational information.
Scope boundary: The Employee Directory application, its API, database, and integration with the corporate HR system and Entra ID.
Out of scope: The HR system itself (documented separately under APP-0112), corporate network infrastructure, and the Entra ID tenant configuration.
Related documents: HR System SAD (APP-0112), Meridian Cloud Platform Standards (STD-0023), Information Security Policy (POL-0008).
The Employee Directory is an internal web application that enables Meridian Financial Services employees to search for and view colleague contact information, including name, department, job title, telephone number, email address, office location, and photograph. It replaces a manually maintained Excel spreadsheet that has become unreliable, difficult to search, and frequently out of date.
The application uses a React single-page application frontend served from Azure App Service, backed by a Node.js REST API and an Azure SQL database. Employee records are synchronised nightly from the corporate HR system via an automated CSV import.
The current employee directory is a shared Excel spreadsheet stored on a SharePoint Online site within the HR team’s document library. Key limitations:
Manual updates: HR staff manually edit the spreadsheet when employees join, leave, or change roles. Updates are often delayed by days or weeks.
No access control: All employees with access to the HR SharePoint site can view and edit the spreadsheet. There is no separation between read and write access.
Poor searchability: Users must open the file and use Excel’s find function. There is no structured search, filtering, or browsing.
No audit trail: Changes to the spreadsheet are not logged beyond SharePoint’s basic version history.
No photographs: The spreadsheet contains text data only; employees cannot look up colleagues by face.
The new application will completely replace this spreadsheet, which will be archived and removed from active use after a 4-week parallel running period.
Aligns with cloud-first strategy; reduces operational overhead; eliminates need for server patching
Application is deployed as a PaaS web app with no VM management
Azure SQL over Cosmos DB
Relational data model suits structured employee records; team has strong SQL skills; Cosmos DB’s global distribution is unnecessary for a single-region internal app
The Employee Directory is a convenience tool. If the service is unavailable, employees can contact colleagues through Outlook (which has its own global address list for email and phone), Microsoft Teams, or by asking their manager. There is no revenue, regulatory, or safety impact from downtime.
graph LR
SPA[React SPA] -- HTTPS/JSON --> API[Node.js API]
API -- TDS/TLS --> DB[Azure SQL DB]
SPA -- OIDC --> EntraID[Entra ID SSO]
API -- Reads CSV --> Blob[Azure Blob Storage]
HR[PeopleSync HR System] -- Nightly SFTP --> Blob
Application architecture: React SPA connects to Node.js API via HTTPS, which connects to Azure SQL DB. SPA authenticates via Entra ID. HR system sends nightly CSV to Blob Storage.
Local development with shared Azure SQL dev database
1x Azure (UK South)
App Service B1 Basic
Production
Live service environment
1x Azure (UK South)
App Service B1 Basic
No staging, pre-production, or DR environments are provisioned. This is appropriate for a Tier 4 application with no DR requirement. Deployments are validated in the development environment before promoting to production.
Azure UK South — chosen primarily for data residency. Microsoft’s UK regions are tracking towards 100% renewable energy matching by 2025.
Non-production environments auto-shutdown out of hours
The dev environment uses B1 Basic SKU which is already low-cost; no auto-shutdown is configured because the environment is shared with developers across time zones. Estimated additional saving < £20/month, judged not worth the operational complexity.
Compute family chosen for performance-per-watt
App Service B1 Basic uses Azure’s standard managed-VM hardware. For a Tier 4 internal directory, sizing was selected for sufficiency rather than peak efficiency; an upgrade to Pv3 would over-provision.
Auto-scaling configured to release capacity when idle
Not applicable at B1 Basic — no auto-scaling. Scaled vertically if usage outgrows the SKU.
DR strategy proportionate
None — the system is non-critical (Tier 4), 8-hour outage tolerable. A DR replica would double compute footprint without business benefit.
Access restricted to authenticated Meridian employees; encrypted at rest and in transit
No Public, Restricted, or Highly Restricted data is stored by this application. The data set does not include sensitive categories such as salary, performance reviews, disciplinary records, or health information — these remain exclusively in PeopleSync.
Employee records are created in PeopleSync by HR. Data is ingested nightly via CSV import. Photographs are uploaded directly by HR administrators through the admin UI.
CSV validated on import (schema check, mandatory fields). Duplicate detection by employee ID.
Processing
API reads employee data for search queries. No transformation or aggregation occurs.
Access controlled by Entra ID authentication and RBAC.
Storage
Data stored in Azure SQL with Transparent Data Encryption (TDE). Blob Storage uses Storage Service Encryption (SSE).
Encryption at rest enabled by default on both services.
Sharing / Transfer
Data is displayed to authenticated employees via the web UI only. No data exports, APIs for other systems, or bulk downloads are provided.
TLS 1.2 in transit. No data leaves the application boundary.
Archival
Soft-deleted employee records (leavers) are retained in the database for the retention period.
Retained in same database with inactive flag.
Deletion / Purging
Records older than 7 years from soft-deletion date are permanently purged by a scheduled job. CSV staging files are auto-deleted after 30 days.
The DPIA concluded that the Employee Directory processes a limited set of non-sensitive personal data for a legitimate business purpose. Standard controls (access control, encryption, retention policy) are sufficient. No high risks were identified.
No — standard database constraints (primary keys, not-null, foreign keys) and TLS-protected transport are sufficient. No additional integrity controls (e.g., checksums, digital signatures) are required for this data set.
No — the application does not allow data downloads, offline storage, or local caching of employee records beyond standard browser session caching. No data is persisted to end-user devices.
Yes — all data is stored in the Azure UK South region (London). This satisfies Meridian’s data residency policy requiring employee personal data to remain within the UK.
Employee records retained for the duration of employment + 6 years (HMRC, NI, and Meridian HR policy alignment); transient session data ≤ 24 hours. No “indefinite” retention.
Older data tiered to cold/archive storage
Not applicable at this scale (~£40/month of database storage); tiering complexity outweighs the saving.
Unused or duplicate replicas
Single Azure SQL S1 instance, no read replicas. No legacy unused storage.
Compression applied
gzip on HTTP responses; Azure SQL uses page-level compression on the primary tables (default for S1+).
Low — employee names, emails, phone numbers, and departments would be exposed. This data is already broadly known internally. Limited external value.
Integrity
Low — incorrect directory data would cause inconvenience but no financial or safety impact. HR can correct data within 24 hours via the next CSV import.
Availability
Low — employees can use Outlook Global Address List or Teams as alternative lookup methods.
Non-Repudiation
Low — no transactions or approvals occur within this application.
1. User navigates to the Employee Directory URL. 2. Browser completes OIDC authentication silently (or prompts for sign-in). 3. User types a name, department, or job title into the search box. 4. Frontend sends GET /api/employees?q={query} with bearer token. 5. API validates the token, queries Azure SQL using parameterised search. 6. API returns matching employee records as JSON. 7. Frontend displays results with name, photo, department, phone, and email. 8. User clicks an employee card to view full details.
Post-conditions
User has the contact information they need
Views Involved
Logical, Integration & Data Flow, Physical, Security
UC-02: HR Administrator Updates an Employee Record
Attribute
Detail
Actor(s)
HR Administrator (Admin role)
Trigger
An employee’s photograph needs updating, or a correction is needed before the next nightly sync
Pre-conditions
User is authenticated and is a member of the SG-EmployeeDir-Admins Entra ID group
Main Flow
1. Admin navigates to the Employee Directory and authenticates. 2. Admin searches for the employee. 3. Admin clicks “Edit” on the employee record (button visible only to Admin role). 4. Admin updates the field(s) or uploads a new photograph. 5. Frontend sends PUT /api/employees/{id} with updated data and bearer token. 6. API verifies the user’s Admin role claim in the JWT. 7. API validates the input and updates Azure SQL. 8. API returns the updated record. 9. Frontend confirms the update to the admin.
Post-conditions
Employee record is updated immediately; change is logged in Application Insights
Views Involved
Logical, Integration & Data Flow, Physical, Data, Security
ADR-001: Use Azure SQL Database over Azure Cosmos DB
Field
Content
Status
Accepted
Date
2025-09-22
Context
The application needs a database for structured employee records (approximately 500 rows, well-defined relational schema). Two Azure-native database options were considered.
Decision
Use Azure SQL Database (Basic tier, 5 DTU).
Alternatives Considered
Azure Cosmos DB: Globally distributed NoSQL database. Offers high availability and horizontal scaling, but this application has a single-region, low-volume workload with a relational data model. Cosmos DB’s minimum cost (~GBP 20/month for 400 RU/s) exceeds Azure SQL Basic (~GBP 4/month) for this use case, and the team has no Cosmos DB experience.
Consequences
Positive: Lower cost, simpler operations, team familiarity with T-SQL. Negative: Limited to single-region deployment (acceptable for Tier 4).
Quality Attribute Tradeoffs
Cost optimisation (positive) and team skills (positive) weighted over global distribution (not required) and horizontal scalability (not required).
ADR-002: Nightly CSV Batch Import over Real-Time Integration
Field
Content
Status
Accepted
Date
2025-09-22
Context
Employee data originates in PeopleSync (the HR system). The directory needs to stay in sync with HR data. PeopleSync supports only CSV file export; it does not offer a real-time API or event-based integration.
Decision
Implement a nightly batch import of the full employee dataset via CSV file transfer to Azure Blob Storage, processed by an Azure Functions timer trigger.
Alternatives Considered
Real-time API integration: Not available from PeopleSync. Would require a custom middleware layer or changes to the HR system, which is out of scope and budget. Manual data entry: Rejected as it replicates the existing problem of stale data and manual effort.
Consequences
Positive: Simple, reliable, uses existing PeopleSync capability. Negative: Data can be up to 24 hours stale. HR stakeholder has accepted this latency as sufficient for a directory.
Quality Attribute Tradeoffs
Simplicity and cost (positive) over data freshness (acceptable trade-off for Tier 4).
Distributed tracing is not implemented. The application is a simple monolith with no service-to-service calls that would benefit from trace correlation.
App Service B1 plan is pre-sized for the expected load (c.450 users, low concurrency). If usage significantly increases, the plan can be manually upgraded to a higher tier. Auto-scaling is not configured as the workload does not justify it.
No — the application is not designed with explicit fault tolerance patterns (circuit breakers, retry logic, graceful degradation). If the API or database is unavailable, the application will return an error page. This is acceptable for a Tier 4 system where alternative lookup methods exist (Outlook GAL, Teams).
Performance testing is not formally conducted. The application serves fewer than 450 users with a low-frequency lookup pattern. Basic load validation will be performed during development using manual browser testing and Application Insights monitoring during the parallel run period.
PaaS services at their lowest tiers were deliberately chosen to minimise cost for a Tier 4 system. Azure SQL Basic (GBP 4/month), App Service B1 (GBP 10/month), Functions Consumption (pay-per-execution, effectively free for one daily run), Blob Storage (negligible for < 10 MB).
Yes — cost was estimated using the Azure Pricing Calculator. The estimated monthly run cost is approximately GBP 200 (including all services, monitoring, and bandwidth). This was reviewed and approved by the project sponsor as proportionate for the business value delivered.
No — the design fully meets requirements. Cost has not constrained the design in any way; the requirements are inherently modest and low-cost Azure services satisfy them.
Has the hosting location been chosen to reduce environmental impact?
No — UK South was selected for data residency compliance. However, Azure UK South is powered in part by renewable energy sources as part of Microsoft’s sustainability commitments.
No — the application is used during business hours only, but the cost of running PaaS services 24/7 is lower than the operational complexity of implementing a start/stop schedule.
Can the solution be shut down or scaled down during off-peak hours?
Technically possible but not cost-justified. The B1 App Service plan cost is the same whether running or stopped.
Are non-production environments configured to downscale or shut down when not in use?
Yes — the development App Service is set to auto-stop outside business hours (08:00-18:00 weekdays) using an Azure Automation runbook.
One-off — email announcement to all staff with link to new application
External system cutover
N/A
Maximum acceptable downtime
Hours (parallel run means the spreadsheet is still available as fallback)
Rollback plan
Revert to the SharePoint spreadsheet. HR retain it as a backup for 4 weeks post-go-live.
Acceptance criteria
1. All active employees visible in directory. 2. Search returns correct results. 3. HR can update records. 4. Nightly import completes successfully for 5 consecutive days.
Clear business context, scope well-defined, strategic alignment demonstrated, criticality justified
3.1 Logical View
3
ARB Panel
2025-11-20
Components documented with technology choices; vendor lock-in assessed. Design patterns section omitted (monolith — no complex patterns to document).
3.2 Integration & Data Flow
4
ARB Panel
2025-11-20
All interfaces documented with protocols and authentication. API contracts not formally versioned (acceptable for single internal consumer).
3.3 Physical View
3
ARB Panel
2025-11-20
Deployment architecture complete, hosting documented. Bandwidth and latency not quantified (not required at this scale).
3.4 Data View
4
ARB Panel
2025-11-20
All data stores classified, retention defined, encryption specified, DPIA complete, sovereignty addressed.
3.5 Security View
4
ARB Panel
2025-11-20
Authentication and authorisation fully documented. Managed Identity eliminates secrets management risk. Formal threat model not produced (proportionate for Tier 4 and low business impact).
3.6 Scenarios
3
ARB Panel
2025-11-20
Two key use cases documented; two ADRs with rationale and alternatives. Additional use cases (e.g., failure scenario) would improve coverage.
4.1 Operational Excellence
3
ARB Panel
2025-11-20
Centralised logging and alerting in place. No distributed tracing (not needed). No formal runbooks (proportionate).
4.2 Reliability
3
ARB Panel
2025-11-20
Backup configured, recovery scenarios documented. No DR or fault tolerance — appropriate for Tier 4.
4.3 Performance
3
ARB Panel
2025-11-20
Targets defined, growth projected. No formal performance testing — acceptable given low concurrency and simple queries.
4.4 Cost Optimisation
4
ARB Panel
2025-11-20
Cost analysis performed, lowest-cost Azure tiers selected, proportionate to business value.
4.5 Sustainability
3
ARB Panel
2025-11-20
Non-production auto-shutdown configured. Hosting region chosen for compliance, not carbon. Right-sized PaaS resources.
5. Lifecycle
3
ARB Panel
2025-11-20
CI/CD documented, migration plan in place, skills assessed. DAST and penetration testing omitted (proportionate).
6. Decision Making
3
ARB Panel
2025-11-20
Constraints, assumptions, risks, and dependencies documented with ownership. No open issues or guardrail exceptions.
Overall
3
ARB Panel
2025-11-20
Solid, proportionate documentation for a Tier 4 internal application at Recommended depth. No critical gaps. Lowest section scores are 3 (meets the minimum for production approval).
