ITech Academy stellt 10 neue Trainings vor!

ITech Academy stellt 10 neue Trainings vor!

Neue Trainings in den Bereichen: Softwaremodellierung, Softwareentwicklung und Softwarearchitektur

Wenn Sie unsere ITech Academy bereits kennen, wissen sie bestimmt, dass Softwarearchitektur ein untrennbarer Teil unserer DNA und vor allem unsere Leidenschaft ist! Das spiegelt sich auch in unserem großen Angebot an iSAQB-akkreditierten Softwarearchitektur Trainings wider. Von den Grundlagen bis hin zu fortgeschrittenen Trainings sind alle relevanten und aktuellen Themen aus der Welt der Softwarearchitektur vertreten. Als IT-Beratungsunternehmen beraten wir unsere Kunden neben innovativen Architekturparadigmen wie Microservices und Cloud Architekturen seit über 17 Jahren auch in allen Phasen ihrer IT-Projekte, von der Konzeption über den Entwurf und die Implementierung bis hin zu Testing, Fertigstellung und Qualitätssicherung.

Wir als ITech Progress haben uns mit der ITech Academy einen Ort geschaffen, um genau diese langjährige Erfahrung in den Bereichen Softwaremodellierung, Softwareentwicklung und Softwarearchitektur in Form von theoretischem und praktischem Wissen weiterzugeben. Denn einer unserer Grundsätze lautet: Wissensmonopole sind für uns tabu!

Aus diesem Grund haben wir 10 neue Trainings und Workshops nach eigenem Lehrplan entwickelt, die jetzt ein Teil unseres Academy-Portfolios sind! In allen Trainings und Workshops steckt das Beste aus unserer Arbeit und Erfahrung mit komplexen Systemen, bewährten Tools, Technologien, Architekturen und den Best Practices der Softwareentwicklung und -architektur. Und all das: Immer auf dem neuesten Stand!

Das sind die neuen Trainings und Workshops:

Softwaremodellierung

Objektorientierter Softwareentwurf mit UML und Objektorientierung

Dieses 3-tägige Grund- und Aufbautraining richtet sich an alle Softwareentwickler:innen und –architekt:innen im objektorientierten Umfeld, die UML als effektives Entwurfs-, Planungs- und Kontrollinstrument einsetzen möchten.

Softwareentwicklung

SQL & DB Design (5 Tage inkl. Workshopzeit)

Java und OOP (5 Tage inkl. Workshopzeit)

html und CSS (3 Tage inkl. Workshopzeit)

JEE (3 Tage inkl. Workshopzeit)

Programmieren für Fortgeschrittene mit JAVA

Diese Trainings eignen sich ideal zur Mitarbeiterbefähigung, wenn in Ihrem Unternehmen beispielsweise noch Legacy-Systeme genutzt werden und der Umstieg auf zeitgemäße Technologien und Architekturen erfolgen soll.

Softwarearchitektur

Methodischer Fokus:

Enterprise Application Integration Patterns

In diesem 2-tägigen Training für Softwareentwickler:innen und -architekt:innen lernen sie Enterprise Application Integration (EAI) Patterns kennen, um Geschäftsfunktionen entlang der Wertschöpfungskette eines Unternehmens, die über diverse Applikationen auf verschiedenen Plattformen verteilt sind, zu integrieren.

Design Patterns

In diesem 2-tägigen Training für Softwareentwickler:innen und -architekt:innen lernen sie das Konzept und den Sinn von Entwurfsmusstern kennen.  Wir geben Ihnen aus unserer jahrelangen Projekterfahrung eine Auswahl wichtiger Entwurfsmuster an die Hand und führen sie mithilfe verschiedener Methoden in die praktische Anwendung.

Technologischer Fokus:

Clean Code

In diesem Training lernen Sie die Werte, Regeln und Prinzipien kennen, auf denen die Handwerkskunst der Softwareentwicklung fußt und können damit dem Sprichwort „Wie der Meister, so das Werk“ folgend, sauberen, änderbaren, testbaren und objektorientierten Code entwickeln.

Kommunikativer Fokus:

Führungskräfteentwicklung

In diesem 2-tägigen branchenübergreifenden Training geben wir Führungskräften das Know How für situationsgerechte Kommunikation, Reflexion und Verantwortungsdelegation als aktive Bestandteile einer effektiven und erfolgreichen täglichen Arbeit mit. Teilnehmer:innen erlernen, die eigenen Rollen und Ziele zu definieren und darauf aufbauend Ihr Verhalten auszurichten.

So nehmen Sie an unseren neuen Trainings und Workshops teil

Vorläufig ist das neue Portfolio nur in Form von Inhouse-Trainings (auch remote) buchbar, aber wir freuen uns auf Ihre direkte Rückmeldung, wenn Interesse an offenen Terminen besteht! Kommen Sie hierfür gerne über die unten angegebenen Kontaktmöglichkeiten auf uns zu oder melden Sie sich für unseren monatlichen Newsletter an, um keine Termine und Neuigkeiten zu verpassen. Aus unserer Erfahrung heraus wissen wir, dass eine Lernatmosphäre außerhalb des eigenen Standortes eine echte Bereicherung für das Team sein kann, weshalb wir Ihnen an unseren Standorten in Ludwigshafen und Nürnberg gerne auch großflächige, modern ausgestattete Schulungsräume zur Verfügung stellen.

Sie haben Interesse an den neuen Trainings oder eine Frage?

Dann rufen Sie uns bitte unter +49 621 595702 41 an, schreiben Sie eine E-Mail an training@itech-progress.com oder schicken Sie uns über das Kontaktformular eine schriftliche Anfrage:

5 + 6 =

Alles soll fließen: Die Prozesse, die Daten, die Services

Alles soll fließen: Die Prozesse, die Daten, die Services

Feix

Axel Feix

Axel Feix hat langjährige Projekterfahrung als Analyst und Softwarearchitekt. Er unterstützt Kunden als Senior Consultant und Trainer bei der Einführung und Umsetzung von Software-Engineering, Requirements-Engineering, Softwarearchitektur-Management und Architekturdokumentation. Er interessiert sich für was fliegt, alles was man visualisieren und spielen kann, und was die Welt zusammenhält.

Eine Zeitreise nach Paris vor 180 Jahren

Stellen Sie sich vor: Sie leben im Jahre 1853 in Paris und sind der frischgebackene Präfekt der Metropole. Die Stadt hat sich seit der Revolution kaum verändert und ist im Kern noch mittelalterlich geprägt mit feinen Stadthäusern, aber auch vielen engen Gassen in denen die armen Bürger:innen von Paris leben. Ihr König Napoleon III. ist aus seinem Londoner Exil zurückgekehrt und begeistert von der modernen Stadt, den Parks, den Boulevards und den prächtigen Bahnhöfen. Er gibt Ihnen den Auftrag: Baron Haussmann – machen Sie Paris zu einer modernen Stadt.

Sie sind dieser Baron Haussmann und lieben gerade Linien, Ordnung, Hygiene und Autorität. Sie bauen ein interdisziplinäres Team auf und beginnen damit, die Stadt tiefgreifend umzubauen. Ihr Motto ist: Mehr Raum, mehr Einheitlichkeit und mehr Schönheit. Sie schaffen Boulevards, die so breit sind, dass keine Barrikaden mehr aufgebaut werden können und dass jeder Ort von der nächsten Feuerwache innerhalb kürzester Zeit erreichbar ist. Sie kreieren durch Ihre geradlinige Straßenführung Blickachsen an deren Ende, sodass Sehenswürdigkeiten wie Bahnhöfe, Kirchen, Stadttore, Reiterstatuen oder Brunnen zu sehen sind. Die Kanalisation folgt den Straßen und das Stadtmobiliar bestehend aus Bänken, Straßenlaternen, Kiosken und Werbesäulen wird vereinheitlicht. 

Haussmann BNF Gallica

Georges-Eugène Haussmann, Städteplaner

Auch die Häuser werden nach dem immer gleichen Schema mit sechs Stockwerken aufgebaut: im Erdgeschoss sind in der Regel Läden und im 1. Stock, einer Art Zwischengeschoss, leben die Unternehmer:innen oder nutzen den Raum zur Lagerung. Im 2. Stock, der Étage noble, gibt es großzügige Balkone für die wohlhabenden Bürger:innen. In den Stockwerken drei und vier wohnt der Mittelstand. Je nach Architektur des Gebäudes gibt es in diesen Stockwerken kleine Balkone oder sie fehlen ganz. Der 5. Stock ist wie eine Loge mit durchgehendem, aber weniger edlem Balkon und direkt unter dem Dach befinden sich Wohnungen für die Dienstboten.

Straßen in Paris

Geradlinige Straßenführung, die einen Blick auf den Eiffelturm ermöglicht

Üblicher Aufbau der Häuser in Paris

In Rekordzeit haben Sie Paris grundlegend verändert: Sie ziehen 70 Schneisen durch die Stadt, bauen neun Brücken, errichten 40.000 Wohnhäuser, legen 585 km Kanalisation, bauen 20 Grünanlagen, zwei große Stadtparks und zwei Stadtwälder auf. 80.000 neugepflanzte Bäume tragen außerdem zu einer verbesserten Atmosphäre bei. Noch heute sind mehr als die Hälfte der Pariser Häuser nach Ihrem Stil kreiert.

Diese Reise in die Vergangenheit soll Ihnen bildlich nahelegen, dass es eine gewaltige Aufgabe ist, städteplanerisch unterwegs zu sein und dass Ihre Entscheidungen das Gesamtsystem, egal ob es sich dabei um eine Stadt oder eine Unternehmensarchitektur handelt, tiefgreifend beeinflussen. All das lässt sich auf die IT übertragen: Dort heißt das entsprechende stadtplanerische Mittel Enterprise Architecture Management (EAM). Das Enterprise Architecture Management gibt den Enterprise-Architekt:innen Hilfsmittel zur Hand, um dieser gewaltigen Aufgabe gewachsen zu sein.

Einflussmöglichkeiten der IT-Strategie auf die Enterprise Architektur

Was ist eigentlich eine Unternehmensarchitektur?

Eine Unternehmensarchitektur vereint die gemeinsame Betrachtung der IT-Architektur und der Business-Architektur. Enterprise-Architekt:innen sind für die Entwicklung und Pflege der Enterprise-Architektur eines Unternehmens verantwortlich. Enterprise-Architekt:innen pflegen einen Unternehmens-Stack, der aus mehreren Schichten besteht. In der untersten Schicht befindet sich die IT mit all ihrer Hardware-Infrastruktur, den Servern und Netzen, in denen die Legacy-Hardware betrieben wird. Also kurz: Alles, was sich anfassen lässt. In der zweiten Ebene befindet sich die Software mit ihren Applikationen und der im Unternehmen betriebenen Middleware. In der dritten Schicht folgt die Welt der Daten und Geschäftsfunktionen und in der vierten Schicht liegen die Geschäftsprozesse, die das eigentliche Business eines Unternehmens ausmachen. Auf den Geschäftsprozessen werden schließlich die Produkte des Unternehmens realisiert.

Business, Daten, Anwendungen und Technologien bilden die vier Schichten der Enterprise Architektur

Der Umbau einer Enterprise-Architektur ist eine Herausforderung

So wie Paris als moderne Großstadt muss sich auch der Unternehmens-Stack weiterentwickeln. Ein solcher Umbau ist eine echte Herausforderung. Oftmals wird zunächst versucht, eine der Schichten zu transformieren. Beispielsweise durch Konsolidierung der Hardware-Landschaft soll die gewachsene IT-Architektur modernisiert werden. Doch diese ist meist sehr eng mit der Applikationsschicht verkoppelt, sodass ein einfacher Austausch schwierig ist. Mutige Unternehmen erstellen ganz neue Geschäftsprozesse und nehmen es in Kauf, dass dabei ältere Produkte nicht mehr bedient werden können.

Der Enterprise-Architekt als Transformator

Jetzt kommen die Enterprise-Architekt:innen ins Spiel. Diese verstehen jede Ebene des Unternehmens-Stacks und schaffen es mit Hilfsmitteln aus dem Enterprise Architecture Management eine ganzheitliche Unternehmenstransformation durchzuführen. Zu solchen Hilfsmitteln gehören Enterprise Architecture Frameworks (EAF) wie z. B. das Zachman Framework oder das Open Group Architecture Framework (TOGAF). Das Ergebnis sind aufgeräumte Geschäftsprozesse mit passenden Daten, weniger Applikationen und eine moderne zukunftsfähige IT-Infrastruktur. Das Wissen für eine komplexe Aufgabe wie das Enterprise Architecture Management (EAM) zu erlangen, ist zeitaufwendig.

Training zu ‘Enterprise Architecture Management (EAM)‘

Unser 3-tägiges Training ‘Enterprise Architecture Management (EAM)‘ vermittelt das notwendige Wissen und die Fähigkeiten, um EAM für mittlere und große Systeme ein- und durchzuführen. Am Ende dieser Schulung haben Sie das Rüstzeug, um eine IT-Strategie für eine Unternehmensarchitektur zu formulieren, Prozesse und Strukturen der IT-Governance einzurichten, zu überwachen und Migrationspläne für die IT-Landschaft abzuleiten. Im Lauf der Weiterbildung lernen die Teilnehmer:innen verschiedene Frameworks wie TOGAF und COBIT kennen. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture – Advanced Level (CPSA-A) nach dem iSAQB-Programm anstreben, erhalten Sie für dieses Training 30 Credit Points im Kompetenzbereich Methodik.

Termine zum Training 'Enterprise Architecture Management (EAM)'

12. – 14. Juli 2021 | Live Online-Training

22. – 24. November 2021 | Live Online-Training

Bounded Context trifft auf Microservice: Wie passt der Deckel auf den Topf?

Bounded Context trifft auf Microservice: Wie passt der Deckel auf den Topf?

Feix

Axel Feix

Axel Feix hat langjährige Projekterfahrung als Analyst und Softwarearchitekt. Er unterstützt Kunden als Senior Consultant und Trainer bei der Einführung und Umsetzung von Software-Engineering, Requirements-Engineering, Softwarearchitektur-Management und Architekturdokumentation. Er interessiert sich für was fliegt, alles was man visualisieren und spielen kann, und was die Welt zusammenhält.

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? Passen Microservices und Bounded Contexts wie Topf und Deckel zusammen oder wird das Thema vielleicht doch zu sehr durch die rosa Brille findiger Consultants betrachtet?

Bounded Context und Ubiquitous Language

Domain Driven Design (DDD) 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 als Vokabular angewendet wird. In den meisten Fällen zeigen sich bei der Herleitung der Domain-Story einige Begriffe, die in unterschiedlichen Zusammenhängen (z. B. Fach-Abteilungen) andere Bedeutungen haben. Im Domain Driven Design (DDD) 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 eindeutige Bedeutung hat. Dieser abgegrenzte „Sprachraum“ ist der Bounded Context.

Ein Bounded Context ist kein Microservice

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. Es ist aber deutlich zu sagen: Ein Bounded Context ist kein Microservice. Ein Microservice ist technisch und stelle eine Deployment Grenze dar. Ein Bounded Context ist dagegen eine fachliche Sprachgrenze mit einer klaren Definition für jeden Begriff. Die Größe und Form eines solchen Contexts wird durch die strategische Planung, die Komplexität des Modells und die Teamstruktur bestimmt.

Bounded Contexts sind 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.

Das richtige Werkzeug für den Einsatz von DDD und Microservices

Die DDD bietet einen ganzen Baukasten an Werkzeugen an, um strategisches und taktisches Domain Driven Design zu betrieben. Beim strategischen DDD sind das z. B. Dave Snowdens  Komplexitätsanalyse nach Cynefin, Domänenmodelllierung mit Aberto Brandolinis Event Storming, Exploration mit Hilfe von Simon Wardleys Wardley Mapping, Strategische Entkopplung durch Eric Evans Bounded Context Mapping oder System Thinking nach Donella Meadows. Diese Werkzeuge zu kennen und erfolgreich einzusetzen ist essenziell für den erfolgreichen Einsatz DDD und Microservices.

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.

Fazit

Anhand dieser Betrachtungen lässt sich klar sagen: Auf der Ebene von Microservices und Domain Driven Design passt der Deckel ganz klar auf den Topf! Bounded Contexts sind für diesen Bund ein wertvoller Beitrag – unter vielen anderen.

Sie möchten mehr zu dem Thema erfahren?

Einen tieferen Einblick in Microservice-Architekturen und Domain Driven Design vermitteln die beiden Trainings „Flexible Architekturmodelle (FLEX)“ und „Domain Driven Design (DDD)“. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced Level (CPSA-A ®) anstreben, erhalten Sie mit diesem perfekten Trainings-Doppelpack Credit Points in den Kompetenzbereichen Technik, Methodik und Kommunikation.

Die Ubiquitous Language der Softwareentwicklung

Die Ubiquitous Language der Softwareentwicklung

Erste Versionen des Cartoons stammen aus den 1960ern. (Illustrator unbekannt)

Feix

Axel Feix

Axel Feix hat langjährige Projekterfahrung als Analyst und Softwarearchitekt. Er unterstützt Kunden als Senior Consultant und Trainer bei der Einführung und Umsetzung von Software-Engineering, Requirements-Engineering, Softwarearchitektur-Management und Architekturdokumentation. Er interessiert sich für was fliegt, alles was man visualisieren und spielen kann, und was die Welt zusammenhält.

Vor vielen Tausend Jahren bestrafte Gott die Menschen in der Stadt Babylon dafür, dass sie sich erdreisteten, einen Turm bis in den Himmel zu bauen. Er sorgte dafür, dass die Menschen sich untereinander nicht mehr verstanden und so musste das Turmbauprojekt eingestellt werden. Seitdem spricht man von der babylonischen Sprachenverwirrung.

Der Turmbau zu Babel als Auslöser der babylonischen Sprachverwirrung

„Ein Redner kann sehr gut informiert sein, aber wenn er sich nicht genau überlegt hat, was er heute diesem Publikum mitteilen will, dann sollte er darauf verzichten, die wertvolle Zeit anderer Leute in Anspruch zu nehmen.“

(Lee Iacocca *1924).

Wenn im IT-Team aneinander vorbeigeredet wird

IT-Teams sind schon ein Volk für sich, und das ist durchaus positiv gemeint. Die ITler bilden oft einen „fachlichen Mikrokosmos“ in einem Unternehmen und bleiben gerne unter sich. Das heißt aber noch lange nicht, dass Entwickler:innen, Softwarearchitekt:innen, Tester:innen, Projektmanager:innen, Scrum Master und Deployment Manager (alle Geschlechter) auch nur ansatzweise eine gemeinsame Sprache sprechen – von Abteilungsleitung, Fachabteilungen und Management einmal ganz abgesehen. Unterschiedliche Ausbildungswege und fachliche Schwerpunkte, aber auch individuelle Unternehmens- und Projekterfahrungen führen in der Regel dazu, dass Fachtermini und Domänenbezeichner nicht durchgängig bekannt sind oder von Mitarbeiter:in zu Mitarbeiter:in anders verstanden werden. Die resultierenden Missverständnisse können gravierende Auswirkungen auf Effizienz und Projekterfolg haben und im Zweifel eine Menge Geld kosten. Was dabei herauskommen kann, sieht man in dem obigen Bild. Aber was tun?

Und die Lösung heißt: Domain-Driven Design (DDD)

Seit Anfang der 2000er-Jahre gibt es mit dem Domain-Driven Design (DDD) eine ganzheitliche Vorgehensweise zur Modellierung komplexer Software. Im DDD geht man dabei von zwei Grundgedanken aus:

  1. Fachlichkeit und Fachlogik sollten den Schwerpunkt im Softwaredesign bilden
  2. Ein Modell der Anwendungsdomäne sollte die Grundlage für den Entwurf komplexer Fachlichkeit bilden

Im Domain-driven Design (DDD) führt die Fachlichkeit und nicht die Technik

Die Anwendungsdomäne soll also die Grundlage für den Softwareentwurf bilden. Um diese adäquat zu beschreiben, sollte eine Ubiquitous Language in allen Stufen der Softwareerstellung, d. h. von der Modellierung über die Implementierung bis zum Softwaretest verwendet werden. Objekte und Beziehungen aus den Objekten und Beziehungen im Domänenmodell finden sich also im Sourcecode und Testcode wieder und alle Projektbeteiligten sprechen innerhalb des Projekts dieselbe (Fach-) Sprache. Diese Sprache wird aber nicht einmalig im Domänenmodell entwickelt und dann überall verwendet. Sie wird evolutionär weiterentwickelt und bei Änderungen in der Implementierung hat dies gegebenenfalls auch Auswirkungen auf das Domänenmodell (und alle anderen Artefakte). Damit ist jeder Stakeholder in der Lage, sich in allen Projektartefakten (Modell, Implementierung, Tests, Datenbank etc.) zurechtzufinden und sich an Diskussionen zu beteiligen.

Wenn Sie mehr zu Domain-driven Design (DDD) lernen möchten

Einige Vorzüge einer gemeinsamen Sprache zur Beschreibung des Problemraums und der Anwendungsdomäne haben Sie jetzt kennengelernt. Wenn Ihnen als Softwarearchitekt:in nun noch das nötige Rüstzeug fehlt, um DDD im Umgang mit Stakeholdern und dem Entwicklungsteam einzuführen, empfehlen wir Ihnen unser 3-tägiges Softwarearchitektur-Training ‚Domain Driven Design (DDD)‘. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced Level (CPSA-A ®) anstreben, erhalten Sie mit diesem DDD Training 20 Credit Points im Kompetenzbereich Methodik und 10 Credit Points im Kompetenzbereich Kommunikation.

Was ist Ihre Meinung?

Schon Wilhelm von Humboldt wusste: Die gemeinsame Sprache ist der Schlüssel zur Welt. Wie gehen Sie in Ihren Projekten mit den Fachsprachen der jeweiligen Experten um? Schreiben Sie es uns in die Kommentare. Wir freuen uns auf den Austausch!

Architekturdokumentation – Schluss mit „Das war schon immer so“

Architekturdokumentation – Schluss mit „Das war schon immer so“

Das Dokumentieren einer Softwarearchitektur ist für den Projekterfolg unabdinglich. Entwürfe, Entscheidungen und Lösungen müssen nachvollziehbar und wirkungsvoll festgehalten werden. Hierzu gehört idealerweise auch die Beschreibung der verworfenen Alternativen. Denn es stellt sich die Frage, wer nach einem Monat oder auch länger noch alle Gründe weiß, weshalb man sich nun für die eine oder andere Variante entschieden hat. Oder eben auch gegen die eine oder anderen Variante.

Typische Fragen in Softwareprojekten sind beispielsweise:

„Wie sieht das Schichtenmodell aus?”

„Welche Design Patterns wurden verwendet?”

„Welche externen Webservices werden verwendet?”

„Wieso habt Ihr das so gemacht? Ist das nicht zu kompliziert?”

 

Und wenn die Antworten dann lauten:

„Das war schon so, als ich ins Projekt kam.”

„Es wurde in einem Meeting entschieden.”

„Es gibt keine Dokumentation, weil wir agil vorgehen.”

…dann entfachen immer wieder die gleichen Diskussionen. Durch die Entwürfe, die Diagramme und die Konzepte der Architekturdokumentation sollen allen Projektbeteiligten bessere Antworten auf diese Fragen in Softwareprojekten parat stehen. Eine ausführliche Architekturdokumentation kann also sehr klärend wirken, die Kommunikation unterstützen und Konflikte vorbeugen. Der Softwarearchitekt hat folglich die Aufgabe, eine angemessene Lösung zu entwerfen, um eine Nachvollziehbarkeit und gleichzeitig Lerneffekte zu gewährleisten.

Für alle Arten von Architekturdokumentation gelten daher einige übergreifende Anforderungen und Regeln, die Sie bei der Erstellung solcher Dokumente berücksichtigen sollten. Softwarearchitekten benötigen dabei ein grundlegendes Verständnis der Beschreibung von Softwarearchitekturen. Lernen Sie effektiv und praxisorientiert Softwarearchitekturen zu dokumentieren und zielgruppengerecht zu kommunizieren. Erfahren Sie, wie die Architekturdokumentation zu einem integralen Kommunikations- und Arbeitsmittel wird. Lernen Sie architekturrelevante Einflussfaktoren und zentrale Entscheidungen festzuhalten.

Unser 2-tägiges Softwarearchitektur-Training ‚Architekturdokumentation (ADOC)‘ vermittelt neben fachlichen Aspekten auch die wichtigen organisatorischen und sozialen Faktoren der Architekturdokumentation. Neben den Grundbegriffen der Architekturdokumentation bekommen Sie das Wissen rund um die Bestandteile, Vorgehensmodelle, Werkzeuge, Vorgaben und Bewertung an die Hand.

Am Ende dieses Softwarearchitektur-Trainings haben Sie das Rüstzeug, um die Architekturdokumentation eines mittleren oder großen Systems zu erstellen, zu bewerten und das Vorgehen zur Dokumentation eines solchen Systems zu definieren. Das Softwarearchitektur-Training ‚Architekturdokumentation (ADOC)‘ deckt einen Bereich der methodischen Kompetenzen des CPSA Advanced Levels (CPSA-A) ab und ist entsprechend beim iSAQB lizenziert. Wenn Sie die CPSA-A Zertifizierung anstreben, können Sie sich mit der Teilnahme 20 Credit Points anrechnen lassen.

Hier kommen Sie zu weiteren Informationen und zur Anmeldung.

Bei Fragen beraten wir Sie gerne unter training@itech-progress.com oder +49 621 595702 41

OOP digital 2021 – wir sind dabei!

OOP digital 2021 – wir sind dabei!

 Full Day Tutorial mit Mahbouba Gharbi und Tom Asel
 
 Digitaler Austausch mit unserem Team via 1:1 Chat über Softwarearchitektur, Trainings, Consulting, Projektunterstützung und Karrieremöglichkeiten 
 
 Verlosung eines iSAQB CPSA Trainings Ihrer Wahl über unsere Präsenz im Event Hub
 
 100€ Rabattcode für alle Trainings über unsere Präsenz im Event Hub

Unter dem Motto “Back to the Future” findet die diesjährige OOP rein digital statt und wir sind wie immer mit dabei! Wir freuen uns bereits aus dem Home Office heraus mit Ihnen in den Austausch zu kommen. Sie finden unsere Teammitglieder über den 1:1 Chat oder Sie besuchen ITech Progress und die ITech Academy direkt im Event Hub.

Full Day Tutorial: 
Wardley Maps als Werkzeug in der Architekturanalyse –
Eine Group Mapping Session für Architekten und Entscheider
 
Datum und Uhrzeit:
Mo, 08.02.2021 von 10:00 – 17:00 Uhr
 
Mit:
Mahbouba Gharbi und Tom Asel
 
Publikum:
Maximal 30 Teilnehmer*innen
l
Abstract:

Der Workshop richtet sich sowohl an interessierte Einsteiger:innen als auch an bereits erfahrene Mapper. Im Plenum werden Wardley Maps als Werkzeug in der Toolbox der Software-Entwickler:innen diskutiert und im Rahmen einer ausgiebigen Group-Mapping-Session in der Praxis erprobt. Am praktischen Beispiel der Digitalisierung eines Möbelhauses wird gezeigt, wie Maps dabei helfen, Lagebewusstsein zu schaffen, Risiken zu erkennen und eine Strategie zu entwickeln.

Wir untersuchen die Systemlandschaft, führen eine Architekturanalyse durch und verorten die Ergebnisse wieder auf unserer Landkarte.

Der Workshop zeigt, warum Trägheit ein Unternehmen scheitern lassen kann, wie Softwarearchitektur und Unternehmens-Strategie zusammenhängen und wie Wardley Maps dabei helfen, beides zu kommunizieren.

.