Turvaline tarkvaraarhitektuur 2026/27 sügis

Project

Design the architecture of a security-critical distributed software system and produce a coherent, reviewable set of architecture artifacts: diagrams, decisions, interfaces, risk analysis, threat modeling, and deployment/operations reasoning.

The project is documentation and design work. No production implementation is required.

Teams

• Teams should have 2-3 students.
• Each team owns its architecture decisions and rationale.
• Teams should rotate responsibility for diagrams, ADRs, risk work, and presentations.

Official GitHub workflow

• Each team works in its own GitHub repository forked from the course project starter repository: https://github.com/edurbrito-cyber/secure-software-architecture-ut-2026.
• Teams must invite the instructors (edurbrito-cyber, margusf, ao-cyb, martoruaascyber, ahtotruu) as collaborators so checkpoints and final submissions can be reviewed in the repository.
• The team repository is the official place where the team submits project work and shows progress during the course.
• Checkpoint and final submissions are reviewed from the state of the team repository at the deadline.
• Teams should keep a top-level README with team name, members, current status, and links to important artifacts.

Use the starter repository as the source of the initial folders, templates, and example files.

Default scenario: Citizen Services Portal

You are designing the architecture for a Citizen Services Portal that provides a single digital entry point for residents to access government services.

The portal integrates multiple agencies and registries, supports strong digital identity, and must be highly available, auditable, privacy-preserving, and evolvable. It handles identity, sensitive personal data, documents, audit trails, external integrations, and delegated access to public services.

Core capabilities include:

• digital identity integration, for example national eID or OIDC-based login;
• localized user interface, profile, preferences, and service catalogue;
• case management: submit requests, track status, messaging;
• notifications: email, SMS, push, in-app inbox;
• document exchange: upload, download, antivirus scanning, retention;
• digital signing workflow;
• audit logging and transparency features;
• regulated public APIs for third-party service providers;
• integration with 2-3 external organizations, agencies, or registries.

Important stakeholders and external systems include residents/citizens, service provider organizations, administrators/helpdesk, auditors, external identity providers, external registries, back-end e-services, and operations/security teams.

Teams should decide and justify:

• where the system boundary is;
• which containers/services exist and what each owns;
• how identity, authorization, roles, and delegation work;
• which workflows are synchronous and which are asynchronous;
• how audit logging and user transparency are implemented;
• how external agencies and registries are integrated;
• how the system behaves when external systems fail.

Final project package

The final project package should include:

• architecture description;
• C4 context and container views;
• selected component views for important parts of the system;
• key architectural mechanisms, especially identity, authorization, workflow, and data handling;
• API specifications for 2-3 key interfaces, OpenAPI recommended;
• ADR log with at least 5-7 important decisions;
• risk register with prioritized technical risks and mitigation/test ideas;
• security goals, trust boundaries, and threat model;
• deployment model with scaling and availability reasoning;
• observability and recovery plan;
• short project plan explaining phases/iterations and the risks addressed by each.

Suggested repository layout

• /docs/ - architecture narrative;
• /diagrams/ - exported diagrams and editable sources;
• /adrs/ - architecture decision records;
• /risk/ - risk register and treatment notes;
• /api/ - OpenAPI specifications and event schemas;
• /ops/ - deployment, observability, and recovery notes.

Starter files and templates

The project starter repository contains the initial folder structure, starter files, and templates. Teams should update these files in their own GitHub fork.

Required early templates:

• scenario brief: /docs/scenario.adoc;
• team contract: /docs/team_contract.adoc;
• architectural drivers: /docs/drivers.adoc;
• risk register: /risk/risk_register.adoc;
• architecture document: /docs/architecture.adoc;
• ADR template: /adrs/ADR-0001-template.adoc.

Later templates:

• OpenAPI stub: /api/openapi_stub.yaml;
• deployment and operations notes: /ops/README.adoc.

Project pages

• Official GitHub workflow
• Citizen Services Portal scenario
• Starter files and templates
• Week 1: project setup and discovery
• Week 2: risk register and iteration plan
• Week 3: quality attributes and security goals
• Week 4: documentation baseline, C4, and ADRs
• Checkpoint 1 review package?

Work up to Checkpoint 1

Checkpoint 1 happens after the first documentation/design cycle. By then, each team should have:

• stable team and repository setup;
• explicit architectural drivers;
• initial risk register;
• prioritized quality attributes and security goals;
• C4 context and container diagrams;
• the first ADRs.

Follow the weekly project pages above. Each week has concrete files to create, minimum expected content, and a quality bar.

Later checkpoints

Checkpoint 2, around Week 8:

• identity and AuthN/AuthZ architecture;
• distributed mechanisms and data ownership;
• threat model v1 with trust boundaries and key threats.

Checkpoint 3, around Week 12:

• API specifications for key interfaces;
• deployment model and trust boundaries;
• observability plan draft with signals and SLO candidates.

Final, Week 16:

• final architecture package;
• short presentation;
• oral exam preparation.