Native Cloud Application (NCA) – Entwicklung unter den Wolken

Native Cloud Application (NCA) – Entwicklung unter den Wolken

Waldemar Artes

Waldemar Artes hat langjährige Erfahrung als Anwendungsentwickler. Er unterstützt Kunden als Senior-Entwickler bei der Umsetzung und Instandhaltung von Fachanwendungen. Er interessiert sich für technischen Fortschritt und alles, was uns weiterbringt.

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. 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, welche für Native Cloud Application steht.

Eine Native Cloud Application ist ein echtes Multitalent

Native Cloud Applications 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“ heißt, dass mindestens eine zusätzliche Ressource als Back-up für den Notfall vorhanden ist. 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 Back-up 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.

Die vier zentralen Bestandteile der Entwicklung einer Native Cloud Application: DevOps, Continuous Delivery, Microservices und Container

Vier zentrale Bestandteile für die Entwicklung einer Native Cloud Application

 

  • DevOps ist die Zusammenarbeit zwischen Entwicklung und Betrieb mit dem Ziel, den Auslieferungsprozess zu automatisieren.
  • Continuous Delivery erlaubt die schnellere und zuverlässigere Auslieferung von Software mit weniger Risiken
  • Microservices ist ein Architekturansatz, in dem eine Anwendung als Verbund von mehreren kleinen Services gebaut wird.
  • Container bieten leichtgewichtige Virtualisierung. Sie sind schneller und effizienter als normale Virtualisierung. Container können miteinander verknüpft und gemeinsam orchestriert werden.

Diese vier Prinzipien erlauben es gemeinsam, schnell und risikoarm eine verteile Anwendung zu entwickeln, auf verteilter Infrastruktur auszuliefern und zu betreiben. Als Infrastruktur kann zum Beispiel Amazon Web Services oder Microsoft Azure genutzt werden.

Herausforderungen bei der Entwicklung und dem Betrieb von NCAs

Die Entwicklung einer Native Cloud Application bringt neue Herausforderungen mit sich, die ein Umdenken in der Entwicklung erfordern.

 

  • Persistente Datenablage: Container lassen sich nur kaum zur Datenhaltung nutzen, da diese sehr flüchtig sind. Wird ein Container gelöscht oder abgebaut, sind die Daten auch weg. Persistente Daten sollten deshalb außerhalb der Microservices gehalten werden. Auf diese Daten kann dann mittels einer Service-Schnittstelle zugegriffen werden.
  • Integration der Services: Verteilte Anwendungen bringen eine eigene Komplexität mit sich. So müssen die einzelnen Microservices über Server oder sogar Cloud-Provider hinweg miteinander integriert werden. Sie müssen sich gegenseitig finden und die Kommunikation soll fehlertolerant verlaufen.
  • Monitoring: NCAs können aus mehreren hundert bis tausend einzelnen Microservices bestehen. Umso wichtiger ist es, alle im Blick zu behalten. So müssen Werte wie Auslastung und Antwortzeiten beobachtet werden, um die Stabilität des gesamten Produktes zu gewährleisten.
  • Cloud Lock-in vermeiden: Durch die Einfachheit in ihrer Bedienung passiert es schnell, dass man sich von einem einzigen Cloud-Provider abhängig macht. Dessen sollte man sich bei der Planung bereits bewusst sein und so viele Industrie-Standards wie möglich anstelle von proprietären Lösungen nutzen.
  • Bauen von Pipelines zum Ausliefern der NCAs: NCAs arbeiten typischerweise in der Cloud. Möglicherweise sogar bei mehreren Cloud-Providern. Das erschwert das Ausliefern von NCAs, da diese stark verteilt sind und miteinander integriert werden müssen. Zudem können unterschiedliche Microservices unterschiedliche Abhängigkeiten fordern. Es werden Pipelines benötigt, die die einzelnen Microservices dorthin und in der benötigten Redundanz deployen, wo sie gebraucht werden.

Vorteile einer Native Cloud Application

Mit all den Herausforderungen, um eine Native Cloud Application zu entwickeln und zu Betreiben stellt sich immer die Frage: Ist es den Aufwand wert? Was sind die Vorteile?

 

  • Kosten: Wird die Anwendung auf einem Cloud-Anbieter betrieben, zahlt man nur das, was verbraucht. So können die Kosten für den Betrieb in nicht-aktiven Zeiten gesenkt werden.
  • Skalierbarkeit: Native Cloud Applications sind durch ihre Microservice-Architektur stark skalierbar. So können einzelne Microservices bei Bedarf dupliziert werden.
  • Kundennähe: NCAs können auf Servern weltweit betrieben werden. So müssen Anwender die Daten nicht über die ganze Welt verschicken und die Latenz sinkt.
  • Life-Cycle: NCAs können schneller und mit weniger Aufwand und Kosten aktualisiert werden. Dadurch erhöht sich die Auslieferungsgeschwindigkeit und das Time-To-Market sinkt.
  • Robustheit: NCAs können georedundant betrieben werden, wodurch Ausfälle bei lokalen technischen Problemen deutlich verringert werden.

Tools für Entwicklung und Betrieb einer Native Cloud Application

Die Cloud Native Computing Foundation ist eine neutrale Plattform für die meisten Open-Source-Projekte, die dabei helfen, die Herausforderungen und Probleme bei der Entwicklung und im Betrieb einer Native Cloud Application zu meistern. Darunter fällt das Orchestrierungstool Kubernetes, sowie das Monitoring-Tool Prometheus.

Die CNCF stellt eine Übersicht über alle Projekte, Tools und Provider zur Verfügung, die bei der Entwicklung, Auslieferung und Betrieb von NCAs helfen.

Was Softwarearchitekt:innen beachten müssen

Das Sicherstellen der ACID-Eigenschaften (Atomic, Consistency, Isolated, Durability) bei der Datenhaltung ist in hoch verteilten Anwendungen mit mehreren Datenbanken sehr schwierig bis unmöglich. In der Regel kann für eine gewisse Zeit auf Konsistenz der Daten verzichtet werden. In diesen Fällen sind Datenbanken mit BASE-Eigenschaften (Basically Available, Soft state, Eventual consistency) interessant, denn hier wird die Datenkonsistenz im Laufe der Zeit hergestellt. Ein gutes Beispiel ist Twitter, da auf dieser Plattform die Follower-Zahlen nicht in Echtzeit aktualisiert werden.

Softwarearchitekt:innen müssen entscheiden, für welche Daten Konsistenz benötigt wird und für welche nicht. Genauso müssen Sie darauf achten, die richtige Anzahl und Größe zu finden, da sie miteinander integriert werden. So sollte vermieden werden, aus reiner Bequemlichkeit neue Microservices zu implementieren. Microservices sollten immer nur eine Funktion erfüllen.

Je mehr Microservices es gibt, desto schwieriger und wichtiger wird es, diese zu beobachten. Wichtige Daten wie Durchlaufzeiten und Aufrufe pro Zeiteinheit können kritische Bereiche, Fehler und Flaschenhälse aufdecken. Monitoring-Lösungen wie der ELK-Stack helfen dabei, die verteilten Metriken zu sammeln, zentralisieren und visualisieren. So können auch Grenzwerte gesetzt werden, deren Überschreitung oder Unterschreitung einen Alarm auslösen. Diese Grenzwerte sollten aber auch immer wieder evaluiert und angepasst werden.

Best Practices bei der Entwicklung und Betrieb von Native Cloud Applications

Die Microservices einer NCA sollten sauber in zustandlose Services und zustandsbehaftete Services getrennt werden. Zustandslose Services können problemlos dupliziert und wieder abgebaut werden, ohne den Zustand der Anwendung zu ändern.

Microservices sollten nach Möglichkeit auch keine Anforderungen an das zu Grunde liegende System wie beispielsweise SSDs oder GPU haben. So lassen sie sich simpel in verschiedenen Umgebungen deployen.

Bei der Entwicklung der NCAs ist es wichtig, so viel wie möglich zu automatisieren. Das hilft, die vielen Microservices und die verteilte Natur einer solchen Anwendung beherrschbar zu machen. Infrastructure-as-Code automatisiert die Bereitstellung der Infrastruktur. Dieser Code kann und sollte auch mit versioniert werden. Das garantiert, dass jeder Service immer und in jeder Umgebung für ihn passend konfigurierte Infrastruktur besitzt.

Wenn dann ein weitverbreiteter Standard zur Kommunikation benutzt wird, wie etwa HTTP, können Microservices mit Technologien und Sprachen entwickelt werden, die am besten zur Aufgabe passen.

Fazit

Native Cloud Applications erlauben es den großen Internetgiganten wie Google und Twitter global ihre Services anzubieten, schnell Änderungen und neue Funktionen an die Nutzer:innen zu bringen. Herausforderungen, die sie mit sich bringen, lassen sich durch bereits etablierte Entwurfsmuster und Open Source Tools und Projekte ohne große Schwierigkeiten meistern. Die Hürden bei der Entwicklung und dem Betrieb einer Anwendung in der Cloud werden immer geringer, sodass heute jeder die Möglichkeit hat NCAs zu entwickeln und zu betreiben.

Training zu ‘Infrastruktur, Container und Cloud Native (CLOUDINFRA)‘

Unser 3-tägiges Training ‘Infrastruktur, Container und Cloud Native (CLOUDINFRA)‘ vermittelt das notwendige Wissen und die Fähigkeiten, um dynamische Cloud Native Architekturen konzipieren und implementieren zu können. Es werden zentrale Themen wie Container Application Design, Logging/Monitoring/Alerting, Container Native Storage, Möglichkeiten zur UI Integration sowie Container Manager vorgestellt. 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 20 Credit Points im Kompetenzbereich Technologie und 10 Credit Points im Kompetenzbereich Methodik.

Termine zum Training 'Infrastruktur, Container und Cloud Native (CLOUDINFRA)'

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:

12 + 8 =

Woran erkennt man gute Zertifikate?

Woran erkennt man gute Zertifikate?

Ein Artikel von: Mahbouba Gharbi und Dr. Carola Lilienthal

Erschienen auf: https://www.isaqb.org/de/isaqb-blog/

Einleitung

Seit ca. fünfzehn Jahren lässt sich in der IT ein neuer Trend beobachten: Wir dürfen nicht mehr nur lebenslang lernen, sondern wir können Zertifikate dafür erwerben, dass wir unser Wissen erweitert haben. Zwei Worte in diesem letzten Satz sollten interessierte Leser:innen aufhorchen lassen: „erwerben“ und „Wissen“.

Für ein Zertifikat muss Geld bezahlt werden! Deshalb wollen wir uns als erstes die Frage stellen, ob man ein Zertifikat kaufen kann, ohne dass man sein Wissen substanziell erweitert hat. Wie sind die Zertifizierungsverfahren organisiert, um einen solchen Missbrauch zu verhindern?

Als zweites wenden wir uns der Frage zu, was Zertifikate prüfen bzw. prüfen können: theoretisches Wissen – also alles, was man aus Büchern lernen kann – oder echte praktische Erfahrung, die über die Jahre wächst und sich verändert. Sollten Zertifikate vielleicht sogar ein Verfallsdatum haben? Gibt es Zertifikate, die prüfen, ob ich mein einmal zertifiziertes Wissen und meine Erfahrung beibehalte oder erweitere? Mit welchen Versprechen werden Zertifikate beworben und was ist von diesen Versprechen zu halten?

Zertifizierungsverfahren

Das Angebot an Zertifikaten ist vielfältig, trotzdem liegt den meisten Zertifikaten und Zertifizierungsverfahren ein ähnlicher Prozess mit einigen vergleichbaren Varianten zugrunde. In Abbildung 1 ist das grundsätzliche Muster für Zertifizierungsverfahren dargestellt.

Will ein Schulungsanbieter zu einem Zertifikat eine Schulung anbieten, so muss er zuerst überprüfen, ob er in der Lage ist, die im Lehrplan enthaltenen Themen zu vermitteln (Schritt 1 in Abbildung 1). Ist dies der Fall, so muss sich der Schulungsanbieter von dem für dieses Zertifikat zuständigen Board lizensieren lassen (Schritt 2). Mit dem entsprechenden Lizenzvertrag stellt das Board sicher, dass der Schulungsanbieter den Lehrplan des Boards umsetzt und seine Schulungsunterlagen ggf. durch das Board qualitätssichern lässt. Ist man als zukünftiger Prüfling auf der Suche nach einem Schulungsanbieter für ein Zertifikat, so sollte man stets kontrollieren, ob der Schulungsanbieter die entsprechende Lizenz tatsächlich besitzt.

Hat der Prüfling den für sich passenden Schulungsanbieter gefunden, so meldet er sich dort für die entsprechende Schulung an und entrichtet die Schulungsgebühr (Schritt 3+4). Möchte der Prüfling die Prüfung direkt im Anschluss an die Schulung machen, so meldet ihn der Schulungsanbieter kurz vor oder auch während der Schulung bei einer Zertifizierungsstelle für die Prüfung an (Schritt 5). Zertifizierungsstellen werden vom für das Zertifikat zuständigen Board für die Prüfung autorisiert. Der Pool von Fragen, aus dem die Zertifizierungsstelle jeweils die Prüfungsbögen zusammenstellt, wird von dem gleichen unabhängigen Board ausgearbeitet, das auch den Lehrplan für die Schulung festgelegt hat.

Die meisten Schulungen sind so organisiert, dass im Anschluss an eine mehrtägige Schulung (Schritt 6) direkt die Prüfung abgelegt werden kann. Dazu wird von der Zertifizierungsstelle eine unabhängige fachfremde Prüferin oder ein unabhängiger fachfremder Prüfer bestellt, die oder der die Prüfung vor Ort durchführt. Die Prüfung wird von einer fachfremden Prüferin bzw. einem fachfremden Prüfer abgenommen, damit auf jeden Fall verhindert wird, dass den Prüflingen bei der Prüfung geholfen werden kann.

Die Zertifizierungsstelle erhält für diese Dienstleistung vom Prüfling eine Prüfungsgebühr (Schritt 7). Der oder die Prüfer:in lässt die Prüflinge einen Multiple-Choice-Test ausfüllen (Schritt 9) – entweder digital oder in Papierform. Die Tests in Papierform hat er bzw. sie von der zuständigen Zertifizierungsstelle bekommen (Schritt 8). Im Anschluss an die Prüfung werden die digitalen Tests direkt von der Zertifizierungsstelle ausgewertet (Schritt 11) und das Ergebnis bekannt gegeben (Schritt 12). Falls Prüfungsbögen in Papierform verwendet werden, schickt der oder die Prüfer:in die ausgefüllten Prüfungsbögen zurück an die Zertifizierungsstelle (Schritt 10). Dort werden die Antworten ausgewertet und die Anzahl der richtigen Antworten festgestellt (Schritt 11). Im Anschluss wird der Prüfling per E‑Mail über das Ergebnis informiert. Hat der Prüfling genug richtige Antworten gegeben, erhält er sein Zertifikat (Schritt 13).

Abbildung 1: Zertifizierungsverfahren aus Sicht des Prüflings [DST]

Dieser auf den ersten Blick für den Prüfling relativ komplizierte Prozess wurde geschaffen, um der in der Einleitung präsentierten Gefahr entgegenzuwirken, dass man Zertifikate einfach kaufen kann.

Gute Zertifikate zeichnen sich dadurch aus, dass die Definition der Inhalte, die Schulung und die Prüfung von verschiedenen voneinander unabhängigen Institutionen verantwortet werden (s. Abbildung 2).

Abbildung 2: Aufgabenteilung [DST]

Zu diesem vollumfänglichen Zertifizierungsverfahren gibt es verschiedene Varianten für einzelne Teilprozesse:

  1. Vorbereitung ohne Schulung (s. Abbildung 3)
  2. Remote-Prüfung (s. Abbildung 4)
  3. Öffentliche Prüfung
  4. Prüfung im Testcenter

Will ein Prüfling ohne eine Vorbereitung durch einen Schulungsanbieter die Prüfung für ein Zertifikat ablegen, so ist die Prüfungsgebühr bei den meisten Zertifikaten etwas höher (Schritt 5 in Abbildung 3). Zu den meisten Zertifikaten werden Bücher angeboten, die das Selbststudium erleichtern (Schritt 6 in Abbildung 3).

Abbildung 3: Vorbereitung ohne Schulung [DST]

Für die Prüfung hat der Prüfling die drei oben aufgeführten Alternativen.

Seit der Coronapandemie werden viele Schulungen remote und damit ortsunabhängig angeboten, sodass eine Remote-Prüfung der logische Schritt ist. Deshalb wird inzwischen bei vielen Zertifikaten eine Remote-Prüfung angeboten. Die Prüfung wird vom Prüfling remote durchgeführt und von einem oder einer Prüfer:in überwacht, der bzw. die sich auf den Rechner des Prüflings aufschaltet und ihn mit der Kamera beobachtet. So entfällt für alle Beteiligten die Notwendigkeit zu reisen. Verfahren, bei denen die Online-Prüfung ohne Aufsicht abgelegt werden kann, laden im Gegensatz dazu zum Missbrauch ein.

Abbildung 4: Remote-Prüfung [DST]

Außerdem gibt es bei einigen Zertifizierungsverfahren die Möglichkeit, dass der Prüfling eine öffentliche Prüfung oder ein Testcenter besucht, wo er seine Prüfung unter persönlicher Aufsicht ablegt.

Für unsere erste Frage stellen wir also zusammenfassend fest: Bei Verfahren, die dem hier vorgestellten Ablauf mit einer Trennung der Verantwortlichkeiten folgen und bei denen die Prüfung unter Aufsicht abgelegt wird, ist sichergestellt, dass man das Zertifikat nicht kaufen kann.

Wissen oder Erfahrung?

Was ist aber mit dem zweiten Thema? Was überprüfen Zertifikate? Theoretisches Wissen oder praktische Erfahrung? Nun, diese Frage hängt tatsächlich von der Art des Zertifikats ab!

Alle Zertifikate, die lediglich aus einem Multiple-Choice-Test bestehen, fragen nur theoretisches Wissen ab. Natürlich versuchen die Boards Prüfungsfragen zu ersinnen, die nur mit praktischer Erfahrung zu beantworten sind, aber im Multiple-Choice-Schema ist das sehr schwierig.

Die Zertifikate, die in diese Kategorie fallen, haben in der Regel den Zusatz „Foundation Level“. Der Foundation Level wird von den Anbietern ausdrücklich als Basis-Zertifikat beworben [FGG10]. Der Prüfling beherrscht anschließend die Grundbegriffe eines Gebiets. Diese Grundbegriffe kann man lernen und sich ihren Sinn erklären lassen. Nach der Prüfung bzw. der Schulung spricht der Prüfling die Sprache dieses Gebiets.

Die Zertifikate, die auf dem „Foundation Level“ aufbauen, gehen in der Regel über einen reinen Multiple-Choice-Test hinaus. Diese Zertifikate tragen oft den Zusatz „Advanced Level“, manchmal auch „Professional“ oder „Master“. Für diese weiterführenden Zertifikate muss man auf irgendeine Weise praktische Erfahrung nachweisen.

Bei einigen Zertifikaten muss man Testimonials von Arbeitgebern für Projekte vorweisen, die zum Thema des Zertifikats passen: z. B. 18 Monate Testaufgaben in Projekten oder 18 Monate Projektleitung bzw. Teilprojektleitung.

Bei einigen anderen weiterführenden Zertifikaten gehört zur Prüfungsleistung zusätzlich zum Multiple-Choice-Test eine mündliche Prüfung. In manchen Fällen wird außerdem keine Schulung im herkömmlichen Sinne abgehalten, sondern es wird versucht, eine Art Projektsituation zu simulieren, in der die Teilnehmenden im jeweiligen Gebiet zusammenarbeiten.

Dann haben einige Zertifikate noch die unangenehme Eigenschaft, dass sie regelmäßig alle drei oder fünf Jahre erneuert werden müssen. Entweder muss die Prüfung erneut durchgeführt werden oder die Prüflinge müssen Credit Points sammeln, die bestimmte Aktivitäten im zertifizierten Bereich nachweisen: Konferenzbesuche, Vorträge, Vorlesungen, Artikelveröffentlichungen. Auf diese Weise wird sichergestellt, dass die Erfahrung der Prüflinge nicht veraltet.

Was die Frage nach dem Wissen und den Erfahrungen angeht, so halten wir fest: das Basiszertifikat, der Foundation Level, entspricht einer theoretischen Führerscheinprüfung. Die Theorie, also die Begriffsbildung und die Regeln, werden beherrscht, praktische Erfahrung liegt aber nicht vor. Insofern sollte man die Basiszertifikate immer als das betrachten, was sie sind: Theoretisches Wissen, das man erwerben muss, um die Aufbauzertifikate ablegen zu können.

Fazit

Falls Sie nach einer Weiterbildung mit Zertifikat suchen, so planen Sie je nach Ihrem aktuellen Wissensstand ein Basiszertifikat und entsprechende Aufbauzertifikate ein. Nur die Aufbauzertifikate sind wirklich in der Lage, Ihnen praktische Erfahrung zu attestieren.

Darüber hinaus sollten Sie auf eine Prüfung mit Aufsicht bestehen und nur Zertifikate wählen, bei denen die Verantwortung für Inhalte, Schulung und Prüfung klar getrennt ist.

Außerdem sollten Sie sich bei der Recherche nach dem passenden Schulungsanbieter nicht von hübschen Broschüren und Äußerlichkeiten täuschen lassen. Versuchen Sie sich ein Bild zu machen, ob die Ihnen angebotenen Schulungsleiter den Hauptteil Ihrer Zeit in Projekten in der Praxis verbringen – also ihr Geld nur gelegentlich mit Schulungen verdienen. Haben Sie einen solchen Schulungsanbieter gefunden, so ist die Wahrscheinlichkeit sehr viel größer, dass Sie nicht nur mit einem Zertifikat, sondern tatsächlich mit praxistauglichen Ratschlägen aus der Schulung zurückkehren.

Wir hoffen, dass Sie, mit diesem Wissen ausgestattet, in der Lage sind, die Qualität der am Markt angebotenen Zertifikate einzuschätzen und die für sich passende Weiterbildung zu identifizieren.

[FGG10] Fahl, W.; Ghadir, P.; Gharbi, M.: Vom Sinn und Unsinn einer Zertifizierung für Softwarearchitekten – CPSA‑F: Ein gemeinsamer Nenner für Softwarearchitekten; Sonderdruck OBJEKTspektrum 11/2010

[DST] Bei den Prozessmodellen handelt es sich um Domainstories: www.domainstorytelling.org

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

Soft Skills in der IT: Feedback und Konfliktfähigkeit in agilen Teams

Soft Skills in der IT: Feedback und Konfliktfähigkeit in agilen Teams

Softwareentwicklung in agilen Teams stellt hohe Anforderungen an jedes einzelne Teammitglied. Während den fachlichen und technischen Skills für gewöhnlich die höchste Aufmerksamkeit gewidmet wird, fallen die Soft Skills naturgemäß mit schöner Regelmäßigkeit unter den Tisch. Das ist gleich aus mehreren Gründen paradox: Scrum dient nicht in erster Linie der Verwaltung von Tasks und deren termingerechter Umsetzung, sondern der Organisation des Teams, das mit der Umsetzung betraut ist. Das bringt zwangsläufig den Faktor „Mensch“ ins Spiel.

Im „Daily Scrum“ bleiben oft nicht mehr als fünfzehn Minuten, um die Befindlichkeit der Kollegen, schwelende Konflikte und Unstimmigkeiten im Team zu erfassen. Wer hier nicht eine gehörige Portion Empathie mitbringt, kann schnell mit Problemen konfrontiert werden. Zusammenarbeit ermöglicht erst wahre Teamfähigkeit und dazu gehören zielgerichtetes Feedback sowie Konfliktfähigkeit. Das sind die Themen für diesen zweiten Artikel aus unserer Soft Skills Reihe. Im ersten Teil ging es um Best Practices in der Kommunikation und Gesprächsführung.

Der Ursprung aller Konflikte zwischen mir und meinen Mitmenschen ist, dass ich nicht sage, was ich meine, und dass ich nicht tue, was ich sage.

Martin Buber

Die Fähigkeit, sich einer Gruppe anderer Menschen nicht nur anzuschließen, sondern auch, sich in angemessenem Umfang in eine Gruppe einzuordnen, ist von zentraler Bedeutung für eine erfolgreiche Zusammenarbeit. Dabei geht es darum, mit anderen Teammitgliedern und Stakeholdern zusammen sozial zu agieren und sich und sein Können im Sinne einer Gruppenaufgabe optimal einzubringen, egal ob Sie Softwarearchitekt:in, Entwickler:in, Scrum Master, Manager oder Product Owner (alle Geschlechter) sind. Eine Kultur der Zusammenarbeit sollte gefördert werden, in der fachliche und persönliche Auseinandersetzungen konstruktiv möglich sind.

Reflektion fördert erfolgreiche Zusammenarbeit

Zu einer erfolgreichen Zusammenarbeit gehört es seinem Gegenüber ein offenes und ehrliches Feedback zu geben. Feedback ist ein wichtiger, entscheidender Teil der Kommunikation. Außerdem ist es wichtig, zwischen der Person und ihrer Rolle zu unterscheiden. Dadurch fühlt der Angesprochene sich nicht persönlich verletzt, sondern realisiert durch eine Reflexion, dass nicht er persönlich angegriffen wird, sondern die Rolle, die er gerade innehat.

Durch Feedback fördert man die Reflexion aus sich selbst und der Gruppe und verbessert so die Zusammenarbeit im Team. Man selbst teilt einem anderen mit, wie man ihn sieht und wie man ihn versteht. Feedback stellt aber auch einen Lernprozess dar. Durch das Feedback kann man selbst lernen und verstehen, wie andere einen wahrnehmen, wie man auf sie wirkt. Es ist somit zu unterscheiden zwischen Feedback geben und Feedback erhalten. Bei beiden Feedbackarten sind Regeln zu berücksichtigen.

Wie Sie richtig Feedback geben – und Feedback nehmen

Beim Feedback geben ist zunächst einmal zu festzustellen, ob das Feedback überhaupt erwünscht ist. Ist dies der Fall, dann sollte der Feedback-Nehmer bei den getroffenen Aussagen wertgeschätzt werden und die eigenen Empfindungen sollten als „Ich-Botschaft“ z. B. mit „Ich habe gesehen, dass…“ ausgedrückt werden. Hierbei gilt es zu beachten, niemals persönlich oder beleidigend zu werden und Verbesserungsvorschläge sowie Alternativen zum Verhalten des Feedbacknehmers anzubieten, die sich auch tatsächlich umsetzen lassen.

Der Feedbacknehmer muss sich im Vorfeld auch über einige Prinzipien bewusst sein. Er muss sich im Klaren sein, ob er für ein Feedback bereit ist. Ist dies der Fall, dann sollte er dem Feedback-Geber in aller Ruhe zuhören und ihm nicht ins Wort fallen. Lediglich Verständnisfragen sind erlaubt. Außerdem ist die Bereitschaft erforderlich, sich über das Gehörte Gedanken zu machen und danach zu entscheiden, was davon zukünftig im eigenen Verhalten umgesetzt werden soll. Als Feedbacknehmer sollte man auch immer seine Dankbarkeit dem Gesprächspartner gegenüber zum Ausdruck bringen.

Kühlen Kopf bewahren mit guter Konfliktfähigkeit

Konfliktfähigkeit – das heißt der Mut, Konflikte auszutragen, statt ihnen aus dem Weg zu gehen, und die Fähigkeit, sie zu einer tragfähigen Lösung zu führen. Sie sind als Softwarearchitekt:in, Teil des Entwicklungsteams oder Stakeholder in IT-Projekten aufeinander angewiesen und Ihre Soft Skills zur Konfliktlösung werden täglich gefordert. Dabei ist es wichtig, die eigene Wahrnehmung nicht als die alleinige „richtige“ Wahrheit anzusehen.

Die Einschränkung einer differenzierten Wahrnehmungsfähigkeit ist ein typisches Kennzeichen von eskalierenden Konflikten. Deshalb ist es notwendig, die eigene Wahrnehmung und damit auch verbunden die Interpretation der Ereignisse nicht absolut zu setzen, sondern einer Überprüfung und Korrektur zu unterwerfen und damit auch die eigenen Anteile am Konflikt zu erkennen. Die Bereitschaft hierfür ist bereits ein wichtiger Schritt zur Anerkennung von Rechten der anderen Konfliktpartei. Zusätzlich sollte die Lösung des Konflikts sich an den Interessen aller Beteiligten und allen Betroffenen orientieren. Es sollten Vorteile für möglichst alle Parteien geschaffen werde und großen Wert auf eine rationale Konfliktaustragung ohne Kontrollverlust gelegt werden. Außerdem ist es ratsam, eine dritte Partei mit einzubeziehen, wenn die Verhandlungen ins Stocken geraten und kein Fortschritt erkennbar ist.

Doch mit kühlem Kopf und guter Konfliktfähigkeit werden sie diese täglichen Herausforderungen meistern, denn wie schon der französischer Moralist Joseph Joubert sagte: „Das Ziel eines Konflikts oder einer Auseinandersetzung soll nicht der Sieg, sondern der Fortschritt sein.“

Was ist Ihre Meinung?

Welche weiteren Praxis-Tipps haben Sie zum Thema Feedback und Konfliktfähigkeit? Welches Thema darf auf keinen Fall in unserer Soft Skills Reihe fehlen? Schreiben Sie es gerne in die Kommentare. Wir freuen uns auf den Austausch!

Sie möchten Ihre Soft Skills auf ein neues Level bringen?

Dann empfehlen wir Ihnen unser 3-tägiges Training ‚Soft Skills für Softwarearchitekten (SOFT)‘. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced Level (CPSA-A ®) anstreben, erhalten Sie mit diesem Soft Skills Training 30 Credit Points im Kompetenzbereich Kommunikation. Zum Soft Skills Training

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!