├── diagrams ├── views.odg ├── roles.puml ├── general-application-design.puml ├── detailled-application-design-dynamic.puml ├── detailled-application-design-inventory.puml ├── infrastructure.puml ├── roles.svg ├── general-application-design.svg ├── detailed-application-architecture-inventory.svg └── infrastructure.svg ├── blank-template ├── resources │ └── views.png ├── glossary.adoc ├── README.adoc ├── export ├── view-sizing.adoc ├── view-application.adoc ├── view-development.adoc ├── view-infrastructure.adoc └── view-security.adoc ├── glossary.adoc ├── base-template-manifest.yaml ├── README.adoc ├── LICENSE.md ├── view-sizing.adoc └── view-application.adoc /diagrams/views.odg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bflorat/architecture-document-template/HEAD/diagrams/views.odg -------------------------------------------------------------------------------- /blank-template/resources/views.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bflorat/architecture-document-template/HEAD/blank-template/resources/views.png -------------------------------------------------------------------------------- /diagrams/roles.puml: -------------------------------------------------------------------------------- 1 | @startuml roles 2 | header Classic authorization model 3 | skinparam defaultFontName Liberation Sans 4 | scale 500 * 400 5 | Role "0 .. *" o-- "0 .. *" Function: "contains" 6 | Group "0 .. *" o-- "0 .. *" User: "contains" 7 | User "0 .. *" -> "0 .. *" Role: "owns" 8 | User "0 .. *" -> "0 .. *" Function: "has privilege on" 9 | Group "1" -> "0 .. *" Role: "owns" 10 | @enduml -------------------------------------------------------------------------------- /diagrams/general-application-design.puml: -------------------------------------------------------------------------------- 1 | @startuml general-application-design 2 | !include 3 | header System context diagram \nGeneral application point of view \n of the AllMyData project 4 | LAYOUT_WITH_LEGEND() 5 | SHOW_PERSON_PORTRAIT() 6 | 7 | Person_Ext(company, "Company", "[Person]") 8 | 9 | System_Ext(administration, "Administration B") { 10 | System(p1, "Accounting system") 11 | } 12 | 13 | System_Boundary(si, "Information System") { 14 | System(ma, "AllMyData", "Allows companies to recover their data") 15 | System(ref1, "REF_ENTREPRISE", "Person repository") 16 | System(compo, "Composition system", "Transactional editing") { 17 | } 18 | 19 | Rel(company, ma, "[1] Request via form") 20 | Rel(ma, ref1, "[2.1] Enrichment with internal data") 21 | Rel(ma, p1, "[2.2] Retrieving accounting information") 22 | Rel(ma, compo, "[3] PDF creation") 23 | @enduml -------------------------------------------------------------------------------- /blank-template/glossary.adoc: -------------------------------------------------------------------------------- 1 | = Glossary of terms used 2 | 3 | WARNING: Please respect the alphabetical order when editing the document 4 | 5 | == Terms under discussion / to be validated 6 | 7 | [cols="1,4,4"] 8 | |================================================== 9 | | Term | Meaning | Comment 10 | 11 | | | | 12 | |================================================== 13 | 14 | == Business and organizational terms 15 | 16 | [cols="1,4,4"] 17 | |================================================== 18 | | Term | Meaning | Comment 19 | 20 | | | | 21 | 22 | 23 | |================================================== 24 | 25 | == Application terms 26 | 27 | [cols="1,4,4"] 28 | |================================================== 29 | | Term | Meaning | Comment 30 | 31 | | | | 32 | 33 | |================================================== 34 | 35 | 36 | == Technical terms 37 | 38 | [cols="1,4,4"] 39 | |================================================== 40 | | Term | Meaning | Comment 41 | 42 | | | | 43 | 44 | |================================================== 45 | 46 | == Sources 47 | 48 | * ... -------------------------------------------------------------------------------- /blank-template/README.adoc: -------------------------------------------------------------------------------- 1 | :icons: font 2 | :lang: en 3 | 4 | # Architecture document 5 | 6 | Last modified: {localdate} {localtime} 7 | 8 | Model version : ## 9 | 10 | *Status*: ... 11 | 12 | This document is made up of: 13 | 14 | * an link:view-application.adoc[application view] presenting the general context and the application architecture; 15 | * a link:view-development.adoc[development view] presenting the software architecture and its environment; 16 | * a link:view-sizing.adoc[sizing view] presenting aspects related to the performance and sizing of the infrastructure; 17 | * an link:view-infrastructure.adoc[infrastructure view] presenting the servers, middleware, operations, etc.; 18 | * a link:view-security.adoc[security view]. 19 | 20 | Each section sets out the constraints, requirements and then solutions implemented. 21 | 22 | [TIP] 23 | ==== 24 | To be read first according to your role: 25 | 26 | image:./resources/views.png[Read this first] 27 | ==== 28 | 29 | 30 | ## Architectural subjects remaining 31 | 32 | * ... -------------------------------------------------------------------------------- /diagrams/detailled-application-design-dynamic.puml: -------------------------------------------------------------------------------- 1 | @startuml detailed-application-architecture-dynamic 2 | !include detailled-application-design-inventory.puml 3 | header Dynamic detailed application view\n R: Read, W:Write, X: Execute, D: Delete\n Dashed lines: asynchronous call 4 | LAYOUT_WITH_LEGEND() 5 | 6 | AddRelTag("async", $lineStyle = DashedLine()) 7 | 8 | Rel(company, static_resources, "Visit https://allmydata.gouv", "HTTPS, R") 9 | Rel(company, spa, "Retrieves information via") 10 | Rel(company, mobile, "Retrieves information via") 11 | Rel(static_resources, spa, "Provide to client's web browser", "HTTPS, R") 12 | Rel(spa, sm, "[1.1] Info request", "HTTPS, R") 13 | Rel(mobile, sm, "[1.1] Information request", "HTTPS, R") 14 | Rel(sm, bdd, "[1.2] Historization of the request", "JDBC, W") 15 | Rel(sm, queue, "[1.3] Request storage", "JMS, W",$tags='async') 16 | Rel(batch, queue, "[2.1] Pop requests", "JMS, R+D") 17 | Rel(batch, scompta, "[2.2] Retrieving accounting information", "HTTPS, R") 18 | Rel(batch, compo, "[2.3] PDF creation", "HTTP R") 19 | Rel(batch, smails, "[2.4] Request to send mail with PDF", "SMTP, X") 20 | Rel(smails, smails, "[2.5] Sending mail with PDF", "SMTP, X") 21 | 22 | @enduml -------------------------------------------------------------------------------- /diagrams/detailled-application-design-inventory.puml: -------------------------------------------------------------------------------- 1 | @startuml detailed-application-architecture-inventory 2 | !include 3 | header Inventory view 4 | LAYOUT_WITH_LEGEND() 5 | 6 | System_Boundary(company_system, "Any company IS") { 7 | Person_Ext(company, "Client", "[person] \nWeb client (PC, tablet, mobile)") 8 | Container(spa, "SPA gui-allmydata", "Container: javascript, React.js", "Graphical interface for requesting information") 9 | Container(mobile, "AllMyData mobile application", "Container: Android", "Graphical interface to request information") 10 | } 11 | 12 | System_Boundary(administration, "System administration B") { 13 | System_Ext(scompta, "Accounting system", "REST service") 14 | } 15 | 16 | System_Boundary(si, "Information System") { 17 | Container(static_resources, "gui-allmydata Web Application", "Container: nginx", "Deliver the static resources (js, html, images ...) of the AllMyData GUI") 18 | Container(sm, "service-allmydata", "Container: Tomcat, Spring Boot", "REST service allowing to request information") 19 | Container(batch, "batch-process-requests", "Container: groovy", "Process requests, launched by cron every minute") 20 | ContainerDb(queue, "requests-queue", "Container: ActiveMQ", "Stores requests") 21 | ContainerDb(bdd, "bdd-allmydata", "Container: PostgreSQL", "Internal database") 22 | Container(compo, "service-compo-pdf", "Container: Wildfly, JasperReport", "Composition REST service") 23 | Container(smails, "mail server", "Container: Postfix", "Send emails") 24 | } 25 | 26 | @enduml -------------------------------------------------------------------------------- /glossary.adoc: -------------------------------------------------------------------------------- 1 | = Glossary of terms used 2 | 3 | WARNING: Please respect the alphabetical order when editing the document 4 | 5 | == Terms under discussion / to be validated 6 | 7 | [cols="1e,4e,4e"] 8 | |================================================== 9 | | Term | Meaning | Comment 10 | 11 | | Channel | Origin of the request | Channel or origin ? 12 | |================================================== 13 | 14 | == Business and organizational terms 15 | 16 | [cols="1e,4e,4e"] 17 | |================================================== 18 | | Term | Meaning | Comment 19 | 20 | | CA | Court of Appeal | "The court has two divisions, Criminal and Civil" [Wikipedia] 21 | 22 | 23 | |================================================== 24 | 25 | == Application terms 26 | 27 | [cols="1e,4e,4e"] 28 | |================================================== 29 | | Term | Meaning | Comment 30 | 31 | | EIDAS | Electronic IDentification Authentication and trust Services | European regulation on electronic signatures 32 | 33 | | SPA | Single Page Application | Web application whose pages are generated in javascript in the browser 34 | 35 | |================================================== 36 | 37 | 38 | == Technical terms 39 | 40 | [cols="1e,4e,4e"] 41 | |================================================== 42 | | Term | Meaning | Comment 43 | 44 | | RP | Reverse Proxy | Makes HTTP calls on behalf of a client (usually over the Internet). 45 | Among other things, it improve security by avoiding direct calls. 46 | 47 | |================================================== 48 | 49 | == Sources 50 | 51 | * _http://km.mydomain.fr_ -------------------------------------------------------------------------------- /base-template-manifest.yaml: -------------------------------------------------------------------------------- 1 | author: Bertrand Florat 2 | license: CC BY-SA 4.0 3 | parts: 4 | - name: Application view 5 | file: view-application.adoc 6 | - name: Development view 7 | file: view-development.adoc 8 | - name: Infrastructure view 9 | file: view-infrastructure.adoc 10 | - name: Security view 11 | file: view-security.adoc 12 | - name: Sizing view 13 | file: view-sizing.adoc 14 | multi_values_labels: 15 | - name: level 16 | available_values: [basic, intermediate, advanced] 17 | - name: project_size 18 | available_values: [small, medium, large] 19 | - detail_level: 20 | available_values: [ overview, detailed, in-depth] 21 | files_imported_into_blank_templates: 22 | - src_dir: blank-template 23 | dest_dir: . 24 | files: 25 | - README.adoc 26 | - glossary.adoc 27 | - export 28 | - src_dir: blank-template/resources 29 | dest_dir: resources 30 | files: 31 | - views.png 32 | files_imported_into_templates: 33 | - src_dir: blank-template 34 | dest_dir: . 35 | files: 36 | - README.adoc 37 | - export 38 | - glossary.adoc 39 | - src_dir: blank-template/resources 40 | dest_dir: resources 41 | files: 42 | - views.png 43 | - src_dir: . 44 | dest_dir: . 45 | files: 46 | - LICENSE.md 47 | - src_dir: diagrams 48 | dest_dir: diagrams 49 | files: 50 | - detailed-application-architecture-dynamic.svg 51 | - detailled-application-design-dynamic.puml 52 | - detailed-application-architecture-inventory.svg 53 | - detailled-application-design-inventory.puml 54 | - general-application-design.svg 55 | - general-application-design.puml 56 | - infrastructure.svg 57 | - infrastructure.puml 58 | - roles.svg -------------------------------------------------------------------------------- /blank-template/export: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -e 3 | 4 | function usage(){ 5 | echo "Usage: 6 | Export an architecture document written in Asciidoc into a package of PDF or HTML files 7 | Requirement : Linux machine with Docker installed. 8 | 9 | --pdf : exports a PDF archive 10 | --adoc : exports asciidoc sources only 11 | --odt : exports HTML + Open Document Text 12 | --html : exports in static HTML 13 | " 14 | } 15 | 16 | if [[ $# != 1 ]]; then 17 | usage 18 | exit 1 19 | fi 20 | 21 | OUT=/tmp/architecture-document 22 | ARCHIVE=/tmp/architecture-document-$(date +%Y%m%d).zip 23 | rm -rf $OUT > /dev/null 2>&1 || true 24 | mkdir $OUT 25 | rm $ARCHIVE > /dev/null 2>&1 || true 26 | cp -rp *.adoc diagrams $OUT/ 27 | 28 | cd $OUT 29 | for doc in $(find . -name '*.adoc' -print); do 30 | if [[ $1 =~ '--adoc' ]]; then 31 | continue 32 | fi 33 | # -a allow to read offline (embedded images) 34 | docker run --rm -v $OUT:/data asciidoctor/docker-asciidoctor asciidoctor -a data-uri -a allow-uri-read -b html5 /data/$doc 35 | doc_without_extension=${doc%.adoc} 36 | if [[ $1 =~ '--pdf' ]]; then 37 | docker run --rm -v $OUT:/data madnight/docker-alpine-wkhtmltopdf --footer-center [page]/[topage] /data/$doc_without_extension.html /data/$doc_without_extension.pdf 38 | elif [[ $1 =~ '--odt' ]]; then 39 | docker run --rm \ 40 | -v "$OUT:/data" \ 41 | --user $(id -u):$(id -g) \ 42 | pandoc/core /data/$doc_without_extension.html -o /data/$doc_without_extension.odt 43 | fi 44 | done 45 | 46 | # Fixes hyperlinks among documents 47 | find . -name '*.html' -exec sed -i 's/.adoc/.html/g' {} \; 48 | 49 | if [[ $1 =~ '--html' ]]; then 50 | find . -name '*.adoc' -exec rm {} \; 51 | rm -rf .git > /dev/null 2>&1 || true 52 | fi 53 | 54 | # Create final archive 55 | cd /tmp 56 | zip -r $ARCHIVE $(basename $OUT) 57 | echo "Export successful at : $ARCHIVE" 58 | 59 | 60 | 61 | -------------------------------------------------------------------------------- /diagrams/infrastructure.puml: -------------------------------------------------------------------------------- 1 | @startuml infrastructure 2 | !include 3 | header Infrastucture architecture view 4 | LAYOUT_WITH_LEGEND() 5 | 6 | AddElementTag("passive", $bgColor="grey") 7 | AddElementTag("external", $bgColor="grey") 8 | 9 | Node("client", "Client", "Desktop / mobile") { 10 | Node("nav1", "Web browser", "Chrome / Firefox / Safari") { 11 | Container("spa", "AllMyData SPA application", "React.js") 12 | } 13 | } 14 | 15 | Node("dc", "Datacenter", "Atlanta") { 16 | Node("r2", "Firewall", "Cisco Firepower 4100") 17 | Node("lb1", "LB Debian lb1", "<>") 18 | Node("lb2", "LB Debian lb2", "<>",$tags="passive") 19 | 20 | Node("rp1", "Reverse Proxy", "x2 Debian Buster <>") { 21 | Container("ha1", "Reverse Proxy", "HaProxy") 22 | } 23 | 24 | Node("server_gui", "AllMyData server", "x2 Debian Buster") { 25 | Node("sw1", "Web server", "Nginx") { 26 | Container("guis1", "SPA Web Application", "React.js", "Expose static resources \n (.js, .html, images ...)") 27 | } 28 | Node("tomcat_batchs1", "JEE Server", "Tomcat 10") { 29 | Container("batch1", "batch-process-requests", "Java", "Process requests") 30 | } 31 | } 32 | 33 | Node("API_server", "API Server", "x3, RHEL") { 34 | Node("wilfly1", "JEE Server", "Wildfly") { 35 | Container("api1", "API service-allmydata", "Java") 36 | } 37 | } 38 | 39 | Node("bdd1", "BDD Server", "RHEL") { 40 | ContainerDb("pg1", "PostgreSQL", "PostgreSQL 12") 41 | ContainerDb("mq1", "Message queue", "ActiveMQ") 42 | Container("mail1", "MTA", "Postfix") 43 | } 44 | 45 | Node("all_servers","") 46 | Node("sup1_server", "Monitoring Server", "x1 Debian Stretch") { 47 | Container("sup1", "Monitoring tool", "Centreon") 48 | } 49 | 50 | } 51 | 52 | Node("administration_b","Datacenter","NYC",$tags="external"){ 53 | Node("ech1","API Geatexway","x1 Windows Server") { 54 | Container("gw1","API Gateway","API Gateway") 55 | } 56 | 57 | Node("compta","Accounting Serveur","x1 Linux") { 58 | Container("api_b","Accounting Service API","") 59 | } 60 | } 61 | 62 | Rel("spa", "r2","HTTPS on the Internet") 63 | Rel("r2","lb1","HTTPS") 64 | Rel("lb2", "lb1","Heartbeat VRRP") 65 | Rel("lb1","ha1","") 66 | Rel("ha1","guis1", "HTTP") 67 | Rel("api1", "mq1", "products \n AMQP")) 68 | Rel("batch1","mq1", "consumes \n AMQP") 69 | Rel("api1", "pg1", "JDBC / PG") 70 | Rel("batch1", "mail1", "SMTP / sends e-mails") 71 | Rel("api1","gw1","SOAP/HTTPS") 72 | Rel("gw1","api_b","SOAP/HTTPS") 73 | Rel("ha1","api1","REST/HTTP") 74 | Rel_L("sup1_server","all_servers","SNMP") 75 | 76 | @enduml -------------------------------------------------------------------------------- /blank-template/view-sizing.adoc: -------------------------------------------------------------------------------- 1 | # Sizing view 2 | :sectnumlevels: 4 3 | :toclevels: 4 4 | :sectnums: 4 5 | :toc: left 6 | :icons: font 7 | :toc-title: Table of contents 8 | 9 | [#32c8942e-443f-429d-a411-43869a720224] 10 | ## Introduction 11 | 12 | [#c443e562-398d-49ab-92bd-8031f3e91bec] 13 | ### Reference Documentation 14 | [cols="1,1,4,4"] 15 | |=== 16 | | N ° | Version | Document title / URL | Detail 17 | | 18 | | 19 | | 20 | | 21 | 22 | |=== 23 | 24 | [#1ef7beb9-71ee-43e5-9a1b-c45a48959084] 25 | ## Not ruled 26 | 27 | [#c5db3e60-e70c-4ebb-9848-44a0cecc4c6e] 28 | ### Points subject to further study 29 | [cols="1,5,2,2,2"] 30 | |=== 31 | | ID | Detail | Status | Subject holder | Deadline 32 | 33 | | 34 | | 35 | | 36 | | 37 | | 38 | 39 | |=== 40 | 41 | [#577c9b37-77a2-4568-9fb5-2804d6f9bc70] 42 | ### Assumptions 43 | [cols="1,6"] 44 | |=== 45 | | ID | Detail 46 | | 47 | | 48 | |=== 49 | 50 | [#69811b17-b947-4562-90ba-a97160421965] 51 | ## Constraints 52 | 53 | [#646fc728-6cef-4e75-9fa9-646b4ec2159d] 54 | ### Storage constraints 55 | 56 | [#1d3ec06e-d63d-4a61-bb4e-437358064687] 57 | ### CPU constraints 58 | 59 | [#ec6a420b-c284-442a-93fd-edc3d45ed00a] 60 | ### Memory constraints 61 | 62 | [#8d948872-15f9-49b6-9527-f511a2f7597d] 63 | ### Network constraints 64 | 65 | [#d6e3eb12-371b-4c26-b538-9fea2051bfed] 66 | ## Requirements 67 | 68 | [#962347a4-c3c8-4f0c-bcac-774a6ef617a4] 69 | ### Static sizing 70 | 71 | [#1736e661-2c68-4aa6-a157-9e4444d5a374] 72 | #### Metrics 73 | [cols="1,1,1,1,1,1,1"] 74 | |=== 75 | | Metric | Description | Measured or Estimated? | Value | Forecast annual increase (%) | Source | Detail/assumptions 76 | 77 | | 78 | | 79 | | 80 | | 81 | | 82 | | 83 | | 84 | |=== 85 | 86 | [#9968c2e6-46b9-4005-89d4-6a9114246a4c] 87 | #### Estimated storage needs 88 | 89 | [cols="1,1,1,1,1,1"] 90 | |=== 91 | | Data | Description | Unit size | Number of items at 2 years | Total size | Annual increase 92 | 93 | | 94 | | 95 | | 96 | | 97 | | 98 | | 99 | |=== 100 | 101 | [#b22cadba-e5a7-4c3a-b4b8-f9ea32a2a0be] 102 | ### Dynamic sizing 103 | 104 | [#910fc171-30ed-47cd-b03c-3ca918b3103e] 105 | #### Metrics 106 | [cols="1,1,1,1,1,1,1,1"] 107 | |=== 108 | | Metric | Description | Measured or Estimated? | Value | Forecast annual increase (%) | Seasonality | Source | Detail/assumptions 109 | 110 | | 111 | | 112 | | 113 | | 114 | | 115 | | 116 | | 117 | | 118 | |=== 119 | 120 | [#3d09511c-17b2-43c3-bcba-0a62ead057b4] 121 | #### Estimated load 122 | 123 | [#c1a8f666-70e1-4acf-9d7a-5e1b06ecb588] 124 | ### Response time requirements 125 | 126 | [#24f70acd-5f7c-49b3-bd75-d594e5af8917] 127 | #### Response time of GUIs 128 | [cols = '3, 1, 1, 1'] 129 | |=== 130 | | Type of request | Good level | Medium level | Insufficient level 131 | 132 | | 133 | | 134 | | 135 | | 136 | |=== 137 | 138 | [#88645b89-d407-4107-93b2-48003fd8688a] 139 | #### Duration of batch execution 140 | 141 | [#fb740b6a-bd23-4401-a7e0-b01610a01b9b] 142 | ## Target sizing 143 | 144 | [#63214041-3461-4019-a685-fac68fdb4d74] 145 | ### Estimate of resource requirements by deployable unit 146 | .Estimation of resource requirements by deployable unit 147 | [cols="2,1,1,3,2"] 148 | |=== 149 | | Deployable unit | (V)CPU requirement per instance | Memory requirement per instance (MiB) | Periods of activity | Comments 150 | 151 | | 152 | | 153 | | 154 | | 155 | | 156 | |=== 157 | 158 | [#6e9675d7-5d8c-4cf8-989a-13640cd28ef3] 159 | ### Sizing of machines 160 | .Sizing of machines 161 | [cols = '1, 3, 1, 1, 1, 1, 1'] 162 | |=== 163 | | Zone | Machine type | Number of machines | Number of (V)CPU | Memory (GiB) | Internal disk (GiB) | External SAN disk (GiB) 164 | 165 | | 166 | | 167 | | 168 | | 169 | | 170 | | 171 | | 172 | 173 | |=== 174 | 175 | .Non-SAN external storage 176 | [cols='1,3,3'] 177 | |=== 178 | |Nature |Size (Gio) |Type(s) of machine using this share 179 | 180 | | 181 | | 182 | | 183 | |=== -------------------------------------------------------------------------------- /blank-template/view-application.adoc: -------------------------------------------------------------------------------- 1 | # Application view 2 | :sectnumlevels: 4 3 | :toclevels: 4 4 | :sectnums: 4 5 | :toc: left 6 | :icons: font 7 | :toc-title: Table of contents 8 | 9 | [#74c82505-5f47-4342-8f1b-f6951d603062] 10 | ## Introduction 11 | 12 | [#c182158d-40af-4840-b8f2-3a2a030c95af] 13 | ### Reference Documentation 14 | [cols="1,1,4,4"] 15 | |=== 16 | | N ° | Version | Document title / URL | Detail 17 | | 18 | | 19 | | 20 | | 21 | 22 | |=== 23 | 24 | [#946b3119-a878-47ca-86f2-4c9e22ef0c89] 25 | ## Not ruled 26 | 27 | [#af23d422-402c-49be-900f-2f55a5619615] 28 | ### Points subject to further study 29 | [cols="1,6,1,1,1"] 30 | |=== 31 | | Subject | Detail | Status | Subject bearer | Deadline 32 | 33 | | 34 | | 35 | | 36 | | 37 | | 38 | |=== 39 | 40 | [#60a52e4c-4416-429a-a739-37153b05133c] 41 | ### Assumptions 42 | [cols="1,6"] 43 | |=== 44 | | ID | Detail 45 | 46 | | 47 | | 48 | |=== 49 | 50 | [#382fd086-f48e-4ad5-9911-07e3de281971] 51 | ## General context 52 | 53 | [#ba1f44fe-c47a-4d34-bfdb-07e777e23dda] 54 | ### Objectives 55 | 56 | [#bbb1f617-3ceb-4f80-a3c4-dbc9b16bcd00] 57 | ### Existing 58 | 59 | [#67bbae56-5ed3-4977-8467-2c951882d1a9] 60 | ### Positioning in the IS 61 | 62 | [#9ca40d05-ab6e-42ab-aa3c-b9724373ae7f] 63 | ### Actors 64 | 65 | #### Internal actors 66 | [cols="1,1,4,4"] 67 | |=== 68 | | Actor | Description | Population | Location 69 | 70 | | 71 | | 72 | | 73 | | 74 | 75 | |=== 76 | 77 | #### External actors 78 | [cols="1,1,1,1"] 79 | |=== 80 | | Actor | Description | Population | Location 81 | 82 | | 83 | | 84 | | 85 | | 86 | 87 | |=== 88 | 89 | [#deafbeef-dead-4bed-8ace-0b0b0b0b0b0b] 90 | #### Nature and Sensitivity of Data and Processing 91 | [%header,cols="2,3,3,2,1,1,1,1"] 92 | |=== 93 | | Business Process | Purpose | Categories of Data Processed | Internal Classification | C | I | A | T 94 | 95 | | 96 | | 97 | | 98 | | 99 | | 100 | | 101 | | 102 | | 103 | |=== 104 | 105 | [cols="1,5"] 106 | |=== 107 | | Legend | \(C)onfidentiality (I)ntegrity (A)vailability (T)raceability / proof: security requirements (Low, Medium, High) 108 | | Classification | Public, Internal, Restricted distribution, Confidential 109 | |=== 110 | 111 | [#d979e090-c43f-48f5-a0e3-83b810efff9f] 112 | ## Constraints 113 | 114 | [#58897e87-0c12-4139-b5da-daec9cae21c6] 115 | ### Budget 116 | 117 | [#ac5b1f28-bfcb-4543-a90b-abcff2b41822] 118 | ### Planning 119 | 120 | [#5837249a-8fcc-4e42-9dd9-384c4fa32afc] 121 | ### Urbanization 122 | 123 | [#abafa462-262f-429e-aad8-d2cdc0cf15a3] 124 | ### Legals 125 | 126 | [#3b714287-891e-4ea3-a7a4-17672caaf945] 127 | ## Requirements 128 | 129 | [#9352a89a-3f8b-4028-98d5-58fb970e01ef] 130 | ### Strategic Requirements 131 | 132 | [#38fd6aa0-2354-4d0d-9812-10ed917eae5e] 133 | ### Interoperability 134 | 135 | [#7d3090d0-87d0-434f-9717-f9a12ccf60d1] 136 | ### Concurrency management requirements 137 | 138 | [#9efde825-9508-4669-918c-7cfb0d45c21f] 139 | ### Retention Periods 140 | [cols="1,1"] 141 | |=== 142 | | Data Class | Maximum Retention Period 143 | 144 | | 145 | | 146 | 147 | 148 | |=== 149 | 150 | [#afdd573d-d1f8-4958-99c1-e404592396d0] 151 | ### Degraded modes 152 | 153 | [#ec7cfacf-e267-4937-80e8-b5c92409ecd1] 154 | ### Archiving 155 | 156 | [#b269e65b-a8c7-4518-a861-5c6c17802869] 157 | ## Target architecture 158 | 159 | [#2c107a25-a1c4-433d-b746-e12aa2c6eea1] 160 | ### General application architecture 161 | 162 | [#6390e724-c2f0-4737-99a0-531fdcfe8e20] 163 | ### Detailed application architecture 164 | 165 | [#148fd29c-b0a0-4bff-b5da-71f5b1195e1e] 166 | #### Principles that dictated the choices 167 | 168 | [#d4124d8e-47b9-4cfa-94ec-8164180bdecc] 169 | #### Inventory view 170 | 171 | [#6c06792f-9e6d-4156-88d3-468063716834] 172 | #### Links between modules 173 | 174 | [#9ac6e5d2-e9a0-427e-ba12-27dedbd8ac4d] 175 | ### Transition paths 176 | 177 | [#f49dc567-ef07-45db-b25a-34c57a58f213] 178 | ### Archiving 179 | 180 | [#7a01e2dd-1921-4e41-95d6-57f2b80e447b] 181 | ### Purges 182 | 183 | [#3a80c49f-5f9d-4c1d-bcb5-d3ef292e2895] 184 | ### Matrix of application flows 185 | [cols = '1, 3, 1, 1, 1'] 186 | |=== 187 | | Source | Destination | Network type | Protocol | Mode.footnote:[Read\(R), Write (W) or Call\(C) to a stateless system] 188 | 189 | | 190 | | 191 | | 192 | | 193 | | 194 | 195 | |=== -------------------------------------------------------------------------------- /blank-template/view-development.adoc: -------------------------------------------------------------------------------- 1 | # Development view 2 | :sectnumlevels: 4 3 | :toclevels: 4 4 | :sectnums: 4 5 | :toc: left 6 | :icons: font 7 | :toc-title: Table of contents 8 | 9 | [#84c5d434-ea70-41fc-92bc-53a40ab29025] 10 | ## Introduction 11 | 12 | [#712fc07b-76ba-4093-bbf8-cceeaa903e64] 13 | ### Reference Documentation 14 | [cols="1,1,4,4"] 15 | |=== 16 | | N ° | Version | Document title / URL | Detail 17 | | 18 | | 19 | | 20 | | 21 | 22 | |=== 23 | 24 | [#fa1ed85e-92d0-4aa9-9421-dcf267d0cf0e] 25 | ## Not ruled 26 | 27 | [#b3592a4d-d0df-4f87-8416-97cfb287cd08] 28 | ### Points subject to further study 29 | [cols="1,1,1,1,1"] 30 | |=== 31 | | ID | Detail | Status | Subject holder | Deadline 32 | 33 | | 34 | | 35 | | 36 | | 37 | | 38 | 39 | |=== 40 | 41 | [#fb0b1a28-1c08-4c0b-bb38-1cae99a46818] 42 | ### Assumptions 43 | [cols="1,6"] 44 | |=== 45 | | ID | Detail 46 | 47 | | 48 | | 49 | |=== 50 | 51 | [#84cd4aed-36c0-4564-8354-29a7de004923] 52 | ## Constraints 53 | 54 | [#8d79cc07-e094-4863-8bb8-0a3ca317743d] 55 | ## Non-functional requirements 56 | 57 | [#48bb8b97-2e97-4515-bf3b-95864f85e4e9] 58 | ### Accessibility 59 | 60 | [#b098d142-655e-4521-9d4f-2c2ea8eceb45] 61 | ### Ergonomics 62 | 63 | [#3c031334-5598-4817-87b4-dec34ce8389b] 64 | #### Ergonomic charter 65 | 66 | [#90b4af62-df5b-485e-87c4-7dd0b21d0464] 67 | #### Specificities on widgets 68 | 69 | [#1cacea74-bede-43b3-93a5-804fd60ff4fb] 70 | #### Fonts 71 | 72 | [#cfd3435f-d888-43e3-a634-35c3d5d92cb4] 73 | #### Responsive website 74 | 75 | [#30cc6226-2213-4351-83aa-a4905c5d4baa] 76 | #### Progressive Web Apps (PWA) 77 | 78 | [#67ff8381-8145-4dc4-bd15-cfec867dc8b5] 79 | #### Supported browsers 80 | 81 | [#39318743-8131-4d46-9354-c64804066ae8] 82 | #### Offline mode 83 | 84 | [#fbe627e5-be3f-41ec-9a2a-c43bd3587c6e] 85 | #### Internationalization (i18n) 86 | 87 | [#8c3bc449-1b44-44cf-82a1-f26cdbf258af] 88 | ### SEO Requirements 89 | 90 | [#c8e58371-6bea-48e2-ab0e-989fec63e0ee] 91 | ### Ecodesign requirements 92 | 93 | [#2c0aa24a-24b8-4272-8787-b5e5207785fb] 94 | ## Target architecture 95 | 96 | [#50b4ef16-e558-4604-9b17-b90e68da6337] 97 | ### Software stack 98 | 99 | [#16dc549a-4b87-428e-b59d-4c0af1e720db] 100 | #### Stack profile 101 | 102 | [#e9b08c72-a836-48ad-9255-e2977a09f290] 103 | #### Main dependencies 104 | [cols="1,4,1"] 105 | |=== 106 | | Library | Role | Version 107 | 108 | | 109 | | 110 | | 111 | 112 | |=== 113 | 114 | [#ec64dc5b-cdc1-4ab3-ae41-ac3c1c3ad9e7] 115 | ### Performance 116 | TIP: See also xref:view-sizing.adoc#d6e3eb12-371b-4c26-b538-9fea2051bfed[Requirements]. 117 | 118 | [#cacf4bd8-9e8a-449c-af31-1fd27169a685] 119 | ### Software factory specifics 120 | 121 | [#11f66697-ac3a-40f0-903a-cc8202b7315e] 122 | ### Blueprints 123 | 124 | [#4cfc1f5e-bf4b-4c33-b718-83ca90974090] 125 | ### Code quality standards and automatic review 126 | 127 | [#bbe62a07-d42a-4495-8d23-4d0ea23d19e6] 128 | ### Notable patterns 129 | 130 | [#99e519d3-e8cf-4b3c-8e87-e06a1bf675af] 131 | ### Specificities of the tests 132 | [cols = '2s, 1,1,1,1,4a'] 133 | |=== 134 | | Type of test | Time to invest | Manual or automated? | Type of module targeted | Target Coverage Rate | Detail 135 | 136 | | 137 | | 138 | | 139 | | 140 | | 141 | | 142 | |=== 143 | 144 | [#6ff8aacb-5020-4ade-a10d-3dce3898276b] 145 | ### Ecodesign 146 | TIP: See also <>. 147 | 148 | [#bb5d8145-8519-4516-98a9-fc089f758d9c] 149 | ### Management of robustness 150 | 151 | [#a7bacacc-de70-48e5-8563-6a0b6d7b31a2] 152 | #### Transaction management 153 | 154 | [#8bd70b17-0223-4aaf-97ac-a7284efe721f] 155 | #### Session management 156 | 157 | [#4ffcfd1b-87c9-48d0-96d6-f3b3b817a869] 158 | #### Error handling 159 | 160 | [#7a33eb60-882d-4095-bde2-9a477cc27433] 161 | #### Frontend robustness 162 | 163 | [#d101d1ee-8ec7-48dd-b733-ebba345c656d] 164 | ### Configuration management 165 | 166 | [#01a81b2c-1dc0-4563-a2e2-5c5248086499] 167 | ### Branch management policy 168 | 169 | [#35b97569-e671-40c3-809c-ffcb5d1af383] 170 | ### Versioning 171 | 172 | [#79682de3-09b7-46f1-8354-9371295d18a8] 173 | ### Concurrency 174 | 175 | [#856b9e7b-3305-48c3-bb99-798cf409181d] 176 | ### Encoding 177 | 178 | [#5885803d-2d3d-4e19-af30-40e904e9fb6d] 179 | ### Timezones 180 | 181 | [#96ec879c-3ce3-4e48-a3f9-84590c281fd4] 182 | ### Log management 183 | 184 | [#cad3fb2c-5047-4025-892f-3180e74579c8] 185 | #### General rules 186 | 187 | [#992c0bb3-83bc-4598-84ff-150a67df3324] 188 | #### Levels and quantity of logs 189 | [cols = '1,3,1,1'] 190 | |=== 191 | | Severity level | Context of use | Indicative volume | By environment 192 | 193 | | 194 | | 195 | | 196 | | 197 | |=== 198 | 199 | [#f2e9066c-18d9-4234-b37c-27d342b1c99e] 200 | ### Administrative tools 201 | 202 | [#ef97a533-5fc7-4999-87fc-def24074746c] 203 | ### Sorting and Pagination 204 | 205 | [#4af6fb38-c84a-456f-b043-32abeb6e7798] 206 | ### Provisioning and DDL updates 207 | 208 | [#201fca5f-50af-41f9-ab97-60b2f7abddc6] 209 | ### i18N Management 210 | TIP: See also <>. 211 | -------------------------------------------------------------------------------- /blank-template/view-infrastructure.adoc: -------------------------------------------------------------------------------- 1 | # Infrastructure view 2 | :sectnumlevels: 4 3 | :toclevels: 4 4 | :sectnums: 4 5 | :toc: left 6 | :icons: font 7 | :toc-title: Table of contents 8 | 9 | [#e3208a9c-8d35-46a1-9399-aacea9817e0a] 10 | ## Introduction 11 | 12 | [#06fd3383-f875-4a44-a1f8-d135f9050038] 13 | ### Reference Documentation 14 | [cols="1,2,5,4"] 15 | |=== 16 | | N ° | Version | Document title / URL | Detail 17 | 18 | | 1 || 19 | | 20 | 21 | |=== 22 | 23 | [#933039be-008f-40c7-a630-a08002b379f1] 24 | ## Not ruled 25 | 26 | [#87385297-c5c3-44f6-b9e8-7599576dda0a] 27 | ### Points subject to further study 28 | [cols="1,5,2,2,2"] 29 | |=== 30 | | ID | Detail | Status | Subject holder | Deadline 31 | 32 | | 33 | | 34 | | 35 | | 36 | | 37 | 38 | |=== 39 | 40 | [#30d20b83-e35d-464b-8286-3ff230fb1471] 41 | ### Assumptions 42 | [cols="1,5"] 43 | |=== 44 | | ID | Detail 45 | 46 | | 47 | | 48 | |=== 49 | 50 | [#82a207de-bc6f-4a62-a586-96a2b4c9f4dc] 51 | ## Constraints 52 | 53 | [#cc4a17a8-d68b-43cf-8b4e-c64829d950fc] 54 | ### Constraints on availability 55 | 56 | [#a18eb613-e522-4bf5-a1fd-742b9d754ce1] 57 | #### MTTD 58 | 59 | [#dc11b031-5685-4972-9832-138fa74cd30b] 60 | #### Monitoring tools 61 | 62 | [#6903a99e-8b8e-464b-909c-d40da5a808d1] 63 | #### MTTR 64 | 65 | [#e7470aba-8588-4792-bc94-28e4bf186b63] 66 | ##### Hardware 67 | 68 | [#96cd73f1-0dca-447e-8fc8-2d9c03399e1c] 69 | ##### System and virtualization 70 | 71 | [#22a1f1de-1ab0-4a54-bd0f-64c7c5ab9713] 72 | ##### Network 73 | 74 | [#b39586c3-6bbe-417f-ad64-eff53c81d283] 75 | ##### Data Restore 76 | 77 | [#421860fb-b6b3-461a-b149-57c6ba6dae41] 78 | #### Scheduled interruptions 79 | 80 | [#21d704f6-f740-40f9-986c-36274643a711] 81 | #### Level of service of the datacenter 82 | 83 | [#7c1d0446-34df-4572-92b0-19baaba54183] 84 | #### Availability Ceiling (Upper Bound) 85 | 86 | [#4860fb1c-98e9-4c2c-adfc-09ea8149235d] 87 | #### Disaster Management 88 | 89 | [#c7c4fce5-c971-4ec8-bef7-006381492aff] 90 | ### Hosting 91 | 92 | [#6f7d74be-7024-4a6e-af4d-d084d49109ae] 93 | ### Network constraints 94 | 95 | [#86a3082e-7069-4120-b86f-f886ef919986] 96 | ### Deployment constraints 97 | 98 | [#16781642-a7f3-40f1-b208-e4064ffedaa4] 99 | ### Constraints Related to the Lifecycle of Infrastructure Components 100 | 101 | [#0a25770c-6a02-4fa3-82cc-bf5152d3cba6] 102 | ### Log constraints 103 | 104 | [#608d63e6-7299-4976-bf59-52fa1c6ac486] 105 | ### Backup and restore constraints 106 | 107 | [#22e6cfa3-bc3d-466c-a902-9854540258b7] 108 | ### Costs 109 | 110 | [#f9ed2469-e3e5-48a1-8b69-4b9c9492c6cb] 111 | ## Requirements 112 | 113 | [#332c967b-3729-4a5f-984e-fc2f301b0329] 114 | ### Operating ranges 115 | [cols="1,5,2"] 116 | |=== 117 | | No window | Hours | Detail 118 | 119 | | 120 | | 121 | | 122 | 123 | |=== 124 | 125 | [#08cb1019-20c4-42ef-9bf2-4adf72936c1c] 126 | ### Availability requirements 127 | .Maximum allowable downtime per range 128 | [cols="1,5"] 129 | |=== 130 | | Operation range ID | Maximum downtime 131 | 132 | | 133 | | 134 | 135 | |=== 136 | 137 | [#231768e7-6a9d-429e-b200-2febdd91a0e3] 138 | ### Robustness requirements 139 | 140 | [#f0e94586-876d-46ca-b060-b5dcde468734] 141 | ### RPO requirements 142 | 143 | [#3e07d851-b2dc-422f-9cba-1b4447a5c956] 144 | ### RTO Requirements 145 | 146 | [#cdb68f23-d2c5-4373-9f7d-e358191f0ebf] 147 | ### Deployment and upgrades requirements 148 | 149 | [#663ee84f-7dde-4c6d-acf6-a810ab8fafb4] 150 | #### Server side 151 | 152 | [#fd64ad27-05da-42f0-9491-f790642b5d91] 153 | #### Client side 154 | 155 | [#0bbb4d10-bb6c-4cb0-b227-2e97db99eae1] 156 | #### Specific deployment strategy 157 | 158 | [#da0d11fe-0dc9-478e-a984-7a80ea1be482] 159 | ### Ecodesign requirements 160 | 161 | [#602a7a0a-7f25-4512-b0ab-3b97c8a734e0] 162 | ## Target architecture 163 | 164 | [#8088138c-5258-4f3a-a293-0984501bb5db] 165 | ### Principles 166 | 167 | [#17a46000-c51d-4fb7-868c-7386aef5b523] 168 | ### Availability 169 | 170 | [#c23ff676-32e3-4957-8cec-6a7619a33567] 171 | ### Deployment in production 172 | 173 | [#28ba010e-1c33-41b9-8061-9596710563bc] 174 | ### Infrastructure components 175 | [cols="1m,2m,1m,2m"] 176 | |=== 177 | |Infrastructure Component |Role |Version |Technical Environment 178 | 179 | | 180 | | 181 | | 182 | | 183 | |=== 184 | 185 | [#3ff53ea7-2e7f-4d71-8848-6819ba23c930] 186 | ### Matrix of network flows 187 | [cols="1m,2m,2m,2m,1m,1m,1m"] 188 | |=== 189 | |ID|Source|Destination|Network Type|Protocol|Listening Port|Encryption? 190 | 191 | | 192 | | 193 | | 194 | | 195 | | 196 | | 197 | | 198 | 199 | |=== 200 | 201 | [#93947744-e0ec-4bc3-af30-cc60473b7caf] 202 | ### Environments 203 | 204 | [cols = '1,2,2,2'] 205 | |=== 206 | | Environment | Role | Content | Nb of platforms 207 | 208 | | 209 | | 210 | | 211 | | 212 | |=== 213 | 214 | [#0bbc320c-6291-4a89-b263-66abf1906ab0] 215 | ### Ecodesign 216 | TIP: See also <>. 217 | 218 | #### Energy Optimization & Infrastructure 219 | 220 | #### **Overall energy impact** 221 | 222 | [#46e9c057-75cb-4bc0-9c8d-9af81f737c61] 223 | ### Load regulation 224 | 225 | [#32466600-a3a5-465f-9679-2a244b34321e] 226 | #### Circuit breakers 227 | 228 | [#44f0732c-3b29-4bd5-873f-046fc010f728] 229 | ### Timeout Management 230 | 231 | [#5fa5ed39-9b6d-4dec-a8c1-1dc1929ff796] 232 | ### Timeout management 233 | 234 | [#c9a330f1-ffde-44e2-a432-a1e178440333] 235 | ### Operations 236 | 237 | [#0a3f0e4e-0458-4528-9513-1f75a4ad8464] 238 | #### Startup/Shutdown Order 239 | 240 | [#314a1ef0-48b4-42a4-a8b6-be49250c5a50] 241 | #### Scheduled Operations and Monitoring 242 | 243 | [#0cf18e71-b20e-4b2b-9377-e104c21c9785] 244 | #### Maintenance Mode 245 | 246 | [#fd5b00b0-4b23-4cbc-8117-0dcee74ddd8b] 247 | #### Backups and Restores 248 | 249 | [#506b442c-ec84-454c-b11b-ddf7fe560701] 250 | ##### Scope 251 | 252 | [#ef7922e8-8122-4120-86f9-c5fed0676811] 253 | ##### Backup Strategy 254 | TIP: See also <>, <<3e07d851-b2dc-422f-9cba-1b4447a5c956,RTO Requirements>>. 255 | 256 | [#93b244a6-976c-465a-80fc-9665a81adeb9] 257 | ##### Tooling 258 | 259 | [#49e36233-2293-4135-80b2-5c145fe72c7d] 260 | ##### Backup Processing 261 | 262 | [#d8955c5f-7ccd-493e-8697-bdd6611ef727] 263 | ##### Storage Modalities 264 | 265 | [#2c96a319-9929-453b-a51e-d1de9b1103af] 266 | ##### Restore 267 | 268 | [#74ff1a8d-91b4-4437-bbfd-439e3d4b18b5] 269 | #### Logging 270 | 271 | [#2c3d502d-d67c-417b-88f4-d610e158e930] 272 | ### Monitoring 273 | 274 | [#f31e9b70-8bf9-41b5-bbb0-c6b3f6de9347] 275 | #### Technical Monitoring 276 | 277 | [#be41d5fd-e1a8-4a49-bf80-a81c3db693db] 278 | #### Application & Business Monitoring 279 | 280 | [#236fd883-5195-4b81-b5dd-f6c66f9ae3f0] 281 | #### Monitoring & Observability Tools 282 | 283 | [#aa3c7bab-527c-4411-a1f2-583a1d62118f] 284 | #### Alerting & Notifications 285 | 286 | [#20dff012-aa85-465f-ba2e-272d7580dd0b] 287 | ##### Black-box Monitoring 288 | 289 | [#f455e87e-47f0-422a-a80b-0ec65517ad53] 290 | ##### Performance Monitoring (Metrology) 291 | 292 | [#53b2f98c-11d9-4aa0-b762-b8f31db0c30f] 293 | ### Decommissioning 294 | -------------------------------------------------------------------------------- /blank-template/view-security.adoc: -------------------------------------------------------------------------------- 1 | # Security view 2 | :sectnumlevels: 4 3 | :toclevels: 4 4 | :sectnums: 4 5 | :toc: left 6 | :icons: font 7 | :toc-title: Table of contents 8 | 9 | [#a08e807e-1e9b-4752-a5b8-372a40665c49] 10 | ## Introduction 11 | 12 | [#cd8c64f1-d216-4b24-946c-175455e824a7] 13 | ### Reference Documentation 14 | [cols="1,1,4,4"] 15 | |=== 16 | | N ° | Version | Document title / URL | Detail 17 | | 18 | | 19 | | 20 | | 21 | 22 | |=== 23 | 24 | [#ea245600-dbd6-4f56-a58c-8c77556643ad] 25 | ## Not ruled 26 | 27 | [#a058d388-72e1-4136-8659-7a9db1c1a340] 28 | ### Points subject to further study 29 | [cols="1,5,2,2,2"] 30 | |=== 31 | | ID | Detail | Status | Subject holder | Deadline 32 | 33 | | 34 | | 35 | | 36 | | 37 | | 38 | 39 | |=== 40 | 41 | [#68a4f41c-1139-4cdd-bb9e-e15667f47fd9] 42 | ### Assumptions 43 | [cols="1,6"] 44 | |=== 45 | | ID | Detail 46 | | 47 | | 48 | |=== 49 | 50 | [#53ae9c06-1846-4dd2-ab55-f4a784c6a676] 51 | ## Constraints 52 | 53 | [#4882e5b9-c250-4079-8b24-04996016606d] 54 | ## Requirements 55 | 56 | [#323d4c77-810a-4015-bc1a-11da07e24f3b] 57 | ### Integrity Requirements 58 | .Required integrity level by data class 59 | [cols='2,1,1,1,1'] 60 | |=== 61 | |Data Class |Non-Integral [small]#(Integrity errors are tolerated)# |Detectable [small]#(Errors are quickly identified)# |Controlled [small]#(Errors are corrected)# |Integral [small]#(No alteration is tolerated)# 62 | 63 | | 64 | | 65 | | 66 | | 67 | | 68 | 69 | |=== 70 | 71 | [#acfa846e-0ed7-4f41-a593-f4ee29e94efd] 72 | ### Confidentiality Requirements 73 | .Required confidentiality level by data class 74 | [cols="1,1,1,1,1"] 75 | |=== 76 | |Data Class |Public [small]#(Accessible to anyone without restriction)# |Limited [small]#(Accessible only to authorized individuals)# |Restricted [small]#(Restricted to authorized internal staff)# |Private [small]#(Strictly individual access)# 77 | 78 | | 79 | | 80 | | 81 | | 82 | | 83 | |=== 84 | 85 | [#94c138c1-3e8b-4eaf-8926-b5b9bfa6a86b] 86 | ### Identification Requirements 87 | 88 | [#9d0646cd-3e3f-4878-96de-f215c9f20bdc] 89 | ### Authentication Requirements 90 | 91 | [#58bf95ee-2fc4-4972-ac2b-7e2f775a4eb9] 92 | #### Authentication Requirements by Use Case 93 | The table below indicates the **authentication factors required** depending on the usage context: 94 | 95 | [cols="1,1,1,1,1,1,1"] 96 | |=== 97 | |Authentication Case 98 | |Password compliant with the security policy 99 | |Known SSH public key 100 | |OTP via Token 101 | |Biometrics 102 | |Knowledge of business data 103 | |Verification link by email 104 | 105 | | 106 | | 107 | | 108 | | 109 | | 110 | | 111 | | 112 | |=== 113 | 114 | [#f552f1e6-9aea-4866-8da1-e7ed676fd228] 115 | ### Identity Federation Requirements 116 | 117 | [#400376ad-cc62-4ab3-8e96-5a9f9a954e49] 118 | ### SSO and SLO Requirements 119 | 120 | [#01404b83-f96f-4649-ace0-e5611601b830] 121 | ### Non-repudiation requirements 122 | [cols="1,1,1,1"] 123 | |=== 124 | |Signed action or document |Required signature level |Origin of client certificate |Origin of server certificate 125 | 126 | | 127 | | 128 | | 129 | | 130 | |=== 131 | 132 | [#958fcccc-60cb-4158-940f-279cd1d12c9b] 133 | ### Anonymity and privacy requirements 134 | 135 | [#fcad5990-c241-4c88-b2c5-646602f8935a] 136 | ### Authorization Requirements 137 | 138 | [#e72e5ea5-5711-4665-8a91-76c63cbca2bc] 139 | ### Traceability and auditability requirements 140 | .Data to be kept for proof 141 | [cols="1,1,1"] 142 | |=== 143 | | Data Nature | Objective | Retention period 144 | 145 | | 146 | | 147 | | 148 | |=== 149 | 150 | [#d1f16239-18f7-4a4a-875e-34a587eb88b4] 151 | ## Security measures 152 | 153 | [#e60500e8-b4a3-471c-941c-8fd8c02c4da9] 154 | ### Integrity 155 | TIP: See also <<323d4c77-810a-4015-bc1a-11da07e24f3b,Integrity Requirements>>. 156 | 157 | 158 | .Measures to ensure the required level of integrity 159 | [cols="1,1,1"] 160 | |=== 161 | | Data class | Required level | Measures 162 | 163 | | 164 | | 165 | | 166 | |=== 167 | 168 | [#a64b5e5d-e4d4-4ed2-b425-19cd542fa58e] 169 | ### Confidentiality 170 | TIP: See also <>. 171 | 172 | .Measures to ensure the required level of confidentiality 173 | [cols="1,1,1"] 174 | |=== 175 | | _Data class_ | _Required level_ | _Measures_ 176 | 177 | | 178 | | 179 | | 180 | |=== 181 | 182 | [#3779a946-fc73-455b-8bab-3d5398ce0311] 183 | ### Identification 184 | TIP: See also <<94c138c1-3e8b-4eaf-8926-b5b9bfa6a86b,Identification Requirements>>. 185 | 186 | [#ac587042-7060-44cf-96aa-93fddadc15f5] 187 | ### Authentication 188 | TIP: See also <<9d0646cd-3e3f-4878-96de-f215c9f20bdc,Authentication Requirements>>. 189 | 190 | [#49de0015-9e27-4f60-91ca-282feec8345d] 191 | ### Identity Federation 192 | TIP: See also <>. 193 | 194 | [#1c4774ab-e6fc-46a4-bb89-97e318a8dd8f] 195 | ### SSO and SLO 196 | 197 | [#8e35ee35-b5bc-433b-8389-f07e62a05339] 198 | ### Service Accounts 199 | .Service accounts 200 | [cols='1,2,2'] 201 | |=== 202 | |Account | Resource requiring authentication | Credential storage method 203 | 204 | | 205 | | 206 | | 207 | |=== 208 | 209 | [#9f09dacf-d151-45af-a5f6-209823e7a401] 210 | ### Non-repudiation and Timestamping 211 | TIP: See also <<01404b83-f96f-4649-ace0-e5611601b830,Non-repudiation requirements>>. 212 | 213 | [#72efb92f-13f8-48e5-aed1-b57c4eab56fc] 214 | ### Anonymity and Privacy 215 | TIP: See also <<958fcccc-60cb-4158-940f-279cd1d12c9b,Anonymity and privacy requirements>>. 216 | 217 | [#e6d0ad26-40b7-412e-b861-1f8e6e2299ca] 218 | ### Authorization (Access Rights) 219 | TIP: See also <>. 220 | 221 | [#3819b8cc-d9c4-4d29-9ca1-adae300a79e2] 222 | ### Traceability and Auditability 223 | TIP: See also <>. 224 | 225 | [#5e00eeef-1d5b-4a21-ac19-116ae376d999] 226 | ### Cyberthreat Mitigation 227 | 228 | [#d13f2885-ab5c-4543-9432-f53002c01c2c] 229 | #### Prevention Solutions 230 | 231 | [#ac7dde83-27c9-4916-9020-73efaab5fcb1] 232 | #### Detection Solutions 233 | 234 | [#d4498522-32aa-4987-aaec-2d9cf01130da] 235 | #### Response Solutions 236 | 237 | [#a69b42f5-4f4e-42bf-b4bc-c6093941600f] 238 | #### Prediction Solutions 239 | 240 | [#d4d0f075-dff9-4d81-aebc-bbd0cc45bb55] 241 | ## Annexes 242 | 243 | [#b2f76b28-83da-478b-bc94-f1bc29dc6084] 244 | ### RACI & Security Governance 245 | This RACI clearly defines the roles and responsibilities of the teams with regard to **information security management**. 246 | 247 | :r: pass:quotes[[.green]#R#] 248 | :a: pass:quotes[[.red]#A#] 249 | :c: pass:quotes[[.blue]#C#] 250 | :i: pass:quotes[[.orange]#I#] 251 | :na: pass:quotes[[.grey]#N/A#] 252 | :et: pass:quotes[[.grey]#&#] 253 | 254 | 255 | * {r}: *Responsible* (executes the action). 256 | * {a}: *Accountable* (approves the action and is answerable to the organization). 257 | * {c}: *Consulted* (provides expertise and must be consulted). 258 | * {i}: *Informed* (must be notified after completion). 259 | 260 | [#7d8dff71-3acd-450b-bc68-d2e2efee2fbb] 261 | ### Vulnerability Self-Assessment 262 | .Vulnerability self-assessment checklist 263 | 264 | [cols="1,1,3"] 265 | |=== 266 | |Vulnerability 267 | |Addressed? 268 | |Technical measures implemented 269 | 270 | | 271 | | 272 | | 273 | |=== 274 | -------------------------------------------------------------------------------- /diagrams/roles.svg: -------------------------------------------------------------------------------- 1 | Classic authorization modelRoleFunctionGroupUsercontains0 .. *0 .. *contains0 .. *0 .. *owns0 .. *0 .. *has privilege on0 .. *0 .. *owns10 .. * -------------------------------------------------------------------------------- /README.adoc: -------------------------------------------------------------------------------- 1 | # Project architecture document template 2 | 3 | This architecture template is applicable to most management IT projects, regardless of the general architecture chosen (monolithic, SOA, microservices, n-tier, ...). 4 | It has already been used on several large projects in private or governmental organizations. It is maintained on a regular basis. 5 | 6 | Others languages : https://github.com/bflorat/modele-da[French]. 7 | 8 | ## Principles of the template 9 | We have divided the architecture into five views (application, security, sizing, infrastructure and development), each view being mostly self-supporting. 10 | 11 | The idea is to offer a set of *architecture views aligned with the roles that are most frequently found in organizations and their respective concerns*. 12 | For example, an infrastructure architect or a DevOps engineer rarely needs to know the details of the software architecture 13 | (the details of the frameworks used or how to handle errors). Likewise, a PO or a business architect will be interested in the macroscopic view of application modules and their main interactions ("batch B calls service S") but rarely by the underlying infrastructure details (choice of service database, machine sizing, etc.). 14 | 15 | image:blank-template/resources/views.png[read this first] 16 | 17 | A project documentation following this model will thus be constituted by : 18 | 19 | * an link:view-application.adoc[application view] presenting the general context and the application architecture; 20 | * a link:view-development.adoc[development view] presenting the software architecture and its environment; 21 | * a link:view-sizing.adoc[sizing view] presenting aspects related to the performance and sizing of the infrastructure; 22 | * an link:view-infrastructure.adoc[infrastructure view] presenting the servers, middleware, operations, etc.; 23 | * a link:view-security.adoc[security view]. 24 | 25 | Each section is divided according the following pattern : 26 | 27 | * *Constraints* (legal, budgetary, technological, normative, ...) applicable to the project; 28 | * *Non-functional requirements* (NFR) expressed by the project leaders within the limits of the constraints; 29 | * *Solution* (description of the chosen architecture responding to the NFR). 30 | 31 | The file also includes an example of a glossary which can be used as support for the https://martinfowler.com/bliki/UbiquitousLanguage.html[Ubiquitous Language], a fundamental element of your architecture. 32 | 33 | For more details, check out https://www.emerald.com/insight/content/doi/10.1108/ACI-12-2020-0159/full/html?utm_source=rss&utm_medium=feed&utm_campaign=rss_journalLatest[this paper] published on Applied Computing and Informatics. 34 | 35 | ## Using this template 36 | ### General presentation 37 | * This template is written using https://www.methods.co.nz/asciidoc/index.html[asciidoc]. You can convert it to the format of your choice even if we recommend a *textual and readable format* (Markdown type) easy to follow and to modify by merge requests in a version management tool. This helps to make your document a living documentation; 38 | * This model can be improved, which is why all feedback, (constructive) criticism, contributions and suggestions are appreciated (please make a https://github.com/bflorat/architecture-document-template/pulls[pull request] 39 | or create an https://github.com/bflorat/architecture-document-template/issues[issue]); 40 | * In addition, it is voluntarily *rich in explanations and examples* because it also has a (modest) learning claim aimed at students and young architects. 41 | * Text in italics contains examples; 42 | * Each chapter contains notes and tips to help fill it out; 43 | * If needed, you can reduce the size of this template using the https://document-template-customizer.florat.net/?base_template_url=https%3A%2F%2Fraw.githubusercontent.com%2Fbflorat%2Farchitecture-document-template%2Frefs%2Fheads%2Fmaster%2F[Document-Template-Customizer] tool. 44 | * link:blank-template[Blank templates] (without examples) are provided for your convenience. *It is strongly recommended to start with blank models while having the model with examples and explanations in front of you in another window*; 45 | * The provided `export` script along with the blank template files can be used to export your Asciidoc document into a PDF, HTML or ODT bundle so it can easily exported from a Github or Gitlab repository for instance. 46 | * It is highly recommended to specify, at the beginning of the `README.adoc` document, the precise version (Git hash) of this model you used for your architectural document (see the blank template : `Model version: `). This practice ensures awareness of any discrepancies that may arise with subsequent model versions. 47 | 48 | ### Advice on writing your architecture document 49 | * *Keep it short*, each word must make sense. No typical 'this is the introduction' useless explanation, no repetition of other documents, company history or vague concepts; 50 | * A reader should understand the operation and constraints of the application without being flooded with details. The *document must remain maintainable and up to date*; 51 | * If the application follows an architecture standardized by the organization, never repeat it *(https://en.wikipedia.org/wiki/Don%27t_repeat_yourself[DRY] principle*) and refer to a common document; 52 | * If a chapter is not applicable, do not leave it blank but simply mention `N/A` so the reader will know that the subject has been covered and `TODO` or `WIP` if it remains to be completed; 53 | * This model is intended to be *comprehensive enough to cover most management information system applications*. It can therefore normal that some chapters are not applicable in your context; 54 | * List the *architectural assumptions* and studies in progress in the chapter "Unresolved points" of each section (they must be exceptional, otherwise the document is written too early); 55 | * *Isolate in appendices* at the end of the document important architectural information but concerning specific points of interest only a few readers. 56 | 57 | ### What is * NOT * in this document? 58 | ** the *detailed design* of the project (UML diagrams of classes, sequences ...) except to present a general pattern specific to the application; 59 | ** *study elements* (SWOT, scenarios, etc.): the choices must have already been made (we nevertheless encourage providing https://adr.github.io/[ADRs] along with the architecture document); 60 | ** the *urbanization* of an entire Information System (IS). We are positioning ourselves here at the level of a single application or a set of coherent modules; 61 | ** the *reference architecture rules* (common to all application modules of the IS); 62 | ** technical details (IP, logins) that could compromise security; 63 | ** *physical architecture* (details of servers and datacenters, network architecture, storage architecture, provisioning, etc.). These are very specific subjects and are generally dealt with by infrastructure architects at an IS level; 64 | ** details of *environments* other than production (acceptance, development, etc.). These are generally too fluctuating to appear in this file and will benefit from being documented by the integrator instead in other files, wikis or CMDB tools. 65 | 66 | ## FAQ 67 | * **From what project size is this model eligible?** This model has been used successfully on a one-person project. It can be used for any size project. A large project will probably fill more sections but most relate to all projects. For example, questions of availability or internationalization are not related to the size of a project in our opinion. 68 | * **Can this model be used as a basis for an architecture repository?** Even if many ideas can be taken up, no, this is not the purpose of this model. 69 | * **Is this model suitable for a complete program?** For a complete program, we recommend a TOGAF-like approach with the associated deliverables. On the other hand, phases C and D can be documented by a DA within each project of this program. 70 | * **How ​​to document architecture trajectories?** We recommend describing the general trajectory (without going into too many details) in the "General Architecture" section of the application view and describing the architecture of future modules in the usual sections of the different panes but clearly specifying which step it is (for example, prefix the title of a module or a flow that only appears in step 2 with `[Step 2]`) . However, be careful to avoid too much documentary refactoring when this part of the project is implemented (broken links for example). 71 | ** Treat the elements described in the same sections as the elements to be implemented immediately in order to treat them according to the same logic as the rest. 72 | ** The more the element described is distant in time, the less its architecture must be detailed (it is a good agile principle of 'Just In Time' architecture which will avoid rewriting these sections many times). 73 | ** The closer the element described is to the physical architecture, the less it must be detailed. For example, it may be relevant to document in the application section the general architecture of modules that should be implemented in a year, but wait as long as possible to document their precise sizing in the sizing section. Similarly, you can document remote application flows, but wait before describing specific technical flows in the infrastructure section. 74 | 75 | ## Terminology 76 | 77 | TIP: Architecture documentation often uses several synonyms for the same concept interchangeably and possibly ambiguously. This architecture document uses (unless in error) consistent and coherent terminology. We have avoided ambiguous terms (such as '_service_') and use the most widely accepted terms in literature and operational contexts. 78 | 79 | - **Module**: A unit of code that groups related functionalities or services. We use this term to refer to APIs (which contain **endpoints**), batch processes or **batches** (which contain **jobs**), and GUIs (graphical interfaces). 80 | 81 | - **Application**: In a monolithic architecture, a complete single-tenant application. In a microservices architecture, a logical set of modules. 82 | 83 | - **Infrastructure Component**: Third-party executable or equipment providing infrastructure services such as persistence for a database, messaging for queues, load balancing for a load balancer, malware detection for an antivirus API, etc. Should not be confused with a 'component', which describes a software subpart of a module or a monolithic application (and is rarely documented in this document as it is too close to the implementation). 84 | 85 | - **Deployable Unit**: A self-contained package/artifact (zip, war, jar, gem, .deb, OCI/Docker image, binary, etc.) that contains the executables of a module (e.g., 'jar' of a Spring Boot application, archive of a PHP or JS application) or an infrastructure component (e.g., 'deb' for installing a PostgreSQL database). 86 | 87 | 88 | ## License 89 | * Copyright (c) 2017-2025 Bertrand Florat and contributors 90 | * This template is licensed under https://creativecommons.org/licenses/by-sa/4.0/[CC-BY-SA 4.0] : Creative Commons Attribution - Share Alike V4.0 91 | * You can create your *own template* as long as it retains the CC BY-SA 4.0 license and therefore contains these three elements: 92 | ** The name of the creator (Bertrand Florat); 93 | ** A link to https://creativecommons.org/licenses/by-sa/4.0/; 94 | ** A disclaimer and a link to https://github.com/bflorat/architecture-document-template. 95 | * The architecture *documents resulting from this template do not have to apply this license*. It is nevertheless recommended to include a link to https://github.com/bflorat/architecture-document-template[this page]. 96 | 97 | ## Thanks 98 | * https://github.com/bflorat/architecture-document-template/graphs/contributors[Contributors] 99 | * Proofreading: Dr. Christophe Gaie 100 | * Feedback: Antoine Parra Del Pozo, Pascal Bousquet, Philippe Mayjonade, Nicolas Chahwekilian, Steven Morvan 101 | * All diagrams of this model were generated with the excellent tool http://plantuml.com/[PlantUML]. The https://c4model.com/[C4 diagrams] use the https://github.com/plantuml-stdlib/C4-PlantUML[C4 Plantuml customization]. 102 | * Lise Florat for helping with the translation into English. 103 | 104 | ## Partial bibliography 105 | * _Site Reliability Engineering_ - Google 106 | * _Living documentation_ - Cyril Martraire 107 | * _Clean Code_ - Robert Martin 108 | * _Performance des architectures IT - 2e ed._ - Pascal Grojean 109 | * _Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides_ (GOF) 110 | * _Le projet d’Urbanisation du SI_ - Christophe Longépé 111 | * _Sécurité de la dématérialisation_ - Dimitri Mouton 112 | 113 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | Creative Commons Attribution-ShareAlike 4.0 International Public License 2 | 3 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 4 | 5 | Section 1 – Definitions. 6 | 7 | Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 8 | Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 9 | BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License. 10 | Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 11 | Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 12 | Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 13 | License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. 14 | Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 15 | Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 16 | Licensor means the individual(s) or entity(ies) granting rights under this Public License. 17 | Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 18 | Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 19 | You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 20 | 21 | Section 2 – Scope. 22 | 23 | License grant. 24 | Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 25 | reproduce and Share the Licensed Material, in whole or in part; and 26 | produce, reproduce, and Share Adapted Material. 27 | Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 28 | Term. The term of this Public License is specified in Section 6(a). 29 | Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 30 | Downstream recipients. 31 | Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 32 | Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply. 33 | No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 34 | No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 35 | 36 | Other rights. 37 | Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 38 | Patent and trademark rights are not licensed under this Public License. 39 | To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 40 | 41 | Section 3 – License Conditions. 42 | 43 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 44 | 45 | Attribution. 46 | 47 | If You Share the Licensed Material (including in modified form), You must: 48 | retain the following if it is supplied by the Licensor with the Licensed Material: 49 | identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 50 | a copyright notice; 51 | a notice that refers to this Public License; 52 | a notice that refers to the disclaimer of warranties; 53 | a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 54 | indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 55 | indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 56 | You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 57 | If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 58 | ShareAlike. 59 | 60 | In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. 61 | The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. 62 | You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. 63 | You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. 64 | 65 | Section 4 – Sui Generis Database Rights. 66 | 67 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 68 | 69 | for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 70 | if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and 71 | You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 72 | 73 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 74 | 75 | Section 5 – Disclaimer of Warranties and Limitation of Liability. 76 | 77 | Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. 78 | To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. 79 | 80 | The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 81 | 82 | Section 6 – Term and Termination. 83 | 84 | This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 85 | 86 | Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 87 | automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 88 | upon express reinstatement by the Licensor. 89 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 90 | For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 91 | Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 92 | 93 | Section 7 – Other Terms and Conditions. 94 | 95 | The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 96 | Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 97 | 98 | Section 8 – Interpretation. 99 | 100 | For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 101 | To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 102 | No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 103 | Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. 104 | -------------------------------------------------------------------------------- /diagrams/general-application-design.svg: -------------------------------------------------------------------------------- 1 | System context diagramGeneral application point of viewof the AllMyData projectAdministration BInformation System[system]Accounting systemAllMyData Allows companies to recovertheir dataREF_ENTREPRISE Person repositoryComposition system Transactional editingCompany [Person][1] Request via form[2.1] Enrichment withinternal data[2.2] Retrievingaccounting information[3] PDF creationLegend personsystemexternal personexternal system -------------------------------------------------------------------------------- /view-sizing.adoc: -------------------------------------------------------------------------------- 1 | # Sizing view 2 | :sectnumlevels: 4 3 | :toclevels: 4 4 | :sectnums: 4 5 | :toc: left 6 | :icons: font 7 | :toc-title: Table of contents 8 | 9 | *Last modified* : {docdate} 10 | 11 | *Last global review* : __ 12 | 13 | *Document status* : _<'WIP', 'DRAFT', ...>_ 14 | 15 | //🏷{"id": "32c8942e-443f-429d-a411-43869a720224", "labels": ["context"]} 16 | ## Introduction 17 | 18 | This is the sizing point of view of the project. It determines the hardware required by the project. 19 | 20 | The other views of the document are accessible link:./README.adoc[from here]. 21 | 22 | The project glossary is available link:glossary.adoc[here]. We will not redefine the functional or technical terms used here. 23 | 24 | 25 | //🏷{"id": "c443e562-398d-49ab-92bd-8031f3e91bec", "labels": ["context","references"]} 26 | ### Reference Documentation 27 | 28 | [PRE-FILLED] 29 | ==== 30 | [cols="1,1,4,4"] 31 | |=== 32 | | N ° | Version | Document title / URL | Detail 33 | | 34 | | 35 | | 36 | | 37 | 38 | |=== 39 | ==== 40 | 41 | //🏷{"id": "1ef7beb9-71ee-43e5-9a1b-c45a48959084", "labels": []} 42 | ## Not ruled 43 | 44 | //🏷{"id": "c5db3e60-e70c-4ebb-9848-44a0cecc4c6e", "labels": []} 45 | ### Points subject to further study 46 | 47 | ==== 48 | Example: 49 | 50 | [cols="1e,1e,1e,2e,2e"] 51 | |=== 52 | | ID | Detail | Status | Subject holder | Deadline 53 | 54 | | 1 | SSD disk capacity | WIP | XYZ | 01/01/2022 55 | 56 | |=== 57 | ==== 58 | 59 | [PRE-FILLED] 60 | ==== 61 | [cols="1,5,2,2,2"] 62 | |=== 63 | | ID | Detail | Status | Subject holder | Deadline 64 | 65 | | 66 | | 67 | | 68 | | 69 | | 70 | 71 | |=== 72 | ==== 73 | 74 | //🏷{"id": "577c9b37-77a2-4568-9fb5-2804d6f9bc70", "labels": []} 75 | ### Assumptions 76 | 77 | [TIP] 78 | ==== 79 | Give here the structuring assumptions taken for the design. 80 | 81 | Example: 82 | 83 | .Assumptions 84 | [cols="1e,6e"] 85 | |=== 86 | | ID | Detail 87 | 88 | | 1 | We estimate that 10M people will download our app and use it at least once a day 89 | 90 | |=== 91 | 92 | ==== 93 | 94 | [PRE-FILLED] 95 | ==== 96 | [cols="1,6"] 97 | |=== 98 | | ID | Detail 99 | | 100 | | 101 | |=== 102 | ==== 103 | 104 | //🏷{"id": "69811b17-b947-4562-90ba-a97160421965", "labels": ["detail_level::overview", "constraint"]} 105 | ## Constraints 106 | 107 | [TIP] 108 | ==== 109 | Constraints are the limits applicable to the requirements on the project. 110 | 111 | It is interesting to explain them in order to obtain realistic requirements. For example, it would not be realistic to require response times from a web service incompatible with the bandwidth of the underlying network. 112 | 113 | ==== 114 | 115 | 116 | //🏷{"id": "646fc728-6cef-4e75-9fa9-646b4ec2159d", "labels": []} 117 | ### Storage constraints 118 | 119 | TIP: List here the possible constraints related to the disks 120 | 121 | [Example] 122 | ==== 123 | Example: The maximum disk space that can be allocated to a VM is 2 TiB. 124 | ==== 125 | 126 | //🏷{"id": "1d3ec06e-d63d-4a61-bb4e-437358064687", "labels": ["level::intermediate", "detail_level::detailed"]} 127 | ### CPU constraints 128 | 129 | TIP: List here the possible constraints related to the computing power 130 | [Example] 131 | ==== 132 | Example 1: A VM will have a maximum of 10 VCPUs 133 | ==== 134 | 135 | ==== 136 | Example 2: All the pods of the application should not require more than 1 CPU per node. 137 | ==== 138 | 139 | //🏷{"id": "ec6a420b-c284-442a-93fd-edc3d45ed00a", "labels": ["level::intermediate", "detail_level::detailed"]} 140 | ### Memory constraints 141 | 142 | TIP: List here the possible constraints related to memory 143 | [Example] 144 | ==== 145 | Example: a pod or a Kubernetes job should not use more than 6 GiB of RAM 146 | ==== 147 | 148 | //🏷{"id": "8d948872-15f9-49b6-9527-f511a2f7597d", "labels": []} 149 | ### Network constraints 150 | 151 | TIP: List here the possible network volume constraints used 152 | [Example] 153 | ==== 154 | Example 1: The minimum latency for requests on the WAN between London and Tokyo is 250 ms 155 | ==== 156 | 157 | [Example] 158 | ==== 159 | Example 2: The Ethernet network of the Datacenter has a bandwidth of 40 Gbps. 160 | ==== 161 | 162 | //🏷{"id": "d6e3eb12-371b-4c26-b538-9fea2051bfed", "labels": ["detail_level::overview", "requirement"]} 163 | ## Requirements 164 | 165 | [TIP] 166 | ==== 167 | It is crucial to collect as much information as possible from production rather than making estimations which often turn out to be far from reality. However, this may not always be possible for new projects. The architects should size the application with a significant margin. The information given here can be used as input to the SLO (Service Level Objective set by the operators). 168 | ==== 169 | 170 | [TIP] 171 | ==== 172 | The following sections dealing with static and dynamic sizing calculations give examples of calculations and elements to consider. Formally, it may be better to use a spreadsheet. For a complex project or one where assumptions may often change, this is essential. 173 | 174 | ==== 175 | 176 | //🏷{"id": "962347a4-c3c8-4f0c-bcac-774a6ef617a4", "labels": []} 177 | ### Static sizing 178 | 179 | TIP: These are the metrics used to determine the *cumulative* storage volume of the project. Remember to clearly specify the assumptions made for the estimated metrics. It will thus be possible to review them if new business elements appear. 180 | 181 | //🏷{"id": "1736e661-2c68-4aa6-a157-9e4444d5a374", "labels": ["detail_level::detailed"]} 182 | #### Metrics 183 | 184 | [TIP] 185 | ==== 186 | These are measured or estimated business data that will be used as inputs to the calculation of required storage. 187 | 188 | [cols="e,e,e,e,e,e,e"] 189 | |=== 190 | | Metric | Description | Measured or Estimated? | Value | Forecast annual increase (%) | Source | Detail/assumptions 191 | 192 | | S1 | Number of eligible companies | Estimated | 4M | + 1% | Government [reference] | We consider that AllMyData is applicable only for companies with more than 10 employees 193 | | S2 | Average size of a PDF | Measured | 40KiB | 0% | Operators | 194 | |=== 195 | ==== 196 | 197 | [PRE-FILLED] 198 | ==== 199 | [cols="1,1,1,1,1,1,1"] 200 | |=== 201 | | Metric | Description | Measured or Estimated? | Value | Forecast annual increase (%) | Source | Detail/assumptions 202 | 203 | | 204 | | 205 | | 206 | | 207 | | 208 | | 209 | | 210 | |=== 211 | ==== 212 | 213 | //🏷{"id": "9968c2e6-46b9-4005-89d4-6a9114246a4c", "labels": ["detail_level::detailed"]} 214 | #### Estimated storage needs 215 | 216 | [TIP] 217 | ==== 218 | List here the storage needs of each module or infrastructure component (especially databases) once the application has reached full load (volume at two years for example). 219 | 220 | Take into account: 221 | 222 | * The size of the databases. 223 | * The size of the files produced. 224 | * The size of the queues. 225 | * The size of the logs. 226 | * ... 227 | 228 | Does not take into account: 229 | 230 | * The volume linked to the backup: it is managed by the operators. 231 | * The volume of binaries (OS, middleware ...) managed by the operators. 232 | * Archived data which is therefore no longer online. 233 | 234 | Also provide an estimate of the annual % increase in volume to allow operators to order or reserve enough disk. 235 | 236 | For the sizing calculations, remember to take into account the specificities of the encoding (number of octets by character, by date, by numerical value ...). 237 | 238 | For a database, plan the space occupied by the indexes, which is very specific to each application. A (very poor) preliminary estimate is to double the disk space (to be refined later). 239 | 240 | Only estimate data whose size is not negligible (several GiB minimum). 241 | 242 | [cols="e,e,e,e,e,e"] 243 | |=== 244 | | Data | Description | Unit size | Number of items at 2 years | Total size | Annual increase 245 | 246 | | Table Article 247 | | Catalog items 248 | | 2 KiB 249 | | 100K 250 | | 200 MiB 251 | | 5% 252 | 253 | | Command Table 254 | | Customer orders 255 | | 10 KiB 256 | | 3M 257 | | 26.6 GiB 258 | | 10% 259 | 260 | | Logs 261 | | Application logs (INFO level) 262 | | 200 B 263 | | 300M 264 | | 56 GiB 265 | | 0% (archiving) 266 | |=== 267 | ==== 268 | 269 | [PRE-FILLED] 270 | ==== 271 | 272 | [cols="1,1,1,1,1,1"] 273 | |=== 274 | | Data | Description | Unit size | Number of items at 2 years | Total size | Annual increase 275 | 276 | | 277 | | 278 | | 279 | | 280 | | 281 | | 282 | |=== 283 | ==== 284 | 285 | //🏷{"id": "b22cadba-e5a7-4c3a-b4b8-f9ea32a2a0be", "labels": []} 286 | ### Dynamic sizing 287 | 288 | TIP: These are metrics by duration (year, month, hour, ...) and allowing to determine the load applied to the architecture, which will help to size the systems in terms of CPU, bandwidth and performance of disks. 289 | 290 | //🏷{"id": "910fc171-30ed-47cd-b03c-3ca918b3103e", "labels": ["detail_level::detailed"]} 291 | #### Metrics 292 | [TIP] 293 | ==== 294 | These are the measured or estimated business data that will be used as inputs for the calculation. 295 | 296 | [cols="e,e,e,e,e,e,e,e"] 297 | |=== 298 | | Metric | Description | Measured or Estimated? | Value | Forecast annual increase (%) | Seasonality | Source | Detail/assumptions 299 | 300 | | D1 | Proportion of users connecting to the service / J | Estimated | 1% | + 5% 301 | a| 302 | - Constant over the year 303 | - Constant over the week 304 | - 3 peaks at 20% of the day at 8:00am-9:00am, 11:00am-12:00am and 02:00pm-03:00pm 305 | | | Users use the application during standard office hours 306 | |=== 307 | ==== 308 | 309 | [PRE-FILLED] 310 | ==== 311 | [cols="1,1,1,1,1,1,1,1"] 312 | |=== 313 | | Metric | Description | Measured or Estimated? | Value | Forecast annual increase (%) | Seasonality | Source | Detail/assumptions 314 | 315 | | 316 | | 317 | | 318 | | 319 | | 320 | | 321 | | 322 | | 323 | |=== 324 | ==== 325 | 326 | //🏷{"id": "3d09511c-17b2-43c3-bcba-0a62ead057b4", "labels": ["detail_level::detailed"]} 327 | #### Estimated load 328 | 329 | [TIP] 330 | ==== 331 | This involves estimating the number of calls to modules and therefore the target throughput (in TPS = Transactions per second) that each of them will have to absorb. A well-sized system should have *average response times of the same order at nominal load and peak*. 332 | 333 | Always estimate the *"peak of the peak"*, i.e., the moment when the load will be maximum following the accumulation of all the factors (for example for an accounting system: between 02 pm and 03 pm on a weekday at the end of December). 334 | 335 | Do not consider that the load is constant but take into account: 336 | 337 | * Daily variations. For a management application with users working during office hours, we typically observe peaks of double the average load at 8-9 a.m., 11-12 a.m. and 2 p.m.-3 p.m. For a consumer Internet application, it will be more at the end of the evening. Again, rely on measurements of similar applications when possible, rather than estimates. 338 | * The elements of seasonality like Christmas for the chocolate industry, Saturday evening for emergency admissions, June for central booking stays etc. The load can then double or even more. This estimate should therefore not be neglected. 339 | 340 | If the calculation of the peak for a module at the end of the linking chain is complex (for example, a central IS service exposing referential data and called by many modules which each have their own peak), cut the day into time intervals sufficiently small (one hour for example) and the measured or estimated sum of the calls of each caller (batch or GUI) will be calculated over each interval to thus determine the highest cumulative demand. 341 | 342 | If the application runs on a PaaS type cloud, the load will be absorbed dynamically, but take care to *estimate the additional cost* and to set consistent consumption limits to respect the budget while ensuring a good level of service. 343 | ==== 344 | 345 | .Example: dynamic volumetric estimation of the REST endpoint `GET Detail` of the AllMyData application 346 | |=== 347 | | Maximum rate of users connected at the same time in annual peak | S1 x F1 x 0.2 = 8K / H 348 | | Average duration of a user session 349 | | 15 mins 350 | | Average number of service calls per session 351 | | 10 352 | | Charge (Transaction / second) 353 | | 8K / 4 x 10/3600 = 5.5 Tps 354 | |=== 355 | 356 | 357 | [TIP] 358 | ==== 359 | For an infrastructure component (such as a database instance) at the end of the linking chain and requested by many services, it is necessary to estimate the number of requests at peak by cumulating the calls from all the clients and to *specify the read/write ratio* when this information is relevant (it is especially important for a database). 360 | 361 | The level of detail of the estimate depends on the progress of the application design and the reliability of the assumptions. 362 | 363 | In the example below, we already have an idea of ​​the number of requests for each operation. In other cases, we will have to be satisfied with a very broad estimate of the total number of requests to the database and a read/write ratio based on measures from similar applications. No need to go into more detail at this point. 364 | 365 | Finally, keep in mind that this is *simply an estimation* yet to be validated during campaigns performance and then in production. Plan a sizing adjustment shortly after the production. 366 | ==== 367 | 368 | ==== 369 | Example: the Oracle BD01 database is used for reading by the REST endpoint `GET DetailArticle` made from the end-user application and for updating by the POST and PUT calls on `DetailArticle` endpoint from the supply batch B03 at night between 01:00 and 02:00. 370 | 371 | .Example estimates number of peak SQL queries to instance BD01 from 01:00 to 02:00 in December 372 | |=== 373 | | Maximum rate of users logged in at the same time | 0.5% 374 | | Maximum number of concurrent connected users 375 | | 5K 376 | | Average duration of a user session 377 | | 15 mins 378 | | Average number of calls to the `GET DetailArticle` endpoint per session 379 | | 10 380 | | User charge GET DetailArticle (Transaction / second) 381 | | (10/15) x 5K / 60 = 55 Tps 382 | | Number of read and write requests per endpoint call 383 | | 2 and 0 384 | | Number of daily calls to the `POST DetailArticle` endpoint from batch B03 385 | | 4K 386 | | Number of INSERT and SELECT requests per endpoint call 387 | | 3 and 2 388 | | Daily number of items modified by batch B03 389 | | 10K 390 | | Number of SELECT and UPDATE queries 391 | | 1 and 3 392 | | Number of SELECT / sec 393 | | 55x2 + 2 x 4K / 3600 + 1 x 10K / 3600 = 115 Tps 394 | | Number of INSERT / sec 395 | | 0 + 3 x 4K / 3600 = 3.4 Tps 396 | | Number of UPDATE / sec 397 | | 0 + 3 x 10K / 3600 = 8.3 Tps 398 | |=== 399 | ==== 400 | 401 | //🏷{"id": "c1a8f666-70e1-4acf-9d7a-5e1b06ecb588", "labels": []} 402 | ### Response time requirements 403 | 404 | //🏷{"id": "24f70acd-5f7c-49b3-bd75-d594e5af8917", "labels": ["detail_level::detailed", "gui"]} 405 | #### Response time of GUIs 406 | 407 | [TIP] 408 | ==== 409 | If the clients access the system via WAN (Internet, VPN, LS, etc.), specify that the *response time requirements are given outside network transit* because it is impossible to commit to the latency and throughput of this type of client. 410 | 411 | In the case of LAN access, it is preferable to integrate the network time, as the load testing tools will already take this into account. 412 | 413 | The response time objectives are always given with a *statistical tolerance* (90th percentile for example) because reality shows that it is very fluctuating being affected by a large number of factors. 414 | 415 | No need to multiply the types of requests (depending on the complexity of the screen, for example) because this type of criterion no longer makes much sense today, particularly for a SPA application). 416 | 417 | Example of types of solicitation: 418 | [cols = '3e, 1e, 1e, 1e'] 419 | |=== 420 | | Type of request | Good level | Medium level | Insufficient level 421 | 422 | | Loading a page 423 | | <0.5 s 424 | | <1 s 425 | |> 2 s 426 | 427 | | Business operation 428 | | <2 s 429 | | <4 s 430 | |> 6 s 431 | 432 | | Editing, Export, Generation 433 | | <3 s 434 | | <6 s 435 | |> 15 s 436 | |=== 437 | 438 | Example of acceptability of response times: 439 | 440 | The level of compliance with response time requirements is good if: 441 | 442 | * At least 90% of response times are good. 443 | * At most 2% of response times are insufficient. 444 | 445 | Acceptable if: 446 | 447 | * At least 80% of response times are good. 448 | * At most 5% of response times are insufficient. 449 | 450 | Apart from these values, the application must be optimized and go back to acceptance and then be subjected to load tests again. 451 | ==== 452 | 453 | [PRE-FILLED] 454 | ==== 455 | [cols = '3, 1, 1, 1'] 456 | |=== 457 | | Type of request | Good level | Medium level | Insufficient level 458 | 459 | | 460 | | 461 | | 462 | | 463 | |=== 464 | 465 | ==== 466 | 467 | //🏷{"id": "88645b89-d407-4107-93b2-48003fd8688a", "labels": ["detail_level::detailed", "batch"]} 468 | #### Duration of batch execution 469 | 470 | [TIP] 471 | ==== 472 | Specify here in what time interval the batch processes should run. 473 | ==== 474 | ==== 475 | Example 1: The end of the execution of the batches being a prerequisite for the opening of the service to end-users, these first must imperatively end before the end of the batch range defined above. 476 | ==== 477 | 478 | ==== 479 | Example 2: the monthly account consolidation batch B1 must be executed in less than 4 days. 480 | ==== 481 | 482 | ==== 483 | Example 3: the batches and the GUI can operate in competition, there is no strict constraint on the execution time of the batches but to ensure an optimization of the hardware infrastructure, we will favor the night during which the GUI requests are less numerous. 484 | ==== 485 | 486 | 487 | //🏷{"id": "fb740b6a-bd23-4401-a7e0-b01610a01b9b","labels": ["solution"]} 488 | ## Target sizing 489 | 490 | [TIP] 491 | ==== 492 | We give a final sizing to support the static and dynamic sizing and meet the requirements. 493 | ==== 494 | 495 | //🏷{"id": "63214041-3461-4019-a685-fac68fdb4d74", "labels": ["detail_level::detailed"]} 496 | ### Estimate of resource requirements by deployable unit 497 | 498 | [TIP] 499 | ==== 500 | Give here RAM, disk and CPU per deployable unit (to be refined after performance campaign or MEP). 501 | 502 | Example: 503 | 504 | [cols="2e,1e,1e,3e,2e"] 505 | |=== 506 | | Deployable unit | (V)CPU requirement per instance | Memory requirement per instance (MiB) | Periods of activity | Comments 507 | 508 | | `tomcat-batchs1` 509 | | 510 | | 1024 511 | | Every hour, 24/7/365 512 | | The application server remains started even outside the execution of jobs 513 | 514 | | `spa` 515 | | 516 | | 50 517 | | 24/6, main activity 8am-5pm GMT Mon-Fri 518 | | SPA Web App, runs in the browser 519 | 520 | | `bdd-postgresql` 521 | | 2 522 | | 2024 523 | | 24/7, main activity 8am-5pm GMT Mon-Fri 524 | | Postgresql instance 525 | |=== 526 | ==== 527 | 528 | [PRE-FILLED] 529 | ==== 530 | [cols="2,1,1,3,2"] 531 | |=== 532 | | Deployable unit | (V)CPU requirement per instance | Memory requirement per instance (MiB) | Periods of activity | Comments 533 | 534 | | 535 | | 536 | | 537 | | 538 | | 539 | |=== 540 | ==== 541 | 542 | //🏷{"id": "6e9675d7-5d8c-4cf8-989a-13640cd28ef3", "labels": []} 543 | ### Sizing of machines 544 | 545 | [TIP] 546 | ==== 547 | 548 | This section provides the final sizing of the machines required. 549 | 550 | * For Virtual Machines, be careful to check that a VCPU = 1 physical core (and not a thread if hyperthreading is enabled) 551 | * The internal disk concerns the disk necessary for the OS and the binaries. For a physical machine, this is local storage (local SDD, NMVe or HDD disks). For a VM, it can be a local disk on the physical machine running the VM or a SAN. 552 | * The external disk concerns storage on a disk bay (SAN). 553 | 554 | .Sizing of machines (example) 555 | [cols = '1e, 3e, 1e, 1e, 1e, 1e, 1e'] 556 | |=== 557 | | Zone | Machine type | Number of machines | Number of (V)CPU | Memory (GiB) | Internal disk (GiB) | External SAN disk (GiB) 558 | 559 | | Zone 1 560 | | VM application server 561 | | 3 562 | | 2 563 | | 4 564 | | 100 565 | | 0 566 | 567 | | Zone 2 568 | | Physical machine Database 569 | | 1 570 | | 2 571 | | 6 572 | | 50 573 | | 1024 (SAN) 574 | 575 | |=== 576 | 577 | ==== 578 | [PRE-FILLED] 579 | ==== 580 | [cols = '1, 3, 1, 1, 1, 1, 1'] 581 | |=== 582 | | Zone | Machine type | Number of machines | Number of (V)CPU | Memory (GiB) | Internal disk (GiB) | External SAN disk (GiB) 583 | 584 | | 585 | | 586 | | 587 | | 588 | | 589 | | 590 | | 591 | 592 | |=== 593 | ==== 594 | 595 | //🏷{"id": "e30801f9-af5b-49f3-bdca-214aae776336", "labels": ["niveau_detail::détaillé"]} 596 | ### Non-SAN external storage 597 | 598 | [TIP] 599 | ==== 600 | 601 | Others external storage deals with distributed file system (NFS, CIFS, WebDav ...) or object storage (Ceph, Swift, Scality, S3, ...) 602 | 603 | Example: 604 | 605 | [cols='1e,3e,3e'] 606 | |=== 607 | |Nature |Size (Gio) |Type(s) of machine using this share 608 | 609 | |NFS (NAS mount) 610 | |248 611 | |Physical machine Database 612 | 613 | |OpenStack Object Storage ("Ceph") 614 | |2000 615 | |VM application server 616 | 617 | |=== 618 | ==== 619 | 620 | [PRE-FILLED] 621 | ==== 622 | [cols='1,3,3'] 623 | |=== 624 | |Nature |Size (Gio) |Type(s) of machine using this share 625 | 626 | | 627 | | 628 | | 629 | |=== 630 | ==== -------------------------------------------------------------------------------- /view-application.adoc: -------------------------------------------------------------------------------- 1 | # Application view 2 | :sectnumlevels: 4 3 | :toclevels: 4 4 | :sectnums: 4 5 | :toc: left 6 | :icons: font 7 | :toc-title: Table of contents 8 | 9 | *Last modified* : {docdate} 10 | 11 | *Last global review* : __ 12 | 13 | *Document status* : _<'WIP', 'DRAFT', ...>_ 14 | 15 | //🏷{"id": "74c82505-5f47-4342-8f1b-f6951d603062", "labels": ["context"]} 16 | ## Introduction 17 | 18 | This is the application point of view of the project. It describes the application modules in play and their exchanges. 19 | 20 | The other views of the document are accessible link:./README.adoc[from here]. 21 | 22 | The project glossary is available link:glossary.adoc[here]. We will not redefine the functional or technical terms used here. 23 | 24 | //🏷{"id": "c182158d-40af-4840-b8f2-3a2a030c95af", "labels": ["references"]} 25 | ### Reference Documentation 26 | 27 | Mention here the reference (defined at a IS level) architecture documents. This file should never summarize their content under penalty of quickly becoming obsolete and unmaintainable. 28 | 29 | [PRE-FILLED] 30 | ==== 31 | [cols="1,1,4,4"] 32 | |=== 33 | | N ° | Version | Document title / URL | Detail 34 | | 35 | | 36 | | 37 | | 38 | 39 | |=== 40 | ==== 41 | 42 | //🏷{"id": "946b3119-a878-47ca-86f2-4c9e22ef0c89", "labels": ["uncertainty"]} 43 | ## Not ruled 44 | 45 | //🏷{"id": "af23d422-402c-49be-900f-2f55a5619615", "labels": ["uncertainty"]} 46 | ### Points subject to further study 47 | 48 | ==== 49 | Example: 50 | 51 | [cols="1e,6e,1e,1e,1e"] 52 | |=== 53 | | Subject | Detail | Status | Subject bearer | Deadline 54 | 55 | | Use of Y services 56 | | Depending on the progress of project Y, this module could call the services of the latter or those of the former module Z 57 | | PENDING 58 | | Project Y team 59 | | BEFORE 2040 60 | |=== 61 | ==== 62 | 63 | [PRE-FILLED] 64 | ==== 65 | [cols="1,6,1,1,1"] 66 | |=== 67 | | Subject | Detail | Status | Subject bearer | Deadline 68 | 69 | | 70 | | 71 | | 72 | | 73 | | 74 | |=== 75 | ==== 76 | 77 | //🏷{"id": "60a52e4c-4416-429a-a739-37153b05133c", "labels": ["uncertainty"]} 78 | ### Assumptions 79 | 80 | [TIP] 81 | ==== 82 | Give here the structuring assumptions taken for the design. 83 | 84 | Example: 85 | [cols="1e,6e"] 86 | |=== 87 | | ID | Detail 88 | 89 | | HA1 90 | | Even if the decision to generalize the centralized directory is not fully endorsed, the application will rely on it and not on a local directory. 91 | |=== 92 | ==== 93 | 94 | [PRE-FILLED] 95 | ==== 96 | [cols="1,6"] 97 | |=== 98 | | ID | Detail 99 | 100 | | 101 | | 102 | |=== 103 | ==== 104 | //🏷{"id": "382fd086-f48e-4ad5-9911-07e3de281971", "labels": ["detail_level::overview"]} 105 | ## General context 106 | 107 | //🏷{"id": "ba1f44fe-c47a-4d34-bfdb-07e777e23dda", "labels": []} 108 | ### Objectives 109 | 110 | [TIP] 111 | Briefly describe the project and recall its objectives. Highlight those which are structuring for the architecture. 112 | 113 | ==== 114 | Example 1: This application allows suppliers invoices digitization and easy consultation of these documents by the accounting services. 115 | ==== 116 | ==== 117 | Example 2: This project is the rewrite in web technologies of the X legacy application. It should ease the maintenance. 118 | ==== 119 | ==== 120 | Example 3: The X application is one of the main modules of the Y program. It leverages the person and billing repositories to enrich the CMS with real-time customer data. 121 | ==== 122 | 123 | //🏷{"id": "bbb1f617-3ceb-4f80-a3c4-dbc9b16bcd00", "labels": ["rewrite"]} 124 | ### Existing 125 | 126 | [TIP] 127 | If this document presents a redesign or migration project, describe briefly the existing application. Do not repeat the documentation, simply refer to it and point to its architecture document if available. Beware of mentioning any information with a strong impact on the new project. 128 | ==== 129 | Example 1: The GOLD application is a Client-Server application in FORMS 4 pointing to an Oracle 9i database. Its architecture document is given in [REFxyz]. 130 | ==== 131 | ==== 132 | Example 2: The existing application is based on an LDAP directory for its authorizations. The new project has to coexist temporary with the former one. Thus, it is important to manage concurrent accesses as well as the coherence of LDAP during the tiling period. 133 | ==== 134 | 135 | //🏷{"id": "67bbae56-5ed3-4977-8467-2c951882d1a9", "labels": ["project_size::large"]} 136 | ### Positioning in the IS 137 | 138 | [TIP] 139 | If the IS is urbanized, identify the block concerned by the project. 140 | 141 | //🏷{"id": "9ca40d05-ab6e-42ab-aa3c-b9724373ae7f", "labels": []} 142 | ### Actors 143 | 144 | #### Internal actors 145 | 146 | [TIP] 147 | ==== 148 | By the term "internal", the IT team project refers to actors belonging to the organization. These actors can be humans or application modules. 149 | 150 | Example: 151 | 152 | |=== 153 | | Actor | Description | Population | Location 154 | 155 | | Administration system B 156 | | Provides company accounting data 157 | | N/A 158 | | Berlin site 159 | 160 | | Agent 161 | | Back-office agent 162 | | 100 163 | | London site 164 | 165 | |=== 166 | 167 | ==== 168 | 169 | [PRE-FILLED] 170 | ==== 171 | [cols="1,1,4,4"] 172 | |=== 173 | | Actor | Description | Population | Location 174 | 175 | | 176 | | 177 | | 178 | | 179 | 180 | |=== 181 | ==== 182 | 183 | #### External actors 184 | 185 | ==== 186 | Example: 187 | [cols="e,e,e,e"] 188 | |=== 189 | | Actor | Description | Population | Location 190 | 191 | | Web client 192 | | A company from a PC 193 | | Max 1M 194 | | 10 calls to the GUI per session, one session per day and per actor 195 | | Mobile client 196 | | A company from a mobile 197 | | Max 2M 198 | | Worldwide 199 | |=== 200 | ==== 201 | 202 | [PRE-FILLED] 203 | ==== 204 | [cols="1,1,1,1"] 205 | |=== 206 | | Actor | Description | Population | Location 207 | 208 | | 209 | | 210 | | 211 | | 212 | 213 | |=== 214 | ==== 215 | 216 | 217 | //🏷{"id": "deafbeef-dead-4bed-8ace-0b0b0b0b0b0b", "labels": []} 218 | #### Nature and Sensitivity of Data and Processing 219 | 220 | Provide a summary of the business processes and the types of data they handle to support solution design. 221 | 222 | WARNING: Do not reproduce the DPIA (Data Protection Impact Assessment) here, but reference it if it exists. 223 | 224 | ==== 225 | Example: 226 | 227 | [%header,cols="2e,3e,3e,2e,1e,1e,1e,1e"] 228 | |=== 229 | | Business Process | Purpose | Categories of Data Processed | Internal Classification | C | I | A | T 230 | 231 | | _Ex. Issuance of certificate_ | _Produce an official record_ | _identity, civil status, technical logs_ | _High_ | _Restricted distribution_ | _High_ | _High_ | _Medium_ 232 | |=== 233 | 234 | ==== 235 | 236 | [PRE-FILLED] 237 | ==== 238 | [%header,cols="2,3,3,2,1,1,1,1"] 239 | |=== 240 | | Business Process | Purpose | Categories of Data Processed | Internal Classification | C | I | A | T 241 | 242 | | 243 | | 244 | | 245 | | 246 | | 247 | | 248 | | 249 | | 250 | |=== 251 | 252 | [cols="1,5"] 253 | |=== 254 | | Legend | \(C)onfidentiality (I)ntegrity (A)vailability (T)raceability / proof: security requirements (Low, Medium, High) 255 | | Classification | Public, Internal, Restricted distribution, Confidential 256 | |=== 257 | ==== 258 | 259 | 260 | //🏷{"id": "d979e090-c43f-48f5-a0e3-83b810efff9f", "labels": ["detail_level::overview", "constraint"]} 261 | ## Constraints 262 | 263 | TIP: Limits and imposed choices on how you may design/implement the solution. They restrict the design space (technology, process, organization, time, budget, regulation). 264 | 265 | //🏷{"id": "58897e87-0c12-4139-b5da-daec9cae21c6", "labels": []} 266 | ### Budget 267 | 268 | TIP: Give the budget constraints of the project 269 | ==== 270 | Example 1: Overall envelope of $1M 271 | ==== 272 | ==== 273 | Example 2: Cloud infrastructure should cost less than $20K a month 274 | ==== 275 | 276 | //🏷{"id": "ac5b1f28-bfcb-4543-a90b-abcff2b41822", "labels": []} 277 | ### Planning 278 | 279 | TIP: Without detailing the project schedules, it is suggested to highlight interesting elements for the architecture. 280 | ==== 281 | Example 1: Application Launch before February 2034, prerequisite for the HEAVY program in May 2034. 282 | ==== 283 | 284 | //🏷{"id": "5837249a-8fcc-4e42-9dd9-384c4fa32afc", "labels": ["project_size::large"]} 285 | ### Urbanization 286 | 287 | [TIP] 288 | ==== 289 | List here the constraints relating to urbanization, this includes for example but not only: 290 | 291 | * The rules applicable for calls between modules (SOA) 292 | * Call rules between network zones 293 | * The rules concerning the localization of data (MDM) 294 | * The rules concerning the propagation of updates by events (EDA) 295 | 296 | ==== 297 | ==== 298 | Example 1: Calls between two services are prohibited except service calls to a nomenclature service. 299 | ==== 300 | ==== 301 | Example 2: to ensure freshness, it is forbidden to replicate data from the PERSON repository. The latter must be interrogated synchronously if necessary. 302 | ==== 303 | ==== 304 | Example 3: When modifying an order, the accounting and invoicing areas will be updated asynchronously via an event. 305 | ==== 306 | ==== 307 | Example 4: All the batches must be able to operate in competition with the UIs without locking the resources. 308 | ==== 309 | ==== 310 | Example 5: Services cannot be called directly. The calls must be made via an exposed route at the level of the company bus which will in turn call the service. It is then possible to control, prioritize, orchestrate or manage the calls. 311 | ==== 312 | ==== 313 | Example 6: The modules of this application follow the SOA architecture as defined in the reference document X. 314 | ==== 315 | ==== 316 | Example 7: modules in an Internet zone cannot call modules in an Intranet zone for security reasons. 317 | ==== 318 | 319 | //🏷{"id": "abafa462-262f-429e-aad8-d2cdc0cf15a3", "labels": []} 320 | ### Legals 321 | 322 | List here (without detailing too much) any legal constraints related to the project. 323 | 324 | ==== 325 | Example 1: The framework contract established with the ESN XYZ provides for the transfer to our company of the copyright on the source code. 326 | ==== 327 | 328 | ==== 329 | Example 2: The project code will be under the free and open source license GPL V3. 330 | ==== 331 | 332 | ==== 333 | Example 3: The data exposed by the project will be licensed under ODS-By. 334 | ==== 335 | 336 | ==== 337 | Example 4: The EULA of the software package provides access to sources for users with shares in the company. 338 | ==== 339 | 340 | //🏷{"id": "3b714287-891e-4ea3-a7a4-17672caaf945", "labels": ["detail_level::overview","requirement"]} 341 | ## Requirements 342 | 343 | TIP: What the solution must achieve for stakeholders: capabilities, behaviors, and quality levels. They express needs/goals and are (ideally) testable. Depending on your context, feel free to add sub-sections. 344 | 345 | //🏷{"id": "9352a89a-3f8b-4028-98d5-58fb970e01ef", "labels": []} 346 | ### Strategic Requirements 347 | 348 | TIP: Describe here the requirements related to the overall strategy of the project in terms of trajectory, budget, and organization. 349 | 350 | ==== 351 | Example 1: Development must be able to take place within distributed teams, each working on distinct modules. 352 | ==== 353 | 354 | ==== 355 | Example 2 (migration project): Legacy modules should require as few adaptations as possible due to a lack of human resources. 356 | ==== 357 | 358 | //🏷{"id": "38fd6aa0-2354-4d0d-9812-10ed917eae5e", "labels": []} 359 | ### Interoperability 360 | 361 | TIP: Describe here the requirements regarding protocols, formats, and semantics to be followed to facilitate exchanges with organizations or third parties. 362 | 363 | ==== 364 | Example: Our XYZ modules must be exposed to X organizations from the Internet in the form of authenticated REST APIs. 365 | ==== 366 | 367 | //🏷{"id": "7d3090d0-87d0-434f-9717-f9a12ccf60d1", "labels": ["level::intermediate","detail_level::detailed"]} 368 | ### Concurrency management requirements 369 | 370 | [TIP] 371 | ==== 372 | Specify the internal or external modules that may interfere with the application. 373 | ==== 374 | ==== 375 | Example 1: All modules of this application must be able to run concurrently. In particular, batches/GUI concurrency must always be possible because the batches must be able to run during the day. 376 | ==== 377 | ==== 378 | Example 2: Batch X should only be started if batch Y is completed correctly, otherwise data may be corrupted. 379 | ==== 380 | 381 | //🏷{"id": "9efde825-9508-4669-918c-7cfb0d45c21f", "labels": ["detail_level::detailed"]} 382 | ### Retention Periods 383 | 384 | TIP: Specify here how long data and documents persisted by your application modules should be kept. Note that these durations may be legally constrained (see legal constraints above), for example in the context of the GDPR right to be forgotten. 385 | 386 | TIP: Don't forget to mention technical data (such as logs or technical tables) as well as archives. 387 | 388 | ==== 389 | Example: 390 | 391 | .Retention period for data and documents 392 | [cols="1e,1e"] 393 | |=== 394 | | Data Class | Maximum Retention Period 395 | 396 | | Payment Data (Credit Card) 397 | | 2 months 398 | 399 | | Order List 400 | | 2 years 401 | 402 | | Access Logs 403 | | 1 month 404 | 405 | | Archived Accounting Data 406 | | 30 years 407 | 408 | |=== 409 | ==== 410 | 411 | [PRE-FILLED] 412 | ==== 413 | [cols="1,1"] 414 | |=== 415 | | Data Class | Maximum Retention Period 416 | 417 | | 418 | | 419 | 420 | 421 | |=== 422 | 423 | ==== 424 | 425 | //🏷{"id": "afdd573d-d1f8-4958-99c1-e404592396d0", "labels": ["level::advanced","detail_level::detailed"]} 426 | ### Degraded modes 427 | [TIP] 428 | ==== 429 | Specify the degraded application modes. 430 | ==== 431 | 432 | ==== 433 | Example 1: The _mysite.com_ site must be able to continue to accept orders in the absence of the logistics department. 434 | ==== 435 | ==== 436 | Example 2: If the SMTP server no longer works, the emails will be stored in the database and then resubmitted following a manual operation by the operators. 437 | ==== 438 | 439 | //🏷{"id": "ec7cfacf-e267-4937-80e8-b5c92409ecd1", "labels": ["detail_level::detailed", "archiving"]} 440 | ### Archiving 441 | 442 | [TIP] 443 | ==== 444 | Archiving is the copying of important data to a dedicated offline medium for occasional consultation, unlike backup which is intended for restoration. Archives are often required for legal reasons and kept for thirty years or more. 445 | 446 | Specify if application data needs to be kept long-term. Specify the reasons for this archiving (usually legal). 447 | 448 | Specify if specific integrity protection mechanisms (mainly to prevent any modification) need to be put in place. 449 | ==== 450 | 451 | ==== 452 | Example 1: As required by the law, accounting data must be kept for at least ten years. 453 | ==== 454 | ==== 455 | Example 2: Accounting documents must be kept online (in the database) for at least two years and then can be archived for at least ten more years. A SHA256 hash will be calculated at the time of archiving and stored separately to verify the integrity of the documents if needed. 456 | ==== 457 | 458 | 459 | //🏷{"id": "b269e65b-a8c7-4518-a861-5c6c17802869", "labels": ["solution","detail_level::overview"]} 460 | ## Target architecture 461 | 462 | //🏷{"id": "2c107a25-a1c4-433d-b746-e12aa2c6eea1", "labels": []} 463 | ### General application architecture 464 | 465 | [TIP] 466 | ==== 467 | Present here the application as a whole (without detailing its sub-components) in relation to the other applications of the IS. Also present the macro-data exchanged or stored. 468 | 469 | Summarize: 470 | 471 | * The kind of architecture (client-server, monolithic Web, SOA, micro-service, event-driven...). 472 | * Large network flows between modules or between applications in the case of monoliths. 473 | * Any derogation to applicable architectural rules. 474 | 475 | If the application is planned to be implemented in several stages, briefly describe the target trajectory. 476 | 477 | ==== 478 | 479 | [TIP] 480 | ==== 481 | 482 | The choice of representation is free but a C4 diagram from System Landscape or a UML2 component diagram seems the most suitable. We provide patterns and details on this topic in https://florat.net/architecture-as-code-with-c4-and-plantuml/[this article]. 483 | 484 | Numbering the steps in chronological order ensures a better understanding of the diagram. Group the sub-steps by the notation x, x.y, x.y.z, ... 485 | 486 | Do not include specific infrastructure system (SMTP server, security device, reverse proxy, LDAP directories, etc.) which are in the domain of technical architecture. On the contrary, mention Enterprise Service Buses, API Gateway or similar infrastructure components if they play an application role (service orchestration for example). 487 | ==== 488 | 489 | ==== 490 | Example 1: Thanks to the August 03, 20xx derogation, the GUI will be written using an SPA (Single Page Application) technology. 491 | ==== 492 | ==== 493 | Example 2: AllMyData allows a company to retrieve by email a document summarizing all the information the administration has on it. The administration can supplement its data with those of another administration. AllMyData is made up of several independent modules (GUIs, batches and APIs). 494 | ==== 495 | 496 | image::diagrams/general-application-design.svg[General application architecture diagram] 497 | 498 | //🏷{"id": "6390e724-c2f0-4737-99a0-531fdcfe8e20", "labels": ["detail_level::detailed"]} 499 | ### Detailed application architecture 500 | 501 | [TIP] 502 | ==== 503 | Detail here all the modules of the application, their interdependencies, and the interactions with other applications within the information system (IS) or with partners. 504 | 505 | The flows are logical rather than technical (for example, you can represent a direct HTTP flow between two modules even though, in reality, it passes through an intermediate load balancer: this level of detail will be provided in the infrastructure view). 506 | 507 | Propose one or more diagrams (preferably C4 container diagrams or UML2 component diagrams). You can find further patterns and details in https://florat.net/architecture-as-code-with-c4-and-plantuml/[this article]. 508 | 509 | Ideally, the diagram should fit on an A4 page, be self-explanatory, and understandable by a non-technical person. It should become one of the most important documentation artifacts and be displayed in the war room of an agile project or printed by each developer. 510 | 511 | ==== 512 | 513 | //🏷{"id": "148fd29c-b0a0-4bff-b5da-71f5b1195e1e", "labels": ["project_size::medium", "detail_level::detailed"]} 514 | #### Principles that dictated the choices 515 | 516 | [TIP] 517 | ==== 518 | Give here the intention in the architecture conception. 519 | ==== 520 | ==== 521 | Example: we will use a monolithic and non-micro-service approach due to a lack of expertise within the IT project team. 522 | ==== 523 | 524 | //🏷{"id": "d4124d8e-47b9-4cfa-94ec-8164180bdecc", "labels": ["project_size::large", "detail_level::detailed"]} 525 | #### Inventory view 526 | 527 | [TIP] 528 | ==== 529 | Expose the application modules in their different zones or domains. 530 | ==== 531 | ==== 532 | Example: module X, Y and Z in the ACCOUNTING domain. Modules A, B in the PERSON domain. 533 | ==== 534 | image::diagrams/detailed-application-architecture-inventory.svg[Detailed application architecture diagram (inventory view)] 535 | 536 | //🏷{"id": "6c06792f-9e6d-4156-88d3-468063716834", "labels": ["project_size::large", "detail_level::detailed"]} 537 | #### Links between modules 538 | 539 | [TIP] 540 | ==== 541 | Expose the dependencies between all application modules across their various zones or domains. Do not detail technical flows (such as those related to monitoring or clustering). 542 | 543 | If (and only if) the complexity of the application justifies it, propose, in addition to this global diagram, a detailed diagram for each main communication chain by numbering the exchanges (use a sequence diagram or, preferably, a Dynamic Diagram C4). 544 | 545 | Use a simple, non-significant, and hierarchical sequence as the ID for the flows (e.g., 1, 2.1, 2.2.3, ..., n). 546 | 547 | For each flow, specify the protocol, a read/write/execute attribute, and a description to make the diagram self-explanatory. If the flow is asynchronous, indicate this (in the example below, the call is shown in dashed lines). 548 | 549 | Each communication chain describes a major functionality. In cases of complex sequences, it is recommended to break down the functionality into several communication chains containing only synchronous calls (see https://florat.net/architecture-as-code-with-c4-and-plantuml/[this article]). 550 | 551 | ==== 552 | 553 | ==== 554 | Example: 555 | 556 | image::diagrams/detailed-application-architecture-dynamic.svg[Detailed application architecture diagram (dynamic view)] 557 | 558 | ==== 559 | 560 | //🏷{"id": "9ac6e5d2-e9a0-427e-ba12-27dedbd8ac4d", "labels": ["level::intermediate","rewrite"]} 561 | ### Transition paths 562 | 563 | [TIP] 564 | ==== 565 | This chapter describes a required migrations from older systems. 566 | 567 | Describe on a macroscopic scale the planned procedure as well as the rollback strategy in case of problem. 568 | 569 | Describe, if necessary, a dry-run operation in parallel with the old system. 570 | ==== 571 | ==== 572 | Example 1: The X API module will be replaced by the Y API. Then the Z Oracle database will be migrated in one-shot via a PL/SQL + DBLink script to the X instance with the new basic format of the T module. 573 | ==== 574 | ==== 575 | Example 2: In the event of a problem with the new module, a rollback will be provided: the old data will be restored within two hours and the new data from the failover will be taken over by the S1 script. 576 | ==== 577 | 578 | 579 | //🏷{"id": "f49dc567-ef07-45db-b25a-34c57a58f213", "labels": ["detail_level::detailed","archiving"]} 580 | ### Archiving 581 | 582 | [TIP] 583 | ==== 584 | Describe here the measures to meet archiving requirements. This section will mainly include: 585 | 586 | * Technology: Ideally, for security, the archive will be duplicated on multiple media of different technologies: magnetic tape type LTO, optical disk (Blu-ray Disc Recordable for example), cloud storage (such as AWS 'Glacier' or GCP 'Coldline'), SMR mode hard drives, etc. 587 | * A specific storage location distinct from traditional backups (e.g., Cloud, bank vault). 588 | ==== 589 | 590 | ==== 591 | Example: Bank statements older than 10 years will be archived on LTO tape and hard drive. A set of each medium will be stored in a vault in two different banks. 592 | ==== 593 | 594 | //🏷{"id": "7a01e2dd-1921-4e41-95d6-57f2b80e447b", "labels": ["detail_level::detailed"]} 595 | ### Purges 596 | 597 | [TIP] 598 | ==== 599 | Describe here the technical measures to meet purge requirements. 600 | ==== 601 | 602 | ==== 603 | Example 1: The consultation history will be archived by a dump with an SQL query like `COPY (SELECT * FROM my_table WHERE ...) TO '/tmp/dump.tsv'` and then purged by an SQL `DELETE` query after the operator has validated the completeness of the dump. 604 | ==== 605 | 606 | ==== 607 | Example 2: Each API is responsible for purging the data it exposes. For this, plan internal processes that delete data according to a schedule (cron expression) and configurable criteria. 608 | ==== 609 | 610 | 611 | //🏷{"id": "3a80c49f-5f9d-4c1d-bcb5-d3ef292e2895", "labels": ["detail_level::in-depth"]} 612 | ### Matrix of application flows 613 | 614 | [TIP] 615 | ==== 616 | List here the main network flows of the application. 617 | 618 | Do not detail the monitoring or clustering streams for example. Indicate the type of network (LAN, WAN). 619 | ==== 620 | 621 | ==== 622 | Example: Partial example of an application flow matrix 623 | [cols = '1e, 3e, 1e, 1e, 1e'] 624 | |=== 625 | | Source | Destination | Network type | Protocol | Mode.footnote:[Read\(R), Write (W) or Call\(C) to a stateless system] 626 | 627 | | Company| PC / tablet / external mobile | WAN | gui-allmydata | R 628 | | batch-process-requests | service-compo-pdf | LAN | HTTP | C 629 | |=== 630 | ==== 631 | 632 | [PRE-FILLED] 633 | ==== 634 | [cols = '1, 3, 1, 1, 1'] 635 | |=== 636 | | Source | Destination | Network type | Protocol | Mode.footnote:[Read\(R), Write (W) or Call\(C) to a stateless system] 637 | 638 | | 639 | | 640 | | 641 | | 642 | | 643 | 644 | |=== 645 | ==== -------------------------------------------------------------------------------- /diagrams/detailed-application-architecture-inventory.svg: -------------------------------------------------------------------------------- 1 | Inventory viewAny company IS[system]System administration B[system]Information System[system]Client [person]Web client (PC, tablet, mobile)SPA gui-allmydata[Container: javascript, React.js] Graphical interface forrequesting informationAllMyData mobileapplication[Container: Android] Graphical interface to requestinformationAccounting system REST servicegui-allmydata WebApplication[Container: nginx] Deliver the static resources (js,html, images ...) of theAllMyData GUIservice-allmydata[Container: Tomcat, Spring Boot] REST service allowing torequest informationbatch-process-requests[Container: groovy] Process requests, launched bycron every minuterequests-queue[Container: ActiveMQ] Stores requestsbdd-allmydata[Container: PostgreSQL] Internal databaseservice-compo-pdf[Container: Wildfly, JasperReport] Composition REST servicemail server[Container: Postfix] Send emailsLegend personsystemcontainerexternal personexternal systemexternal container -------------------------------------------------------------------------------- /diagrams/infrastructure.svg: -------------------------------------------------------------------------------- 1 | Infrastucture architecture viewClient[Desktop / mobile]Web browser[Chrome / Firefox / Safari]Datacenter[Atlanta]Reverse Proxy[x2 Debian Buster «active/active»]AllMyData server[x2 Debian Buster]Web server[Nginx]JEE Server[Tomcat 10]API Server[x3, RHEL]JEE Server[Wildfly]BDD Server[RHEL]Monitoring Server[x1 Debian Stretch]Datacenter[NYC]API Geatexway[x1 Windows Server]Accounting Serveur[x1 Linux]AllMyData SPAapplication[React.js]Firewall[Cisco Firepower 4100]LB Debian lb1[«active»]LB Debian lb2[«passive»]<Any server>Reverse Proxy[HaProxy]SPA Web Application[React.js] Expose static resources (.js, .html, images ...)batch-process-requests[Java] Process requestsAPI service-allmydata[Java]PostgreSQL[PostgreSQL 12]Message queue[ActiveMQ]MTA[Postfix]Monitoring tool[Centreon]API Gateway[API Gateway]Accounting Service APIHTTPS on the InternetHTTPSHeartbeat VRRP.HTTPproducts AMQP)consumes AMQPJDBC / PGSMTP / sends e-mailsSOAP/HTTPSSOAP/HTTPSREST/HTTPSNMPLegend personsystemcontainerexternal personexternal systemexternal container --------------------------------------------------------------------------------