Continuous Delivery – Der Architekt als Speedmaster

Continuous Delivery – Der Architekt als Speedmaster

Sind es nicht faszinierende Zeiten, in denen ein einzelnes Feature Milliarden an Börsenwert produzieren oder über Nacht vernichten kann? Den Trend, in dem wir uns aktuell bewegen, wurde in einem Vortrag im Rahmen des “Architecture Gathering 2018” unlängst beschrieben: Wir befinden uns in der post-industriellen Ära der hochdynamischen, globalen Märkte und disruptiven Veränderungen. Im Fokus stehen dabei weniger die Entwicklungskosten. Time-to-Market ist der entscheidende Erfolgsfaktor. Wer zuerst kommt und den nächsten Hype inszeniert, hat die besten Chancen auf das große Geschäft.

In der Softwareentwicklung ist Geschwindigkeit längst keine Hexerei mehr. Immer höhere Automatisierungsgrade und ein verändertes Prozessdesign ermöglichen Performancesprünge, die noch vor wenigen Jahren undenkbar schienen. Der Softwarearchitekt ist dabei der zentrale „Driver“, sozusagen der Speedmaster im Projekt. Mit seinem Architekturkonzept steuert er nahezu alle relevanten Parameter, um ein Projekt auf seine Anforderungen auszurichten. Wenn Time-to-Market die Priorität hat, sind flexible Architekturmodelle und Continuous Delivery zumeist die erste Wahl. Erstere schaffen mit weitgehend autarken Komponenten bis hin zu Microservices die Voraussetzungen, um effizient zu entwickeln und über die Continuous Delivery Pipeline fortlaufend zu liefern. Aber schauen wir uns das einmal genauer an.

Ein erster Blick auf Continuous Delivery

Continuous Delivery – kurz „CD“ genannt – beschreibt eine Sammlung von Techniken, Prozessen und Werkzeugen, mit deren Hilfe kurze Entwicklungszyklen und die schnelle Auslieferung von Software-Updates oder produktiven Endsystemen ermöglicht werden. CD zielt darauf ab, jede Entwicklung oder Änderung im Code sofort in eine mehrstufige, weitgehend automatisierte Test-Pipeline zu übergeben und nach erfolgreichem Durchlauf mit dem nächsten Deployment produktiv zu stellen. Typischerweise werden bei den Tests drei Phasen unterschieden: Eine Commit Stage, auf der die Software gebaut und die Unit-Tests durchgeführt werden, eine Accaptance Test Stage für die Integrations-, Akzeptanz- und Systemtests sowie eine dritte Phase, in der gegebenenfalls manuelle Tests und ein Freigabeprozess stattfinden können. Für jede Phase gilt das Prinzip „Stop-the-line“: Bei Ermittlung eines Fehlers wird die Test-Pipeline angehalten, bis das Problem behoben ist. Der Entwickler erhält umgehend Feedback. So können Fehler frühzeitig entdeckt und beseitigt werden.

Continuous Delivery und DevOps

In der Konsequenz durchläuft jeder Softwarestand zigmal die Test-Pipeline und muss entsprechend zigmal auf einer Testumgebung installiert werden. Traditionell liegt die Installation für den Test im Aufgabenbereich des Betriebs. Wie soll sich das in der Praxis darstellen lassen? Betrieb und Entwicklung müssen die Konfiguration der Anwendung und die Deployments in so enger Abstimmung planen, dass eine Trennung der Abteilungen nicht länger gegeben ist. DevOps, die Zusammenlegung von Development und Operations, ist tatsächlich eine notwendige Konsequenz, wenn die Umsetzung von Continuous Delivery zum Erfolg führen soll.

Der Softwarearchitekt im Lead

Wenn wir die angesprochenen Themen zusammennehmen, ist der Softwarearchitekt der einzige im Bunde, der gleichzeitig über die Kompetenz verfügt und frei ist von Interessenskonflikten. Allein deshalb bringt es viele Vorteile, Design und Überwachung von Continuous Delivery Projekten im Aufgabenbereich erfahrener Architekten anzusiedeln. Wir haben gesehen, dass die Konzeption von Continuous Delivery unmittelbar abhängig vom Architekturmodell ist. Der Architekt kann Continuous Delivery also im Flow des Gesamtkonzepts entwickeln – auch das ist ein Argument. Weiterhin ist die Perspektive des Architekten auf die Test-Szenarien naturgemäß weniger Tool-getrieben und er kann aufkommende Konflikte von Entwicklung und Betrieb aus dem Konzept heraus moderieren.

Ein Aufwand, der sich lohnen sollte

Mit Continuous Delivery erweitern Softwarearchitekten ihren Kompetenzbereich um ein Thema, mit dem sie punkten können: Speed! Der Entwickler profitiert von unmittelbarem Feedback aus der Test-Pipeline, von der Verringerung des Risikos in der Entwicklung und einer drastischen Verkürzung der Zeit bis zur Produktivstellung. Neue Features können innerhalb weniger Tage zum Anwender gebracht und bei Bedarf mit Varianten ausgetestet werden. So lassen sich auch höchste Anforderungen an die Time-to-Market erfüllen.

Die wichtigsten Grundlagen und Tools rund um Continuous Delivery sind Teil unseres Trainings „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ auf iSAQB Advanced-Level. Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Nächstes Training: 05.-07. März 2019 in Ludwigshafen
Weitere Infos: www.itech-progress.com/isaqb-improve/

 


1 Quelle: Uwe Friedrichsen, „Life after Microservices“, zum Artikel auf Slideshare hier klicken

Clean Code als Architekturaufgabe

Clean Code als Architekturaufgabe

In unserem ersten Beitrag der Reihe „Softwarearchitektur verbessern“ greifen wir ein Thema auf, das in den Trainings der ITech Academy und auch in zahlreichen Blog- und Forenbeiträgen immer wieder kontrovers diskutiert wird: 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 Training „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ auf iSAQB Advanced-Level versuchen wir, die teilnehmenden Architekten zur Entscheidungsfähigkeit hinzuführen, 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.

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

Nächstes Training: 14.-16. November 2018 in Nürnberg
Weitere Infos: www.itech-progress.com/isaqb-improve/

Das Doppelpack für die moderne Architektur

Das Doppelpack für die moderne Architektur

Trendreport: Flexible Architekturen

 

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?

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 Modulen Flexible Softwaremodelle (FLEX) und Domain Driven Design (DDD) ein starkes Doppelpack an iSAQB-lizenzierten Trainings, in denen alle relevanten Grundlagen anschaulich und praxisnah vermittelt werden. An der ITech Academy zählt die Kombination von FLEX und DDD bereits seit über einem Jahr zu den am stärksten nachgefragten, oft und gerne ergänzt durch das Modul Agile Softwarearchitektur (AGILA). Bei Interesse sollte an eine frühzeitige Anmeldung gedacht werden.

 

Weiterführende Links

Training iSAQB CPSA Domain Driven Design (DDD)

Training iSAQB Flexible Architekturmodelle (FLEX)

Training iSAQB Agile Softwarearchitektur (AGILA)

Vorteile

 

  • Fokussierung auf die Fachlichkeit des Unternehmens
  • Vereinfachte Modularisierung in Microservices
  • Verbesserte Stabilität
  • Adaptive Reaktion auf veränderliche Anforderungen
  • Effizienz- und Kostenvorteile
Digitaler Posteingangsstempel – Blockchain als spezialisierte Datenbank im Solution Stack

Digitaler Posteingangsstempel – Blockchain als spezialisierte Datenbank im Solution Stack

Beitrag von Marcus Klüsener und Mahbouba Gharbi in der JavaSPEKTRUM 03/2017

Ein möglicher Anwendungsfall für eine Blockchain könnte so beschrieben werden: Ein Kunde schickt ein digitales Dokument an ein Unternehmen. Dieses erzeugt einen Hash-Wert des Dokumentes und veröffentlicht ihn in einer Blockchain. Der Kunde scannt die Blockchain nach diesem Dokument-Hash und erhält dadurch einen unveränderbaren digitalen Posteingangsstempel. So können Geschäftsprozesse optimiert, Kosten gesenkt und das Betrugsrisiko verringert werden. Der Artikel führt anhand dieses Anwendungsfalls und seiner Java-Implementierung als Zeitstempel-App in die Verwendungsmöglichkeiten von Blockchain in existierenden Client-/Server-Anwendungen und in dezentralen Anwendungen ein.

 

PDF DownloadArtikel als PDF laden.

Architekturdokumentation – das Manifest des Softwarearchitekten. iSAQB Schulung vom 27. bis 28. November 2014

Architekturdokumentation – das Manifest des Softwarearchitekten. iSAQB Schulung vom 27. bis 28. November 2014

Für alle Arten von Architekturdokumentation gelten übergreifende Anforderungen und Regeln, die die Vorteile der Dokumentation erst möglich machen. Lernen Sie effektiv und praxisnah Softwarearchitekturen zu dokumentieren und das Vorgehen zur Dokumentation eines solchen Systems zu definieren. In unseren Schulungen erfahren Sie außerdem, wie die Dokumentation zu einem integralen Kommunikations- und Arbeitsmittel wird.

Die Schulung „Architekturdokumentation“ vermittelt Ihnen neben fachlichen Aspekten auch die so wichtigen organisatorischen und sozialen Faktoren im Umgang mit Architekturdokumentation. Am Ende des Trainings sollten Sie in der Lage sein, die Softwarearchitektur eines mittleren bis großen Systems effektiv und praxisorientiert dokumentieren zu können und zielgruppengerecht kommunizieren zu können.

Wenn Sie die Zertifizierung zum iSAQB Certified Professional for Software Architecture anstreben, können Sie mit dem Besuch von „Architekturdokumentation“ den Kompetenzbereich „Methodik“ des Advanced Levels abdecken und sich 20 von 70 nötigen Credit Points für das gesamte Programm anrechnen lassen.

Die nächste offene Schulung findet vom 27. bis 28. November 2014 statt. Detaillierte Informationen zu den Schulungsinhalten finden Sie hier.

Sie erreichen uns per E-Mail an training@itech-progress.com oder telefonisch unter 0621/59570241, gerne stehen wir für Fragen zur Verfügung und machen Ihnen ein speziell auf Sie zugeschnittenes Angebot.

Web-Architekturen im internationalen Umfeld gerecht werden – iSAQB CPSA-A Training vom 10.11.-12.11.14 und 01.12.–03.12.2014

Web-Architekturen im internationalen Umfeld gerecht werden – iSAQB CPSA-A Training vom 10.11.-12.11.14 und 01.12.–03.12.2014

In unserer dreitägigen Schulung erhalten die Teilnehmer Kenntnisse und Fertigkeiten zu Grundlagen, Protokolle und Standards, Architekturstile, Technologie und Qualität von Web-Architekturen.

Softwarearchitekten müssen heutzutage nicht nur in der Lage sein, selbstständig  Softwaresysteme zu entwerfen, sondern auch, Risiken und Bedrohungen einzuschätzen und diese in ihren Web-Architekturen berücksichtigen. Ein weiterer Trend, der gezielt in die tägliche Arbeit einbezogen werden sollte, ist die Internationalisierung und die zunehmende Vernetzung innerhalb der Arbeitswelt. Kunden aus den USA und Partner aus Frankreich besuchen Ihre Website und dabei spielt es nicht nur eine Rolle, dass auf dieser Inhalte auf verschiedenen Sprachen erhältlich sind. Für den Erfolg Ihrer Website und damit auch für Ihren Erfolg als Softwarearchitekt ist es auch ausschlaggebend, dass kulturelle Unterschiede und rechtliche Rahmenbedingungen im Design, im Layout und in den Inhalten berücksichtigt werden.

In unserer dreitägigen Schulung erhalten die Teilnehmer Kenntnisse und Fertigkeiten zu Grundlagen, Protokolle und Standards, Architekturstile, Technologie und Qualität von Web-Architekturen. Ein großer inhaltlicher Fokus liegt auch auf dem selbstständigen Entwurf von Web-Architekturen und das Kennenlernen von Beispielarchitekturen, um das Gelernte gleich zu festigen und auszuprobieren. Die Schulung eignet sich nicht nur für Web-Architekten sondern auch allgemein für Softwarearchitekten-, Designer und Entwickler und weitere IT Professionals. Profitieren Sie von unseren hoch qualifizierten Trainern, die sich auf die individuellen Bedürfnisse der kleinen Gruppe einstellen und entdecken Sie unsere komfortablen Schulungsräumen.

Wünschen Sie mehr Informationen zur Schulung Web-Architektur?

Die nächsten beiden Schulung der ITech Progress finden vom 10. – 12.11.2014 und vom 01. – 03.12.2014 in Ludwigshafen am Rhein oder in Nürnberg statt. Interessenten können sich per E-Mail an training@itech-progress.com oder telefonisch unter 0621/59570241 beraten lassen und sich einen der Schulungsplätze sichern. Selbstverständlich kann das Seminar auch maßgeschneidert als Inhouse Schulung angeboten werden.