Mehr als Pfeile und Kästen: Architekturdiagramme mit Ralf D. Müller und Lisa Moritz

Software Architektur im Stream (Video)
16 Dec 202259:57

Summary

TLDRIn this engaging discussion, Ralf Müller, a Chief Architect at DB Systel, shares his insights on software architecture documentation. Ralf emphasizes the importance of clear and maintainable architectural diagrams, highlighting his journey from traditional documentation methods to adopting the DocToolchain approach. He discusses the challenges of keeping diagrams up-to-date and how scripting and tools like PlantUML and diagrams.net have streamlined the process. Ralf also explores the role of visual language in diagrams, advocating for intuitive design and the use of legends to enhance understanding. The conversation touches on the benefits of open-source collaboration and the potential for cross-project use of diagrams, emphasizing the value of collective knowledge and continuous improvement.

Takeaways

  • 🌟 The importance of clear and effective communication in software architecture documentation was emphasized, highlighting the role of diagrams and visual representations.
  • 📈 Ralf Müller, as a Chief Architect, stressed the significance of architecture documentation and his journey towards improving it through scripting and automation.
  • 🔄 The evolution from traditional text-based documentation to incorporating tools like draw.io, diagrams.net, and the challenges of keeping diagrams up-to-date were discussed.
  • 🔧 The transition to using code (doctools Code approach) for generating documentation was explored, including the benefits of automating the process and integrating UML tools.
  • 📚 The impact of using Markdown and AsciiDoctor for creating and maintaining documentation was highlighted, offering a more dynamic and flexible approach.
  • 🔗 The discussion touched on the integration of diagrams within documentation, ensuring that they are referenced and can be easily updated as the system evolves.
  • 🎨 The role of visual language in diagrams, including the use of colors, shapes, and sizes, was emphasized to convey meaning and structure within architectural documentation.
  • 👥 The value of collaboration and feedback in refining documentation practices was underscored, with the mention of open-source contributions and community involvement.
  • 🛠️ The practical aspects of handling diagram sources and version control were discussed, stressing the need for organized management to facilitate easy updates and revisions.
  • 📊 The potential of using tools like PlantUML for creating diagrams that are both aesthetically pleasing and semantically meaningful was presented, with tips on maintaining clarity and simplicity.
  • 🚀 The conversation concluded with a look towards future improvements and the continuous development of the doctools Code approach, aiming to enhance the creation and maintenance of architecture documentation.

Q & A

  • What is Ralf Müller's profession and main area of focus?

    -Ralf Müller is a Chief Architect at the DB Systel, the IT partner of the railway company. His main focus is on architecture documentation.

  • How did Ralf Müller become interested in architecture documentation?

    -Ralf Müller became interested in architecture documentation after years of working as a developer. He wanted to understand the bigger picture and realized that architecture involves a lot of communication and documentation.

  • What challenges did Ralf face with traditional text processing and UML tools?

    -Ralf found that while traditional text processing allowed for a quick initial draft, keeping it up-to-date was difficult. As for UML tools, he found it cumbersome to manually update diagrams across all documentation whenever there was a change.

  • How did Ralf Müller improve his documentation process?

    -Ralf improved his documentation process by using scripts to automate the extraction of diagrams from his UML tool and embedding them into his documentation. This led him to the doccscript approach, which made the process easier and allowed for diagrams to be automatically updated in his documentation.

  • What is the doccscript approach and how does it benefit architecture documentation?

    -The doccscript approach is a method of architecture documentation that involves using scripts to automate the generation and maintenance of diagrams and other documentation. It benefits architecture documentation by making the process of keeping diagrams and documentation up-to-date more efficient and less error-prone.

  • What was the first script Ralf Müller created for his documentation?

    -The first script Ralf Müller created was for automatically exporting diagrams from Enterprise Architect, a tool he was using for architecture modeling, and then using the doccscript approach to update his documentation with the exported images.

  • How did Ralf Müller's scripts evolve into the doccscript project?

    -Ralf Müller's scripts evolved into the doccscript project when he decided to make them open source. He wanted others to be able to use and improve upon his scripts. Over time, many contributors enhanced the project, adding new features and use cases, which led to doccscript becoming a larger project with a variety of modules.

  • What is the significance of the doccscript project for architecture documentation?

    -The doccscript project is significant because it provides a set of tools and scripts for automating the creation and maintenance of architecture documentation. It allows for easier integration of diagrams and other visual elements, and it supports a variety of markup languages, making it a versatile tool for architects and developers.

  • What are some of the benefits of using a tool like draw.io or diagrams.net for architecture diagrams?

    -Tools like draw.io or diagrams.net are popular because they offer a what-you-see-is-what-you-get (WYSIWYG) interface for creating diagrams. They are intuitive and widely used, making it easier for team members to collaborate and maintain documentation.

  • How does Ralf Müller handle feedback and improvements for the doccscript project?

    -Ralf Müller handles feedback and improvements by engaging with the community and collaborators. He is open to suggestions and takes user feedback into account when updating the doccscript project. This collaborative approach has allowed the project to grow and improve over time.

Outlines

00:00

🤝 Introduction and Guest

The paragraph introduces Ralf Müller as a guest in a new episode of Software Architecture. Ralf is a Chief Architect at DB Systel, focusing on architecture documentation. The conversation revolves around the challenges and evolution of documenting architectural diagrams and the motivation behind Ralf's interest in improving documentation practices.

05:03

📈 Evolution of Documentation Tools

Ralf discusses his journey from using basic text processing to more sophisticated tools for architecture documentation. He talks about the limitations of traditional methods like Wikis and the transition to tools like Enterprise Architect. He also shares his experience with creating scripts to automate the process of extracting diagrams and embedding them into documentation.

10:03

🔄 Feedback and Improvement

The conversation touches on the importance of feedback in the development of documentation tools. Ralf shares how his scripts evolved into a project called 'doctoolchain', which became open-source and contributed to by various contractors. The paragraph highlights the collaborative effort in refining tools and the impact of community involvement on the project's growth.

15:03

📊 Handling Diagrams in Documentation

Ralf discusses the challenges of managing diagrams in documentation, such as keeping them up-to-date and the difficulties with different file formats. He talks about his experiences with tools like draw.io and diagrams.net, and the benefits of using a 'what you see is what you get' editor. The paragraph also touches on the importance of version control for diagrams.

20:07

🌐 Accessibility and Styling in Diagrams

The paragraph delves into the accessibility of diagrams, emphasizing the importance of styling for visually impaired users. Ralf shares insights on the benefits of using PlantUML and the potential for creating diagrams that can be understood by both sighted and blind users. The conversation also covers the significance of maintaining a clear and concise visual language in diagrams.

25:07

🔧 Customization and Integration

Ralf talks about the customization options available in doctoolchain, including support for different markup languages and the integration of mermaid diagrams. The paragraph discusses the flexibility of the toolchain and its potential for use in various technology ecosystems, not just Java. The conversation also highlights the ease of setting up a public diagram server for various diagram types.

30:08

📚 Structuring Documentation

The paragraph focuses on strategies for structuring and maintaining architectural documentation. Ralf discusses the use of doctoolchain for managing multiple report stories and the benefits of keeping documentation close to the code. He also talks about the ability to generate microsites for architecture documentation and the features of static site generators.

35:09

🎨 Aesthetics and Clarity in Diagrams

Ralf emphasizes the importance of aesthetics and clarity in diagrams, discussing principles such as the use of white space and the need for diagrams to be readable without zooming. He shares his approach to creating diagrams that are concise and easy to understand, including the use of visual cues and the avoidance of overly complex diagrams.

40:11

🌈 Use of Colors and Visual Language

The conversation turns to the strategic use of colors and the development of a visual language within diagrams. Ralf discusses the intuitive meanings of colors and the importance of defining and explaining this language within a diagram's legend. He also talks about the impact of diagram aesthetics on understanding and the need for a sanity check when creating diagrams.

45:13

🔄 Sharing and Collaborating on Diagrams

Ralf talks about the benefits of sharing diagrams and the collaborative potential within teams. He discusses the impact of having the creator's name on diagrams and the reduction of the 'bus factor' when multiple team members are involved in documentation. The paragraph also touches on the practice of acknowledging contributors in documentation and the potential for open-source approaches.

Mindmap

Keywords

💡Software Architecture

The term 'Software Architecture' refers to the structure of a software system, the discipline of creating such structures, and the documentation of these structures. In the context of the video, it is the central theme, with the guest Ralf Müller discussing his role as a Chief Architect and his focus on architecture documentation.

💡Architecture Documentation

Architecture Documentation is the process of creating, maintaining, and presenting the structural description of a software system. It is a critical aspect of software engineering that helps in understanding the system's design and functionality. Ralf Müller emphasizes the importance of keeping documentation up-to-date and his journey towards automating this process.

💡docToolchain

docToolchain is an open-source project initiated by Ralf Müller for automating the process of creating and maintaining architecture documentation. It allows for the integration of diagrams and other artifacts directly into markdown documents, making the documentation process more efficient and less error-prone.

💡UML Tools

UML (Unified Modeling Language) Tools are software applications that provide graphical representations for modeling and designing software systems. They are used to create diagrams that illustrate the structure and behavior of a system, such as class diagrams, sequence diagrams, and more.

💡Enterprise Architecture

Enterprise Architecture is a holistic approach to understanding and designing the business processes and IT systems of an organization. It provides a blueprint for the organization's IT infrastructure and demonstrates how it supports the business strategy.

💡PlantUML

PlantUML is a tool that allows users to create UML diagrams from a simple textual description. It is often used for generating diagrams in documentation due to its ability to convert text descriptions into visual diagrams, making it a valuable tool for software architects.

💡Version Control

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. It is essential for tracking the evolution of documentation and diagrams, ensuring that the most up-to-date information is available.

💡Visual Communication

Visual communication is the conveyance of ideas and messages through visual means, such as diagrams, charts, and images. In the context of software architecture, it is crucial for explaining complex system designs and functionalities in a clear and understandable way.

💡Open Source

Open Source refers to a software system or project whose source code is made available to the public, allowing anyone to view, use, modify, and distribute the code. It promotes collaboration and community involvement in the development and improvement of software.

💡Architecture Diagrams

Architecture Diagrams are visual representations of the structure and components of a software system. They are essential tools in software architecture for communicating the design and relationships between system elements.

💡Collaboration

Collaboration refers to the act of working together with others to achieve a common goal. In the context of software architecture, it involves team members from different disciplines, such as developers, architects, and stakeholders, to design, review, and refine the system's architecture.

Highlights

Ralf Müller, Chief Architect at DB Systel, discusses his passion for architecture documentation and how he transitioned from being a developer to focusing on architectural aspects.

Ralf emphasizes the importance of communication and documentation in architecture, and how he began to explore ways to improve the documentation process using scripts and tools.

The conversation delves into the challenges of keeping documentation up-to-date, especially when it comes to diagrams, and how Ralf started using scripts to automate the process of extracting diagrams from UML tools.

Ralf shares his journey towards creating the doccscript approach, which simplifies the process of embedding diagrams and keeping documentation current.

The discussion highlights the evolution of Ralf's scripts into the doccscript language, which has since become an open-source project with contributions from various contractors, improving and expanding its capabilities.

Ralf talks about the benefits of using doccscript, including the ability to easily update diagrams and documentation without needing access to expensive tools like Enterprise Architect.

The conversation touches on the topic of intuitive diagram editors like draw.io (now diagrams.net) and how they can be integrated with the doccscript approach for a more streamlined documentation experience.

Ralf addresses the issue of version control for diagrams, emphasizing the importance of being able to trace changes and updates in architecture documentation.

The discussion explores the advantages of using PlantUML, particularly for sequence diagrams, and how it can enhance collaboration within teams by allowing members to easily compare and contrast different versions of diagrams.

Ralf shares insights on the importance of accessibility in architecture documentation, highlighting how the doccscript approach can make diagrams more accessible to users with disabilities.

The conversation highlights the versatility of the doccscript approach, which is not limited to Java ecosystems but can be applied to various technologies and projects.

Ralf discusses the potential of using the doccscript approach to generate microsites for architecture documentation, emphasizing its flexibility and the ability to create tailored documentation for different audiences.

The discussion concludes with Ralf sharing his excitement for the upcoming JavaLand conference, where he will be presenting on the topic of diagrams and architecture documentation, offering attendees a chance to learn and engage with these concepts.

Transcripts

play00:00

hallo und herzlich willkommen zu einer

play00:01

neuen Episode von Software Architektur

play00:04

im Stream wir haben heute die letzte

play00:05

Episode für dieses Jahr und ich hoffe

play00:07

und glaube dass sie ziemlich cool und

play00:09

besonders wird weil heute ist Ralf

play00:12

Müller bei uns zu Gast hallo Ralf hallo

play00:15

Lisa und die Einladung zu diesem Stream

play00:18

basierter auf einer ich sage mal

play00:20

hitzigen Diskussion als damals mit mir

play00:24

über Youtube Dokumentation gesprochen

play00:27

hatte und da dachten wir wie ergreifen

play00:29

die Chance schnappen uns Ralf und

play00:31

sprechen mal mit ihm über

play00:32

architekturdiagramme und über

play00:35

Architektur Dokumentation genau und wir

play00:38

freuen uns auf jeden Fall riesig wenn

play00:39

ihr auch Fragen stellt und vielleicht

play00:41

auch Kommentare liefert das kam schon

play00:43

ein paar Sachen im Vorfeld aber genau

play00:45

das ja so viel zu Einleitung jetzt

play00:48

geht's wirklich los

play00:50

genau hallo Ralf erstmal wer bist du und

play00:52

was machst du so

play00:54

ja Ralf Müller mein Name wer bin ich was

play00:58

mache ich ich finde die Frage immer

play00:59

schwer zu beantworten ich bin als Chef

play01:03

Architekt bei der dbsstelle dem

play01:05

IT-Partner der Bahn eingestellt und

play01:07

kümmere mich darum alle möglichen

play01:09

Probleme aber vor allem mein

play01:11

Steckenpferd Architektur Dokumentation

play01:14

wie bist Du daran gekommen also was hat

play01:16

dich bewogen dich für Architektur

play01:18

Dokumentation zu interessieren ja das

play01:21

war dass ich eben lange Jahre als

play01:23

Entwickler gearbeitet habe und gemerkt

play01:26

habe irgendwie will ich auch mal das

play01:28

große und ganze verstehen und habe mich

play01:30

dann eben an die Architektur Range

play01:32

gewagt an die Definition was ist

play01:34

eigentlich Architektur habe gemerkt dass

play01:36

Architektur eben viel kommunizieren und

play01:39

dokumentieren ist und kommunizieren über

play01:42

die Dokumentation und habe dann gemerkt

play01:45

dass so das Dokumentieren mit

play01:47

Textverarbeitung und Co nicht so

play01:49

wirklich Spaß macht weil man kriegt zwar

play01:51

einen schnellen ersten Wurf hin aber

play01:53

dann das aktuell zu halten ist dann doch

play01:57

etwas schwieriger und habe dann

play01:59

angefangen ja mich damit zu beschäftigen

play02:02

wie kann ich es besser machen wie kann

play02:05

ich mit Skripten zum Beispiel aus meinem

play02:08

UML Tool die Diagramme rausziehen und

play02:11

automatisch in meine Dokumentation

play02:13

einbetten und so bin ich dann zu dem

play02:16

docess Code Ansatz gekommen und ark42

play02:19

und seitdem baue ich das immer weiter

play02:22

aus das ist immer leichter wird eben

play02:25

dieses gespannt so nutzen was waren die

play02:29

ersten Tools mit denen du dokumentiert

play02:31

hast also bevor du zu dem doktor-ansatz

play02:34

kamst ja das ist also was man halt so

play02:37

kennt die normale Textbearbeitung was

play02:40

natürlich dann immer irgendwie so zu so

play02:44

einem

play02:44

orientierten

play02:46

orientierten Dokumentation führt ja wo

play02:49

man dann immer auch die Probleme hat und

play02:51

irgendwelchen verweisen und wenn man

play02:54

dann auf einen in einem Dokument

play02:55

hinweisen möchte dann verschickt man das

play02:58

ganze Dokument und sagt du in dem und

play03:00

dem Kapitel das passt irgendwie nicht so

play03:02

gut

play03:03

Wikis ja gab es auch damals schon und

play03:08

waren als damit angefangen habe waren da

play03:12

ein paar Features noch nicht vorhanden

play03:13

haben aber natürlich Vorteile weil man

play03:16

da eben direkt auf irgendwelche

play03:18

Abschnitte verlinken kann

play03:20

was natürlich da Sachen Diagramm immer

play03:23

so ein bisschen

play03:24

schwierig ist die wie gehe ich damit

play03:27

Diagramm um erstelle ich die in einem

play03:30

externen Tool lad die dann hoch und wenn

play03:35

es dann hochgeladen habe genauso wie bei

play03:37

einer Textverarbeitung wenn ich da

play03:38

irgendwie was per Copy and pace

play03:40

reingespielt habe wenn sich dann das

play03:43

Diagramm irgendwie ändert dann muss ich

play03:45

mich wieder daran erinnern wo habe ich

play03:47

es überall per Copy and Paste

play03:49

reingebracht wo muss ich es

play03:50

aktualisieren und das wird dann mit der

play03:53

Zeit ziemlich aufwendig und das führt

play03:56

dann eigentlich meistens dazu dass man

play03:57

eben leider doch nicht aktualisiert

play04:04

aber ich muss gerade so an den

play04:06

Enterprise Architekt denken oder nur

play04:07

eine Handvoll ausgewählter Personen

play04:10

Zugang zu diesem sauten Schule hat was

play04:12

kaum einer bedienen kann und die sind

play04:15

dann alle im Urlaub und dann wird dieser

play04:16

Architektur Dokumentation einfach nicht

play04:18

angepasst weil kann halt dann keine

play04:21

ja ja da spricht so aber ein sehr

play04:23

schönes Thema an also der Enterprise

play04:25

Architekt der geht ja noch vom von den

play04:27

Lizenzkosten her also dass das ist ja

play04:29

was wo man tatsächlich eben Zugriff

play04:31

geben kann aber

play04:34

die Bedienung ist nicht so ganz einfach

play04:36

anruhr im l-tools sind ja tatsächlich so

play04:38

teuer dass ja nur wenig Leute in der

play04:42

Lizenz haben dass sie editieren dürfen

play04:44

aber gerade wenn ich dann eben mit einem

play04:47

Architekturmodell arbeite und man dann

play04:50

sagt ach komm hier dieses Modul das

play04:52

nennen wir jetzt um ich benennst im

play04:55

Modell um und dann ist die erste Frage

play04:57

in wie viel sichten hat sich das jetzt

play04:58

geändert

play04:59

welche Diagramme welche sichten werden

play05:02

in Dokumenten verwendet und wie kann ich

play05:06

das jetzt aktuellisieren und zwar in der

play05:08

Tat so der erste das erste Skript in

play05:12

meiner skriptsammlung die dann zu Doktor

play05:14

wurde

play05:16

da ich eben gesagt habe irgendwie muss

play05:18

ich diese Diagramme automatisiert

play05:20

rausbekommen und habe es dann geschafft

play05:23

in Enterprise Architekt headless zu

play05:26

starten in einem Skript alle Diagramme

play05:29

zu exportieren

play05:31

und mich dann den doxos Code Ansatz

play05:35

verwendet dann habe ich ja mein Mark

play05:38

down oder besser noch aski dog was diese

play05:41

images referenziert aus einem Folder das

play05:44

heißt sobald ich die Images neu

play05:46

exportiert habe und dann die

play05:48

Dokumentation Bau dann habe ich die eben

play05:50

auch in meiner Dokumentation

play05:52

aktualisiert

play05:54

und das ist so schon ganz ganz großer

play05:56

Schritt nach vorne weil ich dann

play05:58

jederzeit einfach sagen kann ist egal

play06:01

was ich an dem Modell geändert habe die

play06:03

Sichten werden aktualisiert exportiert

play06:06

und meine Dokumentation ist in Sachen

play06:09

Diagramm auf aktuellen Stand was gerade

play06:13

schon gesagt die Doktor chain das war

play06:14

eine der ersten Sachen mit dem

play06:16

Enterprise Architekt ich frage mich

play06:17

gerade ob das so war dass du so deine

play06:20

Scriptsammlung irgendwo rumliegen

play06:22

hattest und irgendwann hast du gemerkt

play06:23

ach das ist eigentlich so cool ich

play06:25

möchte das Teilen und dann ist so daraus

play06:27

die Doktor geworden oder ist das

play06:28

irgendwie anders gekommen ja es war

play06:32

damals ich mein Soundprojekt der

play06:35

ziemlich cool ne also seine eigene Vater

play06:37

und deswegen habe ich mir eben auch

play06:40

gedacht dieses Skripte die ich habe

play06:42

warum nicht Open Source machen ähm

play06:47

und damit auch die Chance haben das

play06:50

andere drüber gucken und sie verbessern

play06:52

und die Rechnung ist aufgegangen also

play06:55

mittlerweile haben wir da relativ viele

play06:58

Kontraktoren die eben tatsächlich das

play07:00

ganze verbessert haben die immer mal

play07:03

wieder irgendwelche anderen Use Cases

play07:06

haben und damit ja zu dem großen Ganzen

play07:10

beigetragen haben dadurch ist die

play07:13

Doktoren eigentlich ein relativ großes

play07:15

Projekt geworden und dem man aber

play07:18

meistens eben nur einen Ausschnitt sieht

play07:20

also gerade der static side Generator

play07:23

oder der Export nach conference ist sehr

play07:26

beliebt und andere Module werden dann

play07:31

nicht ganz so tief betrachtet

play07:34

und wir sind ja jetzt beim Diagrammen da

play07:37

ist ja

play07:39

Diagramme im doxos Code Ansatz

play07:41

planturmeln und sowas ist ja immer nicht

play07:44

ganz so einfach zu händeln

play07:47

und

play07:48

es gibt ja dieses Tool früher hier ist

play07:51

draw.io dann diagrams.net und irgendwie

play07:54

weiß ich jetzt momentan gar nicht

play07:56

welches der offizielle Name ist

play07:59

aber das ist ja so ein diagrammeditor

play08:01

der

play08:02

recht beliebt ist recht weit verbreitet

play08:05

und

play08:08

das war mit alexander Schwarz das ich

play08:11

mich da unterhalten habe hey es gibt für

play08:14

Visual Studio Code da ein entsprechendes

play08:16

Plugin mit alexander Schwarz hatte ja

play08:19

auch das Astrid Doktor Plugin für

play08:23

Intelli J und da habe ich mir gedacht

play08:25

Mensch der hat doch sicher das Know-how

play08:27

wie man da eben entsprechend

play08:30

Plugin für intelligenz macht

play08:34

und in dem Zuge dieses Open Source

play08:37

austauschst

play08:38

kam dann auch noch Henning dieterichs

play08:41

dazu der das Plugin schon für Visual

play08:44

Studio Code gemacht hat und dann haben

play08:48

wir zusammen zu dritt das Ganze für

play08:49

intelligen gemacht und ja das ist jetzt

play08:53

für intelligente das direcross.net

play08:55

Plugin was jetzt eben auch im Doktor

play08:58

change Namespace liegt

play09:01

lange Herleitung aber das war jetzt so

play09:03

manchmal

play09:05

loswerden wollte dass eben

play09:07

das Doktor Jane vieles umfasst viele

play09:11

Ansätze und das gerade dieses Plugin

play09:14

eben jetzt sehr gut hilft

play09:18

Diagramme besser zum

play09:22

damit hast du aus Versehen auf eine

play09:24

Frage beantwortet die wir vorher im

play09:26

slack bekommen haben würde ich behaupten

play09:28

und zwar hatte da Kevin stillhammer

play09:30

gefragt wie gehst du mit dem Feedback um

play09:32

das what you Sears what you get Editoren

play09:34

wie Gira conference Visio intuitiver

play09:36

sind und man mit drolshain eine unnötige

play09:39

Hürde schafft also du hast eben einmal

play09:41

gesagt dass du ja von Dr Jane nach

play09:43

conference die point quasi kannst

play09:46

oder veröffentlichen die vielleicht auch

play09:49

zu viel gesagt und du hast auch gesagt

play09:50

dass man diese draw iO oder nett oder

play09:54

die what is what you get Diagramm

play09:57

Editoren mit der Doktor chain nutzen

play09:58

kann

play10:00

denkst du denn dass das Argument häufig

play10:03

kommt dass dort intuitiv ist und dass

play10:07

man lieber nur in Konferenz und so

play10:09

weiter arbeiten sollte

play10:11

ja also diese Argument kommt immer

play10:13

wieder und es kommt immer darauf an wer

play10:15

mit der Dokumentation arbeitet wer sie

play10:17

erstellen möchte

play10:19

ich erlebe es bei Techis immer wieder

play10:21

dass sie den Docs Code Ansatz lieben sie

play10:25

sind den ganzen Tag in ihrer Idee

play10:27

möchten die am liebsten gar nicht

play10:29

verlassen und wenn sie dann die

play10:31

Dokumentation auch in die schreiben

play10:33

können dann sind sie glücklich

play10:36

Wikis sind natürlich da brauche ich mich

play10:39

erstmal nicht großartig einzuarbeiten es

play10:42

ist augenscheinlich die kleinere Hürde

play10:46

ich sage augenscheinlich weil jeder

play10:49

kennt eigentlich von Markdown

play10:51

ich schreibe so eine Dokumentation

play10:53

runter wie eine E-Mail und

play10:55

dann merke ich okay Überschriften

play10:58

formatieren ja ein Hashtag davor dass

play11:00

das einfach das geht auch in asketok und

play11:03

den as geht doch kann ich dann genauso

play11:04

wie ich in Wikis besondere Formatierung

play11:07

ausfindig machen kann und so kann ich

play11:10

das dann auch in afdok und dann ist

play11:12

eigentlich die größere Hürde

play11:14

geht dass man wenn man da irgendwie äh

play11:17

request hat da irgendwelche

play11:21

Probleme hat dass man die überwindet

play11:25

aber das ist halt auch interessant dass

play11:27

ich viele Teams erlebt habe die eben

play11:30

auch schon mit Ihrer Textverarbeitung

play11:31

nach einem Dokumentenmanagement System

play11:35

geschrien haben und wenn sie da eins

play11:37

bekommen haben gesagt haben oh das ist

play11:39

aber komplex und nee das ist

play11:41

unpraktikabel ja und ich denke mit git

play11:45

haben wir Techies ein ja

play11:49

Dokumentenmanagementsystem was perfekt

play11:52

ist was eben die minimale Komplexität

play11:54

mitbringt die man braucht

play11:57

ja und mit den Diagrammen

play12:03

also gerade mit dem direcrimes.net ist

play12:05

deshalb ein schöner what you see is what

play12:07

you get Editor mit dem ich arbeiten kann

play12:10

und das tolle ist halt dass beim PNG und

play12:15

SVG Format die Sourcen direkt in dem

play12:18

Format gespeichert werden das heißt ich

play12:21

habe nur ein PNG in meinem reposttory

play12:26

und kann das direkt wieder editierbar

play12:29

öffnen

play12:31

und das ist auf so vielen Ebenen super

play12:33

klasse weil was mich an vielen

play12:36

Diagrammen stört ist wenn man so ein

play12:38

Projekt reinkommt und fragte ob mir die

play12:41

Architektur ja hier guck mal ich habe

play12:43

hier

play12:44

PDF das von von der PowerPoint und wenn

play12:48

man dann architekturarbeit leisten soll

play12:50

dann sieht man da zwar schöne Diagramme

play12:54

aber es ist teilweise sehr sehr schwer

play12:56

bis unmöglich die Quelle der Diagramme

play12:59

ausfindig zu machen und sie dann wieder

play13:03

zu bearbeiten das heißt man erstellt sie

play13:06

teilweise neu und gerade wenn die

play13:08

modellbasiert sind dann ist es halt

play13:10

schon ziemlich ärgerlich wenn man dann

play13:12

das ganze Modell irgendwie neu aufsetzen

play13:14

muss

play13:15

und deshalb bei dem direcrimes.net wenn

play13:17

ich das repostory kennen wenn ich das

play13:19

PNG File habe dann kann ich direkt damit

play13:22

arbeiten bei plantronell ist es ähnlich

play13:26

und da fällt mir auch gerade so ein

play13:28

Punkt ein bezüglich Plan du ml viele

play13:30

Leute sagen ihr plant URL ist ist das

play13:32

sieht so hässlich aus aber ich sag das

play13:35

ist ein Vorteil das ist ein Vorteil wenn

play13:37

ich an dem Design erkenne welches Tool

play13:41

das war weil ich dann schon weiß wo ich

play13:43

suchen muss

play13:46

und da finde ich eben leichter auch die

play13:48

source

play13:49

es gibt auf jeden Fall ich hätte eine

play13:51

Nachfrage noch mal du sagst ihm also

play13:54

genau ich kenne den Plan und ich kenne

play13:55

auch was ich mich frage bei planto ml

play13:58

sich ja in der geht Historie ganz klar

play14:00

wo sich was geändert hat weil das ja das

play14:02

ist einfach textbasierte Ansatz um die

play14:05

Diagramme zu beschreiben

play14:07

habe ich dieselben Möglichkeiten auch

play14:09

wenn ich es BG oder einen PNG Einchecken

play14:12

dass ich wirklich die das Gif visuell

play14:15

sehe und sehe was hat sich geändert oder

play14:17

habe ich die Chance dann vertan wenn ich

play14:19

pro einsetze

play14:22

ist eine sehr gute Frage

play14:25

ja das ist ein großer Vorteil von plant

play14:28

URL und

play14:30

das ist halt bei bei

play14:33

grounds.net oder troyo nicht so

play14:36

es gibt aber sehr gute

play14:39

grafische Diff Tools für

play14:42

images

play14:43

wenn man nicht zu viel an dem Diagramm

play14:47

ändert dann sieht man über so ein Diff

play14:49

eben auch optisch was ich geändert hat

play14:50

ja

play14:54

meistens ist es dann doch so also

play14:57

es ist selten dass ich mal irgendwie den

play15:00

dift bei einem Diagramm einsetze wobei

play15:03

bei plant UML liebe ich wenn man mit

play15:05

Sequenz Diagrammen arbeitet und im Team

play15:09

irgendwie so verschiedene Vorschläge

play15:11

vergleichen möchte und dann jedes Team

play15:15

Mitglied sich sonst Sequenzdiagramm

play15:18

einfach nehmen kann bisschen verändern

play15:19

kann und man sieht genau was was ist da

play15:22

anders an welcher Stelle hat derjenige

play15:25

gearbeitet und für die Zusammenarbeit

play15:27

ist das Gold wert

play15:30

6% gerade so ein paar Anmerkungen und

play15:32

Fragen über die Chats rein und ich würde

play15:34

dir gerne erst die die ich glaube plant

play15:36

UML Anmerkungen Vorlesen was man

play15:39

Anmerkungen sind Jendrik Oltmann sagt

play15:41

plant UL kann man auch stylen dann sieht

play15:43

sogar schick aus

play15:44

und ach ja diese die Namen aussprechen

play15:48

ist immer das größte Highlight hier Abo

play15:51

mormos sagt ich denke wenn man die

play15:53

Standard 7 plus minus zwei

play15:55

komponentenregel einhält werden planto

play15:58

Diagramme auch nicht so unübersichtlich

play16:00

ich glaube da hat er auch recht und ich

play16:03

glaube dann sind sie auch noch bartbarer

play16:04

als wenn man zu viel versucht dann ein

play16:06

Diagramms hatten

play16:08

definitiv also gerade ist 7 plus minus 2

play16:12

ist bei plant ganz wichtig weil

play16:14

ansonsten wird das Ganze schwer

play16:16

erwartbar die Sache mit dem Styling das

play16:19

ja kann man machen

play16:22

da habe ich aber oftmals das Problem

play16:25

dass das plant Ulm liagramm dann mehr

play16:29

Styling Optionen hat als überhaupt

play16:31

diagramminformationen das kann man

play16:33

natürlich auslagern wird meistens aber

play16:35

so wie ich das sehe nicht gemacht und

play16:38

was ich in dem Zusammenhang sehr

play16:40

interessant finde ist

play16:41

dass das wird einem gar nicht so bewusst

play16:44

aber

play16:46

ich habe einen blinden Kollegen der auf

play16:49

mich zukam und gesagt hat er hat plant

play16:52

Urmel gefunden und er findet das super

play16:54

klasse weil jetzt hat er die Möglichkeit

play16:58

als Blinder für Sehende Diagramme zu

play17:01

bauen

play17:03

und das passt dann auch im Umkehrschluss

play17:05

dass wenn wir plant oder plant OML

play17:08

Diagramme erstellen dass die

play17:10

accessibility höher ist weil man eben

play17:14

das das Diagramm sich auch noch vorlesen

play17:15

lassen kann und wenn man dann eben so

play17:19

viel Styling Informationen unter

play17:20

Umständen drin hat wenn es nicht einfach

play17:22

nur in include ist dann macht das diesen

play17:24

Use Case wieder kaputt

play17:27

man musste gerade noch dran denken ich

play17:29

habe auch gelernt dass die Tabellen in

play17:31

Konferenz sind auch nicht exzessibel für

play17:33

Blinde Nutzer ist noch etwas was wir vor

play17:36

einiger Zeit zugetragen wurde also da

play17:38

kommen immer noch mehr zu und ich glaube

play17:40

die also noch mehr Dinge um drauf und

play17:42

ich glaube gerade dieser magdon oder

play17:45

aski Bock Ansatz und dann eben plant ist

play17:47

ja quasi maximal Exzesse will was ja

play17:51

das maximale Wirkung genau ich gebe dir

play17:56

noch weitere Fragen und zwar hat Thomas

play17:58

Schwert relativ am Anfang geschrieben du

play18:00

hattest von deinem ersten Skript

play18:02

berichtet und du hast den Enterprise

play18:03

Architekt headless gestartet und ihn

play18:05

interessiert hat sich Sparks mal den

play18:07

Ansatz Enterprise Architekt auf diese

play18:10

Weise zu nutzen geäußert

play18:15

wie soll ich darauf antworten

play18:19

genau kommt drauf an ist die Antwort

play18:22

eines Architekten also nein ich habe da

play18:26

nichts mitbekommen

play18:28

es ist es ich glaube die

play18:32

Dokumentations Engine im Enterprise

play18:35

Architekt ist mittlerweile besser

play18:37

geworden damals ja wurde so eine html

play18:41

exportiert mit dem man nur schwer was

play18:43

anfangen konnte

play18:45

aber nein da habe ich kein kein weiteres

play18:47

Feedback bekommen apropos damals seit

play18:50

wann gibt es die Doktor Training

play18:51

eigentlich

play18:52

oder müsste ich jetzt Lügen ich weiß

play18:55

nicht muss man mal gucken welches der

play18:57

älteste commit ist

play18:59

aber es sind ja Jahre es sind einige

play19:01

Jahre wenn euch kam ich hatte es noch

play19:04

rausgefunden in einer Projektliste dass

play19:06

ich irgendwann 2017 mal damit rumspielen

play19:08

durfte also es ist auf jeden Fall schon

play19:10

ein bisschen

play19:11

genau es gibt noch zwei Fragen zu eben

play19:14

dieser Doktor chain einmal gibt es

play19:16

Maximilian Schmidt fragt auf Youtube

play19:18

gibt es in der Doktor chain auch eine

play19:20

Integration für mermaid

play19:23

das Interessante ist also mittlerweile

play19:26

unterstützt die doctool chain nicht nur

play19:28

huskydog sondern auch

play19:30

Markdown und restructured Text und über

play19:33

Plugins kann man theoretisch noch

play19:36

weitere Mark Absprachen reinnehmen und

play19:38

dann hängt es an der Mark Absprache was

play19:40

die unterstützt und aski dog das ist das

play19:43

was ich immer empfehlen würde

play19:45

unterstützt auch mermaid und ich

play19:48

empfehle mittlerweile auch also bei

play19:51

vielen Diagrammtypen muss man

play19:54

theoretisch Lokal noch irgendwelche

play19:56

Tools installieren

play19:58

und solche Geschichten

play20:00

und der Kroki Server der nimmt einem das

play20:03

ganze ab und es geht Doktor hat Support

play20:07

für den cookies-server da ich einfach

play20:09

über zwei Attribute den konfiguriere es

play20:12

gibt ein Public Cookie Server den ich

play20:15

natürlich für Projekte nicht einsetzen

play20:19

würde aber

play20:20

der ist relativ relativ leicht selbst

play20:23

aufgesetzt und darüber werden alle

play20:26

möglichen Diagrammtypen unterstützt und

play20:28

eben auch mermaid

play20:31

sehr gut Thomas Schwert hatte noch die

play20:33

Anmerkung das Bit bucket einen

play20:35

grandioses diphon-bnb PNGs eingebaut hat

play20:38

auf wirklich gute Weise also das scheint

play20:41

sich zu lohnen dass man anzuschauen wenn

play20:43

man muss und es kam noch die Frage von

play20:46

Hans Fallada 42 auf Twitch sieht sehr

play20:50

nice aus ist die doktool chain eher für

play20:52

das Java Ökosystem gedacht oder kann ich

play20:54

auch engular und notapplikationen

play20:55

Web-Apps damit versorgen

play20:59

also seit Anfang des Jahres haben wir

play21:02

mit der doktor-chain einen Schritt

play21:04

gemacht um die Technik herauszuziehen

play21:06

aus dem Report Story

play21:09

viele dieser Tools und doctool chain

play21:12

wird leider oft auch mit static side

play21:15

Generators verglichen haben die die

play21:18

ganze Technik mit im Report Story

play21:21

das haben wir jetzt geändert das war

play21:24

nämlich auch immer so die Frage oh ja

play21:26

das ist gerade drin das ist also nur für

play21:28

für Java und jetzt ist da quasi nur noch

play21:32

ein Rapper im repostory und der schaut

play21:35

ob

play21:36

Docker installiert ist ob er ein Docker

play21:38

Image verwendet oder ob er es lokal in

play21:42

User Folder installieren soll und

play21:46

mittlerweile gibt es auch ein Kommando

play21:48

get Java was dann die richtige Java

play21:51

Version auch noch in den Doktor chain

play21:54

Folder installiert und damit ist es

play21:57

eigentlich unabhängig von der

play21:58

Technologie ist natürlich in einer

play22:00

Technologie in Java umgesetzt

play22:03

aber ansonsten solltest unabhängig sein

play22:05

und kann eben für alles mögliche

play22:07

verwendet werden

play22:09

genau noch mal ich gehe gleich darauf

play22:11

ein noch ein kurzer Rücksprung magst du

play22:14

noch einmal kurz so ganz kurz sagen was

play22:16

mermaid überhaupt ist weil es hier Leute

play22:18

sind die das noch nicht gehört haben

play22:19

also ja mermaid ist ähnlich wie plant

play22:23

URL ein eine Library die

play22:27

eine textuelle Beschreibung eines

play22:29

Diagramms in eine Grafik umsetzt der

play22:32

große Unterschied ist dass mermaid als

play22:35

JavaScript auf dem Frontend eigentlich

play22:38

läuft und plant UML eher auf dem Backend

play22:43

und dadurch dass es als JavaScript im

play22:46

Frontend läuft hat zum Beispiel auch der

play22:47

Kroki Server ein bisschen mehr Probleme

play22:51

dabei das ist dann companion

play22:54

Docker Container der dann glaube ich per

play22:57

headless Chrom das Image rausholt oder

play23:00

sowas

play23:02

aber es funktioniert und wenn man auf

play23:05

kroki.io geht und dann sieht man eine

play23:08

ganze Liste von solchen Diagramm Tools

play23:11

die alle eben Text nach Diagramm wandeln

play23:14

da gibt es auch

play23:15

netzwerk-diagramme und auch ich glaube

play23:19

Vega heißt es mega und mega Leid ist für

play23:23

Standard Diagramme wie Peitsche bei

play23:27

liniendiagramme und sowas

play23:30

sehr gut jetzt tun wir so als hätten wir

play23:32

die Anmerkung nicht gehört und wussten

play23:34

noch über was es davor ging genau die

play23:37

Frage mit dem gibt es das nur fürs Java

play23:39

Ökosystem ich habe in Projekten die

play23:41

Erfahrung gemacht das ganz oft die

play23:43

Dokumentation eines eines einzelnen

play23:46

Services gar nicht wirklich in diesem

play23:48

Service liegt sondern das ist ein

play23:49

separaten wird Ordner ein extra

play23:54

Repository gibt wo die Dokumentation

play23:56

drin liegt

play23:58

erste Frage hast du das auch schon mal

play24:00

so gesehen zweite Frage was würdest du

play24:02

empfehlen oder was findest du sinnvoller

play24:04

und noch die Anmerkung dazu das finde

play24:07

ich macht das noch unabhängiger von der

play24:09

eigentlich eingesetzten Sprache weil es

play24:11

dann halt vollkommen egal ist ob der

play24:12

Service sind da was gibt geschrieben ist

play24:14

oder Ingo oder in ja genau

play24:17

genau also ja das sieht man tatsächlich

play24:19

sehr häufig dass ein Projekt über

play24:22

verschiedene Report Stories verteilt ist

play24:24

eine Architektur über verschiedene

play24:26

Microsoft Services und ich denke es

play24:29

macht durchaus Sinn das Jahr einer der

play24:32

Vorteil von dem Doktors Code Ansatz dass

play24:34

man die Dokumentation beim Code liegen

play24:36

hat dass man eben zum Beispiel auch Code

play24:39

referenzieren kann dass man den

play24:41

inkludieren kann und der dann in der

play24:43

Dokumentation weiterleben mit jedem

play24:45

bauen der Dokumentation

play24:47

und gerade weil dort Tool chain eben ja

play24:50

ein config-pfeil und ein Rapper ist kann

play24:54

ich diesen Rapper in jedes dieser

play24:56

repostories legen um diese Report

play24:58

Stories einzeln zu rendern

play25:00

aber ich kann eben auch ein

play25:02

übergeordnetes Architektur Report Story

play25:05

aufmachen indem ich dann alles

play25:07

zusammenziehe und ich mache das ganz

play25:09

gerne mit einem einfachen geht Klone der

play25:12

tiefer 1 dass ich eben ein kleines

play25:16

Skript habe wo ich die anderen Report

play25:17

Stories reinziehe und dann aus der

play25:19

hauptdokumentation referenzieren kann

play25:21

das funktioniert super und ich habe

play25:24

ehrlich gesagt noch kein environment

play25:26

Entwicklungs environment erlebt wo kein

play25:29

Kind Client installiert war so dass

play25:31

dieser Ansatz super funktioniert

play25:34

an teurer ist ja auch noch mal so ein

play25:38

static side Generator der coole Features

play25:41

hat

play25:43

nennt immer das als großes Feature das

play25:46

die Dokumentation in verteilten

play25:48

repostores liegen kann weil eben da ein

play25:51

Javascript basierter gibt Client mit

play25:53

dabei ist aber ich habe diesen Use Case

play25:56

eben noch nicht gefunden da ich eben

play25:57

extra geht klein brauche

play26:00

aber da sagst du gerade noch was mit dem

play26:03

static side Generator also wir sind

play26:04

vorhin schon ziemlich oft auf dieses

play26:06

wird generieren nach Konferenz gegangen

play26:08

ich glaube auch das ist das was ich in

play26:10

ihrem häufigsten in der Praxis erlebt

play26:12

habe

play26:12

ich habe jetzt eine frage kann man du

play26:16

hast mal einen Vortrag gehalten damals

play26:18

ich weiß nicht das ein oder zwei Jahre

play26:20

hier ähm über Micro Sites für

play26:23

Architektur Dokumentation und meine

play26:26

Frage kann man mit der Doktor Jane auch

play26:28

Micro sights generieren oder ist das

play26:30

noch nicht wirklich doch also das ist

play26:33

jetzt eigentlich mit einer der Haupt Use

play26:37

Case die die ich benutze

play26:39

ich kann tatsächlich es sind glaube ich

play26:42

vier befehle ich habe meinen Tweet

play26:44

verfasst wo sie drin sind da ich mit

play26:46

einem Curl den Doktor chain Rapper ziehe

play26:49

den executable mache dann durch den

play26:53

Befehl Download Template aus mit dem ich

play26:55

dann das Akt 42 Template mit mir die

play26:59

aktuellste Version er fragt dann nur

play27:01

noch welche Sprache und mit oder ohne

play27:04

Hilfe und mit dem Befehl generate Zeit

play27:07

baue ich da tatsächlich eine Microsoft

play27:09

Seite auf mit Landingpage mit der

play27:12

Dokumentation es ist sogar eine lokale

play27:16

Suche mit dabei über Luna JS

play27:20

und da wird jaybake als static side

play27:24

Generator genutzt und JP kann eben was

play27:27

geht ab und Markdown und HTML und über

play27:30

das HTML Feature wird dann eben auch

play27:32

restructure Text zum Beispiel

play27:34

reingezogen dass man das noch mal extern

play27:37

aufruft und nach HTML konvertiert somit

play27:40

ist das eins der großen Features aber es

play27:43

sind eben auch so Features dabei dass

play27:45

ich dann eben auch PDF rauslassen kann

play27:47

da ist nach Konferenz noch exportieren

play27:48

kann da ich aber zum Beispiel auch wenn

play27:50

ich komplexere Tabellen habe und um mal

play27:55

wieder auf das Thema Diagramme

play27:56

zurückzukommen

play27:57

unterstütze ich ja auch ganz gerne so

play28:00

ein Diagramm mit einer Tabelle wo ich

play28:01

die Elemente noch näher beschreibe und

play28:05

Doktor zum Beispiel Excel falls einlesen

play28:09

nach asgok konvertieren und da der total

play28:15

viele Features von dem excel-fall mit

play28:16

die Spaltenbreite

play28:20

Hintergrundfarben Word horizontal

play28:23

Element soll ich da viele Möglichkeiten

play28:25

habe mich in Excel auszutoben das dann

play28:29

aber in die Dokumentation reinzuziehen

play28:30

und da haben wir dann auch wieder den

play28:32

interessanten Fall wie mit den Image

play28:34

Stifts das dadurch dass ich das eine

play28:38

Textform rausgezogen habe kann ich dann

play28:40

von dem Excel File tatsächlich den Stift

play28:42

sehen und sehen was ich geändert hat

play28:48

aber nur das also du würdest trotz also

play28:51

ich würde das Excel-File pflegen und die

play28:53

Pipeline würde dann die Informationen

play28:55

aus dem Wechsel zu fallen in die Pool

play28:57

Clan pusten und in der Transformation

play29:00

von der Tool chain würde ich dann das

play29:02

sehen also genau und das ist dann so ein

play29:04

Punkt wo man eigentlich als Entwickler

play29:07

sagt ja das Export also aus Excel

play29:10

exportiert Tabelle das ist dann

play29:12

eigentlich generiert und sollte

play29:14

eigentlich nur ein Bild voller Leben

play29:18

das Ganze kam aber als Paul request ich

play29:21

weiß jetzt gar nicht mehr von wem rein

play29:22

müsste man noch mal aussuchen

play29:24

und derjenige hat das Ganze eben in den

play29:30

Source Folder reingelebt da wo es eben

play29:32

versioniert wird und wir hatten dann

play29:34

eine kurze Diskussion ja sollte es nicht

play29:36

eigentlich ein Bild voll da liegen der

play29:38

hat gesagt nein weil die Versionierung

play29:41

bringt eben den Vorteil dass ich machen

play29:43

kann und dass ich eben sehe dass ich da

play29:45

was geändert hat und das ist so ja da

play29:48

muss man ein bisschen über den eigenen

play29:50

Schatten springen dass man

play29:51

wahrscheinlich das Excel weil und das

play29:54

exportierte

play30:00

du hast schon gesagt wir müssen mal

play30:01

wieder zurück zu Diagrammen kommen das

play30:03

stimmt aber jetzt hat man schon mal dich

play30:05

hier denn ist klar dass man gerne Fragen

play30:07

zu stellt

play30:09

genau ich glaube rausgehört zu haben

play30:12

dass du lieber plant omel machst als

play30:14

draw.io stimmt das nein also

play30:16

mittlerweile

play30:18

plant URL ist toll fürs die können es

play30:21

Diagramme weil da gibt's keine Layout

play30:23

Probleme bei allem anderen die hier

play30:26

schon gesagt worden ist 7 + -2 das ist

play30:29

prima wenn ich Gefahr laufe des

play30:33

komplexer wird dann sollte ich aufpassen

play30:37

aber das plusminus 7 plus minus 2 das

play30:40

tatsächlich ein guter Ansatz um

play30:44

ja um übersichtliche Diagramme zu

play30:47

erstellen also über die Zeit habe ich so

play30:50

ein paar

play30:51

Prinzipien mehr angewöhnt dass zum

play30:54

Beispiel ein Diagramm ohne rein zu

play30:57

zoomen auf einer Bildschirmseite lesbar

play30:59

sein sollte früher habe ich gesagt auf

play31:02

einer DIN A4 Seite

play31:03

mittlerweile drucke ich nichts mehr

play31:05

deswegen sage ich Bildschirmseite und

play31:07

ich meine nicht diese Risiken 8k

play31:09

Monitore sondern ich meine ein normalen

play31:13

Notebook

play31:14

Bildschirm

play31:17

ohne Zoom und das bedeutet eigentlich

play31:20

schon ich kann gar nicht so viel

play31:22

Elemente draufsetzen sondern ich muss

play31:24

auf einer gewissen abstraktions Ebene

play31:26

bleiben bei einer gewissen Flughöhe und

play31:29

da hilft von Simon Brown das C4 der C4

play31:33

Ansatz dass ich ja auf der obersten

play31:37

Ebene nur den Kontext darstelle nächste

play31:40

Ebene gehe ich in die einzelnen

play31:42

Container rein

play31:44

von components die classis das ist

play31:46

meistens für eine Architektur zu

play31:49

dynamisch dass ich das dann nicht mehr

play31:51

darstelle aber das hilft eben die

play31:54

Abstraktionsebene beizubehalten und dann

play31:57

eben wenig Elemente in einem Diagramm zu

play32:00

haben

play32:01

das

play32:03

net hat noch ein paar andere nette

play32:06

Vorteile nicht nur für

play32:09

architekturdiagramme zum Beispiel auch

play32:10

wenn ich ein User Manual mache und mit

play32:13

Screenshots arbeite und irgendwas

play32:15

Highlighten will oder so

play32:18

das ist auch so ein ja mindset dass man

play32:23

mit einem Diagramm Tool mit Screenshot

play32:25

arbeitet aber ich habe herausgefunden

play32:28

ist ganz nützlich weil wenn ich den

play32:30

Screenshot reinsetze und dann mit

play32:32

Pfeilen oder Highlights arbeite oder so

play32:34

dann habe ich eben source diese Pfeile

play32:37

und Highlights getrennt vom Screenshot

play32:39

und wenn ich das ganze dann irgendwann

play32:42

mal aktualisieren muss neuer Screenshot

play32:44

rein dann hänge ich einfach den

play32:45

Screenshot rein und guck ob die Pfeile

play32:47

noch passen

play32:49

und das sind einfach Features die sind

play32:51

die sind toll dabei

play32:54

ja

play32:55

Architektur Dokumentation noch nicht

play32:57

sehr oft Screenshots gesehen genau

play32:59

deswegen das ist dann eher so ein User

play33:02

Manual oder so aber auch das hat man

play33:05

teilweise mit zu arbeiten

play33:09

der Screenshots in Architektur

play33:11

Dokumentationen

play33:16

ich glaube es kommt auf die Architektur

play33:18

drauf an wenn man irgendwie mit einer

play33:21

Architektur anfängt eine zu verbessern

play33:24

und irgendwie auf Probleme in der alten

play33:27

hinweisen möchte vielleicht ist dann

play33:29

Screenshot passend

play33:32

genau du hast schon ganz oft gesagt und

play33:34

wie Sequenzdiagramme und meine Frage

play33:37

wäre was die Diagrammtypen sind die du

play33:39

am häufigsten in Architektur

play33:41

Dokumentationen einsetzt

play33:43

ja eigentlich Boxen lines ne also gar

play33:47

nicht so an den URL Diagramm entlang

play33:50

hangeln sondern das was passt und wir

play33:54

waren vorhin beim Enterprise Architekt

play33:56

und das ist ein Feature was ich an ihm

play33:58

Liebe dass man Elemente aus

play34:00

verschiedenen Diagrammtypen

play34:02

zusammenschmeißen kann weil ich eben

play34:04

auch an ein Klassendiagramm mal ein

play34:07

actor dranhängen kann damit ich weiß der

play34:10

und der Entwickler kümmert sich um die

play34:12

und die Klasse und

play34:16

von daher ich meine das Arc 42 Template

play34:21

das

play34:22

bringt ja schon einige Vorschläge für

play34:26

für bestimmte Diagrammtypen zusammen

play34:30

und das sind dann eigentlich auch so die

play34:32

groben Diagramm Typen die ich immer

play34:34

benutze

play34:35

wichtig für mich ist halt vor allem auch

play34:38

und wir hatten ja jetzt das ganze hier

play34:41

als mehr als nur Linien und Kästchen

play34:44

genannt

play34:45

das es kommt nicht nur auf den Diagramm

play34:49

Typ drauf an ob etwas lesbar ist sondern

play34:52

eben auch wie ich das ganze Aufbau und

play34:55

ich glaube es hat jeder schon diese

play34:58

Diagramme gesehen

play34:59

wo sehr viel weitspace drin ist wo

play35:03

zwischen den Blöcken ganz lange Linien

play35:06

sind die ich irgendwie visuell verfolgen

play35:08

muss dann kleine Schriften in den

play35:12

Blöcken drin so dass wenn ich das ganze

play35:16

Diagramm was zwar nur wenig Elemente hat

play35:19

aber wenn ich es eben in einer Zoomstufe

play35:23

habe dass ich eben komplett übersehen

play35:26

kann dass dann eben die Schriften

play35:29

teilweise zu klein sind da ich die nicht

play35:31

mehr lesen kann und das ist zum Beispiel

play35:33

auch so ein Ding wo ich sag da kann man

play35:35

an Diagramm viel verbessern dass man

play35:37

eben white space rausnimmt dass man die

play35:40

Sachen enger zusammensetzt dass man auch

play35:43

auf das optische achtet das ich mache

play35:46

zum Beispiel ganz gerne dass die

play35:49

Schriftgröße von den von den Blöcken

play35:53

vergrößert teilweise fett machen damit

play35:56

man das auf jeden Fall einfach lesen

play35:58

kann und so Beschriftung von Teilen

play36:01

kleiner mache weil das ist das man muss

play36:05

erstmal mit dem ersten Blick die Blöcke

play36:08

erfassen

play36:09

und dann geht man die Pfeile entlang und

play36:11

dann hilft da die Beschriftung was macht

play36:13

eigentlich dieser Pfeil und dieses

play36:16

visuelle das finde ich total wichtig

play36:20

und da gibt es auch ein Talk eine

play36:24

Aufzeichnung vom

play36:28

Jochem Schulen Klopper und der geht

play36:32

genau auf diese Sachen auf das visuelle

play36:35

sehr stark ein und der zum Beispiel auch

play36:38

diesen Punkt angebracht was ist mit den

play36:41

Farben und

play36:43

Farben haben bei uns eigentlich so eine

play36:47

intuitive Bedeutung dass zum Beispiel

play36:49

rot achtung da ist irgendwas komisch

play36:53

aber wir setzen uns in Diagramm nicht so

play36:56

ein nicht zum Beispiel an AWS Diagramme

play36:59

denke ich glaube der ist drei bucket ist

play37:00

rot warum ist der eigentlich rot sollte

play37:03

ich den meiden oder

play37:06

und wenn man auf sowas achtet dass man

play37:10

die Farben auch richtig einsetzt

play37:13

Gold wert also grün ist etwas damit sind

play37:18

wir zufrieden blau ist eh stabil

play37:20

orange und rot nee also da sollten wir

play37:24

daran arbeiten

play37:25

es bringt was

play37:28

auch hatte ich mal ein Projekt wo ich

play37:30

die Kästen so groß gemacht habe wie halt

play37:34

die Beschriftung waren also wenn wenn

play37:35

die Beschriftung der Name etwas größer

play37:37

war dann braucht die bisschen mehr Platz

play37:38

habe da also größeren Kasten genommen

play37:41

und wurde dann sofort gefragt

play37:44

warum ist jetzt dieser Kasten größer als

play37:47

Jena und bei mir erst gar nicht so

play37:51

bewusst dass das Leute da drauf achten

play37:53

aber auch das kann eben eine Bedeutung

play37:55

haben

play37:57

kann zum Beispiel Komplexität sein oder

play37:59

sowas

play38:02

und auf diese visuelle Sprache zu achten

play38:04

und sie auch zu erklären dass man eine

play38:07

Legende in seinen Diagramm reinbringt

play38:09

und in der Legende kann man zum Beispiel

play38:11

auch die Quelle des Diagramms gleich

play38:13

nennen und den den Autor dass man

play38:15

Ansprechpartner hat dass man die Quelle

play38:17

auch findet dass man was verändern kann

play38:20

ist eben auch ganz wichtig und ich denke

play38:24

es sollte man nur weglassen wenn man

play38:27

eine

play38:28

visuelle Sprache benutzt die auch

play38:31

irgendwo anders definiert ist aber

play38:34

selbst dann sollte man auf diese

play38:36

Definition verweisen dass man sagen kann

play38:39

hey wir benutzen hier den keine Ahnung

play38:42

AWS diagram Style und hier findet ihr

play38:47

den

play38:54

aber dann würdest du auch in dieser

play38:55

Legenden Tabelle würdest du auch

play38:57

beschreiben wenn etwas rot ist dann

play38:59

bedeutet das Legacy System wird abgelöst

play39:02

läuft noch bis Ende 23 oder so und wenn

play39:05

etwas grün ist wurde vor zwei Jahren

play39:07

abgelöst oder sowas also würdest das

play39:09

schon nicht nur die die

play39:12

verwendeten Typen von Dingen also Kasten

play39:16

Pfeil was wir da nicht alles haben

play39:18

sondern auch wirklich die Farben

play39:20

reinschreiben und in deinem Beispiel

play39:22

vorhin hätte die Größe eines Kästchens

play39:24

eine Bedeutung gehabt hättest Du

play39:25

möglicherweise auch noch als Anmerkung

play39:27

bei dem Kasten wenn größer dann

play39:29

wichtiger oder wenn größer dann

play39:31

umfangreicher oder so da reingeschrieben

play39:33

genau und da ist halt wichtig dass man

play39:35

eben auch

play39:37

damit arbeitet was intuitiv Sinn macht

play39:40

also es gibt ja diese Spielereien wo man

play39:43

so paar Farbnamen hat und Grün in blau

play39:46

schreibt und solche Geschichten und das

play39:49

verbirgt ja als würde genauso verwöhnen

play39:51

wenn ich jetzt definieren würde ein

play39:54

kleines Kästchen hat großkomplexität

play39:55

Großes Kästchen hat kleine Komplexität

play39:57

oder sowas und deswegen

play40:01

ist gut das zu erklären ist wichtig das

play40:04

zu erklären aber eben auch wichtig dass

play40:06

man intuitive

play40:08

Eigenschaften nimmt so dass wenn man die

play40:11

Erklärung gelesen hat man sagt ah ja

play40:13

okay das macht Sinn und jetzt weiß ich

play40:15

rot ist das was wir verändern wollen

play40:18

also ich finde das total also ich finde

play40:20

es sinnvoll ich finde es auch cool mit

play40:21

Farben zu arbeiten also ich mag es

play40:23

buntes Sammlung wirklich auch einige

play40:24

hier draußen schmecken merkt ich habe

play40:27

aber gerade also so ich hätte Angst dass

play40:31

man das ja auch schnell übertreiben kann

play40:33

mit dieser also mit Farben und jetzt ist

play40:36

zum Beispiel grün-weiß gestreift

play40:37

bedeutet das und das und nachher hat man

play40:39

viel zu umfangreiches Diagramm obwohl

play40:43

vielleicht nur fünf Komponenten da drin

play40:44

sind aber die Legende davon ist vier

play40:47

Seiten lang was die einzelnen außen und

play40:50

Abstufungen zu bedeuten haben

play40:52

Frage a hast du sowas schon mal erlebt

play40:55

und Frage B machst du wenn du ein

play40:58

Diagramm entwirfst so ein zenity Check

play41:00

das sowas vielleicht gerade nicht

play41:01

passiert

play41:03

ja sanity Check ist ein gutes Thema

play41:08

Simon Brown hat eine Checkliste für gute

play41:12

Diagramme die habe ich in einem Buch was

play41:15

ich angefangen habe auf lean Pub was

play41:18

noch nicht fertig ist mal übersetzt und

play41:21

auch mit meinen Ideen noch erweitert da

play41:25

kann man einiges an Checkliste machen

play41:27

aber schon allein wenn man eine Legende

play41:30

erstellt und das macht keinen Spaß

play41:31

sondern Legende zu erstellen ja dann

play41:34

denkt man sich manchmal brauche ich

play41:36

diesen extra Linientyp wenn ich den

play41:38

rausnehmen dann ist die Legende kleiner

play41:40

dann also auch das hilft teilweise

play41:44

und wenn man tatsächlich

play41:47

so komplex eine eigene visuelle Sprache

play41:51

erstellt dann macht es vielleicht Sinn

play41:53

die er wird das Projekt oder das

play41:56

Unternehmen mal zu definieren und nur

play41:57

darauf zu verweisen aber sonst in den

play42:01

meisten Fällen merke ich eigentlich

play42:04

genauso wie die Anzahl der Elemente

play42:07

sollte man eben auch die die Anzahl der

play42:10

Bedeutung von Farben Linien Größen und

play42:13

sonst was

play42:14

reduzieren und da auf einem

play42:17

abstraktionslevel bleiben und

play42:20

dann macht es vielleicht Sinn eben

play42:23

mehrere Diagramme aufzubauen die eben

play42:26

verschiedene Sachen darstellen

play42:29

also wenn ich zum Beispiel ein

play42:30

Kontrollfluss darstelle dann werde ich

play42:33

nicht die Farben noch dazu verwenden von

play42:35

den Elementen um zu sagen an dem Element

play42:39

müssen wir arbeiten sondern dann ist

play42:41

halt der kontrollbeschluss im Fokus

play42:44

das ist übrigens auch so ein Ding die

play42:47

die Richtung der Pfeile in den Diagramm

play42:49

sind manche Sachen wo ich selbst früher

play42:53

irgendwie drüber gestolpert bin was ich

play42:56

mittlerweile als trivial ansehe aber die

play43:01

Pfeilrichtung ich habe früher immer so

play43:05

überlegten in welche Richtung mache ich

play43:07

die Pfeile da wo die Daten hinfließen

play43:09

dann rufe ich irgendwas auf und kriegt

play43:12

Daten zurück also Daten rückrichtung

play43:15

aber dann habe ich irgendeine API wo ich

play43:18

ziemlich viel hinschicke und auch wieder

play43:20

zurückbekommen und dadurch hatte ich

play43:22

dann oftmals Pfeile die einfach in beide

play43:24

Richtungen gezeigt haben und das hat

play43:26

irgendwie gar keinen Mehrwert gegeben

play43:28

bis ich mal mit Peter ruschka gesprochen

play43:31

habe und der gesagt hat du es ist doch

play43:33

klar es geht darum wer ruft wen auf ja

play43:36

und ja seitdem ist dieses Problem aus

play43:40

meinem Kopf raus ist hört sich albern an

play43:43

wenn man es eben weiß aber es sind

play43:46

genauso wie die das eben manche Leute

play43:49

auf die größte der Elemente achten

play43:52

hat mir dieser Hinweis einfach extrem

play43:54

geholfen und trotzdem schreibe ich es in

play43:57

die Legende rein in kleinen Pfeil und

play44:00

daneben Aufruf Richtung und damit ist

play44:03

das eben klar

play44:05

ich muss mal einmal hier einen Anmerkung

play44:08

an die Youtube Jan und Tobias Höft

play44:11

machen ihr habt einmal geschrieben denkt

play44:13

jeden keine Informationen übers Internet

play44:14

und Beispiel der Youtube Chat ist leider

play44:18

für uns ein bisschen versetzt also wir

play44:20

sind ein bisschen vor eurer Zeit sagt

play44:22

man das so hört sich blöd an wenn ihr

play44:24

wollt dass ich dem Reifen Fragen stelle

play44:26

dann wäre es total cool wenn ihr die so

play44:28

ausformuliert dass ich sie jetzt stellen

play44:30

könnte ohne den genauen Kontext zu haben

play44:32

weil mir der schon fällt wenn ich euren

play44:35

Text lese genau das wollte ich nur

play44:37

einmal als Anmerkung sagen ich glaube

play44:40

die Anmerkung mit den Informationen über

play44:42

das Internet bezieht sich wahrscheinlich

play44:44

auf den Cookies Server weil wenn man

play44:46

jetzt eben für die Dokumentation für das

play44:48

Rendering der Diagramme den Cookies aber

play44:51

im Internet nimmt

play44:53

ist das natürlich blöd dann gehen da die

play44:56

Infos über das Projekt irgendwo raus

play44:59

was ganz nett ist ist dass der Kroki

play45:03

Server plant ulml kompatibel ist das

play45:05

heißt für Plantur mehr gibt es eben auch

play45:07

ein entsprechenden Server und

play45:09

gitlab nutzt diesen Plan du Mail Server

play45:13

und den kann ich eben gegen den Cookie

play45:16

Server austauschen in meiner

play45:18

Organisation so dass eben gitlab plant

play45:23

Ulm über den Server rendert aber eben

play45:25

ich dann auch diesen Cookie Server für

play45:28

andere Diagrammtypen habe

play45:32

und damit kriege ich den relativ leicht

play45:34

aufgesetzt also wenn ich ein getlep Team

play45:36

habe dann

play45:37

bitte ich die einfach die Komponente

play45:39

austauschen

play45:41

möglicherweise war das die Antwort auf

play45:43

ganz anderem genau

play45:45

du hattest eben das fand ich ganz

play45:47

interessant

play45:49

öfter mal darauf verwiesen dass es ja

play45:50

vielleicht schon eine visuelle Sprache

play45:52

im Unternehmen gibt die man nutzen kann

play45:54

oder eben nicht und man führt einer ein

play45:56

würdest du sagen dass es mein Ziel als

play45:59

softwarearchitektin die total

play46:01

Visualisierung und Dokumentation liebt

play46:04

sein sollte eine visuelle Sprache in

play46:06

einem Unternehmen einzuführen die dann

play46:08

derer sich dann andere auch bedienen

play46:09

können

play46:12

ich weiß nicht ob so das direkte Ziel

play46:14

sein muss aber ich kenne das häufig dass

play46:17

Vater ausgetrampelt werden dass das was

play46:20

gut ist von anderen übernommen wird und

play46:23

wenn man eben so eine gute visuelle

play46:25

Sprache aufsetzt in einem Projekt und

play46:28

andere die sehen dann wird die

play46:30

wahrscheinlich übernommen werden

play46:32

und ich glaube so ergibt sich das

play46:35

einfach natürlich macht es auch Sinn

play46:37

wenn man dann eben mal drüber spricht

play46:40

dass man sagt hey ich hatte hier immer

play46:42

visuelle ja Probleme mit dem visuellen

play46:46

Styling das sehr ähnlich bei bei

play46:49

planturml wenn man da

play46:52

den Style nicht mag und einen eigenen

play46:54

Style aufsetzt dass der dann eben durch

play46:57

die Teams die Runde macht und mehrere

play46:59

den verwenden

play47:01

und ich glaube ähnlich ist das bei dem

play47:03

visuellen Style von architekturdiagramm

play47:06

natürlich macht es dann auch Sinn

play47:08

vielleicht mal so ein bisschen Best

play47:10

Practice aufzuschreiben und ich glaube

play47:13

so eine Checkliste von Simon Brown oder

play47:15

aus dem Docs Code Buch was nicht fertig

play47:19

ist

play47:20

die macht da auch Sinn

play47:24

es ist noch nicht fertig

play47:25

ich glaube fest an Dich ich auch

play47:30

es macht übrigens auch Spaß wenn man

play47:32

sich einfach mal

play47:33

zusammensetzt und aus dem Internet mal

play47:38

nach architekturdiagramm Google

play47:40

in der Bildersuche ein Diagramm

play47:43

rauspickt und in der Gruppe drüber

play47:46

diskutiert was an dem Diagramm gut ist

play47:49

was verständlich ist und was

play47:52

unverständlich ist und dann eben auch so

play47:55

fragen ja wärst du jetzt Architekt wie

play47:59

würdest du jetzt mit diesem Diagramm

play48:01

arbeiten könntest du es verändern zum

play48:04

Beispiel auch

play48:05

oder

play48:07

ja dass man mal guckt welche

play48:11

Informationen man daraus zieht

play48:14

oftmals ist es auch so dass so ein

play48:15

Diagramm etwas unverständlich ist aber

play48:18

man sich gar nicht

play48:19

traut da Kritik zu äußern weil man

play48:23

denken ja also da wird sich schon

play48:24

irgendwer was bei gedacht haben das S3

play48:27

bucket immer rot ist das

play48:29

wird schon irgendwie visuelle Sprache

play48:32

sein die ich halt nicht kenne

play48:36

links also genau mit dem Zusammensetzen

play48:38

finde ich gerade noch interessant es

play48:39

gibt ja in vielen Organisationen diese

play48:41

Idee von es hat immer andere Namen Trips

play48:44

chapters

play48:46

ich weiß nicht unendliche Mengenangaben

play48:48

wo sich Menschen aus verschiedenen Teams

play48:51

die eigentlich an den gleichen Dingen

play48:52

arbeiten z.B UX oder Architektur

play48:55

zusammensetzen und über Dinge

play48:56

diskutieren denkst dass ergibt Sinn

play48:58

einen Trip für oder was auch immer wie

play49:01

wie es auch immer genannt wird für

play49:03

Dokumentation speziell zu machen wo man

play49:05

sich einmal im Monat hinsetzt und

play49:08

Diagramme anschaut die vielleicht nicht

play49:10

gelungen sind oder überhaupt in der

play49:12

Dokumentation spricht oder sowas

play49:14

in der Tat ich denke das macht Sinn und

play49:18

das ist auch dass sie der Doktors Code

play49:21

Ansatz weiterentwickelt wird und eben

play49:24

auch dorthin weiterentwickelt wird und

play49:27

das macht durchaus Sinn sich das Ganze

play49:30

anzugucken und zu gucken wo kann ich

play49:33

hier jetzt

play49:35

ich sag mal viele dieser Sachen zum

play49:39

Beispiel diese

play49:40

Enterprise Architekt Export ja der der

play49:43

wäre nie so entstanden wenn ich mir

play49:46

nicht gesagt hätte den kann ich für

play49:48

mehrere Projekte gebrauchen in einem

play49:50

Projekt hätte man gesagt nee das zu viel

play49:52

Aufwand macht es nicht

play49:55

aber wenn ich mich dann eben in mehreren

play49:58

Projekten darüber Ärger das wäre

play50:02

leichter wenn ich das exportieren könnte

play50:03

und mich dann dran setze dann dann hat

play50:08

es so einen Mehrwert und deswegen ist

play50:10

dieses zentrale darüber nachdenken wie

play50:13

können wir das verbessern und auch das

play50:16

Plugin ist ist so ein Beispiel dass

play50:20

ja in einem Projekt für das Projekt

play50:23

hätte man es nie gemacht aber jetzt

play50:26

benutzen es ganz viele auch wenn es noch

play50:29

so ein bisschen

play50:31

ja es hat noch Verbesserungspotenzial

play50:34

wenn ich zum Beispiel in der

play50:37

standardzoomstufe ein PNG erstelle dann

play50:40

ist es ein bisschen pixelig ist die

play50:43

Auflösung für die Schrift nicht so gut

play50:45

deswegen ziehe ich meine ganzen Elemente

play50:47

erstmal auf 200% hoch und nehmen auch

play50:50

anstatt 12 Punkt Schrift 24.schrift

play50:54

dann ist das gelöst passt da jemand mal

play50:57

Lust hat an das Plugin Rand zu gehen

play51:00

ja wir würden uns freuen

play51:04

genau ein Thema was damals mit falschen

play51:07

Auftrag haben was glaube ich mit

play51:09

genereller Architektur Dokumentation

play51:11

noch einfacher zu beheben ist als mit

play51:12

Diagrammen aber vielleicht hast du da

play51:14

auch eine Lösung für ist die Diagramme

play51:17

in der Architektur Dokumentation aktuell

play51:19

zu halten hast Du spezielle

play51:21

Vorgehensweisen wie das gewährleistet

play51:23

bleiben kann

play51:27

also ein wichtiger Punkt ist natürlich

play51:29

dass man überhaupt weiß wo die Quellen

play51:31

des Diagramms liegen dass man damit

play51:33

arbeiten kann

play51:35

der nächste Punkt haben wir ja auch

play51:37

schon angesprochen dass ich eben weiß

play51:40

wie ich

play51:41

dann auch die aktualisierten Diagramme

play51:44

in die Dokumentation reinbekommen das

play51:46

heißt besser in der Dokumentation sind

play51:50

die Diagramme referenziert das übrigens

play51:52

ein Feature was auch eine

play51:54

Textbearbeitung kann sie sie kann

play51:56

externe Diagramme reinziehen dann wäre

play51:59

das Ganze leichter damit zu arbeiten

play52:01

aber es ist halt ein Feature was von

play52:03

vielen nicht genutzt wird und spätestens

play52:05

wenn dann eben nur das Hauptdokument per

play52:07

E-Mail verschickt wird dann sagen alle

play52:10

das funktioniert so nicht

play52:12

aber wichtig ist auch genauso wie bei

play52:15

der restlichen Architektur Dokumentation

play52:17

das meinen ein

play52:19

abstraktionslevel erwischt der sich

play52:23

selten verändert so dass man eben weiß

play52:26

das hat jetzt längere Zeit Gültigkeit

play52:29

und wenn wir an die Definition von

play52:32

Architektur denken dass das die

play52:34

Entscheidung sind die eben später

play52:37

schwierig sind zu verändern die

play52:39

tragenden Mauern unseres Gebäudes die

play52:42

reißt sich nicht einfach noch mal ein

play52:43

wenn ich die

play52:46

ja die Position eines Sofas in im

play52:50

Wohnzimmer dokumentiert naja dann dann

play52:54

muss ich das ständig aktualisieren aber

play52:56

das sollte eigentlich eben auch nicht

play52:58

Teil der Architektur sein

play53:00

ich frage mich oft drin im Wohnzimmer

play53:02

umräumst dass unser so versteht er

play53:04

einfach steht Seite ewig aber okay

play53:09

ja es ist zum Beispiel jetzt musste das

play53:13

Sofa dem Weihnachtsbaum irgendwie

play53:14

weichen

play53:16

und dann kann das schon woanders stehen

play53:19

die Architektur Dokumentation fürs

play53:22

Wohnzimmer temporär angepasst werden das

play53:24

wäre ja dann die Innenarchitektur und

play53:28

also das sind halt wirklich wichtige

play53:32

Punkte und dieser Ansatz dass ich die

play53:36

Quellen bei dem stop net

play53:39

Diagramm habe das ist super klasse

play53:43

und ich sollte halt auch wirklich bei

play53:46

allem was ich in die Diagramme

play53:48

reinschreibe darauf achten welche

play53:52

Details ich rein schreibe und das das

play53:54

sehe ich eben auch immer wieder bei

play53:55

Diagramm wenn da irgendwo eine Pfeil

play53:59

eine Portnummer dran steht

play54:01

ja es gibt Standardports aber ansonsten

play54:05

ist das eigentlich den Betriebsteam

play54:07

überlassen auf welchen Port irgendein

play54:09

microservice läuft oder sowas und

play54:12

teilweise sehr mittlerweile auch

play54:13

dynamisch oder ich weiß dass in der

play54:16

Information die veraltet viel zu schnell

play54:17

dann schreibst lieber nicht dran

play54:21

noch einmal noch warum habe ich das

play54:22

gerade gefragt mit dem aktuell auf

play54:24

Twitter kam der kommentar von stefan

play54:26

Hildebrandt aktuell sollten sie sein und

play54:28

Zugriff auf historisches ist manchmal

play54:30

auch gut also zu architekturdiagramm das

play54:33

historische haben wir schon abgebildet

play54:35

mit dem wir haben es geht genau unter

play54:38

Aktuell hast du jetzt gerade noch mal

play54:39

erklärt wir neigen uns langsam dem Ende

play54:42

der Zeit Ralf und ich glaube du möchtest

play54:44

ganz bestimmt noch Werbung machen für

play54:46

alle Leute die richtig Lust haben sich

play54:48

noch mehr mit Architektur die

play54:50

Dokumentation zu befassen und zufällig

play54:52

im März ist es ne aber genau

play54:56

ja auf der javaland werde ich mit Falk

play55:00

sippach das Thema noch mal

play55:03

noch mal aufbereiten dass wir

play55:05

tatsächlich noch mal über Diagramme

play55:08

fantastische Diagramme haben wir jetzt

play55:10

genannt sprechen werden und all diese

play55:12

Dinge die wir jetzt mal so angeschnitten

play55:16

haben noch mal zusammen suchen dass wir