Deliverable 3 · Cloud architecture¶
In a city-builder game, the moment comes when you stop building every plant yourself. You sign contracts with the utilities, decide which neighbourhoods get their own substation, check the monthly bill and read the small print: where is the power station, and can you switch company if the service gets worse? That is a cloud architecture.
Deliverable 3 is that plan for your company. Your group decides which of its systems go to the cloud and at which service model, what the cloud will do for it and how much it will cost with a real provider's calculator, what the plant must keep deciding locally at the edge, fog and mist, and where the data will live. And this time the result is not only a PDF: your group publishes its dossier as a real website on GitHub Pages. It is the third chapter of your digital transformation dossier.
What you will learn
- Choose and justify a service model and a real provider for the systems of a real company
- Produce a dated, reproducible cost estimate with a provider's pricing calculator, and read its limits
- Split a real plant's work between mist, edge, fog and cloud, with reasons
- Choose a deployment model and decide where the data live, with the law that applies
- Publish the group's dossier as a static website, and defend your own section alone
What you hand in¶
| Format | The group's website on GitHub Pages and one PDF of the same content, about 6–10 pages without the cover. The PDF includes the link to the website |
| Where | Google Classroom, assignment "D3 · Cloud architecture". The Coordinator hands it in |
| Deadline | Monday 8 February 2027, 23:59 |
| Defence | Individual, in session 14, Monday 8 February 2027 (the same day) |
| Weight | 70% of the RA3 mark. The other 30% are the class activities of sessions 10 to 13 |
Every fact about your company needs a source
Everything you state as a fact about your company (its systems, its plant, the providers it already uses) must be found and cited: its website, annual report, the press, job offers, public tenders, Ibestat, the BOIB. Each citation has a title, the author or website, the link and the date you consulted it. What you cannot find, you may still propose with reasons, but you label it hypothesis. The same applies to providers: every claim about a service (what it offers, where it stores data) cites the provider's own page. Prices always carry the date of the estimate.
No generative AI
Generative AI is not allowed in this deliverable. A section written with AI or copied scores 0, and the defence will show it: you cannot explain a text you did not write.
The website is public
With a free GitHub account the repository must be public, so anybody can read your site. Publish no personal data: no phone numbers, no addresses, and first names only if you prefer (your full names go in the PDF on Classroom). Nothing confidential about the company: only what you found in public sources.
The sections¶
Each member owns and signs one section (the individual part). With 3 members, Section D becomes part of the group part and everybody writes it together.
| Section | Criterion | What to write | Owner |
|---|---|---|---|
| A · Service models for three systems | RA3 a) | Three systems of the company (for example the website, the bookings or orders, the ERP, email, backups, plant supervision). For each: what it does, the service model you propose (IaaS, PaaS or SaaS) and why, saying what the company would manage and what the provider would. A real provider and product for each, with a link to its official page and the sentence that proves the model. At least two different models among the three. | Individual |
| B · Cloud functions and real cost estimate | RA3 b), e) | The functions of the cloud in this company: at least one example each of processing data, exchanging information and running applications. Then a real estimate for one system with a provider's pricing calculator (AWS, Azure, Google Cloud) or price list (Hetzner): the configuration (region, size, hours, GB, transfer) as a labelled hypothesis, the monthly total, the date, and what it does not include (VAT, people's work...). Evidence: the exported PDF or a screenshot with configuration and total, and the share link if there is one. A second estimate in another region or with another provider, and a short conclusion: which one and why, and what advantage the pay-per-use model gives this company. | Individual |
| C · Edge, fog and mist in the plant | RA3 c), d) | The company's plant (the OT side of D1). A real cited source on its equipment or control systems, or on a plant of the same kind. A latency measurement to two cloud regions (GCPing or similar) with its date. A table of at least six tasks done with the plant's data, each placed in mist, edge, fog or cloud with its reason (latency, working offline, data volume, privacy, computing power). What happens if the internet connection drops. One piece of data that would never go to the cloud, and why. A diagram of the four layers. | Individual |
| D · Deployment model and data sovereignty | RA3 e) | The deployment model (public, private, hybrid, multicloud) for the whole architecture, justified with the company's size, data, existing systems and budget. Where the data will live: provider, country of its head office, region, and what its privacy policy says about transfers outside the EEA (cited, with date). Whether the CLOUD Act could reach them, and how the Data Act protects the company if it wants to switch. Three advantages of the cloud for this company's connected systems and two risks with how you would reduce them. | Individual (4th member) |
| Introduction | RA3 a)–e) | The company in five lines (from D1 and D2) and what this architecture changes for it: which systems move, which stay. | Group |
| Architecture diagram | RA3 a)–e) | One diagram that joins the four sections: the plant's devices, the mist, edge and fog layers of C, the cloud services of A with their provider and region, and the arrows of the data flow. Exported as an image (PNG), so that it shows on the website. | Group |
| The published website | RA3 a), b) | The whole dossier published on GitHub Pages (or Google Sites if nobody in the group can use GitHub): one page or several, with the four sections, the diagram and the sources, the same version as the PDF. In the PDF, one paragraph on how you published it and which service model GitHub Pages is. | Group |
| Integration and conclusions | RA3 a)–e) | The four sections must agree: the provider of A is the one of B's estimate and D's region; the plant of C is the one in the diagram. Half a page of conclusions. | Group |
| Sources | All | One list of every source cited, in the same format, with consultation dates. | Group |
| Group log | All | Who owned which section, who had which role, what you decided and when (template on the project page). | Group |
Roles in this deliverable¶
Everybody changes role and section from Deliverable 2. Write them in the group log.
| Role | In Deliverable 3 |
|---|---|
| Coordinator | Splits the sections, sets an internal deadline (we suggest Thursday 4 February 2027), checks the group log and hands in the PDF and the link |
| Source checker | Opens every link, checks every fact has a source and every guess is labelled hypothesis, and that every price has its date and its evidence |
| Technician | Creates the repository, invites the others, publishes the website, exports the diagram as an image and checks the site opens from another computer |
| Editor | Format, spelling, one voice; the same name for the same system and provider everywhere; the PDF matches the website. With 3 members, the Coordinator does it |
How it is assessed¶
| Part | Weight | What is assessed |
|---|---|---|
| Your section | 40% | Content correct for its criterion, real and cited sources, dated evidence, hypotheses labelled, reasons given, clear writing |
| Your defence | 20% | You explain your section in your own words, answer why, and know how it connects to another member's section |
| Group part | 40% | Introduction, architecture diagram, the published website, coherence between sections, conclusions, sources list, format and spelling, group log |
Rubric¶
| Part | Excellent | Adequate | Insufficient |
|---|---|---|---|
| Your section | Everything the table asks for, about this company; every choice justified; real providers and sources cited; estimates dated and reproducible; terms used precisely | Most of what is asked; some generic reasons, a missing date or a source without the exact sentence; the main ideas are correct | Missing parts; generic text that could be about any company; models or layers confused; prices without date or evidence |
| Your defence | Answers fluently and with reasons; can say where each fact and figure comes from; explains how a teammate's section links to yours | Answers the main questions with some help; knows the sources of the key facts | Cannot explain parts of the section, or does not know where its content comes from |
| Group part | One coherent architecture: same providers, region and plant in every section and in the diagram; the website works and matches the PDF; clean format, one voice, complete log | Small contradictions between sections; the website works but is incomplete or differs from the PDF; minor format problems | Four separate texts glued together; no diagram or no website; no log; many spelling or format errors |
Programme rules: RA3 needs at least a 5. Late work is marked out of 5; more than 48 hours late is a 0. Plagiarism or unauthorised AI is a 0. If you fail RA3, the recovery is an individual task: you redo one section of this deliverable alone and defend it, for a maximum of 5.
The defence¶
On Monday 8 February 2027 (session 14) the groups finish their deliverable while the teacher calls each student for 2–3 minutes. No paper and no computer: a conversation about your section as it is that day.
- Two questions about your own section. For example: "Why SaaS and not PaaS for this system?", "Which is the most expensive line of your estimate, and how would you reduce it?", "What happens in your plant if the internet goes down?", "Where would the data be stored, and which law would apply?"
- One question about another member's section or the group part. For example: "Follow one piece of data through your diagram, from the sensor to the cloud", or "Which service model is GitHub Pages?"
If you miss the session with a justified absence, your defence is moved to the start of session 15; tell the teacher as soon as you can.
Before you hand in¶
| Check | Who |
|---|---|
| Every section has its owner's name | Coordinator |
| Every fact about the company has a working source; every guess says hypothesis | Source checker |
| Every provider claim cites the provider's own page | Source checker |
| Every estimate has its date, its configuration and its evidence (PDF, screenshot or link) | Source checker |
| Section A uses at least two different service models | Editor |
| The provider of A, the estimate of B and the region of D agree | Editor |
| The diagram shows the four layers and the cloud services, and is an image on the website | Technician |
| The website opens from a computer outside the group, and matches the PDF | Technician |
| The group log is filled in and signed | Coordinator |
| One PDF with the website link, on Classroom before Monday 8 February 2027 at 23:59 | Coordinator |
Start from what you did in class: the activities of Cloud and service models, Deployment and functions, Edge, fog and mist and Advantages and sovereignty are the first drafts of sections A to D.