├── .gitignore ├── CNAME ├── LICENSE.txt ├── README.md ├── README_de.md ├── _config.yml ├── _descriptions ├── card01_expectation.md ├── card02_quickcheck.md ├── card03_adr.md ├── card04_torte.md ├── card05_produktbox.md ├── card06_standards.md ├── card07_bierdeckel.md ├── card08_unbekannte.md ├── card09_schmerzen.md ├── card10_rootcause.md ├── card11_erfolg.md ├── card12_ausreden.md ├── card13_tonne.md ├── card14_standort.md ├── card15_schulden.md ├── card16_shitstorm.md ├── card17_codesmell.md ├── card18_dokucheck.md ├── card19_idol.md ├── card20_zauberstab.md ├── card21_powerskills.md ├── card22_traum.md ├── card23_investment.md ├── card24_minidoku.md ├── card25_wege.md ├── card26_expertise.md ├── card27_minirisiko.md ├── card28_vergleich.md ├── card29_roadmap.md └── card30_nutzen.md ├── _descriptions_EN ├── card01_expectation.md ├── card02_quickcheck.md ├── card03_adr.md ├── card04_cake.md ├── card05_productbox.md ├── card06_standards.md ├── card07_coaster.md ├── card08_unknown.md ├── card09_pain.md ├── card10_rootcause.md ├── card11_success.md ├── card12_excuses.md ├── card13_waste.md ├── card14_positioning.md ├── card15_debt.md ├── card16_shitstorm.md ├── card17_codesmell.md ├── card18_doccheck.md ├── card19_idol.md ├── card20_wand.md ├── card21_superpowers.md ├── card22_dream.md ├── card23_investment.md ├── card24_minidoc.md ├── card25_paths.md ├── card26_expertise.md ├── card27_minirisk.md ├── card28_businessability.md ├── card29_roadmap.md └── card30_value.md ├── _includes ├── card_EN.html ├── footer_EN.html └── head_EN.html ├── _info ├── 10_news.md ├── 20_haeufig_auftretende_fragen.md ├── 50_feedback.md ├── 90_mitwirkende.md ├── 95_lizenz.md └── 99_kontakt.md ├── _info_EN ├── 10_news.md ├── 20_faq.md ├── 50_feedback.md ├── 90_contributors.md ├── 95_license.md └── 99_contact.md ├── _layouts ├── card_page.html ├── compress.html ├── default.html └── page.html ├── assets ├── cards42_header.jpg ├── cards42_header_en.jpg ├── cards42_preview.jpg ├── cards42_preview_en.jpg ├── cards42_prototyp.jpg ├── js │ ├── index.js │ ├── lozad.min.js │ └── polyfill.min.js ├── sponsor.png ├── style.css └── style2021.css ├── cards ├── card01.png ├── card02.png ├── card03.png ├── card04.png ├── card05.png ├── card06.png ├── card07.png ├── card08.png ├── card09.png ├── card10.png ├── card11.png ├── card12.png ├── card13.png ├── card14.png ├── card15.png ├── card16.png ├── card17.png ├── card18.png ├── card19.png ├── card20.png ├── card21.png ├── card22.png ├── card23.png ├── card24.png ├── card25.png ├── card26.png ├── card27.png ├── card28.png ├── card29.png └── card30.png ├── cards42 English edition.pdf ├── cards_EN ├── card01.png ├── card02.png ├── card03.png ├── card04.png ├── card05.png ├── card06.png ├── card07.png ├── card08.png ├── card09.png ├── card10.png ├── card11.png ├── card12.png ├── card13.png ├── card14.png ├── card15.png ├── card16.png ├── card17.png ├── card18.png ├── card19.png ├── card20.png ├── card21.png ├── card22.png ├── card23.png ├── card24.png ├── card25.png ├── card26.png ├── card27.png ├── card28.png ├── card29.png └── card30.png ├── cards_examples ├── idol_1.png ├── rootcause_1.md └── rootcause_1.svg ├── cards_examples_EN └── codesmell_1.png ├── cards_pdf_EN ├── card01.pdf ├── card02.pdf ├── card03.pdf ├── card04.pdf ├── card05.pdf ├── card06.pdf ├── card07.pdf ├── card08.pdf ├── card09.pdf ├── card10.pdf ├── card11.pdf ├── card12.pdf ├── card13.pdf ├── card14.pdf ├── card15.pdf ├── card16.pdf ├── card17.pdf ├── card18.pdf ├── card19.pdf ├── card20.pdf ├── card21.pdf ├── card22.pdf ├── card23.pdf ├── card24.pdf ├── card25.pdf ├── card26.pdf ├── card27.pdf ├── card28.pdf ├── card29.pdf └── card30.pdf ├── cards_preview_EN ├── card01.png ├── card02.png ├── card03.png ├── card04.png ├── card05.png ├── card06.png ├── card07.png ├── card08.png ├── card09.png ├── card10.png ├── card11.png ├── card12.png ├── card13.png ├── card14.png ├── card15.png ├── card16.png ├── card17.png ├── card18.png ├── card19.png ├── card20.png ├── card21.png ├── card22.png ├── card23.png ├── card24.png ├── card25.png ├── card26.png ├── card27.png ├── card28.png ├── card29.png └── card30.png ├── cards_svg ├── card01.svg ├── card02.svg ├── card03.svg ├── card04.svg ├── card05.svg ├── card06.svg ├── card07.svg ├── card08.svg ├── card09.svg ├── card10.svg ├── card11.svg ├── card12.svg ├── card13.svg ├── card14.svg ├── card15.svg ├── card16.svg ├── card17.svg ├── card18.svg ├── card19.svg ├── card20.svg ├── card21.svg ├── card22.svg ├── card23.svg ├── card24.svg ├── card25.svg ├── card26.svg ├── card27.svg ├── card28.svg ├── card29.svg └── card30.svg ├── cards_svg_EN ├── card01.svg ├── card02.svg ├── card03.svg ├── card04.svg ├── card05.svg ├── card06.svg ├── card07.svg ├── card08.svg ├── card09.svg ├── card10.svg ├── card11.svg ├── card12.svg ├── card13.svg ├── card14.svg ├── card15.svg ├── card16.svg ├── card17.svg ├── card18.svg ├── card19.svg ├── card20.svg ├── card21.svg ├── card22.svg ├── card23.svg ├── card24.svg ├── card25.svg ├── card26.svg ├── card27.svg ├── card28.svg ├── card29.svg └── card30.svg ├── en └── index.html ├── favicon.ico ├── favicon.png ├── favicon2021.png └── index.html /.gitignore: -------------------------------------------------------------------------------- 1 | _site/ 2 | .jekyll-cache/ 3 | .jekyll-metadata 4 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | cards42.org -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # cards42.org 2 | 3 | *[German version (outdated)](README_de.md)* 4 | 5 | ## What is this all about? 6 | 7 | This is the repository for the website [cards42.org](https://cards42.org). The cards42 project consists (in the final stage) of 42 cards, which support software architects in their daily architectural work. 8 | 9 | The cards provide brief food for thought for deadlocked situations and help to shed new light on difficult challenges. 10 | 11 | Backgrounds and more details about the cards are available on [cards42.org](https://cards42.org). 12 | 13 | ## How can I contribute? 14 | 15 | cards42 is an open project where people can bring in new ideas. 16 | 17 | 18 | ### Proofreading 19 | 20 | The cards42 project was originally created in the German language. 21 | We've decided to translated the cards in English as well. 22 | We would appreciate any comments or/and suggestions for improvements. 23 | 24 | ### New ideas for cards 25 | 26 | You are also welcome to contribute your ideas for new cards. 27 | Just [open a new ticket](https://github.com/innoq/cards42org_en/issues/new) and describe your idea. 28 | Maybe you already have a sketch of the cards? 29 | Just upload it and we can discuss it. 30 | We would then work out the idea together and also redesign it graphically. 31 | 32 | ### Description texts 33 | 34 | The texts explaining the cards can be found under `descriptions` (German version) or `descriptions_EN)` (English version). 35 | Feel free to create a new Pull Request with your changes or additions to the existing texts. 36 | You can also contribute a new text together with a new card. 37 | Please follow the naming conventions described below. 38 | 39 | ### Your participation 40 | 41 | We will be happy to mention your name on our website [cards42.org](https://cards42.org) under the "Contributors" section! 42 | Feel free to add yourself under `_info/90_contributors.md`. 43 | 44 | ## What are some of the rules? 45 | 46 | When you are creating a new card, there are some conventions to adhere to. 47 | The card images (under `cards`) and their descriptions (under `_descriptions`) are brought together using file name conventions. 48 | 49 | * The file name `cardname` of a card is `card<2-digit number>.png` 50 | * The file name of a description is `_.md` 51 | 52 | Using Jekyll / Liquid, the corresponding information in the `index.html` is thus extracted from the file names. 53 | 54 | ## How is it built? 55 | 56 | ### Website 57 | 58 | The page is generated via [Jekyll](https://jekyllrb.com/) 59 | Every time you make a change in the master branch, GitHub rebuilds the website. 60 | 61 | A local installation of Jekyll for local testing is also possible: 62 | 63 | ``` 64 | gem install bundler jekyll 65 | ``` 66 | 67 | The website can then be opened locally. 68 | 69 | Build the website with the command 70 | 71 | ``` 72 | jekyll serve 73 | ``` 74 | 75 | Under , you can then take a look at the website. 76 | 77 | ### Pictures 78 | 79 | _Only relevant for the main maintainers of the project_ 80 | 81 | The PNG images are generated by Ghostscript from the print PDFs of INNOQ (the company that came up with the idea for the cards and most of the cards are from so far). 82 | 83 | Step 1: With the original PDF, the print margins must first be removed: 84 | 85 | ``` 86 | gs -sDEVICE=pdfwrite -o "cards42_temp.pdf" -g2960x4144 -c "<< /Install { -22 -22 translate } bind >> setpagedevice" -f cards42.pdf 87 | ``` 88 | 89 | Step 2: The individual cards are exported without title and explanation card (`-dFirstPage=3`) as PNG images (`-sDEVICE=png16`) with anti-aliasing (`-dTextAlphaBits=4` and `-dGraphicsAlphaBits=4`) in 144 DPI (`-r144`) and the naming scheme `-o card%02d.png` defined above. 90 | 91 | ``` 92 | gs -dFirstPage=3 -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r144 -o card%02d.png cards42_temp.pdf 93 | ``` 94 | 95 | Alternatively, we directly export PNGs from the publishing software. 96 | 97 | 98 | Additionally, we create preview pictures e.g. for social networks. These need to be smaller with additional whitespace on each side. We use ImageMagick for this. 99 | 100 | ``` 101 | for file in *.png; do convert -resize 50% -gravity center -extent 450x450 $file $file; done 102 | ``` 103 | 104 | ### Internationalization 105 | 106 | * Originally, the cards42 project was created in the German language. The English edition was integrated in the original German version with a few adjustments: 107 | * the layout for the English cards was duplicated and refactored into several files 108 | * the cards and descriptions for English version are in directories with a postfix `_EN` 109 | * the English version of the `index.html` is in the root directory `/en` to allow the entry point cards42.org/en 110 | * the URL to the cards is not based on an HTML anchor (#), but URL-based to create similar short URLs to the cards 111 | * there is the main site that contains all cards but also a dedicated page for each card 112 | * both content on the main site and the cards' pages are identical 113 | 114 | ## License 115 | 116 | Creative Commons license
This work is licensed under Creative Commons - Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). -------------------------------------------------------------------------------- /README_de.md: -------------------------------------------------------------------------------- 1 | # cards42.org 2 | 3 | ## Was ist das hier? 4 | 5 | Dies ist das Repository für die Homepage [cards42.org](https://cards42.org). Das cards42-Projekt besteht (in der Endausbaustufe) aus 42 Karten, welche Softwarearchitektinnen und Softwarearchitekten bei der täglichen Architekturarbeit unterstützen. 6 | 7 | Die Karten geben kurze Denkanstöße für festgefahrene Situationen und helfen, neues Licht auf schwierige Herausforderungen zu werfen. 8 | 9 | Hintergründe und mehr Details zu den Karten sind auf [cards42.org](https://cards42.org) zu finden. 10 | 11 | ## Wie kann ich hier mitarbeiten? 12 | 13 | ### Beschreibungstexte 14 | 15 | Die Texte, welche die Karten erklären, findest Du unter `_descriptions`. Erstelle gerne einen neuen Pull Request mit Deinen Änderungen oder Ergänzungen zu den vorhandenen Texten. Einen neuen Text kannst Du zusammen mit einer neuen Karte ebenfalls beisteuern. Halte Dich hier bitte an die Namenskonventionen, welche weiter unten beschrieben sind. 16 | 17 | ### Neue Kartenideen 18 | 19 | Gerne kannst Du auch Deine Ideen für neue Karten beitragen. Öffne dazu einfach ein neues Ticket in Repository und beschreibe Deine Idee. Vielleicht hast Du auch schon eine Skizze der Karte? Lade sie einfach hoch und wir diskutieren drüber. Wir würden dann die Idee gemeinsam ausarbeiten und auch grafisch redesignen. 20 | 21 | ### Deine Mitarbeit 22 | 23 | Gerne nennen wir Deinen Namen dann auf unserer Website [cards42.org](https://cards42.org) unter der "Mitwirkende"-Sektion! 24 | 25 | ## Was muss beachtet werden? 26 | 27 | Die Kartenbilder (unter `cards`) und deren Beschreibungen (unter `_descriptions`) werden über Namenskonventionen der Dateinamen zusammengefügt. 28 | 29 | * Der Dateiname `cardname` einer Karte lautet `card<2-stellige Nummer>.png` 30 | * Der Dateiname einer Beschreibung lautet `_.md` 31 | 32 | Über Jekyll / Liquid werden in der `index.html` so die entsprechenden Informationen aus den Dateinamen extrahiert. 33 | 34 | ## Wie wird das gebaut? 35 | 36 | ### Website 37 | 38 | Die Seite wird über [Jekyll](https://jekyllrb.com/) erzeugt. Bei jeder Änderung wird die Website über GitHub neu erzeugt. 39 | 40 | Eine lokale Installation von Jekyll ist hiermit möglich: 41 | 42 | ``` 43 | gem install bundler jekyll 44 | ``` 45 | 46 | Anschließend kann die Website lokal mit dem Befehl 47 | 48 | ``` 49 | jekyll serve 50 | ``` 51 | 52 | gebaut und unter betrachtet werden. 53 | 54 | ### Bilder 55 | 56 | Die PNG-Bilder werden per Ghostscript aus den Druck-PDFs von INNOQ erzeugt. 57 | 58 | Schritt 1: Bei der Original-PDF müssen zuerst die Druckränder entfernt werden: 59 | 60 | ``` 61 | gs -sDEVICE=pdfwrite -o "cards42_temp.pdf" -g2960x4144 -c "<< /Install { -22 -22 translate } bind >> setpagedevice" -f cards42.pdf 62 | ``` 63 | 64 | Schritt 2: Die einzelnen Karten werden ohne Titel- und Erklärungskarte (`-dFirstPage=3`) als PNG-Bilder (`-sDEVICE=png16`) mit Anti-Aliasing (`-dTextAlphaBits=4` und `-dGraphicsAlphaBits=4`) in 144 DPI (`-r144`) und dem weiter oben definierten Namensschema `-o card%02d.png` exportiert. 65 | 66 | ``` 67 | gs -dFirstPage=3 -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r144 -o card%02d.png cards42_temp.pdf 68 | ``` 69 | 70 | ## Lizenz 71 | 72 | Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter einer Creative Commons: Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International (CC BY-SA 4.0). 73 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | collections: 2 | descriptions: 3 | directory: descriptions 4 | descriptions_EN: 5 | directory: descriptions_EN 6 | permalink: :title/ 7 | output: true 8 | info: 9 | directory: info 10 | info_EN: 11 | directory: info_EN 12 | -------------------------------------------------------------------------------- /_descriptions/card01_expectation.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: ResourceAllocationExpectation 3 | --- 4 | Oft sind wir in unserer eigenen Welt mit all ihren Beschränkungen gefangen. Wir sind darauf konditioniert, uns bescheiden zu geben – bescheiden sind damit dann auch unsere Lösungen. 5 | 6 | Aber was wäre, wenn ihr unerschöpfliche Ressourcen nutzen könntet? Was würde es im Softwaresystem bewirken? Was sind die maximal sinnvollen Ressourcen? Wie weit seid ihr hiervon weg? Wie bekommt ihr die wirklich wichtigen Ressourcen, um euer Softwaresystem noch besser zu machen? 7 | 8 | Sammelt die Möglichkeiten auf dieser Karte und diskutiert sie mit eurem Team! -------------------------------------------------------------------------------- /_descriptions/card02_quickcheck.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Architektur-Quick-Check 3 | --- 4 | Wichtige Qualitätsziele bestimmen Entscheidungen bei der Umsetzung von Softwaresystemen maßgeblich. In diesem Quick-Check kannst Du Deine TOP 3 Qualitätsziele mit der umgesetzten Lösung vergleichen, um zu sehen, ob diese zusammenpassen. 5 | 6 | Finde als erstes heraus, was die TOP Qualitätsziele sind. Dann identifiziere die wesentlichen Architekturansätze Deines Softwaresystems. Das sind die Dinge, die Du einer technikaffinen Person erzählst, die wissen will, wie ihr die Software aufgebaut habt. Schätze dann ab, wie gut der jeweilige Architekturansatz die Erreichung eines Qualitätsziels unterstützt (oder auch entgegenwirkt). 7 | 8 | **Mehr Informationen** 9 | * Artikel [Quality-Driven Software Architecture](https://www.innoq.com/en/articles/2012/04/quality-driven-software-architecture/) von Gernot Starke 10 | * Bewertungsmethode [Architecture Tradeoff Analysis Method](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513908) 11 | -------------------------------------------------------------------------------- /_descriptions/card03_adr.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Architecture Decision Record 3 | --- 4 | In länger entwickelten Softwaresystemen ist es mit der Zeit sehr schwierig, getroffene Entscheidungen aus der Vergangenheit nachzuvollziehen. Daher ist es wichtig, Entscheidungen und deren Beweggründe verständlich zu dokumentieren. 5 | 6 | Mittels Architecture Decisions Records (ADRs) gibt es die Möglichkeit, Entscheidungen möglichst leichtgewichtig und einheitlich zu dokumentieren. Zudem werden hier die Gründe für eine Entscheidung und die dabei durchlaufenen Gedankengänge sowie der Kontext (Zeit, Wissen, Beteiligte, etc.) festgehalten. 7 | 8 | Mit diesem Template könnte ihr üben, eure Entscheidungen nach den Ideen der ADRs zu strukturieren. 9 | 10 | **Mehr Informationen** 11 | 12 | * [Einstiegsseite für das Thema ADR](https://adr.github.io/) 13 | * [Initiale Vorstellung der Idee von ADRs](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) 14 | * [Beispiele von ADRs des Open-Source-Projekts Arachne Web Framework](https://github.com/arachne-framework/architecture) -------------------------------------------------------------------------------- /_descriptions/card04_torte.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Die 8-Stunden-Torte 3 | --- 4 | Der Tag hat 24h und die Nacht ist auch noch da. — Unbekannt. 5 | 6 | ...und plötzlich war der Tag schon wieder vorbei. Aber was habt ihr bewegt? Diese Zeittorte hilft euch zu sehen, worin ihr eure wertvolle Zeit investiert: 7 | 8 | * Nutzt ihr eure Zeit auch wirklich effektiv? 9 | * Welche der Zeitslots könnt ihr einfach loswerden? 10 | * Wie hart am Anschlag seid ihr ausgelastet? 11 | 12 | Beurteilt eure genutzte Zeit auch danach, ob ihr von der Arbeit getrieben seid oder ob ihr über die Zeit selbst bestimmen könnt: 13 | 14 | * Welche Zeit investiert ihr für zukunftsgerichtete Arbeit? 15 | * Wie viel Zeit verschwendet ihr mit ungeplanten Arbeiten? 16 | * Welche Zeit geht für Routinearbeiten drauf? 17 | 18 | **Mehr Informationen** 19 | * [Pomodoro-Technik für besseres Zeitmanagement](https://francescocirillo.com/pages/pomodoro-technique) 20 | * Das Buch [Projekt Phoenix](https://oreilly.de/produkt/projekt-phoenix/) gibt zahlreiche Hinweise für eine effektivere Gestaltung der eigenen Arbeit 21 | 22 | -------------------------------------------------------------------------------- /_descriptions/card05_produktbox.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Deine Produktbox 3 | --- 4 | Oft fehlt bei in die Jahre gekommenen Softwaresystemen die Vision oder das Zielbild. Was ist der richtige Weg? Für wen machen wir all das? Ergibt das überhaupt alles noch einen Sinn? 5 | 6 | Die Produktbox hilft euch, wichtige Antworten für eure Software aus der Sicht der Kunden zu finden: 7 | * Was wird eigentlich entwickelt? 8 | * Wer hat den Nutzen? 9 | * Was sind die zentralen Verkaufs- und Nutzungsargumente? 10 | * Was sind die Kernfunktionen? 11 | * Wie hebt sich das Produkt von anderen Produkten oder der Vorgängerversion ab? 12 | 13 | Durch die Beantwortung solcher Fragen bekommt ihr ein besseres Gefühl dafür, wofür ihr die Software wirklich entwickelt. 14 | 15 | **Mehr Informationen** 16 | * Methode [Design the Box](https://gamestorming.com/design-the-box/) von gamestorming.com 17 | 18 | -------------------------------------------------------------------------------- /_descriptions/card06_standards.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Arbeite ich nach gängigen Entwicklungsstandards? 3 | --- 4 | Mit der immer komplexer werdenden Software haben sich im Laufe 5 | der Jahre kontinuierlich mehr Standards etabliert, welche die Entwicklung und Evolution eines Softwaresystems nachweislich positiv unterstützen. 6 | 7 | Prüft in eurem Team, welche dieser Standards ihr umsetzt und wo es möglicherweise Nachholbedarf gibt. Überlegt euch auch, warum ihr fehlende oder unzureichende Maßnahmen bisher nicht angegangen seid. 8 | 9 | **Mehr Informationen** 10 | * Das Buch [Accelerate](https://itrevolution.com/book/accelerate/) liefert wissenschaftliche Belege zu der ein oder anderen Good Practice -------------------------------------------------------------------------------- /_descriptions/card07_bierdeckel.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Meine Architektur 3 | --- 4 | Das System ist zu komplex, um es kurz mal eben aufzumalen! – diesen oder ähnliche Sätze hat mit Sicherheit jede\*r Entwickler\*in schon einmal gehört. 5 | 6 | Eine gut strukturierte und klare Softwarearchitektur muss jedoch auf einen Bierdeckel passen. 7 | 8 | Versucht, die wichtigsten Strukturen eurer Architektur kompakt auf der Karte zu skizzieren. 9 | * Wann trefft ihr auf Platzprobleme? Besitzt ihr zu viel unnötigen Ballast? 10 | * Wird es an manchen Stellen zu detailliert? Ist das System vielleicht zu unterschiedlich abstrahiert? 11 | * Wisst ihr nicht, was ihr malen sollt? Sind wesentliche Konzepte der Architektur nicht bekannt? 12 | 13 | Diskutiert euer Vorgehen beim Zeichnen und die Ergebnisse. Überlegt euch, welche Maßnahmen ihr für eine noch klarere Strukturierung eures Softwaresystems vornehmen könnt. 14 | 15 | **Mehr Informationen** 16 | * Das [Dokumentationsschubladensystem arc42](https://arc42.org/) bietet eine bewährte Struktur, wenn ihr mehr dokumentieren wollt 17 | * Das Buch [Softwarearchitekturen dokumentieren und kommunizieren](http://www.swadok.de/) hilft beim Einstieg in eine leichtgewichtige Softwarearchitekturdokumentation 18 | -------------------------------------------------------------------------------- /_descriptions/card08_unbekannte.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Der unbekannte Bekannte 3 | --- 4 | Vermutlich hat jede an einem Softwareprojekt beteiligte Person in einer technischen Rolle dieses Problem schon einmal erlebt: Man glaubt, alles richtig zu machen, und auf einmal möchte ein Stakeholder aber etwas ganz anderes. Das Unverständnis ist groß, die Frustration steigt. 5 | 6 | Was denkt ihr, bewegt diese Person? Versucht euch, in ihre Lage zu versetzen und überlegt, was die Motivation hinter dem Verhalten des Stakeholders ist. Wie könnt ihr auf seine Bedürfnisse eingehen, um die Situation produktiver und für alle angenehmer zu gestalten? 7 | 8 | **Mehr Informationen** 9 | * Der [Mini Quality Attribute Workshop](https://re-magazine.ireb.org/articles/discover-quality-requirements-with-the-mini-qaw) besteht im Kern darin, andere Stakeholder und ihre Bedürfnisse besser zu verstehen 10 | * Artikel über [Empathy Driven Development](https://www.empathy-driven-development.com/why-empathy-will-transform-tech/) von Andrea Goulet -------------------------------------------------------------------------------- /_descriptions/card09_schmerzen.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Mein schmerzhaftestes Problem 3 | --- 4 | Probleme verursachen Kosten. Wenn diese Problemkosten die Kosten für die Lösung überproportional überschreiten, ist es durchaus rentabel, Probleme aus wirtschaftlichen Gründen anzugehen. 5 | 6 | Diese Karte hilft Dir, ein für Dich sehr wichtiges Problem strukturiert zu erfassen und die damit verbundenen Kosten abzuschätzen. Die Intervallschätzung drückt dabei aus, wie sicher oder unsicher Du in Deiner Schätzung bist. 7 | 8 | **Mehr Informationen** 9 | * Die [Architecture Improvement Method aim42](https://aim42.github.io/#Estimate-Issue-Cost) zeigt weitere Beispiele für die Problemkostenschätzung -------------------------------------------------------------------------------- /_descriptions/card10_rootcause.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Root Cause Analysis 3 | examples: rootcause_1.svg 4 | --- 5 | Softwareentwickler*innen lösen tagtäglich hunderte von kleinen und großen Problemen. Wir sind dadurch darauf konditioniert, schnell Lösungen hervorzubringen. In manchen schwierigen Situationen ist dies aber kontraproduktiv. Wir reagieren hier oft auch mit unserem antrainierten Lösungsreflex auf das erste vermeintliche und für uns klar erscheinende Problem. 6 | 7 | Diese Karte soll euch dabei helfen, den ersten Reflex zu unterdrücken, in dem ihr mit gezielten Warum?-Fragen erst die wahren Probleme ergründet. 8 | 9 | Versucht die sog. "5 Whys" bei verzwickten Situationen einzusetzen, um nicht nur ständig Symptome zu lösen, sondern die richtigen Problemursachen bei der Wurzel anzupacken. 10 | 11 | **Mehr Informationen** 12 | * Erklärung der [Root Cause Analysis](https://aim42.github.io/#Root-Cause-Analysis) auf der Seite der Architecture Improvement Method aim42 -------------------------------------------------------------------------------- /_descriptions/card11_erfolg.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Erfolg in der Zukunft 3 | --- 4 | Oft liegen sehr naheliegende Lösungen vor uns, welche maßgeblich zum Erfolg eines Softwaresystems beitragen, aber wir sehen sie gerade nicht. Zu sehr sind wir mit unserer Engstirnigkeit im Tagesgeschäft gefangen. 5 | 6 | Diese Karte löst dieses Dilemma dadurch, dass sie euch gedanklich ganz bewusst in die ferne Zukunft versetzt. Damit eröffnet sich eine völlig andere Perspektive auf das "heutige damals", da ihr nun auf die Gegenwart zurückblickt. 7 | 8 | Gedanklich in der Zukunft angekommen, sammelt die TOP 3 Aktionen, die passiert sind, um euer Softwaresystem so richtig erfolgreich werden zu lassen. Diskutiert anschließend wieder im Hier und Jetzt, warum ihr die Maßnahmen noch nicht getroffen habt: 9 | 10 | * Was muss passieren, damit ihr es besser habt? 11 | * Was passiert kurz davor? 12 | * Was passiert dann als nächstes? 13 | * Wie könnt ihr jetzt loslegen? 14 | 15 | **Mehr Informationen** 16 | 17 | * Artikel über die Verwendung der [artverwandten Pressemitteilung](https://www.businessinsider.com/heres-the-surprising-way-amazon-decides-what-new-enterprise-products-to-work-on-next-2015-3?IR=T) bei Amazon 18 | * Sammlung von [ähnlichen Formaten](http://www.funretrospectives.com/category/futurespective/), welche mit Zukunftsszenarien arbeiten -------------------------------------------------------------------------------- /_descriptions/card12_ausreden.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Wie schlimm redest Du Dir das Dokumentieren? 3 | --- 4 | Das Schreiben einer Dokumentation gilt als eine der unbeliebtesten Aufgaben in der Softwareentwicklung. Sehr häufig wird die Wichtigkeit der Dokumentation nicht gewürdigt oder als umständlich abgetan. 5 | 6 | Eine gute Dokumentation hilft nicht nur anderen, sondern auch der schreibenden Person selbst. Das Schreiben und Aktualisieren der Dokumentation muss kein Hexenwerk sein, es kann parallel zur Entwicklung geschehen – sogar innerhalb der bereits geöffneten Entwicklungsumgebung. Die Verwendung von arc42 bildet eine gute Grundlage für eine gute und einfache Dokumentation von Softwarearchitekturen. 7 | 8 | **Mehr Informationen** 9 | 10 | * [Offizielle Seite von arc42](https://arc42.org/) 11 | * Buch [Primer - Softwarearchitekturen pragmatisch dokumentieren](https://leanpub.com/arc42-primer) 12 | * Leichtgewichtiges, entwicklerfreundliches Dokumentieren mit dem [Docs-As-Code-Ansatz](https://docs-as-co.de/) 13 | -------------------------------------------------------------------------------- /_descriptions/card13_tonne.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Das Worst-Case-Szenario 3 | --- 4 | Häufig überlegt man erst nach dem Ende eines Projekts was zu dem oft fatalen Ausgang geführt hat. In agilen Projekten werden zudem Retrospektiven veranstaltet, um frühzeitig Risiken für ein Projekt zu finden, aber beschränken sich diese oft nur auf die Ereignisse der vergangenen Wochen. 5 | 6 | In beiden Fällen könnten wir fröhlich vor uns hin arbeiten, bis es einen harten Cut in Form eines Projektabbruchs kommt – den wir uns dann so gar nicht erklären können. 7 | 8 | Aber warum muss es erst so weit kommen? Macht euch Gedanken, was dazu führen könnte, dass euer Produkt in der nahen Zukunft gegen die Wand gefahren wird. Nimmt dies für unterschiedliche Zeiträume vor, damit ihr nicht im Hier und Jetzt gefangen seid. Nutzt dann diese Erkenntnisse, um geeignete Gegenmaßnahmen zu definieren und umzusetzen. -------------------------------------------------------------------------------- /_descriptions/card14_standort.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Standortbestimmung 3 | --- 4 | Vielen Teams ist nicht bewusst, wie gut ihre Software eigentlich ist und wo für ihren Erfolg Gefahren lauern. Die Standortbestimmung hilft euch dabei, ungenutzte Chancen zu finden und blinde Flecken zu identifizieren. 5 | 6 | Diskutiert hierfür untereinander, mit welchen Stärken eure Software punkten kann: 7 | * Was lief bisher richtig gut? 8 | * Worauf seid ihr so richtig stolz? 9 | 10 | Fragt euch auch, welche Schwächen derzeit vorhanden sind: 11 | * Wo tut ihr euch schwer? 12 | * Was fehlt euch? 13 | 14 | Sucht auf dieser Basis Gelegenheiten, um die identifizierten Schwächen zu kompensieren: 15 | * Welche Chancen könnt ihr in naher Zukunft nutzen? 16 | * Was könnt ihr gleich selbst ändern? 17 | 18 | Identifiziert ebenfalls Risiken, die sich in eurer Software verbergen: 19 | * Welche ungünstigen Entwicklungen in eurem Umfeld gibt es? 20 | * Wo lauern mögliche Gefahren? 21 | 22 | **Mehr Informationen** 23 | * [SWOT Analysis auf gamestorming.com](https://gamestorming.com/swot-analysis/) -------------------------------------------------------------------------------- /_descriptions/card15_schulden.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Technische Schulden 3 | --- 4 | Der Begriff "Technische Schulden" wirkt heutzutage schon sehr abgedroschen, diffus und auch abstrakt. Mache für Dein Softwaresystem sichtbar, was ihr im Team damit meint. Schätzt dazu ab, was und wie viel an "Technischen Schulden" ihr habt. Definiert und diskutiert die gefundenen Punkte untereinander, damit klarer wird, an was es Eurem Softwaresystem wirklich mangelt. 5 | 6 | **Mehr Informationen** 7 | 8 | * [Artikel von Martin Fowler](https://martinfowler.com/articles/is-quality-worth-cost.html), der klar macht, weshalb man sich mit dem Thema auseinandersetzen muss -------------------------------------------------------------------------------- /_descriptions/card16_shitstorm.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Vermeide den #Shitstorm! 3 | --- 4 | Es gibt Personen in und um eure Software, welche einen großen Einfluss haben, ohne dass ihr es wisst. Findet heraus, welche Personen wie wichtig für den Erfolg eures Softwareprodukts sind und wie sie euer Softwaresystem sehen. Sind sie damit eher die Gewinner bzw. oder Nutznießer? Oder verlieren sie etwas, wenn euer Softwaresystem erfolgreich ist? Haben sie eine Hidden Agenda und manipulieren euere Entwicklung vielleicht sogar? 5 | 6 | Geht entsprechend der Ansichten über euer Softwaresystem auf die jeweiligen Personen zu: 7 | * Wie könnt ihr Influencer besser informieren? 8 | * Wie könnt ihr Zusicherungen nachhalten? 9 | * Wen könnt ihr besser in die Pflicht nehmen? 10 | * Wer kann euch helfen, wenn ihr etwas eskalieren müsst? 11 | 12 | **Mehr Informationen** 13 | * Verwandte Methode der [Stakeholder Analysis](https://gamestorming.com/stakeholder-analysis/) -------------------------------------------------------------------------------- /_descriptions/card17_codesmell.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Code-Smell-Monster 3 | --- 4 | Ähnlich wie in Horrorfilmen, gibt es auch in der Softwareentwicklung Monster. Diese kosten euch zwar nicht das Leben, dafür aber sehr viel Zeit, Nerven und im schlimmsten Fall Geld. Gottklassen, von denen eine riesige Anwendung abhängt, switch-Anweisungen mit unzähligen Einträgen oder eine Parameterliste, welche den halben Bildschirm einnimmt: all das sind die Monster, die uns jeden Tag begegnen können. Wie sieht dein persönliches Code-Smell-Monster aus? Male es auf die Karte und überlege dir, wie du es besiegen kannst. 5 | 6 | **Weitere Informationen** 7 | - Das Buch [Working Effectively with Legcay Code](https://www.oreilly.com/library/view/working-effectively-with/0131177052/) von Michael Feathers behandelt einige dieser Themen und zeigt passende Refactorings. -------------------------------------------------------------------------------- /_descriptions/card18_dokucheck.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Checkliste Dokumentation 3 | --- 4 | Oft haben wir hunderte Seiten Dokumentation – und gefühlt versteht diese niemand oder sie ist hoffnungslos veraltet. In der Folge wird meist weniger Dokumentation erstellt oder vorhandene nicht mehr weiter gepflegt. Selten hinterfragen wir allerdings den Grund für das Unverständnis. Mit unserer Checkliste könnt ihr in ein paar Minuten prüfen, ob die vorhandene Dokumentation korrekt auf die Zielgruppe abgestimmt und auf dem aktuellen Stand ist. 5 | 6 | Hakt dafür bei jedem Aspekt, den ihr klar mit "Ja!" beantworten könnt, das entsprechende Kästchen an. Gibt es Aspekte, die nicht OK sind? Dann habt ihr schon die ersten Anhaltspunkte, wo ihr eure Dokumentation schrittweise verbessern könnt. Idealerweise führt ihr diesen Check regelmäßig durch, damit ihr sicher sein könnt, dass eure Dokumentation immer zielgerichtet und aktuell bleibt. 7 | 8 | -------------------------------------------------------------------------------- /_descriptions/card19_idol.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Was würde ___ tun? 3 | examples: idol_1.png 4 | --- 5 | Ihr wisst bei einem kniffligen Problem nicht mehr weiter? 6 | Ihr müsst etwas schnell umsetzen, habt aber eine Denkblockade? 7 | Ihr seid verzweifelt, weil euch die einfachsten Ideen fehlen? 8 | 9 | Fragt euch: Was würde jetzt eine Person, zu der ihr aufschaut, in eurer Situation machen? 10 | 11 | - Was würde Margaret Hamilton über eure "Herausforderungen" bei der Umsetzung von zuverlässiger Software sagen? 12 | - Wie würde James Bond die Performance-Bottlenecks mit der Datenbank eliminieren? 13 | - Was würde das Krümelmonster mit euren zahlreichen Ticket-Leichen tun? 14 | 15 | Zieht euch aus eurer misslichen Lage, indem ihr euch bewusst eine andere Sichtweise auf eure Probleme schafft! 16 | -------------------------------------------------------------------------------- /_descriptions/card20_zauberstab.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Der goldene Zauberstab 3 | --- 4 | Wäre es nicht schön, wie Hermine Granger in "Harry Potter" den Zauberstab schwingen zu können 5 | und sofort ist die Brille – oder in unserem Fall ein Software-System – repariert? 6 | 7 | Leider ist die Welt nicht so einfach und wir haben keinen Weg, um per Zauberspruch unsere Probleme zu lösen. 8 | Stattdessen bedarf es viel harter Arbeit, um problematische Systeme zurück in geordnete Bahnen zu führen. 9 | 10 | Aber vielleicht hilft es euch beim Nachdenken, wenn ihr unseren goldenen Zauberstab schwingt. Überlegt euch, 11 | was euer Zauberspruch reparieren würde, wenn ihr die Möglichkeit hättet. Diskutiert anschließend die Ergebnisse in der Gruppe. 12 | Und wer weiß, vielleicht findet sich ja ein magischer Einfall, der das ein oder andere Problem löst. -------------------------------------------------------------------------------- /_descriptions/card21_powerskills.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Powerskills 3 | --- 4 | Verschiedene Softwaresysteme mit ihren verschiedenen Softwarearchitekturen brauchen auch verschiedene Fähigkeiten der Beteiligten, um erfolgreich zu sein. 5 | 6 | - Welche Fähigkeiten wären in eurem Team von großem Nutzen? 7 | - Habt ihr im Team die notwendigen Skills? 8 | - Welche Skills nimmt ihr implizit an, habt es aber nicht kommuniziert? 9 | 10 | Findet es mit dieser Karte heraus, in dem ihr die vier wichtigsten Skills in die vier Felder schreibt! Ihr wollt es noch genauer machen? Dann vergebt zusätzlich noch Punkte zwischen 0-100, um die Ausprägung der jeweiligen Fähigkeit festzulegen. 11 | 12 | Stellt ihr fest, dass euch notwendige Skills fehlen, sucht nach Möglichkeiten, euch diese gezielt anzueignen oder holt euch Leute in euer Team, die diese Skills besitzen. -------------------------------------------------------------------------------- /_descriptions/card22_traum.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Traum 3 | --- 4 | Wir Techies können es oft gar nicht erwarten, bei einem neuen Softwareprojekt in die Tasten zu hauen. 5 | Zu selten fragen wir uns aber: "Sind denn die Grundlagen für ein erfolgreiches Softwaresystem bekannt?" 6 | 7 | Ist dies nicht der Fall ist, kann sich ein Team noch so stark anstrengen: 8 | - Die Motivation wird stetig abnehmen, da eine gemeinsame Zielvorstellung im Team fehlt. 9 | - Böse Überraschungen in Form von Risiken lauern hinter jeder Ecke, da an sie nicht gedacht wurde. 10 | - Ständige Konflikte und Spannungen werden euch begegnen, da wichtige Trade-Offs nicht abgewogen und offengelegt wurden. 11 | - Die Ziele für die relevanten Stakeholder werden nicht erreicht werden, da beides nicht bekannt ist. 12 | 13 | Diese Checkliste hilft euch bei der Einschätzung, ob ihr in der Anfangsphase eures Projekts an die wichtigsten Dinge gedacht habt, und gibt Denkanstöße, was euch noch fehlen könnte. 14 | 15 | 16 | **Weitere Informationen** 17 | * Michael Keeling gibt in seinem Buch "Design It! From Programmer to Software Architect" viele Denkanstöße für erfolgreiche Softwareprojekte 18 | * Der Softwarearchitekturdokumentationsbaukasten [arc42](https://arc42.org/) bietet Platz, um die wichtigsten Dinge einer Software festzuhalten -------------------------------------------------------------------------------- /_descriptions/card23_investment.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Investment-Sanity-Checker 3 | --- 4 | Investitionen sagen viel über den Status eines Softwareprojektes aus. 5 | Häufig müsst ihr als Architekt\*innen technische Themen (*wichtig*) gegenüber 6 | den Produktthemen (*dringend*) vertreten. 7 | 8 | **Support/Bugfixing** – Fehler sind oft leichter zu beheben, je eher sie im Zyklus der Softwareentwicklung gefunden werden. 9 | Hotspots bei Fehlern sind gute Kandidaten für Refactorings. 10 | Ihr solltet hier idealerweise einen Wert unterhalb von 10% haben – sehr wahrscheinlich 11 | ist der Wert aber größer. 12 | 13 | **Technische Verbesserungen** – Reduziert ihr technischen Schulden eures Systems, 14 | so verbessert ihr dadurch die Qualität der Software und reduziert gleichzeitig 15 | die Kosten für Fehlerbehebung sowie Entwicklungszeiten neuer Themen. 16 | Die Empfehlung liegt bei etwa 10-15%. 17 | 18 | **Neue Features** – Die Entwicklung neuer Funktionen bringt den Geschäftswert, 19 | daher solltet ihr hier am meisten investieren. 20 | Mindestens 50% oder mehr eurer Entwicklungszeit solltet ihr darauf verwenden, 21 | neuen Wert zu schaffen. 22 | 23 | **Architekturarbeit** – Nur durch kontinuierliche Arbeiten an der Architektur 24 | könnt ihr die Software am Leben halten und ermöglicht das Adressieren 25 | neuer Zukunftstrends sowie Anforderungen. Ein Empfehlungswert liegt hier bei 15-20% 26 | in größeren Projekten. 27 | 28 | **Mehr Informationen** 29 | * [aim42 - Architecture Improvement Method](https://www.aim42.org/) 30 | -------------------------------------------------------------------------------- /_descriptions/card24_minidoku.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Minidoku 3 | --- 4 | Viele Personen verbinden mit Architekturdokumentation lange und komplexe Dokumente, 5 | deren Aussagekraft meist fragwürdig ist. Dementsprechend hoch sind die Hürden, selbst 6 | mit einer Dokumentation anzufangen. Dass dies aber auch ganz einfach sein kann, demonstriert unsere 7 | Minidoku. 8 | 9 | Beginne damit, den geschäftlichen Grund der Software zu nennen oder kurz zu beschreiben. Damit 10 | ist klargestellt, warum man diese Software überhaupt braucht. Anschließend notiere die drei wichtigsten 11 | Qualitätsmerkmale, geordnet nach ihrer Priorität. Zum Schluss werden noch die wichtigsten Design-Entscheidungen 12 | skizziert, damit diese nachhaltig dokumentiert und nachvollziehbar sind. 13 | 14 | Mit dieser Minidoku ist dann auch erfolgreich der Grundstein zu einer umfangreicheren Architekturdokumentation gelegt. 15 | Um diese ohne unnötigen Overhead zu erstellen, kann z. B. ein Template wie arc42 verwendet werden. 16 | 17 | **Mehr Informationen** 18 | 19 | * [Offizielle Seite von arc42](https://arc42.org/) 20 | * Buch [Primer - Softwarearchitekturen pragmatisch dokumentieren](https://leanpub.com/arc42-primer) 21 | * Leichtgewichtiges, entwicklerfreundliches Dokumentieren mit dem [Docs-As-Code-Ansatz](https://docs-as-co.de/) 22 | -------------------------------------------------------------------------------- /_descriptions/card25_wege.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Nicht eingeschlagene Wege 3 | --- 4 | 5 | Jeden Tag werden Entscheidungen getroffen, die unsere Software oft langfristig 6 | gestalten. Jeder dieser Entscheidungen liegen mehrere Optionen zu Grunde, 7 | von denen allerdings immer nur eine als Lösungsansatz gewählt werden kann. 8 | Die gewählte Option wird meistens in einer Architekturdokumentation beschrieben und ist damit 9 | nachvollziehbar. Was ist aber mit den Optionen, die ebenfalls betrachtet aber nicht 10 | ausgewählt wurden? Auch diese sollten dokumentiert werden, um die getroffenen Entscheidungen 11 | langfristig nachvollziehen zu können. 12 | 13 | Überlegt euch nun, welche Wege ihr bewusst nicht in eurer Software eingeschlagen habt. 14 | Tragt diese auf der Karte ein und beschreibt, was der Grund für die Ablehnung der einzelnen Optionen 15 | war. Die Ergebnisse dieser Karte könnt ihr beispielsweise verwenden, um **Architecture Decision Records** 16 | für eure Software anzulegen, um so deren Historie nachvollziehbarer zu gestalten. 17 | 18 | **Mehr Informationen** 19 | 20 | * [Einstiegsseite für das Thema ADR](https://adr.github.io/) 21 | * [Initiale Vorstellung der Idee von ADRs](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) -------------------------------------------------------------------------------- /_descriptions/card26_expertise.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: How to learn X 3 | --- 4 | 5 | Niemand von uns kann alles, aber sicher kann jede/r etwas besonders gut. 6 | Dieses besondere Wissen zu teilen, hilft euch, euer Team noch besser zu machen 7 | und Wissensinseln zu verringern. 8 | 9 | Was ist also euer absolutes Expertenthema? Schreibt dieses Thema – jede und jeder für sich – auf eine Karte und überlegt 10 | euch, welche fünf Anleitungen, Bücher, Blogs oder sonstige Ressourcen euch dabei geholfen haben, 11 | in das Thema einzusteigen. Sortiert diese, beginnend bei der leichtesten Einstiegsressource, und 12 | schreibt sie ebenfalls auf die Karte. 13 | 14 | Tauscht euch im Anschluss über eure Ergebnisse aus. Hat vielleicht 15 | noch jemand dieses Thema gewählt und es war niemandem bewusst? Perfekt! 16 | Denn dadurch ergibt sich eine größere Ansammlung an Wissen und vielleicht auch unterschiedlichen Lernressourcen. 17 | Sammelt die ausgefüllten Karten idealerweise an einem Ort, der jeder und jedem im Team zugänglich ist. 18 | So könnt ihr jederzeit auf die Lernressourcen zurückgreifen und euer Wissen erweitern. 19 | -------------------------------------------------------------------------------- /_descriptions/card27_minirisiko.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Risikominimierung 3 | --- 4 | Auch wenn wir es ungerne hören: Risiken begleiten unsere Projekte 5 | vom ersten Moment an. Häufig wird jedoch vergessen, sowohl diese Risiken als auch deren Gegenmaßnahmen, 6 | entsprechend zu dokumentieren. Dies kann später fatale Folgen 7 | haben, wenn beispielsweise auf zu fragile Nachbarsysteme gesetzt, oder vielleicht 8 | auch relevante Regulatorik übersehen wird. 9 | 10 | Überlegt euch, welche Risiken es in eurem Projekt gibt und dokumentiert je ein Risiko pro Karte. 11 | Im Anschluss daran notiert ihr die Maßnahme zur Minimierung des Risikos und die davon erwarteten Auswirkungen. 12 | 13 | Diskutiert die Ergebnisse miteinander. Habt ihr möglicherweise ein bisher unbekanntes Risiko entdeckt? 14 | Sehr gut! Damit könnt ihr euer Projekt gleich etwas sicherer machen und die Architekturdokumentation erweitern. 15 | Zusätzlich könnt ihr sowohl euch als auch betroffene Stakeholder dafür sensibilisieren. 16 | -------------------------------------------------------------------------------- /_descriptions/card28_vergleich.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Businessability 3 | --- 4 | 5 | Wer kennt es nicht: Man darf ein neues Projekt starten und hat die Qual der Wahl bei 6 | der Auswahl der zu nutzenden Technologie. Als Techniker\*in nimmt man natürlich am liebsten 7 | die neueste Sprache oder das neueste und hipste Framework, aber ist das wirtschaftlich 8 | überhaupt vertretbar? Häufig gibt es für neue Technik kaum Support, wenige Spezialisten 9 | und hier und da muss auch das Rad erst wieder neu erfunden werden. Das alles kostet Geld – 10 | im Worst Case sehr viel Geld. Damit ihr den wirtschaftlichen Faktor einer Technologieentscheidung 11 | nicht vernachlässigt, hilft euch diese Karte, die wichtigsten Fragen zu beantworten. 12 | 13 | Vergleicht dazu zwei Technologien, die ihr für euer Projekt auswählen würdet. Dann 14 | entscheidet für jede Frage, welche der beiden die Anforderungen besser erfüllt. Dazu könnt ihr ein für 15 | euch passendes Bewertungssystem nutzen, beispielsweise eine Bewertungsskala von 1-5. Zählt am 16 | Ende die Einzelbewertungen pro Technologie zusammen und vergleicht das Ergebnis. Möglicherweise 17 | seid ihr überrascht, dass vielleicht doch nicht die neue Supertechnologie "gewonnen" hat, sondern 18 | etwas Älteres und Etabliertes. 19 | 20 | Das Ergebnis dieser Bewertung könnt ihr nun für die weitere Projektplanung und eine Architekturdokumentation nutzen. 21 | Außerdem hilft euch die Bewertung dabei, eine Entscheidung auch bei Projektleiter\*innen / -manager\*innen vertreten zu können, 22 | die weniger auf Technik, aber dafür umso mehr auf Wirtschaftlichkeit einer Lösung achten. -------------------------------------------------------------------------------- /_descriptions/card29_roadmap.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Technologie-Roadmap 3 | --- 4 | Kennt ihr das? Ihr kommt ganz frisch von einer Konferenz und möchtet den ganzen neuen Kram jetzt und sofort bei euch umsetzen. Dann aber denkt ihr darüber nach, und irgendetwas hindert euch dann doch daran: der ganze vorhandene alte Kram! 5 | 6 | Es sind oft die vorhandenen Rahmenbedingungen, welche es (zumindest jetzt) schwer machen, den Tech-Stack zu aktualisieren. Aber wie könnt ihr frühzeitig kommunizieren, dass ihr schon die ein oder andere neue Sache im Blick habt? 7 | 8 | Diese Karte hilft euch, einen klaren Kopf zu behalten, anstatt zu verzweifeln und das Handtuch zu werfen. Legt offen, welche Technologie ihr in welchem Stadium der Adaption seht. Bewertet nicht nur die neuen Trend-Themen, welche ihr interessant für eure Software findet, sondern versucht auch, bereits verwendete Technologie in eine der folgenden Stadien einzuordnen und damit die aktuelle Sichtweise auf die Technologien zu kommunizieren: 9 | 10 | 1. **Abwarten**: Schon gehört, passt jetzt noch nicht direkt zu uns 11 | 2. **Ansehen**: Könnte interessant sein, wir informieren uns näher 12 | 3. **Austesten**: Es gibt einen guten Anwendungsfall, den wir umsetzen 13 | 4. **Anwenden**: Ja, hat sich bewährt, wir nehmen das jetzt ins Standardportfolio 14 | 5. **Aufhören**: Ok, wir wollen hier langsam mal weg davon 15 | 6. **Abbauen**: Überall, wo wir darüber stolpern, kommt es raus 16 | 17 | **Mehr Informationen** 18 | 19 | * Ein ähnliches Vorgehen ist im [Technology Radar](https://www.thoughtworks.com/de/radar) zu finden (welches wir zur Inspiration nutzten) -------------------------------------------------------------------------------- /_descriptions/card30_nutzen.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Kundennutzen 3 | --- 4 | _"Lasst uns doch dieses neue Framework einbauen, das letzte Woche erschienen ist!"_ 5 | 6 | Bestimmt habt ihr in einem eurer Projekte diese Aussage in ähnlicher Form 7 | schon einmal gehört oder gar selbst getroffen. 8 | In erster Linie schreibt ihr eure Software für eure Anwender\*innen oder euren Kund\*innen. 9 | Und dennoch wird bei Entscheidungen viel zu selten darauf geachtet, 10 | welchen Nutzen eure Zielgruppe von der bevorstehenden Änderung hat. 11 | 12 | Ihr wollt ein eigenes komplexes Logging-Framework für eure Software schreiben und 13 | rechnet mit ca. sechs Wochen Entwicklungszeit? Dies wird für die Stakeholder sehr wahrscheinlich 14 | – hoffentlich! – keine spürbaren Auswirkungen haben, 15 | hindert euch aber gleichzeitig daran, in dieser Zeit neue Features zu entwickeln. 16 | 17 | Ihr habt vor, eine weitere, neue Bezahlmethode in euerem System zu integrieren, 18 | seid aber nicht sicher, ob dafür neun Wochen Entwicklung verwendet werden können? 19 | Viele eurer Anwender\*innen könnten dankbar sein, dass sie eine neue Möglichkeit bekommen, 20 | Produkte bei euch zu bezahlen. Dieses Feature hat also einen sehr großen Nutzen. 21 | 22 | Mit dieser Karte könnt ihr bei euren nächsten Entscheidungen überprüfen, 23 | wie viel Nutzen die Anwender\*innen daraus ziehen und ob die Änderungen tatsächlich 24 | sinnvoll oder notwendig sind. 25 | 26 | **Mehr Informationen** 27 | - [Value Chains und Wardley Maps](https://www.cio.com/article/196094/an-introduction-to-wardley-value-chain-mapping.html) 28 | - [Markus Top 5 Empfehlungen für den Einstieg in Wardley Maps](https://www.feststelltaste.de/top-5-learning-wardley-maps/) -------------------------------------------------------------------------------- /_descriptions_EN/card01_expectation.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: ResourceAllocationExpectation 3 | layout: card_page 4 | slug: expectation 5 | --- 6 | We are often trapped in our own world with all its restrictions. We are conditioned to be modest – this leads to solutions that are modest as well. 7 | 8 | But what if you only had infinite resources (time, money, people, ...)? What would you then do with your software system? What is the maximum amount of meaningful resources that still make sense? How far away are you from getting those? What valuable resources can you get your hands on today that make your software system tremendously better? 9 | 10 | Collect the opportunities on this map and discuss them with your team! 11 | 12 | -------------------------------------------------------------------------------- /_descriptions_EN/card02_quickcheck.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Architecture quick check 3 | layout: card_page 4 | slug: quickcheck 5 | --- 6 | Important quality attribute goals significantly determine decision-making in the implementation of software systems. In this quick check, you can compare your top 3 quality goals with the implemented solutions to check if they fit together. 7 | 8 | Find out first what the top quality attribute goals are. Then identify the essential architectural approaches of your software system. These are all the technical stuff you would talk about with a tech-savvy person who wants to know how you have designed your software system. Then estimate how well the architecture approach supports (or contradicts) the fullfillment of a quality goal. 9 | 10 | If they don't match, double-check that your quality goals are still the right ones or if you've chosen the wrong approaches for your software system. 11 | 12 | **More information** 13 | 14 | * Article about [Quality-Driven Software Architecture](https://www.innoq.com/en/articles/2021/08/quality-driven-software-architecture-revised/) from Gernot Starke 15 | * Evaluation method [Architecture Tradeoff Analysis Method](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513908) 16 | -------------------------------------------------------------------------------- /_descriptions_EN/card03_adr.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Architecture Decision Record 3 | layout: card_page 4 | slug: adr 5 | --- 6 | In software systems that have been under development for a long time, it becomes challenging to understand decisions made in the past. Therefore it is essential to document decisions and their motives understandably. 7 | 8 | With the help of Architecture Decisions Records (ADRs), it is possible to document decisions in light and consistent ways. In addition, the motivation for a decision, the thought processes that led to the decision, and the context (time, knowledge, participants, ...) are recorded, too. 9 | 10 | With this template, you could practice structuring your decisions according to the ideas of the ADRs: 11 | 12 | * Title: What decision is at stake? 13 | * Status: What is the status of the ADR? List rejected or obsolete ADRs! 14 | * Context: Why decide now? What were the circumstances? 15 | * Decision: What was the decision and what were the alternatives? 16 | * Consequences: With which advantages and disadvantages do we want to live from now on? 17 | 18 | 19 | **More information** 20 | 21 | * [Website about ADRs](https://adr.github.io/) 22 | * [Initial introduction of the idea of ADRs](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) 23 | * [Examples of ADRs of the open-source project Arachne Web Framework](https://github.com/arachne-framework/architecture) 24 | -------------------------------------------------------------------------------- /_descriptions_EN/card04_cake.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: The 8-hour cake 3 | layout: card_page 4 | slug: cake 5 | alt: The card shows a circle that represents a cake. This cake is divided into eight pieces. Each piece stands for an hour. By writing down the actual work you do during the day, you should find out which parts of the day you're using ineffectively. 6 | --- 7 | The day has 24h and then there is the night, too. — A former professor of Markus. 8 | 9 | ...and suddenly the day was over. But what did you get done? This pie chart can help you see what you've been spending your precious time on: 10 | 11 | 12 | * Are you using your time effectively? 13 | * Which of the time slots can you simply get rid of? 14 | * Are you achieving maximum utilization of your time? 15 | 16 | Assess the time you spent! See if others determine how you work or if you have control over your own time: 17 | 18 | * How much time do you invest in future-oriented work? 19 | * How much time do you expend on unplanned work? 20 | * How much time is spent on routine tasks? 21 | 22 | **More information** 23 | 24 | * Take a look at the [Pomodoro technique](https://francescocirillo.com/pages/pomodoro-technique) for better time management 25 | * The book [Project Phoenix](https://itrevolution.com/the-phoenix-project/) gives plenty of tips for designing your own work more effectively 26 | -------------------------------------------------------------------------------- /_descriptions_EN/card05_productbox.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Your product box 3 | layout: card_page 4 | slug: productbox 5 | --- 6 | The vision or the goal is often missing in aging software systems. What is the right path? For whom are we doing all this? Does it even make sense anymore? 7 | 8 | The product box helps you to find meaningful answers for your software from the customers' point of view: 9 | 10 | * What is actually being developed? 11 | * Who has the benefit? 12 | * What are the central selling points and reasons for use? 13 | * What are the core functions? 14 | * What is the unique selling point of your product (compared to other products or the previous version)? 15 | 16 | You will better understand what you are creating software for by answering these questions. 17 | 18 | **More information** 19 | 20 | * [Design the Box](https://gamestorming.com/design-the-box/) method from gamestorming.com 21 | 22 | -------------------------------------------------------------------------------- /_descriptions_EN/card06_standards.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Do you work according to common development standards? 3 | layout: card_page 4 | slug: standards 5 | --- 6 | Over the years, standards emerged from software systems and software development practices. 7 | Some of them have been proven to positively influence the development and evolution of a software system regardless the context. 8 | 9 | Check within your team which of these standards you are implementing. Where are the potential needs for improvement? In addition, think about why you have not yet addressed missing or insufficient measures. 10 | 11 | **More information** 12 | 13 | * The book [Accelerate](https://itrevolution.com/book/accelerate/) provides scientific evidence good practices for software development -------------------------------------------------------------------------------- /_descriptions_EN/card07_coaster.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Architecture on a beer coaster 3 | layout: card_page 4 | slug: coaster 5 | --- 6 | The system is too complex to put on a piece of paper! – this or something along those lines has certainly been a phrase you've heard before as an excuse to avoid visualizing your software architecture. 7 | 8 | However, a well-structured software system can fit on a beer coaster – if you choose the right level of abstraction and scope! 9 | 10 | Try to sketch the most important aspects of your software's structure on this card. 11 | 12 | * When do you encounter space limitations? Do you have too much unnecessary information in it? 13 | * Does it get too detailed in some places? Could the system be abstracted in different ways? 14 | * Don't you even know what you are supposed to draw? Do you know how you can hide complexity with blackboxes and hierarchization? 15 | 16 | Discuss your drawing approach as well as the outcome. Think about what measures you can take to communicate the structure of your software system even more clearly. 17 | 18 | **More information** 19 | 20 | * The [documentation drawer system arc42](https://arc42.org/) defines different views on your software system that might help you to communicate your system's structure. 21 | * The [C4 model](https://c4model.com/) provides defined views and abstraction levels for visualizing your software architecture. -------------------------------------------------------------------------------- /_descriptions_EN/card08_unknown.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: The unknown familiar 3 | layout: card_page 4 | slug: unknown 5 | --- 6 | You might have already encountered this problem: You think you're doing everything right, but suddenly, a stakeholder wants something completely different. The lack of understanding is huge and frustration increases. 7 | 8 | What do you think drives this person? Try to put yourself in their shoes and think about the underlying motivation behind the stakeholder's behavior. How can you respond to their needs to make the situation more productive and more agreeable for everyone? 9 | 10 | **More information** 11 | 12 | * The [Mini Quality Attributes Workshop](https://re-magazine.ireb.org/articles/discover-quality-requirements-with-the-mini-qaw) is essentially about better understanding other stakeholders and their needs 13 | * Article about [Empathy Driven Development](https://www.empathy-driven-development.com/why-empathy-will-transform-tech/) by Andrea Goulet -------------------------------------------------------------------------------- /_descriptions_EN/card09_pain.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: My most painful problem 3 | layout: card_page 4 | slug: pain 5 | alt: The card shows a form where you can write down the name and a short description of your most painful problem. Additionally, a pain scale lets you choose the severity of the problem. At the bottom of the cards, you can estimate the costs of the problem by writing down the frequency of occurrence and the minimal and maximum costs of the problem. 6 | --- 7 | Issues cause costs. If those costs of the issue are disproportionately higher than the costs of the solution, it is profitable to address the issues for economic reasons. 8 | 9 | This card helps you to record a very important problem in a structured way and lets you estimate the associated pain and costs. The interval for your problem cost estimation allows you to indicate how certain or uncertain you are with your estimation. If the interval is wide, it might be a good reason to take a deeper look into the problem or to divide it up into smaller ones. 10 | 11 | **More information** 12 | 13 | * The [Architecture Improvement Method aim42](https://aim42.github.io/#Estimate-Issue-Cost) shows further applications of issue cost estimation 14 | 15 | -------------------------------------------------------------------------------- /_descriptions_EN/card10_rootcause.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Root cause analysis 3 | layout: card_page 4 | slug: rootcause 5 | --- 6 | Software developers solve hundreds of small and large issues daily. We are therefore conditioned to work out solutions quickly. However, in some challenging situations, this is counterproductive. We often react with our trained solution repertoire to the first apparent problem that seems obvious to us. 7 | 8 | This card should help you overcome this initial instinct, whereby you first find out the real problems by asking concious why? questions. 9 | 10 | Try to use the so-called "5 Whys" in tricky situations to solve symptoms continuously and tackle the root causes of the problem at the right time. 11 | 12 | **More information** 13 | 14 | * Explanation of the [Root Cause Analysis](https://aim42.github.io/#Root-Cause-Analysis) on the Architecture Improvement Method aim42 -------------------------------------------------------------------------------- /_descriptions_EN/card11_success.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Sucess in the future 3 | layout: card_page 4 | slug: success 5 | --- 6 | Often there are self-evident solutions in front of us, which contribute significantly to the success of a software system, but we do not see them yet. We are too much caught with our narrow-mindedness in our daily business. 7 | 8 | This card solves this dilemma by deliberately taking you into the distant future. This opens up a completely different perspective on "today then" as you now look back on the present. 9 | 10 | Once you have arrived in the future, collect the TOP 3 actions that have happened to make your software system successful. Discuss afterward, again in the here and now, why you haven't taken the actions yet: 11 | 12 | * What needs to happen to make you better off? 13 | * What happened just before? 14 | * What happens up next? 15 | * How can you start now? 16 | 17 | **More information** 18 | 19 | * Article about the use of the [hypothetical press release](https://www.businessinsider.com/heres-the-surprising-way-amazon-decides-what-new-enterprise-products-to-work-on-next-2015-3?IR=T) at Amazon 20 | * Collection of [similar formats](https://www.funretrospectives.com/category/futurespective/), which work with future scenarios -------------------------------------------------------------------------------- /_descriptions_EN/card12_excuses.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: How bad are you talking about documentation to yourself? 3 | layout: card_page 4 | slug: excuses 5 | --- 6 | Writing documentation is one of the most unpopular tasks in software development. Very frequently, the importance of documentation is not appreciated or dismissed as cumbersome. 7 | 8 | Good documentation not only helps others but also benefits the person writing it. Writing and updating the documentation does not have to be magic. You can do it parallel to development – even within the already running development environment. Using arc42 provides a solid foundation for good and easy documentation of software architectures. 9 | 10 | **More information** 11 | 12 | * [Official Site of arc42](https://arc42.org/) 13 | * Lightweight, developer-friendly documentation with the [Docs-As Code Approach](https://docs-as-co.de/) -------------------------------------------------------------------------------- /_descriptions_EN/card13_waste.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: The waste case scenario 3 | layout: card_page 4 | slug: waste 5 | --- 6 | In many cases, one does not think about what led to the often fatal outcome until after the end of a project. In agile projects, retrospectives can help identify risks for a project at an early stage, but these are often limited to the past few weeks' events. 7 | 8 | In both cases, we could happily work our way through until we get a hard cut in the form of a project termination – which we can't even explain to ourselves at that point. 9 | 10 | But why does it have to come to this point? Think about what could cause your product to hit the wall in the near future. Do this for different time horizons to avoid being trapped in the here and now. Then use this knowledge to define and implement suitable countermeasures. 11 | 12 | **More information** 13 | 14 | * A similar approach are [pre-mortems](https://www.funretrospectives.com/pre-mortem-activity/), which help you to find weak spots in your way of developing a software system -------------------------------------------------------------------------------- /_descriptions_EN/card14_positioning.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Positioning 3 | layout: card_page 4 | slug: positioning 5 | --- 6 | Many teams are not aware of how great their software actually is and where dangers lurk for their success. The analysis of the current situation helps you to find unused opportunities and identify blind spots. 7 | 8 | Discuss among yourselves with which strengths your software can score points: 9 | 10 | * What has been going really well so far? 11 | * What are you really proud of? 12 | 13 | Also, ask yourself what weaknesses are currently present: 14 | 15 | * Where are you struggling? 16 | * What are you missing? 17 | 18 | On this basis, look for opportunities to compensate for the weaknesses identified: 19 | 20 | * What opportunities can you take in the near future? 21 | * What can you change yourself right away? 22 | 23 | Identify threats that are hidden in your software: 24 | 25 | * What are the unfavorable developments in your environment? 26 | * Where are the possible threats? 27 | 28 | **More information** 29 | 30 | * [SWOT analysis on gamestorming.com](https://gamestorming.com/swot-analysis/) 31 | -------------------------------------------------------------------------------- /_descriptions_EN/card15_debt.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Technical debt 3 | layout: card_page 4 | slug: debt 5 | --- 6 | The term "technical debt" already seems very jaded, vague and even abstract today. Make it clear what is meant by this term within your team for your software system. In the end, they are liabilities that you need to get rid of if it is worth it. Estimate what kind and how much of "technical debt" you are carrying. Define and discuss the found issues among yourselves so that it becomes clearer what your software system really lacks. 7 | 8 | **More information** 9 | 10 | * This [article by Martin Fowler](https://martinfowler.com/articles/is-quality-worth-cost.html) makes it clear why this topic needs to be addressed 11 | 12 | -------------------------------------------------------------------------------- /_descriptions_EN/card16_shitstorm.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Avoid the #shitstorm! 3 | layout: card_page 4 | slug: shitstorm 5 | --- 6 | There are people involved with and around your software who have a huge influence without you knowing it. Find out which persons have an important role in the success of your software product as well as how much and how they perceive your software system. Are they rather winners or beneficiaries? Or do they tend to lose something if your software system is successful? Do they have a hidden agenda and maybe even manipulate your development? 7 | 8 | Approach the respective persons according to their views about your software system: 9 | 10 | * How can you improve communication to influencers? 11 | * How can you keep assurances? 12 | * Who can be held accountable more effectively? 13 | * Who can support you if you need to escalate something? 14 | 15 | **More information** 16 | 17 | * Related method of [Stakeholder Analysis](https://gamestorming.com/stakeholder-analysis/) -------------------------------------------------------------------------------- /_descriptions_EN/card17_codesmell.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Code smell monster 3 | layout: card_page 4 | slug: codesmell 5 | examples: codesmell_1.png 6 | alt: A card with an empty instant picture in the middle. The text above tells the reader to think about a code smell and to draw that one into the empty picture. 7 | --- 8 | Similar to horror movies, there are also monsters in software development. They don't cost you your life, but they do cost you a lot of time, nerves and in the worst case even money. God objects upon which a huge application depends, switch statements with countless entries or a parameter list which takes up half of the screen: all these are monsters we may encounter every day. What does your personal code smell monster look like? Draw it on the card! Think about measures on how you can defeat it! 9 | 10 | **More information** 11 | 12 | - The book [Working Effectively with Legcay Code](https://www.oreilly.com/library/view/working-effectively-with/0131177052/) by Michael Feathers covers some of these topics and shows appropriate refactorings 13 | - [Refactoring Guru](https://refactoring.guru/refactoring/smells) lists a lot of code smells and measures on how to get rid of them 14 | - In the book [Refactoring for Software Design Smells](https://www.sciencedirect.com/book/9780128013977/refactoring-for-software-design-smells), Girish Suryanarayana, Ganesh Samarthyam and Tushar Sharma provide a taxonomy of code smells as well as many ideas for code improvement. -------------------------------------------------------------------------------- /_descriptions_EN/card18_doccheck.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Checklist for a better documentation 3 | layout: card_page 4 | slug: doccheck 5 | alt: A checklist with several items regarding good documenation. 6 | --- 7 | Often we have several hundred pages of documentation – and nobody seems to understand it. Or the documentation is hopelessly out of date. As a result, little or none documentation is usually created or existing documentation is no longer maintained by the developers. Rarely do we question the reasons for this lack of understanding. With our checklist you can verify in a few minutes whether the existing documentation is properly tailored to the target group and recent. 8 | 9 | Please cross the appropriate box for each question that you can answer with a clear "Yes". Are there certain areas that are not OK? Then you already have the first hints where you can improve your documentation step by step. Ideally, you should do this check regularly so that you can be sure that your documentation is always up to date and targeted towards your goals. 10 | 11 | **More information** 12 | 13 | - Gernot Starke about the [Principles of technical documentation](https://www.innoq.com/en/articles/2022/01/principles-of-technical-documentation/) -------------------------------------------------------------------------------- /_descriptions_EN/card19_idol.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: What would ___ do? 3 | layout: card_page 4 | slug: idol 5 | alt: The cards shows speech bubble where you can write down what your idol would do in your situation. 6 | --- 7 | Are you stuck with a challenging problem? 8 | Do you have to implement something swiftly but don't get an idea of how to do it? 9 | Are you desperate because you lack inspiration? 10 | 11 | Ask yourself: What would a person you admire do in your situation? 12 | 13 | - What would Margaret Hamilton say about your "challenges" in developing and implementing reliable software? 14 | - How would James Bond eliminate performance bottlenecks in the database? 15 | - What would the Cookie Monster do with your numerous zombie tickets? 16 | 17 | Get out of your pitfall by consciously creating a different perspective on your problems! -------------------------------------------------------------------------------- /_descriptions_EN/card20_wand.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: The conjurer's wand 3 | layout: card_page 4 | slug: wand 5 | alt: A cards that shows a magic wand. The text tells you to swing the card very hard. A smaller text says that this doesn't work to get rid of your problems. 6 | --- 7 | In a fantasy world, if the conjurer knows the real name of the evil she’s confronting, 8 | she can unsummon the demon with a flick of her wand. 9 | Wouldn't it be nice to be able to do the same, only with our software systems? 10 | 11 | Unfortunately, we developers are left without such a magical device. 12 | Even if we do know the root of evil in our software, there is rarely — or even never — a quick solution at hand. It takes a lot of hard work to improve our software system at least a little bit. 13 | 14 | But maybe this image of a conjurer's wand will help you reflect on your system while you're waving the card. 15 | Think about the fixes your spell could provide. 16 | And then discuss the results with your team. 17 | 18 | Who knows, maybe you might even come up with a magical idea that could solve a problem or two. 19 | -------------------------------------------------------------------------------- /_descriptions_EN/card21_superpowers.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: The Superarchitectodon 3 | layout: card_page 4 | slug: superpowers 5 | --- 6 | Different software systems with their varying software architectures also require different skills of the parties involved in order to be successful. 7 | 8 | - Which skills would be of particular value in your team? 9 | - Do you have the required skills within your team? 10 | - Which skills do you implicitly assume but have not yet communicated? 11 | 12 | Find out with this map by writing the four most important skills into the four fields! You want to be more precise? Then assign additional points from 0-100 to determine the level of the particular skill. 13 | 14 | If you detect that you lack the necessary skills, look for opportunities to acquire them or bring people into your team who possess these skills. -------------------------------------------------------------------------------- /_descriptions_EN/card22_dream.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Dream project's checklist 3 | layout: card_page 4 | slug: dream 5 | --- 6 | As developers, we often can't wait to start a new software project. 7 | But too rarely we ask ourselves: "Are the fundamentals for a successful software system known to us?" 8 | 9 | If this is not the case, no matter how hard a team tries: 10 | 11 | - The motivation will steadily decrease because a common goal is missing in the team. 12 | - Nasty surprises in the guise of risks lurk everywhere because they have not been anticipated. 13 | - You will encounter constant conflicts and tensions because necessary trade-offs have not been assessed and disclosed. 14 | - The goals for the relevant stakeholders will not be achieved, as neither of these are known. 15 | 16 | This checklist will help you assess whether you have thought of the most critical matters in the initial phase of your project and give you food for thought about what you might be missing. 17 | 18 | 19 | **More information** 20 | 21 | * Michael Keeling provides many hints for successful software projects in his book [Design It! From Programmer to Software Architect](https://pragprog.com/titles/mkdsa/design-it/) 22 | * The software architecture documentation toolkit [arc42](https://arc42.org/) provides space to record the most important things about the architecture of a software system -------------------------------------------------------------------------------- /_descriptions_EN/card23_investment.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Investment sanity checker 3 | layout: card_page 4 | slug: investment 5 | --- 6 | Investments reveal a lot about the status of a software project. 7 | Often you as an architect have to deal with technical matters (*important*) in contrast to the product matters (*urgent*). 8 | 9 | **Support/Bugfixing** – errors are often easier to fix the sooner they are identified in the software development cycle. 10 | Hotspots for errors are good candidates for refactoring. 11 | Ideally, you should get a value below 10% here – very likely, the value will be greater. 12 | 13 | **Technical improvements** – by reducing the technical debts of your system, you improve the quality of the software and at the same time reduce 14 | the costs for bug fixing as well as development times of new features. 15 | The recommendation is about 10-15%. 16 | 17 | **New features** – the development of new features brings business value, so you should invest the most here. 18 | At least 50% or more of your development time should be spent on this to create new value. 19 | 20 | **Architectural work** – Only through continuous work on the architecture can you keep the software alive and enable addressing new future trends and requirements. The recommendation is about 15-20% in larger projects. 21 | 22 | **More information** 23 | 24 | * _We are missing a reference here. Feel free to contact us if you come across it!_ 25 | * [aim42 - Architecture Improvement Method](https://www.aim42.org/) gives you plenty of ideas on how you can make investments the right way. 26 | -------------------------------------------------------------------------------- /_descriptions_EN/card24_minidoc.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Mini architecture documentation 3 | layout: card_page 4 | slug: minidoc 5 | --- 6 | Many people associate architecture documentation with long and complex documents — mostly of questionable validity. The barriers are correspondingly high, even to start with a documentation. But this can be quite simple, as demonstrated by our Minidocu. 7 | 8 | Start by stating the business reason for the software or briefly describe it. So 9 | it is clarified why you need this software at the first place. Then note the three most important quality attributes, sorted according to their priority. Finally, list the most important design decisions so that they are sustainably documented and verifiable. 10 | 11 | With this minimalistic version of a documentation, you can lay the foundation for a more comprehensive architectural documentation. 12 | To create this without unnecessary overhead, a template such as arc42 can be used. 13 | 14 | **More information** 15 | 16 | * The architecture documentation toolkit [arc42](https://arc42.org/) and especially the [FAQ section](https://faq.arc42.org/questions/B-4/) give you pointers to a minimalistic documentation. 17 | * Lightweight, developer-friendly documentation approach [Docs as Code](https://docs-as-co.de/) shows you how you can make documentation a first-class citizen. 18 | 19 | -------------------------------------------------------------------------------- /_descriptions_EN/card25_paths.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Paths not taken 3 | layout: card_page 4 | slug: paths 5 | --- 6 | Every day, decisions are taken that often have a long-term impact on our software system. 7 | Each of these decisions is based on several alternatives, of which, however, only one can ever be selected as a solution approach. 8 | The selected solution is usually described in an architecture documentation and is therefore comprehensible. 9 | But what about the alternatives, which have also been considered but were not chosen? 10 | These should also be documented so that the decisions made can be understood in the long term. 11 | 12 | Now, think about which paths you deliberately did not follow in your software. 13 | Write them down on the card and describe the reasons for the rejection of the individual alternative. 14 | 15 | **More information** 16 | 17 | * Michel Keeling lists "Paths not taken" as one of dozens of activities in his marvelous book [Design It!](https://pragprog.com/titles/mkdsa/design-it/) 18 | * [Introductory page for the topic ADR](https://adr.github.io/) 19 | * [Initial presentation of the idea of ADRs](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) -------------------------------------------------------------------------------- /_descriptions_EN/card26_expertise.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: How to learn X? 3 | layout: card_page 4 | slug: expertise 5 | --- 6 | 7 | None of us can do everything, but surely each of us can do something especially well. 8 | Sharing this special knowledge helps you to make your team even better and reduce knowledge islands. 9 | 10 | So, what is your special subject of expertise? 11 | Write the topic down on a card and think about which five guides, books, blogs, or other resources you would recommend to others to get started. Sort them, starting with the most basic resource, and write them on the card as well. 12 | 13 | Afterwards you can discuss your results. Maybe someone else choose the same topic as well and nobody was aware of it? Awesome! You're the only expert in a subject? Why don't you give a talk about it? 14 | 15 | If you do this with your team, this will result in a greater distribution of knowledge. 16 | Ideally, collect the filled cards in a location that is accessible to everyone in the team. 17 | This allows everyone to access the learning resources and expand their knowledge at any time. 18 | 19 | * Markus Harrer lists some of his personal TOP 5's [on his blog](https://www.feststelltaste.de/category/top5/). -------------------------------------------------------------------------------- /_descriptions_EN/card27_minirisk.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Risk minimization 3 | layout: card_page 4 | slug: minirisk 5 | --- 6 | Although we hate to hear it: risks are part of our projects from the very first moment. 7 | Often, however, both these risks and their countermeasures are forgotten to be documented accordingly. 8 | This can later have fatal consequences if, for example, you have relied on too fragile adjacent systems, or perhaps also ignored relevant regulatory issues. 9 | 10 | Think about the risks in your project and document one risk per card. 11 | Afterwards, write down the measures you have taken to minimize the risk and the expected impact. 12 | 13 | Discuss the results with each other. Perhaps you have discovered a previously unknown risk? 14 | Very good! Now you can make your project a bit safer and extend the architecture documentation. 15 | In addition, you can raise the awareness of both yourself and affected stakeholders. -------------------------------------------------------------------------------- /_descriptions_EN/card28_businessability.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Businessability 3 | layout: card_page 4 | slug: businessability 5 | --- 6 | 7 | Everybody has experienced it: You are allowed to start a new project and are spoiled of choices when it comes to the selection of technologies to be used. 8 | As a engineer, of course, one prefers to take the latest programming language or the latest and hottest framework, but is it economically even justifiable? 9 | Often there is hardly any support for new technology, few specialists exists and ocassionally the wheel also has to be reinvented. 10 | All this costs money – in the worst case, a lot of money. 11 | In order for you to understand the economic factor of a technology decision, this card will help you to answer the most important questions. 12 | 13 | To do this, compare two technologies that you would choose for your project. 14 | Then decide for each question which of the two meets the requirements better.You can use a rating system that suits you, for example, a scale from 1-5. 15 | At the end, sum up the individual score per technology and compare the results. You may be surprised that perhaps it is not the new super technology that has "won" but something older and more established. 16 | 17 | You can now use the result of this evaluation for further project planning and architectural documentation. 18 | The evaluation also helps you to be able to support your decision to the project manager, who pays less attention to technology but all the more to the economic efficiency of a solution. 19 | 20 | **More information** 21 | 22 | - [The "Boring Software" manifesto](https://tqdev.com/2018-the-boring-software-manifesto) give you ideas at what you'll also need to look at when you want to choose a technology -------------------------------------------------------------------------------- /_descriptions_EN/card29_roadmap.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Technology roadmap 3 | layout: card_page 4 | slug: roadmap 5 | alt: A card that shows six road signs. Each sign stands for a different stage of adoption of a certain technology. All signs contain a box underneath where you can write down several technologies for a specific stage. 6 | --- 7 | Do you recognize this? Developers just returned from a conference and would like to put all the new stuff they've just heard of into the software system right now? The temptation might be great, but "conference-driven development" isn't the best approach and all the existing stuff constrains your freedom of choice, too. 8 | 9 | How can you communicate that you address the developers' ideas about renewing your tech stack and keep the balance with the stuff that's already existing? This card allows you to set a roadmap for the technologies you use or want to use in your software system. Put your new and existing technologies in different stages of adoption: 10 | 11 | 1. **Hold on**: Already heard; doesn't really fit to us yet 12 | 2. **Assess**: Could be interesting; we'll find out more about this 13 | 3. **Trial**: There's a good use case that we're implementing in our context 14 | 4. **Apply**: Yes, it's worked out well; we're adding it to our standard portfolio 15 | 5. **Stop**: Okay, we're not gonna use it in new projects anymore 16 | 6. **Remove**: Everywhere where we come across it, we remove it 17 | 18 | By doing this, you achieve two goals: Developers with the urge to introduce new technologies feel heard because they see that you have addressed their ideas by putting them on the roadmap. On the other end, developers see which technologies they don't need to invest time to learn certain technologies that'll get removed soon. 19 | 20 | PS: This roadmap is not limited to technology only. You can also communicate practices and methodologies you want to apply or get rid of. 21 | 22 | **More information** 23 | 24 | * A similar procedure can be found in the [Technology Radar](https://www.thoughtworks.com/radar) (which we used as inspiration). We added the stages "stop" and "remove" because we thought you could not just put stuff into software systems, but you also have to get rid of them. 25 | 26 | -------------------------------------------------------------------------------- /_descriptions_EN/card30_value.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Where is the value for the user? 3 | layout: card_page 4 | slug: value 5 | alt: A cards with an arrow on the y-axis on the left side named "value for the user) 6 | --- 7 | *"Let's add this new framework that was launched last week!"* 8 | 9 | I'm sure in one of your projects you have heard this statement in a similar form before or even made it yourself. 10 | First and foremost, you develop your software for your users. 11 | And yet, far too little attention is paid to this when making decisions, what benefits your target group has from the upcoming change. 12 | 13 | You want to write your own complex logging framework for your software and 14 | estimates a development time of about six weeks?This will most likely have no noticeable impact on stakeholders, but simultaneously prevents you from developing new features during this time. 15 | 16 | You plan to integrate another new payment method into your system, but aren't you sure if nine weeks of development time can be spent on this? 17 | Many of your users might be grateful to have a new opportunity. 18 | This will most likely have no noticeable impact on stakeholders, but simultaneously prevents you from developing new features during this time. 19 | 20 | You plan to integrate another new payment method into your system, but aren't you sure if nine weeks of development time can be spent on this? 21 | Many of your users might be grateful to have a new option to pay for products. So this feature has a very big benefit. 22 | 23 | With this card you, can check your next decisions regarding how much benefit users get from the changes and whether your discussions actually are useful. 24 | 25 | **More information** 26 | 27 | - [Value Chains and Wardley Maps](https://www.cio.com/article/196094/an-introduction-to-wardley-value-chain-mapping.html) 28 | - [Markus's Top 5 learning resources for Wardley Maps](https://www.feststelltaste.de/top-5-learning-wardley-maps/) -------------------------------------------------------------------------------- /_includes/card_EN.html: -------------------------------------------------------------------------------- 1 | {% assign path_tokens = card.path | split: '/' %} 2 | 3 | {% assign file_tokens = path_tokens[1] | split: '_' %} 4 | {% assign image = file_tokens[0] %} 5 | {% assign tag = card.slug %} 6 |
7 |
8 |
9 |

{{ card.name }} ▲ ◫

10 |
11 |
12 |
13 |
14 | {% if card.alt %}{{card.alt}}{% else %}The image for the card with the name {{card.name}}{%endif%} 15 | 16 |
17 | Download: 18 | PNG 19 | PDF 20 | SVG 21 | {% if card.examples %} 22 | {% assign i = 1 %} 23 | {% for filename in card.examples %} 24 | Example {{i}} 25 | {% assign i = i | plus:1 %} 26 | {% endfor %} 27 | {% else %} 28 | {% endif %} 29 | 30 |
31 |
32 | {{ card.content | markdownify }} 33 |
34 |
35 |
-------------------------------------------------------------------------------- /_includes/footer_EN.html: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /_includes/head_EN.html: -------------------------------------------------------------------------------- 1 | {% assign card = page %} 2 | 3 | {% assign path_tokens = card.path | split: '/' %} 4 | 5 | {% assign file_tokens = path_tokens[1] | split: '_' %} 6 | {% assign image = file_tokens[0] %} 7 | {% assign preview_image = file_tokens[0] %} 8 | 9 | 10 | 11 | 12 | 13 | {% if card.slug %}{{card.name}} - {% else %}{% endif %}cards42.org 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /_info/10_news.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: News 3 | --- 4 | 04.11.2019: Das 2. Set ist on- und offline verfügbar! 5 | 6 | 11.10.2019: Die Karten des 2. Sets sind im finalen Review. 7 | 8 | 09.08.2019: Wir haben an der Performance und an der Usability gearbeitet 9 | 10 | 07.08.2019: Das Review des Redesigns des 2. Packs ist erfolgt 11 | 12 | 08.07.2019: Das Repo zur cards42.org-Seite ist nun public. 13 | 14 | 04.07.2019: Die 1. Auflage von cards42 ist nach der Java Forum Stuttgart Konferenz komplett vergriffen. 15 | 16 | 02.07.2019: 1. Nachdruck des 1. Teils wurde in Auftrag gegeben (mit verbesserter Banderole) 17 | 18 | 26.06.2019: Die Arbeiten am 2. Teil-Pack (von 3) beginnen. Es wird teils noch spielerischer. 19 | 20 | 24.06.2019: Wir feiern Premiere auf der Konferenz "Developer Week 2019". 21 | 22 | 18.06.2019: Wir gehen live ([Blog-Post](https://www.innoq.com/de/articles/2019/06/cards42/))! Der dazugehörige Tweet geht durch die Decke. Wir sind gespannt, wie die gedruckten Karten bei euch ankommen! 23 | -------------------------------------------------------------------------------- /_info/20_haeufig_auftretende_fragen.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Häufig auftretende Fragen 3 | --- 4 | 5 | ### Wie komme ich an die Karten? 6 | 7 | Die ersten gedruckten Kartenpacks gibt es auf Konferenzen, wo INNOQ mit vertreten ist (wie z. B. der DeveloperWeek, dem Java Forum Stuttgart oder dem Herbstcampus). Wenn alle 42 Karten fertig sind, denken wir über eine Online-Bestellmöglichkeit nach. 8 | 9 | ### Wie entstand die Idee? 10 | 11 | Markus ging eines Abends (noch nachhaltig beeindruckt von einem INNOQ Event) in eine Buchhandlung und entdeckte dort die ["50 Karten: Kunterbunte Mitmach-Karten für das Handgepäck"](https://www.usborne.de/usborne-verlag-buecher/katalog/produkt/5/8810/50-karten-kunterbunte-mitmach-karten-fuer-das-handgepaeck/). Diese Karten sollen Kinder zum Nachdenken über verschiedenste Dinge anregen. Markus hat sich von diesem Konzept für die "Mitmach-Karten für Softwarearchitekten*innen" inspirieren lassen und so entstanden die ersten Ideen für cards42. 12 | 13 | Ein Foto welches die ersten Kartenideen zeigt 14 | 15 | ### Warum der Name "cards42"? 16 | 17 | Wir folgen damit der Tradition von [Gernot Starke](https://www.innoq.com/en/staff/gernot-starke/) (INNOQ Fellow) bei der Namensgebung. Gernot hat bereits die Projekte [arc42](https://arc42.org/) und [aim42](https://www.aim42.org/) ins Leben gerufen. Er hat auch den Ursprung von 42 [erklärt](https://faq.arc42.org/questions/A-1/). 18 | 19 | *OK, und die Domain war natürlich auch noch frei ;-)* -------------------------------------------------------------------------------- /_info/50_feedback.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Feedback 3 | --- 4 | Gerne kannst Du uns Feedback zu cards42 zukommen lassen. Nutze hierfür bitte [GitHub Issues](https://github.com/innoq/cards42org/issues) oder schreibe [Markus Harrer auf LinkedIn](https://www.linkedin.com/in/markus-harrer/) an. Für längere Rückmeldungen kannst Du gerne auch den Initiator des Projekts, [Markus Harrer](https://www.innoq.com/de/staff/markus-harrer/), direkt per E-Mail unter markus<punkt>harrer<at>innoq<punkt>com anschreiben. 5 | -------------------------------------------------------------------------------- /_info/90_mitwirkende.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Mitwirkende 3 | --- 4 | * [Markus Harrer](https://www.innoq.com/de/staff/markus-harrer/) (Idee, Erstellung und Erst-Design) 5 | * [Sonja Scheungrab](https://www.innoq.com/de/staff/sonja-scheungrab/) (Re-Design und Druck) 6 | * [Tobias Erdle](https://www.innoq.com/de/staff/tobias-erdle) (CSS-Optimierungen und Texte) 7 | * [Lisa Maria Moritz](https://www.innoq.com/de/staff/lisa-moritz/) (Texte) 8 | * [Ben Wolf](https://www.innoq.com/de/staff/benjamin-wolf/) (Kartenideen, Reviews) 9 | * [Simon Harrer](https://www.innoq.com/de/staff/dr-simon-harrer/) (Kartenideen) 10 | -------------------------------------------------------------------------------- /_info/95_lizenz.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Lizenz 3 | --- 4 | Creative Commons Lizenzvertrag
Dieses Werk ist lizenziert unter einer Creative Commons: Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International (CC BY-SA 4.0). -------------------------------------------------------------------------------- /_info/99_kontakt.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Kontakt 3 | --- 4 | Dir gefällt cards42 und Du möchtest mehr davon haben? INNOQ bietet Dir ein umfangreiches Angebot an Themen rund um Softwarearchitektur. 5 | 6 | Besuche uns unter [https://www.innoq.com/de/architektur/](https://www.innoq.com/de/architektur/) oder kontaktiere uns unter [https://www.innoq.com/de/kontakt](https://www.innoq.com/de/kontakt). Gerne stellen wir auch das cards42-Projekt inkl. Hands-On direkt in Deiner Firma vor! -------------------------------------------------------------------------------- /_info_EN/10_news.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: News 3 | --- 4 | 5 | 31/05/2022: Released printed English edition and improved website 6 | 7 | 19/04/2022: Merged English version with the German one 8 | 9 | 07/08/2020: Added support for short URLs. 10 | 11 | 31/07/2020: Added translation for cards. 12 | 13 | 30/07/2020: We've published the repository with the English version. It's still work in progress, but we are moving forward! 14 | 15 | more news are listed on the [German version](../#news) -------------------------------------------------------------------------------- /_info_EN/20_faq.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Frequently Asked Questions 3 | --- 4 | 5 | ### How do I get the printed cards? 6 | 7 | The printed card packs are available at conferences where INNOQ participates (e.g., DeveloperWeek, Goto conference, or JAX). 8 | Markus also offers shipping cards from time to time (at least in his training courses). 9 | 10 | ### Do you have a file with all cards? 11 | 12 | Yes, we have. You can download a PDF file with all cards at once: [cards42 English edition.pdf](../cards42%20English%20edition.pdf) 13 | 14 | ### How was the idea born? 15 | 16 | Once upon a time, [Markus Harrer](https://www.innoq.com/de/staff/markus-harrer/) (the initiator and main contributor) went after an internal INNOQ company event to a bookstore and discovered ["50 Karten: Kunterbunte Mitmach-Karten für das Handgepäck"](https://www.usborne.de/usborne-verlag-buecher/katalog/produkt/5/8810/50-karten-kunterbunte-mitmach-karten-fuer-das-handgepaeck/) (rough translation: "50 cards: colorful activity cards for your hand luggage"). 17 | These cards were designed to encourage children to think about various things. 18 | Markus was heavily inspired by these cards and created the initial idea for "Activity Cards for Software Architects." 19 | The cards42 project was born. 20 | 21 | A photo which shows the first card ideas 22 | 23 | ### Why the name "cards42"? 24 | 25 | With this name, we follow the tradition of [Gernot Starke](https://www.innoq.com/en/staff/gernot-starke/) (INNOQ Fellow) in the naming process. Gernot has already created the projects [arc42](https://arc42.org/) and [aim42](https://www.aim42.org/). He also explained [the origin of the number 42](https://faq.arc42.org/questions/A-1/). 26 | 27 | *OK, and of course, the domain was still available ;-)* 28 | 29 | ### Why is there a logo with "INNOQ" on the cards? 30 | 31 | INNOQ is the company where the main contributors are employed. 32 | The company gives the main contributors the time for creating and maintaining the cards42 project. 33 | INNOQ also prints the cards on paper and spreads these cards packs on various occasions. 34 | -------------------------------------------------------------------------------- /_info_EN/50_feedback.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Feedback 3 | --- 4 | You are welcome to send us feedback on cards42. 5 | Please use [GitHub Issues](https://github.com/innoq/cards42org/issues) or write to [Markus Harrer on LinkedIn](https://www.linkedin.com/in/markus-harrer/). 6 | For longer feedback, you can also contact the initiator of the project, [Markus Harrer](https://www.innoq.com/de/staff/markus-harrer/), directly via e-mail at markus<dot>harrer<at>innoq<dot>com. 7 | -------------------------------------------------------------------------------- /_info_EN/90_contributors.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Contributors 3 | --- 4 | * [Markus Harrer](https://www.innoq.com/en/staff/markus-harrer/) (Translation, initial idea and prototypical card design) 5 | * martina (many translations, examples for cards) 6 | 7 | Contributors to the original, German version: 8 | * [Sonja Scheungrab](https://www.innoq.com/en/staff/sonja-scheungrab/) (Re-design and printing) 9 | * [Tobias Erdle](https://www.innoq.com/en/staff/tobias-erdle) (CSS optimizations and texts) 10 | * [Lisa Maria Moritz](https://www.innoq.com/en/staff/lisa-moritz/) (Texts) 11 | * [Ben Wolf](https://www.innoq.com/en/staff/benjamin-wolf/) (Card ideas, reviews) 12 | * [Simon Harrer](https://www.innoq.com/en/staff/dr-simon-harrer/) (Card ideas) 13 | -------------------------------------------------------------------------------- /_info_EN/95_license.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: License 3 | --- 4 | Creative Commons license
This work is licensed under Creative Commons - Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). 5 | -------------------------------------------------------------------------------- /_info_EN/99_contact.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Contact 3 | --- 4 | You like cards42 and you want to have more? INNOQ offers you an extensive range of topics around software architecture. 5 | 6 | [Visit](https://www.innoq.com/en/services/softwarearchitektur-entwicklung/) or [contact](https://www.innoq.com/en/contact_messages/new/) us. 7 | We would also be happy to present the cards42 project including hands-on directly in your company! -------------------------------------------------------------------------------- /_layouts/card_page.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 | 5 | {% assign card = page %} 6 | 7 | 8 | 9 |
10 |
11 |
12 |
13 |
14 |

cards42.org

15 | 16 |
17 | Cards for 18 | Analyzing and 19 | Reflecting on 20 | Doomed 21 | Software 22 |
23 | 24 |
25 |
26 |
27 | 28 |
29 |
30 |
31 |
32 |

{{ card.name }}

33 |
34 |
35 |
36 |
37 | 38 | 39 | {% assign path_tokens = card.path | split: '/' %} 40 | 41 | {% assign file_tokens = path_tokens[1] | split: '_' %} 42 | {% assign image = file_tokens[0] %} 43 | {% assign tag = card.slug %} 44 |
45 |
46 |
47 | {% if card.alt %}{{card.alt}}{% else %}The image for the card with the name {{card.name}}{%endif%} 48 |
49 | Download: 50 | PNG 51 | PDF 52 | SVG 53 | {% if card.examples %} 54 | {% assign i = 1 %} 55 | {% for filename in card.examples %} 56 | Example {{i}} 57 | {% assign i = i | plus:1 %} 58 | {% endfor %} 59 | {% else %} 60 | {% endif %} 61 | 62 |
63 |
64 | {{ card.content | markdownify }} 65 |
66 |
67 |
68 |
69 |
70 |
71 |

72 | ◄ Take me to all the other cards! 73 |

74 |
75 |
76 |

77 | Give feedback 78 |

79 |
80 | 81 |
82 |
83 |
84 |
85 | -------------------------------------------------------------------------------- /_layouts/compress.html: -------------------------------------------------------------------------------- 1 | --- 2 | # Jekyll layout that compresses HTML 3 | # v2.1.0 4 | # http://jch.penibelst.de/ 5 | # © 2014–2015 Anatol Broder 6 | # MIT License 7 | --- 8 | 9 | {% if site.compress_html.ignore.envs contains jekyll.environment %}{{ content }}{% else %}{% capture _content %}{{ content }}{% endcapture %}{% assign _profile = site.compress_html.profile %}{% if site.compress_html.endings == "all" %}{% assign _endings = "html head body li dt dd p rt rp optgroup option colgroup caption thead tbody tfoot tr td th" | split: " " %}{% else %}{% assign _endings = site.compress_html.endings %}{% endif %}{% for _element in _endings %}{% capture _end %}{% endcapture %}{% assign _content = _content | remove: _end %}{% endfor %}{% if _profile and _endings %}{% assign _profile_endings = _content | size | plus: 1 %}{% endif %}{% for _element in site.compress_html.startings %}{% capture _start %}<{{ _element }}>{% endcapture %}{% assign _content = _content | remove: _start %}{% endfor %}{% if _profile and site.compress_html.startings %}{% assign _profile_startings = _content | size | plus: 1 %}{% endif %}{% if site.compress_html.ignore.whitespaces %}{% assign _random = site.time | date: "%s%N" %}{% if site.compress_html.ignore.whitespaces contains "SPACE" %}{% capture _ignore_space %} {% endcapture %}{% capture _freeze_space %}space{{ _random }}{% endcapture %}{% capture _join %} 10 | {% endcapture %}{% else %}{% capture _ignore_space %}{% endcapture %}{% capture _freeze_space %}{% endcapture %}{% capture _join %} {% endcapture %}{% endif %}{% if site.compress_html.ignore.whitespaces contains "LINE FEED" %}{% capture _ignore_line_feed %} 11 | {% endcapture %}{% capture _freeze_line_feed %}line_feed{{ _random }}{% endcapture %}{% else %}{% capture _ignore_line_feed %}{% endcapture %}{% capture _freeze_line_feed %}{% endcapture %}{% endif %}{% if site.compress_html.ignore.whitespaces contains "CHARACTER TABULATION" %}{% capture _ignore_character_tabulation %} {% endcapture %}{% capture _freeze_character_tabulation %}character_tabulation{{ _random }}{% endcapture %}{% else %}{% capture _ignore_character_tabulation %}{% endcapture %}{% capture _freeze_character_tabulation %}{% endcapture %}{% endif %}{% endif %}{% assign _pre_befores = _content | split: "" %}{% if _pres.size != 0 %}{% if site.compress_html.ignore.whitespaces %}{% assign _pres_after = _pres.last | replace: _ignore_space, _freeze_space | replace: _ignore_line_feed, _freeze_line_feed | replace: _ignore_character_tabulation, _freeze_character_tabulation | split: " " | join: _join | replace: _freeze_character_tabulation, _ignore_character_tabulation | replace: _freeze_line_feed, _ignore_line_feed | replace: _freeze_space, _ignore_space %}{% else %}{% assign _pres_after = _pres.last | split: " " | join: " " %}{% endif %}{% endif %}{% case _pres.size %}{% when 2 %}{% capture _content %}{{ _content }}{{ _pres_after }}{% endcapture %}{% when 1 %}{% capture _content %}{{ _content }}{{ _pres_after }}{% endcapture %}{% endcase %}{% endfor %}{% if _profile %}{% assign _profile_collapse = _content | size | plus: 1 %}{% endif %}{% if site.compress_html.comments == "all" %}{% assign _comments = "" | split: " " %}{% else %}{% assign _comments = site.compress_html.comments %}{% endif %}{% if _comments.size == 2 %}{% assign _comment_befores = _content | split: _comments.first %}{% for _comment_before in _comment_befores %}{% assign _comment_content = _comment_before | split: _comments.last | first %}{% if _comment_content %}{% capture _comment %}{{ _comments.first }}{{ _comment_content }}{{ _comments.last }}{% endcapture %}{% assign _content = _content | remove: _comment %}{% endif %}{% endfor %}{% if _profile %}{% assign _profile_comments = _content | size | plus: 1 %}{% endif %}{% endif %}{% if site.compress_html.clippings == "all" %}{% assign _clippings = "html head title base link meta style body article section nav aside h1 h2 h3 h4 h5 h6 hgroup header footer address p hr blockquote ol ul li dl dt dd figure figcaption main div table caption colgroup col tbody thead tfoot tr td th" | split: " " %}{% else %}{% assign _clippings = site.compress_html.clippings %}{% endif %}{% for _element in _clippings %}{% assign _edges = " ;; ;" | replace: "e", _element | split: ";" %}{% assign _content = _content | replace: _edges[0], _edges[1] | replace: _edges[2], _edges[3] | replace: _edges[4], _edges[5] %}{% endfor %}{% if _profile and _clippings %}{% assign _profile_clippings = _content | size | plus: 1 %}{% endif %}{{ _content }}{% if _profile %}
Step Bytes
raw {{ content | size }}{% if _profile_endings %}
endings {{ _profile_endings }}{% endif %}{% if _profile_startings %}
startings {{ _profile_startings }}{% endif %}{% if _profile_collapse %}
collapse {{ _profile_collapse }}{% endif %}{% if _profile_comments %}
comments {{ _profile_comments }}{% endif %}{% if _profile_clippings %}
clippings {{ _profile_clippings }}{% endif %}
{% endif %}{% endif %} 12 | -------------------------------------------------------------------------------- /_layouts/default.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: compress 3 | published: true 4 | --- 5 | 6 | 7 | {% include head_EN.html %} 8 | 9 |
10 | {{ content }} 11 | {% include footer_EN.html %} 12 |
13 | 14 | 15 | -------------------------------------------------------------------------------- /_layouts/page.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 | 5 | 6 | 7 | 8 |
9 |
10 |

{{ page.title }}

11 |
12 | 13 |
14 | {{ content }} 15 |
16 |
17 | -------------------------------------------------------------------------------- /assets/cards42_header.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innoq/cards42org/f15ca81a70720398a877355225d423262bb984c5/assets/cards42_header.jpg -------------------------------------------------------------------------------- /assets/cards42_header_en.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innoq/cards42org/f15ca81a70720398a877355225d423262bb984c5/assets/cards42_header_en.jpg -------------------------------------------------------------------------------- /assets/cards42_preview.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innoq/cards42org/f15ca81a70720398a877355225d423262bb984c5/assets/cards42_preview.jpg -------------------------------------------------------------------------------- /assets/cards42_preview_en.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innoq/cards42org/f15ca81a70720398a877355225d423262bb984c5/assets/cards42_preview_en.jpg -------------------------------------------------------------------------------- /assets/cards42_prototyp.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innoq/cards42org/f15ca81a70720398a877355225d423262bb984c5/assets/cards42_prototyp.jpg -------------------------------------------------------------------------------- /assets/js/index.js: -------------------------------------------------------------------------------- 1 | window.onload = function () { 2 | initImgLazyLoading(); 3 | } 4 | 5 | function initImgLazyLoading() { 6 | var observer = lozad(); 7 | observer.observe(); 8 | } -------------------------------------------------------------------------------- /assets/js/lozad.min.js: -------------------------------------------------------------------------------- 1 | /*! lozad.js - v1.9.0 - 2019-02-09 2 | * https://github.com/ApoorvSaxena/lozad.js 3 | * Copyright (c) 2019 Apoorv Saxena; Licensed MIT */ 4 | !function(t,e){"object"==typeof exports&&"undefined"!=typeof module?module.exports=e():"function"==typeof define&&define.amd?define(e):t.lozad=e()}(this,function(){"use strict";var g=Object.assign||function(t){for(var e=1;eMath.pow(2,32)-1)throw new RangeError("Invalid array length");var n=[];return n.length=r,n}function Call(t,l){var n=arguments.length>2?arguments[2]:[];if(!1===IsCallable(t))throw new TypeError(Object.prototype.toString.call(t)+"is not a function.");return t.apply(l,n)}function Get(n,t){return n[t]}function HasProperty(n,r){return r in n}function IsArray(r){return"[object Array]"===Object.prototype.toString.call(r)}function IsCallable(n){return"function"==typeof n}function ToBoolean(o){return Boolean(o)}function ToInteger(n){var i=Number(n);return isNaN(i)?0:1/i===Infinity||1/i==-Infinity||i===Infinity||i===-Infinity?i:(i<0?-1:1)*Math.floor(Math.abs(i))}function ToLength(n){var t=ToInteger(n);return t<=0?0:Math.min(t,Math.pow(2,53)-1)}function ToObject(e){if(null===e||e===undefined)throw TypeError();return Object(e)}function GetV(t,e){return ToObject(t)[e]}function GetMethod(e,n){var r=GetV(e,n);if(null===r||r===undefined)return undefined;if(!1===IsCallable(r))throw new TypeError("Method not callable: "+n);return r}function Type(e){switch(typeof e){case"undefined":return"undefined";case"boolean":return"boolean";case"number":return"number";case"string":return"string";case"symbol":return"symbol";default:return null===e?"null":"Symbol"in this&&e instanceof this.Symbol?"symbol":"object"}}function GetPrototypeFromConstructor(t,o){var r=Get(t,"prototype");return"object"!==Type(r)&&(r=o),r}function IsConstructor(t){return"object"===Type(t)&&("function"==typeof t&&!!t.prototype)}function OrdinaryToPrimitive(r,t){if("string"===t)var e=["toString","valueOf"];else e=["valueOf","toString"];for(var i=0;i1?arguments[1]:undefined;if("object"===Type(e)){if(arguments.length<2)var i="default";else t===String?i="string":t===Number&&(i="number");var r="function"==typeof this.Symbol&&"symbol"==typeof this.Symbol.toPrimitive?GetMethod(e,this.Symbol.toPrimitive):undefined;if(r!==undefined){var n=Call(r,e,[i]);if("object"!==Type(n))return n;throw new TypeError("Cannot convert exotic object to primitive.")}return"default"===i&&(i="number"),OrdinaryToPrimitive(e,i)}return e}function ToString(t){switch(Type(t)){case"symbol":throw new TypeError("Cannot convert a Symbol value to a string");case"object":return ToString(ToPrimitive(t,"string"));default:return String(t)}}if (!("Date"in this&&"now"in this.Date&&"getTime"in this.Date.prototype 4 | )) {Date.now=function e(){return(new Date).getTime()};}if (!("document"in this 5 | )) {"undefined"==typeof WorkerGlobalScope&&"function"!=typeof importScripts&&(this.HTMLDocument?this.Document=this.HTMLDocument:(this.Document=this.HTMLDocument=document.constructor=new Function("return function Document() {}")(),this.Document.prototype=document));}if (!("Element"in this&&"HTMLElement"in this 6 | )) {!function(){function e(){return a--||clearTimeout(t),!(!document.body||document.body.prototype||!/(complete|interactive)/.test(document.readyState))&&(m(document,!0),t&&document.body.prototype&&clearTimeout(t),!!document.body.prototype)}if(window.Element&&!window.HTMLElement)return void(window.HTMLElement=window.Element);window.Element=window.HTMLElement=new Function("return function Element() {}")();var t,n=document.appendChild(document.createElement("body")),o=n.appendChild(document.createElement("iframe")),r=o.contentWindow.document,c=Element.prototype=r.appendChild(r.createElement("*")),d={},m=function(e,t){var n,o,r,c=e.childNodes||[],u=-1;if(1===e.nodeType&&e.constructor!==Element){e.constructor=Element;for(n in d)o=d[n],e[n]=o}for(;r=t&&c[++u];)m(r,t);return e},u=document.getElementsByTagName("*"),i=document.createElement,a=100;c.attachEvent("onpropertychange",function(e){for(var t,n=e.propertyName,o=!d.hasOwnProperty(n),r=c[n],m=d[n],i=-1;t=u[++i];)1===t.nodeType&&(o||t[n]===m)&&(t[n]=r);d[n]=r}),c.constructor=Element,c.hasAttribute||(c.hasAttribute=function l(e){return null!==this.getAttribute(e)}),e()||(document.onreadystatechange=e,t=setInterval(e,25)),document.createElement=function p(e){var t=i(String(e).toLowerCase());return m(t)},document.removeChild(n)}();}if (!("defineProperty"in Object&&function(){try{var e={} 7 | return Object.defineProperty(e,"test",{value:42}),!0}catch(t){return!1}}() 8 | )) {!function(e){var t=Object.prototype.hasOwnProperty("__defineGetter__"),r="A property cannot both have accessors and be writable or have a value";Object.defineProperty=function n(o,i,c){if(e&&(o===window||o===document||o===Element.prototype||o instanceof Element))return e(o,i,c);if(null===o||!(o instanceof Object||"object"==typeof o))throw new TypeError("Object.defineProperty called on non-object");if(!(c instanceof Object))throw new TypeError("Property description must be an object");var a=String(i),f="value"in c||"writable"in c,p="get"in c&&typeof c.get,s="set"in c&&typeof c.set;if(p){if("function"!==p)throw new TypeError("Getter must be a function");if(!t)throw new TypeError("Getters & setters cannot be defined on this javascript engine");if(f)throw new TypeError(r);Object.__defineGetter__.call(o,a,c.get)}else o[a]=c.value;if(s){if("function"!==s)throw new TypeError("Setter must be a function");if(!t)throw new TypeError("Getters & setters cannot be defined on this javascript engine");if(f)throw new TypeError(r);Object.__defineSetter__.call(o,a,c.set)}return"value"in c&&(o[a]=c.value),o}}(Object.defineProperty);}function CreateDataProperty(e,r,t){var a={value:t,writable:!0,enumerable:!0,configurable:!0};try{return Object.defineProperty(e,r,a),!0}catch(n){return!1}}function CreateDataPropertyOrThrow(t,r,o){var e=CreateDataProperty(t,r,o);if(!e)throw new TypeError("Cannot assign value `"+Object.prototype.toString.call(o)+"` to property `"+Object.prototype.toString.call(r)+"` on object `"+Object.prototype.toString.call(t)+"`");return e}function CreateMethodProperty(e,r,t){var a={value:t,writable:!0,enumerable:!1,configurable:!0};Object.defineProperty(e,r,a)}if (!("isArray"in Array 9 | )) {CreateMethodProperty(Array,"isArray",function r(e){return IsArray(e)});}if (!("forEach"in Array.prototype 10 | )) {CreateMethodProperty(Array.prototype,"forEach",function r(t){var e=ToObject(this),n=e instanceof String?e.split(""):e,o=ToLength(Get(e,"length"));if(!1===IsCallable(t))throw new TypeError(t+" is not a function");for(var a=arguments.length>1?arguments[1]:undefined,i=0;i=n)return-1;if(o>=0)var i=-0===o?0:o;else{var i=n+o;i<0&&(i=0)}for(;i1?arguments[1]:undefined,a=0;a=0&&"[object Function]"===r.call(t.callee)),n}var e=Object.prototype.hasOwnProperty,r=Object.prototype.toString,n=Object.prototype.propertyIsEnumerable,o=!n.call({toString:null},"toString"),l=n.call(function(){},"prototype"),c=["toString","toLocaleString","valueOf","hasOwnProperty","isPrototypeOf","propertyIsEnumerable","constructor"],i=function(t){var e=t.constructor;return e&&e.prototype===t},u={$console:!0,$external:!0,$frame:!0,$frameElement:!0,$frames:!0,$innerHeight:!0,$innerWidth:!0,$outerHeight:!0,$outerWidth:!0,$pageXOffset:!0,$pageYOffset:!0,$parent:!0,$scrollLeft:!0,$scrollTop:!0,$scrollX:!0,$scrollY:!0,$self:!0,$webkitIndexedDB:!0,$webkitStorageInfo:!0,$window:!0},a=function(){if("undefined"==typeof window)return!1;for(var t in window)try{if(!u["$"+t]&&e.call(window,t)&&null!==window[t]&&"object"==typeof window[t])try{i(window[t])}catch(r){return!0}}catch(r){return!0}return!1}(),f=function(t){if("undefined"==typeof window||!a)return i(t);try{return i(t)}catch(e){return!1}};return function p(n){var i="[object Function]"===r.call(n),u=t(n),a="[object String]"===r.call(n),p=[];if(n===undefined||null===n)throw new TypeError("Cannot convert undefined or null to object");var s=l&&i;if(a&&n.length>0&&!e.call(n,0))for(var y=0;y0)for(var g=0;g2?arguments[2]:r,o=arguments.length>1?arguments[1]:[];if(!IsConstructor(r))throw new TypeError("F must be a constructor.");if(!IsConstructor(t))throw new TypeError("newTarget must be a constructor.");if(t===r)return new(Function.prototype.bind.apply(r,[null].concat(o)));var n=OrdinaryCreateFromConstructor(t,Object.prototype);return Call(r,n,o)}function ArraySpeciesCreate(r,e){if(1/e==-Infinity&&(e=0),!1===IsArray(r))return ArrayCreate(e);var t=Get(r,"constructor");if("object"===Type(t)&&null===(t="Symbol"in this&&"species"in this.Symbol?Get(t,this.Symbol.species):undefined)&&(t=undefined),t===undefined)return ArrayCreate(e);if(!IsConstructor(t))throw new TypeError("C must be a constructor");return Construct(t,[e])}if (!("filter"in Array.prototype 20 | )) {CreateMethodProperty(Array.prototype,"filter",function r(e){var t=ToObject(this),o=ToLength(Get(t,"length"));if(!1===IsCallable(e))throw new TypeError(e+" is not a function");for(var a=arguments.length>1?arguments[1]:undefined,n=ArraySpeciesCreate(t,0),i=0,l=0;i1?arguments[1]:undefined,n=ArraySpeciesCreate(t,a),i=0;i=0&&h>=0&&{top:n,bottom:o,left:i,right:r,width:s,height:h}}function u(t){var e;try{e=t.getBoundingClientRect()}catch(n){}return e?(e.width&&e.height||(e={top:e.top,right:e.right,bottom:e.bottom,left:e.left,width:e.right-e.left,height:e.bottom-e.top}),e):a()}function a(){return{top:0,bottom:0,left:0,right:0,width:0,height:0}}function l(t,e){for(var n=e;n;){if(n==t)return!0;n=p(n)}return!1}function p(t){var e=t.parentNode;return e&&11==e.nodeType&&e.host?e.host:e&&e.assignedSlot?e.assignedSlot.parentNode:e}var f=[];o.prototype.THROTTLE_TIMEOUT=100,o.prototype.POLL_INTERVAL=null,o.prototype.USE_MUTATION_OBSERVER=!0,o.prototype.observe=function(t){if(!this._observationTargets.some(function(e){return e.element==t})){if(!t||1!=t.nodeType)throw new Error("target must be an Element");this._registerInstance(),this._observationTargets.push({element:t,entry:null}),this._monitorIntersections(),this._checkForIntersections()}},o.prototype.unobserve=function(t){this._observationTargets=this._observationTargets.filter(function(e){return e.element!=t}),this._observationTargets.length||(this._unmonitorIntersections(),this._unregisterInstance())},o.prototype.disconnect=function(){this._observationTargets=[],this._unmonitorIntersections(),this._unregisterInstance()},o.prototype.takeRecords=function(){var t=this._queuedEntries.slice();return this._queuedEntries=[],t},o.prototype._initThresholds=function(t){var e=t||[0];return Array.isArray(e)||(e=[e]),e.sort().filter(function(t,e,n){if("number"!=typeof t||isNaN(t)||t<0||t>1)throw new Error("threshold must be a number between 0 and 1 inclusively");return t!==n[e-1]})},o.prototype._parseRootMargin=function(t){var e=t||"0px",n=e.split(/\s+/).map(function(t){var e=/^(-?\d*\.?\d+)(px|%)$/.exec(t);if(!e)throw new Error("rootMargin must be specified in pixels or percent");return{value:parseFloat(e[1]),unit:e[2]}});return n[1]=n[1]||n[0],n[2]=n[2]||n[0],n[3]=n[3]||n[1],n},o.prototype._monitorIntersections=function(){this._monitoringIntersections||(this._monitoringIntersections=!0,this.POLL_INTERVAL?this._monitoringInterval=setInterval(this._checkForIntersections,this.POLL_INTERVAL):(s(t,"resize",this._checkForIntersections,!0),s(e,"scroll",this._checkForIntersections,!0),this.USE_MUTATION_OBSERVER&&"MutationObserver"in t&&(this._domObserver=new MutationObserver(this._checkForIntersections),this._domObserver.observe(e,{attributes:!0,childList:!0,characterData:!0,subtree:!0}))))},o.prototype._unmonitorIntersections=function(){this._monitoringIntersections&&(this._monitoringIntersections=!1,clearInterval(this._monitoringInterval),this._monitoringInterval=null,h(t,"resize",this._checkForIntersections,!0),h(e,"scroll",this._checkForIntersections,!0),this._domObserver&&(this._domObserver.disconnect(),this._domObserver=null))},o.prototype._checkForIntersections=function(){var t=this._rootIsInDom(),e=t?this._getRootRect():a();this._observationTargets.forEach(function(o){var r=o.element,s=u(r),h=this._rootContainsTarget(r),c=o.entry,a=t&&h&&this._computeTargetAndRootIntersection(r,e),l=o.entry=new n({time:i(),target:r,boundingClientRect:s,rootBounds:e,intersectionRect:a});c?t&&h?this._hasCrossedThreshold(c,l)&&this._queuedEntries.push(l):c&&c.isIntersecting&&this._queuedEntries.push(l):this._queuedEntries.push(l)},this),this._queuedEntries.length&&this._callback(this.takeRecords(),this)},o.prototype._computeTargetAndRootIntersection=function(n,o){if("none"!=t.getComputedStyle(n).display){for(var i=u(n),r=i,s=p(n),h=!1;!h;){var a=null,l=1==s.nodeType?t.getComputedStyle(s):{};if("none"==l.display)return;if(s==this.root||s==e?(h=!0,a=o):s!=e.body&&s!=e.documentElement&&"visible"!=l.overflow&&(a=u(s)),a&&!(r=c(a,r)))break;s=p(s)}return r}},o.prototype._getRootRect=function(){var t;if(this.root)t=u(this.root);else{var n=e.documentElement,o=e.body;t={top:0,left:0,right:n.clientWidth||o.clientWidth,width:n.clientWidth||o.clientWidth,bottom:n.clientHeight||o.clientHeight,height:n.clientHeight||o.clientHeight}}return this._expandRectByRootMargin(t)},o.prototype._expandRectByRootMargin=function(t){var e=this._rootMarginValues.map(function(e,n){return"px"==e.unit?e.value:e.value*(n%2?t.width:t.height)/100}),n={top:t.top-e[0],right:t.right+e[1],bottom:t.bottom+e[2],left:t.left-e[3]};return n.width=n.right-n.left,n.height=n.bottom-n.top,n},o.prototype._hasCrossedThreshold=function(t,e){var n=t&&t.isIntersecting?t.intersectionRatio||0:-1,o=e.isIntersecting?e.intersectionRatio||0:-1;if(n!==o)for(var i=0;i 7 |
8 |
9 |

cards42.org

10 | 11 |

The activity cards for software architects

12 | 13 | Display of different cards42 cards as an example 14 | 15 |
16 | Cards for 17 | Analyzing and 18 | Reflecting on 19 | Doomed 20 | Software 21 |
22 | 23 |
24 |
25 | 26 | 27 |
28 |
29 |
30 |

The accompanying page to the cards42 project. This project is also available in German.

31 | 32 |

Introduction

33 | 34 | Welcome to the cards42 project! The cards from cards42 support you in your daily work on software architecture. The cards give you short, thought-provoking impulses for difficult situations and help to shed new light on complex challenges. 35 | 36 | This website offers detailed explanations as well as the background and further information about the cards' contents. 37 |
38 |
39 |
40 | 41 |
42 |
43 |
44 |

Overview

45 | 46 | {% comment %} accepted techdebt: High code duplication with the card listing generation below {% endcomment %} 47 | 48 | {% for card in site.descriptions_EN %} 49 | {% assign path_tokens = card.path | split: '/' %} 50 | {% assign file_tokens = path_tokens[1] | split: '_' %} 51 | {% assign tag = file_tokens[1] | remove: ".md" %} 52 | {% assign tags = tags | append: tag | append: " " %} 53 | {% endfor %} 54 | 55 | {% assign sorted_tags = tags | split: " " | sort %} 56 | {% for sorted_tag in sorted_tags %} 57 | {{sorted_tag}} 58 | {% endfor %} 59 | 60 | 61 |
62 |
63 |
64 |
65 |
66 |
67 |

Cards

68 |
69 |
70 |
71 | {% for card in site.descriptions_EN %} 72 | {% include card_EN.html %} 73 | {% endfor %} 74 | 75 | {% for i in site.info_EN %} 76 |
77 |
78 |
79 |

{{ i.title }}

80 | {{ i.content | markdownify }} 81 |
82 |
83 |
84 | {% endfor %} 85 | 86 | -------------------------------------------------------------------------------- /favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innoq/cards42org/f15ca81a70720398a877355225d423262bb984c5/favicon.ico -------------------------------------------------------------------------------- /favicon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innoq/cards42org/f15ca81a70720398a877355225d423262bb984c5/favicon.png -------------------------------------------------------------------------------- /favicon2021.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/innoq/cards42org/f15ca81a70720398a877355225d423262bb984c5/favicon2021.png -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | --- 2 | title: cards42 - Die Mitmach-Karten für Softwarearchitekt*innen 3 | --- 4 | 5 | 6 | 7 | 8 | 9 | {{page.title}} 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 |
35 |
36 |
37 |
38 |

cards42.org

39 |

Die Mitmachkarten für Softwarearchitekt:innen

40 | 41 | Darstellung verschiedener cards42-Karten als Beispiel 42 | 43 |
44 | Cards for 45 | Analyzing and 46 | Reflecting on 47 | Doomed 48 | Software 49 |
50 | 51 |
52 |
53 |
54 |
55 | 56 |
57 |
58 |
59 |

Die Begleitseite zum cards42-Projekt. Now also availabile in English! 60 | 61 |

Einleitung

62 | 63 | Willkommen beim cards42-Projekt! Die Karten von cards42 unterstützen bei der täglichen Arbeit mit Softwarearchitekturen. Die Karten geben kurze Denkanstöße für festgefahrene Situationen und helfen, neues Licht auf schwierige Herausforderungen zu werfen. 64 | 65 | Diese Webseite bietet ausführliche Erklärungen sowie die Hintergründe und weitere Informationen zu den Karten. 66 |
67 |
68 |
69 | 70 |
71 |
72 |
73 |

Übersicht

74 | 75 | {% comment %} accepted techdebt: Hohe Code-Duplikation mit der untereren Erzeugung der Kartenauflistung {% endcomment %} 76 | 77 | {% for card in site.descriptions %} 78 | {% assign path_tokens = card.path | split: '/' %} 79 | {% assign file_tokens = path_tokens[1] | split: '_' %} 80 | {% assign tag = file_tokens[1] | remove: ".md" %} 81 | {% assign tags = tags | append: tag | append: " " %} 82 | {% endfor %} 83 | 84 | {% assign sorted_tags = tags | split: " " | sort %} 85 | {% for sorted_tag in sorted_tags %} 86 | #{{sorted_tag}} 87 | {% endfor %} 88 | 89 | 90 |
91 |
92 |
93 |
94 |
95 |
96 |

Karten

97 |
98 |
99 |
100 | {% for card in site.descriptions %} 101 | {% assign path_tokens = card.path | split: '/' %} 102 | {% assign file_tokens = path_tokens[1] | split: '_' %} 103 | {% assign image = file_tokens[0] %} 104 | {% assign tag = file_tokens[1] | remove: ".md" %} 105 | 106 |
107 |
108 |
109 |

{{ card.name }} ▲

110 | #{{tag}} 111 |
112 |
113 |
114 |
115 | 116 | 117 |
118 | Download: 119 | PNG 120 | SVG 121 | {% if card.examples %} 122 | {% assign i = 1 %} 123 | {% for filename in card.examples %} 124 | Beispiel {{i}} 125 | {% assign i = i | plus:1 %} 126 | {% endfor %} 127 | {% else %} 128 | {% endif %} 129 | 130 | 131 |
132 |
133 | {{ card.content | markdownify }} 134 |
135 |
136 |
137 | {% endfor %} 138 | 139 | {% for i in site.info %} 140 |
141 |
142 |
143 |

{{ i.title }}

144 | {{ i.content | markdownify }} 145 |
146 |
147 |
148 | {% endfor %} 149 | 150 | 153 | 154 | 155 | 156 | --------------------------------------------------------------------------------