ITech Night School über “Blockchain”

ITech Night School über “Blockchain”

“Alle zwei Wochen findet unsere interne Weiterbildungsmaßnahme mit dem Namen Nightschool “von den Kollegen für die Kollegen“ in unseren Räumlichkeiten in Nürnberg statt. Die Nightschool am 15.05.19 lief unter dem Titel „Blockchain – Grundlagen und Architektur“. Neben einer allgemeinen Einführung nur Entstehung und Geschichte der Technologie, behandelten wir die Anforderungen und den Aufbau der Blockchain. Zunächst erhielten die Teilnehmer eine explizite Definition und lernten, wie das Verkettungsprinzip einer Blockchain funktioniert und was es so besonders macht. Danach wurden die Anforderungen der dezentralen Buchführung erläutert, sowie die verschiedenen Konsensverfahren, mit denen neue Blöcke geschaffen und an die bereits vorhandene Blockchain gehängt werden können. Hierbei wurde auch das populärste Konsensverfahren „Proof of work“ mit seinen Transaktionsregeln thematisiert.

Das berühmteste Anwendungsbeispiel ist wohl die Kryptowährung “Bitcoin”, welche von unseren Kollegen näher unter die Lupe genommen wurden. Zudem wurden auch Nachteile der Blockchain aufgeführt und die Frage geklärt, wie man mit diesen am besten umgeht. Zuletzt fand eine Bewertung der Blockchain in Bezug auf die Zukunft und den sozioökonomischen Kontext statt.

Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Der Abnahmetermin für die Software steht bevor und das Review der Softwarearchitekturen sorgt für schlaflose Nächte. Eine Architekturbewertung soll durchgeführt werden um die Stärken und Schwächen der Softwarearchitektur zu ermitteln. Wurden die relevanten Qualitätsmerkmale erfüllt und alle Ziele erreicht?

Grundlegend geht es bei der Architekturbewertung darum, herauszufinden, ob eine Softwarearchitektur die in sie gesetzten Erwartungen erfüllt oder nicht. Was sind die Stärken und Schwächen einer Architektur und welche Risiken und Probleme ergeben sich daraus?

Als Vergleich zur Softwarearchitekturbewertung nehmen wir einmal die Bewertung von sportlichen Leistungen. Genau wie bei der Softwarearchitektur lassen sich auch sportlichen Leistungen je nach Disziplin mehr oder weniger gut beurteilen. Wer läuft schneller? Wer springt höher? Wer wirft weiter? Wer schießt mehr Tore?  Diese Fragen sind noch einfach zu beantworten. In der Softwarearchitektur sind die Fragen natürlich ein wenig anders: Wie viele gefundene Fehler gibt es pro Paket? Wie hoch ist der Resscourcenverbrauch? Wie viel Zeit wird für die Verarbeitung bestimmter Funktionen oder Anwendungsfälle benötigt?

Doch nicht alle Fragen sind immer so leicht zu beantworten. Die Bewertung von Turniertänzern oder Eiskunstläufern ist schon etwas komplizierter und lässt sich nicht nach einfachen Zahlen bemessen, sondern funktioniert nach einem komplizierten Schema. Die Qualität entscheidet!

Wie ist das nun in der Softwarearchitektur? Gibt es hier sowas wie Messlatten und Schiedsrichter? Wie sieht hier das Ergebnis aus? Im Sport ist das klar: Der Gewinner bekommt die Goldmedaille.

  • Wie zuverlässig läuft das System?
  • Wie sicher ist das System?
  • Kann die Software ihr Leistungsniveau unter festgesetzten Bedingungen über einen bestimmten Zeitraum aufrechterhalten?
  • Wie sparsam ist die Software zur Lösung eines festgelegten Problems bezüglich der Ressourcen, Zeitverhalten bei Anfragen und Bearbeitungen sowie Speicherplatz?
  • Wie hoch ist der Aufwand zur Fehlerbeseitigung, zur Umsetzung von Verbesserungen oder zur Anpassung an Umgebungsveränderungen?
  • Ist die Software auch auf anderen Systemen (Hard- und Software) einsetzbar?

In der Softwarearchitektur gibt es verschiedene Methoden und Werkzeuge, die zu unterschiedlichen Zeitpunkten eingesetzt werden können. Bei der Bewertung einer Architektur gibt es jedoch zwei Ansätze: der qualitative Ansatz und der quantitative Ansatz.

Qualitativer Ansatz zur Architekturbewertung

Der qualitative Ansatz ist eine Bewertung nach Beschaffenheit oder Güte und hilft Risiken zu identifizieren. Hier wird direkt nach den Qualitätsmerkmalen beurteilt, die eine wichtige Rolle bei der Bewertung spielen. Sie werden auch Nicht-funktionale Anforderungen (NFA) genannt und lauten: Übertragbarkeit, Funktionalität, Wartbarkeit, Effizienz, Sicherheit, Kompatibilität, Zuverlässigkeit und Benutzbarkeit.

Die qualitative Bewertung sollte jedoch regelmäßig und so früh wie möglich stattfinden. Eine der führenden Methoden im Bereich der Softwarearchitekturbewertung ist ATAM. ATAM seht für Architecture Tradeoff Analysis Method und bezeichnet eine Szenario-basierte Methode zur Bestimmung der Stärken, Schwächen und den getroffenen Kompromissen einer Softwarearchitektur. Ein ATAM-Workshop dauert in der Regel 3 – 4 Tage und wird gemeinsam mit den Stakeholdern durchgeführt.

Quantitativer Ansatz zur Architekturbewertung

Der quantitative Ansatz ist eine Bewertung der Artefakte in Zahlen und kann helfen, kritische Teile innerhalb von Systemen zu identifizieren. Im Gegensatz zur qualitativen Bewertung liefert sie keine Aussage über die Funktionsfähigkeit der Software. Zur Bewertung wird eine Reihe von Messungen und Metriken verwendet, wie beispielsweise die Anzahl der geänderten Anforderungen pro Zeiteinheit, die Anzahl der Testfälle, die Anzahl der gefundenen Fehler pro Paket, die Anzahl der neuen Codezeilen oder die Zyklomatische Komplexität. Der Vorteil ist, dass die Messungen automatisierbar sind und leicht wiederholt werden können. Es besteht jedoch auch die Gefahr von Missdeutungen, da ein fachlicher und technischer Kontext benötigt wird, um vergleichbar zu sein. Gesammelte Daten aus Vergleichsprojekten können hierbei hilfreich sein.

Insgesamt gesehen ist die Architekturbewertung ein wichtiges Hilfsmittel zur Bestimmung der Qualität einer Software bei der es aber weniger darum geht die Architektur zu benoten, sondern eher mehr Durchblick zu bekommen.

Architekturbewertung nach ISAQB AWERT

Die iSAQB-zertifizierte Weiterbildung Architekturbewertung vermittelt den Schulungsteilnehmern das notwendige Wissen und die Fähigkeiten, um Softwarearchitekturen bewerten zu können. Ziel ist die Beantwortung der Frage: Wie findet man heraus, ob eine Architektur die Erwartungen erfüllt?

Weiterführende Links:

Training “iSAQB Architekturbewertung (AWERT)”

Girls’ Day

Girls’ Day

Unser erster Girls‘ Day ist nun vorbei, bei dem wir 9 Teilnehmerinnen einen spannenden Einblick in die Welt der Softwarearchitekten ermöglichen konnten. Zu Beginn stellten wir uns als Arbeitgeber vor. Danach wurden den Mädchen einige Grundlagen der Softwarearchitektur erläutert, die sie später in Gruppenarbeit in praktischen Programmierübungen auf der Website „Scratch“ ausprobieren konnten. Im Anschluss wurde das Erarbeitete dann in einer Präsentation vorgestellt. Darüber hinaus durfte natürlich auch ein Rundgang mit expliziter Einführung in unser Unternehmen nicht fehlen, bei der sich auch die Geschäftsführerin vorstellte und schildern durfte, wie sie es schaffte, sich in einem männerdominierten Berufsfeld durchsetzen zu können. Auch die von uns organisierten Snacks und „la Pizza“ als Mittagessen sind bei den Mädchen sehr gut angekommen:). Wir bedanken uns für den schönen und lehrreichen Tag und hoffen, viele junge Mädchen für den Beruf “Softwarearchitektin” begeistert zu haben.

Hier einige Feedbacks der Mädchen:

„Es hat sehr viel Spaß gemacht, den Girls’ Day in eurer Firma zu verbringen!”

„Mir hat es sehr viel Freude bereitet, den Tag als „kleine Programmiererin“ oder Softwarearchitektin zu gestalten. Alle ihre Mitarbeiter sind super freundlich und man hatte viel Spaß, hier zu sein.“

„Der Tag in eurer Firma war echt cool und gelassen. Das ganze Essen war auch lecker. Die Räumlichkeiten der Firma sind auch richtig modern gestaltet.“

„Ich danke ihnen für das Essen und Trinken und hoffe ihr macht weiterhin beim Girls’ Day mit.“

„Ich fand sehr gut, dass wir anfängergerecht ans Programmieren herangeführt wurden…“

„Nehmen Sie unbedingt noch an weiteren Girls’ Days teil, damit auch andere Mädchen die Gelegenheit haben in das Programmieren und in Ihre Firma Einblick zu erhalten“…

„Ich habe Interesse an dem Beruf gefunden. Die Führung durch die Räume war gut, weil die Räume wirklich schön gestaltet sind. Für das nächste Mal würde ich sagen, dass sie genauso weitermachen sollen.“

Night School – Weiterbildung von Kollegen für Kollegen

Night School – Weiterbildung von Kollegen für Kollegen

Alle zwei Wochen findet unsere interne Weiterbildungsmaßnahme „von den Kollegen für die Kollegen“ in unseren Räumlichkeiten in Nürnberg statt. Die Maßnahme, in welcher wir laufend unsere Mitarbeiter weiterbilden nennen wir „Night School“.

 

 

Die erste Nightschool 2019 lief unter dem Titel „Von der Anforderung zum UML-Modell“ und hatte dementsprechend das Thema Objektorientierung, UML und Anforderungsanalyse. 

 

Zunächst wurde beschrieben welche Eigenschaften objektorientierte Systeme ausmachen.
Danach wurde die Unified Modeling Language als grafische Beschreibungssprache zur Objektorientierten Analyse (OOA) eingeführt.
Die UML-Diagrammtypen Use-Case Diagramm, Aktivitätsdiagramm, Sequenzdiagramm, Klassendiagramm, State-Machine und Deployment-Diagramm wurden anhand von Beispielen vorgestellt.
Danach wurde eine Analysemethode vorgestellt anhand von Textanalyse Use-Cases, Aktivitätsdiagramme, State-Machines um schliesslich ein Klassendiagramm zu ermitteln.

Im Praxisteil analysierten die Teilnehmer in kleinen Teams zu 3-4 Personen wie man aus der textuellen Beschreibung des Spiels “Dame” mittels Textanalyse die UML-Diagramme ermittelt.

 

Die zweite Nightschool hatte das Thema Dokumentationsmöglichkeiten in agilen Projekten.  Zunächst wurde erläutert warum man dokumentieren soll und was die Vorteile einer guten und aktuellen Dokumentation sind. 

Dann wurde auf die verschiedenen Dokumentationstypen:  Projektdokumentation, Systemdokumentation und Prozessdokumentation eingegangen und warum es im agilen Umfeld nicht zwingend geboten ist Dokumentation einzusetzen.

Als Lösungsmöglichkeiten wurden Wiki als Master, der Docs-as-Code Ansatz und Lean Dokumentation vorgestellt. Im Praxisteil bekamen Zweierteams ein Use-Case zugeordnet, dessen Ablauf sie mit Hilfe von Klebebändern, großen Post-ITs und Malstiften an die Wand zu basteln und ihre Lösung mit den anderen Teams zu diskutieren.

Unter den Wolken – Infrastrukturen für die Cloud

Unter den Wolken – Infrastrukturen für die Cloud

Nichts hat die Art und Weise wie in der IT-Welt Software konzipiert und entwickelt wird in den letzten Jahren so sehr verändert wie Microservices. Auch hier in unserem Blog hatten wir das Thema Microservices bereits mehrfach aufgegriffen (z.B. hier: https://www.itech-progress.com/microservices-und-bounded-contexts-perfekte-ehe-oder-ungleiches-paar/ oder hier: https://www.itech-progress.com/ueberlegen-zerlegen-softwarearchitektur-mit-der-flex/). Heutige Anwendungen müssen in einem Cluster von mehreren Knoten funktionieren, dynamisch platzierbar, skalierbar und fehlertolerant sein.

Microservices wiederum bilden die Basis von Cloud native Applikationen. Die einzelnen Microservices sind voneinander unabhängig und können auf mehreren Servern an verschiedenen Standorten laufen. Cloud native Anwendungen nutzen diese lose gekoppelten Cloud Services. Bei Cloud native handelt es sich um einen Ansatz, der gewährleisten soll, dass Anwendungen für die Cloud-Computing-Architektur entworfen und entwickelt werden. Die Besonderheiten der Cloud-Computing-Architektur sollen zum Vorteil der Anwendungen genutzt und alle Möglichkeiten voll ausgeschöpft werden. Für diese Art von Anwendungen wird oft die Abkürzung NCA verwendet, das für Native Cloud Application steht.

NCAs haben zahlreiche Vorteile. Sie sind weder an eine spezielle Hardware noch an bestimmte Betriebssysteme gebunden, lassen sich leicht skalieren, sind einfach zu deployen, und sie sind georedundant. „Redundanz“ bedeutet, dass man mindestens eine zusätzliche Ressource als Backup für den Notfall hat. In der Kombination mit „Geo“ bedeutet es, dass diese Ressourcen zusätzlich räumlich voneinander getrennt sind. Nur so kann wirklich sichergestellt werden, dass auch bei schwerwiegenden technischen Problemen an dem einen Ort noch immer ein intaktes Backup an einem anderen Ort verfügbar ist. Laut Bundesamt für Sicherheit in der Informationstechnik (BSI) sollten es sogar mindestens 200 km sein, um auch vor Naturkatastrophen gut geschützt zu sein.

 

Seit Juli 2018 gibt es beim iSAQB ein neues Modul mit dem Namen CLOUDINFRA.

Das Modul beschäftigt sich mit den Themen Infrastruktur, Container und Cloud Native und mit der Frage: “Wie konzipiert und implementiert man anpassungsfähige Infrastrukturen für die Cloud?”.

Im Modul CLOUDINFRA geht es jedoch nicht nur um die Gründe für den Betrieb und die Vor- und Nachteile einer Cloud. Die Teilnehmer lernen die Grundlagen moderner Infrastrukturen, wie z.B. die unterschiedlichen *aaS Begriffe, Microservice-Architekturen, Container und verteilte Anwendungen.

Über die gängigsten Architekturkonzepte, hier im speziellen Microservices und Self-contained Systems geht es zu einer Reise in die Tiefen des Cloud-Native-Konzepts. Den Abschluss bilden hilfreiche Patterns und alles Wichtige über Development, CI/CD (Continuous Integration und Continuous Delivery) und Betrieb.

Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Weiterführende Links:

Training “iSAQB Infrastruktur, Container und Cloud Native (CLOUDINFRA)”

Microservices und Bounded Contexts: Perfekte Ehe oder ungleiches Paar?

Microservices und Bounded Contexts: Perfekte Ehe oder ungleiches Paar?

Microservices und Domain Driven Design (DDD) zählen nach wie vor zu den Hype-Themen der IT-Szene. Ein paar Sekunden Google-Suche reichen aus, um gleich dutzende Artikel ausfindig zu machen, die wahre Loblieder auf die „Liebesbeziehung“ von Microservices und Bounded Contexts singen. Aber ist das wirklich so? Bilden Microservices und Bounded Contexts die perfekte Ehe oder wird das Thema vielleicht doch zu sehr durch die rosa Brille findiger Consultants betrachtet?

Domain Driven Design ist als ein Konzept entstanden, um die Distanz zwischen den Domänen-Experten und dem Software-Entwicklungsteam und die daraus resultierenden Projektrisiken nachhaltig zu verringern. Eric Evans hat das in seinem Standardwerk „Domain-Driven Design: Tackling Complexity in the Heart of Software“ präzise beschrieben. Ein zentrales Element ist dabei eine gemeinsame Fachsprache, die „Ubiquitous Language“, die aus der Domänen-Story entwickelt und auf allen Ebenen, vom Grobkonzept bis in den Quellcode hinein, angewendet wird. In den meisten Fällen zeigen sich bei der Herleitung der Domain-Story einige Begriffe, die in unterschiedlichen Zusammenhängen (z.B. Abteilungen) andere Bedeutungen haben. Im Domain Driven Design wird in diesem Fall keine sprachliche Lösung geschaffen, sondern eine Grenze um den maximalen Raum innerhalb der Domäne gezogen, in dem jeder Fachbegriff eine einzige, eindeutige Bedeutung hat. Dieser abgegrenzte „Sprachraum“ ist der Bounded Context.

Aus dieser Perspektive wird klar, dass ein Bounded Context – je nach Komplexität der Domäne – ganz unterschiedliche Dimensionen annehmen kann. Die Spanne erstreckt sich von einem sehr kleinen Kontext, der sich durchaus zur Abgrenzung eines Microservice eignen kann, bis hin zu einem gewaltigen, als Microservice untauglichen Kontext-Monolithen. In den meisten Fällen sind Microservice und Bounded Context folglich ein ausgesprochen ungleiches Paar. Der Bounded Context beschreibt die maximale Ausdehnung, die ein Microservice logisch annehmen kann und steht damit geradezu im Widerspruch zu dessen Anforderungen an reduzierte Komplexität und Größe.

Woher rührt dann also der Hype? Nun, zum einen sind Bounded Contexts eine Möglichkeit, erste Schnitte im Projekt anzusetzen und bieten damit zumindest eine Annäherung. Zum anderen ist jeder Bounded Context ein Cluster, in dem mehrere zu definierende (Micro-)Services durch die Ubiquitous Language logisch verbunden sind. Auch das kann bis hin zur Evolution der Microservice-Landschaft eine Menge Vorteile bringen.

Für die Microservices selbst und deren Abgrenzung stellt Domain Driven Design das Konzept der internen Bausteine (Internal Building Blocks) mit vielen nützlichen Patterns zur Verfügung. Das vielleicht wichtigste dabei sind die Aggregates, die als kleinste sinnvolle Einheit für einen Microservice sozusagen den Gegenpol zu den Bounded Contexts bilden.

Anhand dieser Betrachtungen lassen sich die Ausgangsfragen klar beantworten: „Die perfekte Ehe“ lässt sich auf der Ebene von Microservices und Domain Driven Design schließen. Bounded Contexts sind für diesen Bund ein wertvoller Beitrag – unter vielen anderen.

Einen tieferen Einblick in Microservice-Architekturen und Domain Driven Design vermittelt das Trainings-Doppelpack „Flexible Architekturmodelle (FLEX)“ und „Domain Driven Design (DDD)“ der ITech Academy.

Weiterführende Links:
Training „iSAQB Domain Driven Design (DDD)“
Training „iSAQB Flexible Architekturmodelle (FLEX)“

 


Bildrechte (Montage):
Halfaral [CC BY-SA 3.0], von Wikimedia Commons