iSAQB CPSA-F Softwarearchitektur-Training jetzt neu in Spanisch und Französisch buchbar

iSAQB CPSA-F Softwarearchitektur-Training jetzt neu in Spanisch und Französisch buchbar

Hola! Nous avons de bonnes nouvelles! ITech Progress goes International

ITech Progress bietet jetzt neu als erster iSAQB® Accredited Training Provider das Grundlagentraining für Softwarearchitektur (CPSA® – Foundation Level) in Spanisch und Französisch an. Die ersten Termine für 2021 sind ab sofort buchbar! Im Anschluss an das Training können Teilnehmer:innen optional eine Online-Zertifizierungsprüfung zum CPSA-F® in Spanisch und ab Mai 2021 auch in Französisch absolvieren.

Das International Software Architecture Qualification Board (iSAQB®) bietet mit der Zertifizierung zum Certified Professional for Software Architecture (CPSA®) ein international anerkanntes und standardisiertes Aus- und Weiterbildungsprogramm für Softwarearchitekt:innen an. Die Trainings im Foundation Level vermitteln fundierte Grundlagen in der Softwarearchitektur, die im Advanced Level gezielt vertieft werden können.

Die beiden Architektur-Expert:innen Mahbouba Gharbi und Alfredo Delgado Sánchez geben in ihren viertägigen Online-Trainings zum CPSA-F® einen umfassenden Einblick in die Welt der Softwarearchitektur. Teilnehmer:innen lernen anhand von vielen praktischen Übungen wichtige Methoden, Techniken und Tools kennen. Das kompakte Grundlagen-Training richtet sich an alle Softwarearchitekt:innen, Senior-Entwickler:innen und an IT-Fachkräfte, die an Softwareprojekten beteiligt sind. Es verbessert durch eine gemeinsame Fachsprache die Kommunikation in Projektteams und hilft somit mehr Verständnis füreinander zu entwickeln. Daher eignet sich dieses Training auch optimal als projektbegleitende Weiterbildung für IT-Teams.

Schulungsinhalte:

  • Grundbegriffe der Softwarearchitektur
  • Entwurf, Entwicklung, Beschreibung und Kommunikation von Softwarearchitekturen
  • Methoden, Techniken und Tools für Softwarearchitekt:innen
  • Qualitätsmodelle, -merkmale, -anforderungen und -bewertung
  • Verantwortlichkeiten und Rollen von Softwarearchitekt:innen im Projekt
  • Praktische Beispiele und Übungen

Am Ende des Softwarearchitektur-Trainings sind Sie in der Lage problembezogene Entwurfsentscheidungen zu treffen, Softwarearchitekturen für kleine und mittlere Systeme zu entwerfen und zu dokumentieren. Im Anschluss an das Training können Sie die Zertifizierungsprüfung zum “Certified Professional for Software Architecture – Foundation Level” ablegen.

Die ersten Termine:

Das erste Online-Training auf Spanisch findet vom 18. – 21. Mai 2021 statt und das erste Online-Training auf Französisch vom 09. – 12. November 2021. Alle Termine, auch auf Deutsch und Englisch, finden Sie hierBis 6 Wochen vor Start des Trainings können Sie mit unserem Early-Bird-Rabatt 100€ pro Person sparen und wenn Sie sich gemeinsam mit einer Kollegin oder einem Kollegen anmelden weitere 100€ pro Person.

Auf Spanisch finden Sie beim iSAQB bereits eine Beispielprüfung und viele weitere informative Dokumente über das Foundation Level zum Download. Die französischen Dokumente folgen in Kürze!

    Vorteile unserer Online-Trainings:

    • Ortsunabhängiges Echtzeit-Lernen
    • Interaktiv durch Übungen, Breakout-Rooms und visuelle Zusammenarbeit (z.B. Miro)
    • Ideale Trainerbetreuung auch in den Breakout-Rooms
    • Kleine und intensive Lerngruppen aus maximal 12 Teilnehmer:innen
    Mahbouba Gharbi

    Mahbouba Gharbi

    Trainerin für CPSA-F auf Französisch, Deutsch und Englisch

    Mahbouba Gharbi ist seit über 20 Jahren Expertin für Softwarearchitektur und gibt ihr Wissen als Chefarchitektin, Beraterin, Dozentin, Trainerin und Autorin weiter. Sie beschäftigt sich mit der Konzeption und Realisierung von mittleren bis großen Softwaresystemen. Neben ihrer Tätigkeit als Geschäftsführerin der ITech Progress ist sie Mitgründerin und Vorstandsvorsitzende des iSAQB e.V. und gestaltet Lehrpläne und Prüfungen aktiv mit.

    Alfredo Delago Sánchez

    Alfredo Delago Sánchez

    Trainer für CPSA-F auf Spanisch

    Alfredo Delago Sánchez ist mit mehr als 30 Jahren Erfahrung Experte für die Entwicklung von IT-Lösungen. Neben seiner technischen Expertise in der Softwarearchitektur bringt er methodische und kommunikative Kompetenzen aus seinen Tätigkeiten als Dozent und IT-Projektmanager mit. Mit seinem Know-how rund um Good Practices, agile Methoden, Standards und Prozesse, hat er es sich zu Aufgabe gemacht, Fachwissen über Softwarearchitektur weiterzugeben.

    Wir beraten Sie bei Ihren Weiterbildungsplänen und begleiten Sie auf dem Weg zum Certified Professional for Software Architecture (CPSA®)! Bei Fragen helfen wir Ihnen gerne weiter unter +49 621 595702 41 und training@itech-progress.com

    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.

    .
    Clean Code als Architekturaufgabe

    Clean Code als Architekturaufgabe

    Clean Code als Architekturaufgabe – Wer nun fragend zum Himmel oder an die Zimmerdecke schaut, sei an das gleichnamige Buch von Robert Martin erinnert, in dem ein erster zielführender Standard für sauberen Quellcode geschaffen und mit einer Vielzahl sachdienlicher Hinweise zu dessen Strukturierung ausgestattet wurde. Tatsächlich beschreibt Clean Code aber nicht nur eine Arbeitsweise, sondern auch eine Bewusstseinshaltung des Entwicklers dahingehend, sich selbst und Nachfolgende nicht mit faktisch unzureichender Codequalität, unsinnigen Entscheidungen und unpräzisen Designs zu belasten. Der Clean-Code-Entwickler übernimmt Verantwortung nicht nur für das Endprodukt, sondern auch für dessen „inneren Werte“ im Hinblick auf Verständlichkeit und Wartbarkeit.

    Zugegeben, das alles bezieht sich auf den Entwickler und seine Arbeit. Es mag deshalb in der Tat verwirren, wenn Architekten angeregt werden, sich mit Clean Code als Verbesserungsansatz in der Softwarearchitektur zu beschäftigen. „Was geht mich der Code an?“ lautet meist die Antwort. „Das ist Sache des Programmierers!“ Die Antwort ist ebenso richtig wie falsch: Mit Clean Code zu arbeiten ist eine strategische Architekturentscheidung, die sinnvollerweise begründet in der Konzeptphase getroffen und vom Management abgesegnet wird. Die Entscheidung wird zumeist im Hinblick auf die langfristige Codequalität und die Weiterentwicklungskosten gefällt, und sie ist anspruchsvoll, wie wir noch sehen werden. Sie kann in einem Projekt eine erhebliche Tragweite entwickeln und Auswirkungen bis hin zur personellen Besetzung der Teams.

    Wenn Clean Code eine Architekturvorgabe an ein Projekt ist, liegt sie auch im Verantwortungsbereich des Architekten. Softwarearchitekten in Clean-Code-Projekten sollten deshalb auch in der Lage sein, die Einhaltung der Anforderungen im Projekt zu steuern und den Code auf konsequente Umsetzung zu prüfen, beispielsweise mit Tools wie Sonarqube. Und damit öffnen wir schon mal die ersten beiden Schubladen der Konfliktkommode. Denn zum einen sehen Entwickler die tägliche Codehygiene gerne als einen Teil ihrer Intimsphäre an und verzichten nur zu gerne auf „väterliche“ Kontrollgänge des Architekten. Zum anderen nagt die Umsetzung von Clean Code unaufhörlich speziell an der Ressource, die für den Entwickler ohnehin die knappste ist: Zeit. Zumindest ein leiser Protest im Team scheint damit vorprogrammiert. Aber hatte jemand behauptet, der Job des Softwarearchitekten sei ein leichter?

    Es gibt noch eine dritte Schublade, nicht minder relevant: Clean Code als Anforderung muss nicht nur dem Projektteam vermittelt, sondern auch dem Management verkauft werden. Auch das kann durchaus schwierig werden. Moderationsfähigkeit und Überzeugungskraft gehörten deshalb ebenso zum Handwerk des Architekten, wie das methodische und technische Wissen.

    Auf dieser Basis stellt sich für uns nicht die Frage, ob Clean Code seinen Platz in einem fortgeschrittenen Architekturtraining haben sollte oder nicht, sondern lediglich, in welchem Umfang und welchem Tiefgang das Thema besprochen gehört. In unserem iSAQB-akkreditierten Training „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ befähigen wir die teilnehmenden ArchitektInnen zur Entscheidungsfindung, ob und wann Clean Code in einem Projekt Sinn ergibt. Weiterhin werden die wesentlichen Grundlagen und Tools sowie weiterführende Literatur vorgestellt, um eine Beschäftigung mit dem Thema über die Schulung hinaus zu ermöglichen.

    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 ermöglicht eine Bewertung nach Beschaffenheit oder Güte der Softwarearchitektur und hilft frühzeitig Risiken zu identifizieren, die die Erreichung der Qualitätsziele gefährden können. Ein Qualitätsmodell (wie z.B. ISO 25010) kann verwendet werden. Das ISO Modell definiert acht Qualitätsmerkmale: Benutzbarkeit, Effizienz, Funktionale Eignung, Kompatibilität, Sicherheit, Übertragbarkeit, , Wartbarkeit und Zuverlässigkeit.

    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.

     

    Sie möchten noch mehr erfahren?

    Das 2-tägige iSAQB-akkreditierte Training “Architekturbewertung (AWERT)” vermittelt 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?

    Zu den Terminen

    Das Doppelpack für die moderne Architektur

    Das Doppelpack für die moderne Architektur

    Während die Skyline unserer Softwarewelt nach wie vor von Monolithen geprägt ist, hat sich der Trend zu flexiblen Architekturmodellen mit Microservices, Continuous Deployment, DevOps und hohen Automatisierungsgraden auf möglichst allen Ebenen inzwischen durchgesetzt. Und in der Tat: kompaktere, weitestgehend autarke Softwaremodule mit eigenen spezialisierten Teams bieten eine Menge Vorteile – von der Konzeption über Entwicklung und Testen bis in die Wartung. Verbesserte Stabilität, adaptive Reaktion auf veränderliche Anforderungen, Effizienz- und Kostenvorteile in der Weiterentwicklung sind Argumente, bei denen jedes Entscheiderherz höher schlagen sollte.

    Aus architektonischer Sicht ist eine flexible Sortwarearchitektur allerdings leichter gesagt, als getan. Welche Methodik ist für mein Projekt die richtige? Anhand welcher Kriterien lassen sich Module zielführend abgrenzen? Wie kann ich von Anfang an vermeiden, dass sich bei zusätzlichen oder sich verändernden Anforderungen mit der Zeit der berühmt-berüchtigte Big Ball of Mud bildet?

    Vorteile

    • Fokussierung auf die Fachlichkeit des Unternehmens
    • Vereinfachte Modularisierung in Microservices
    • Verbesserte Stabilität
    • Adaptive Reaktion auf veränderliche Anforderungen
    • Effizienz- und Kostenvorteile

    Für viele Softwarearchitekten ist Domain Driven Design (DDD) die Antwort auf diese und andere gängige Fragestellungen im Vorfeld einer flexiblen Architektur. DDD setzt konsequent auf die Fachlichkeit, und die liegt im Business des Unternehmens begründet, nicht im technischen Jargon des Entwicklerteams. Aus dem Business heraus lassen sich bereits in frühen Phasen des strategischen Designs inhaltliche und funktionale Einheiten als Bounded Contexts separieren. Aber auch im taktischen Design können sich sinnvolle Modularisierungsoptionen ergeben. So bildet die Fachlichkeit letztendlich die Basis für die Abgrenzung der Microservices und die Herausbildung dedizierter Teams.

    Architekten, die ihr Handwerk in diese Richtung entwickeln möchten, finden in den iSAQB-akkreditierten Trainings Flexible Architektur­modelle, Microservices & Self-Contained Systems (FLEX) und Domain Driven Design (DDD) ein starkes Doppelpack, in denen alle relevanten Grundlagen anschaulich und praxisnah vermittelt werden. In unserer ITech Academy zählt die Kombination von FLEX und DDD bereits seit über zwei Jahr zu den am stärksten nachgefragten, oft und gerne ergänzt durch das Modul Agile Softwarearchitektur (AGILA).