DevOps als Unternehmens-Kultur verändert  die agile Software-Entwicklung

DevOps als Unternehmens-Kultur verändert die agile Software-Entwicklung

DevOps als Unternehmenskultur verändert die agile Softwareentwicklung

Nach einer Entwicklungsphase jeder Software geht die Anwendung im besten Fall in Produktion und wird eingesetzt und betrieben. DevOps ist eine Kombination der Wörter “Development” und “Operations” und vereint zwei organisatorisch voneinander getrennte IT-Bereiche: die Softwareentwicklung (Dev) und den IT-Betrieb (Ops).

Dadurch kann die Entwicklung hochqualitativer Anwendungen vorangetrieben und einen stabilen, zuverlässigen Betrieb gewährleistet werden.

Ziel von DevOps

DevOps ist hauptsächlich eine Unternehmenskultur und zielt darauf, die Bereiche der Entwicklung und des IT-Betriebs in der modernen Softwareentwicklung zusammenzubringen. Alle Prozesse, die die Entwicklung, den Betrieb und die Auslieferung von Software betreffen, müssen gegebenenfalls angepasst werden. Dies wird durch agile Entwicklungsprozesse (Development, Tests) vereinfacht, der Prozess der Softwareauslieferung (Delivery) wird dann mit aufgenommen.

Durch den DevOps-Ansatz werden Prozesse der Softwareentwicklung und des IT-Betriebs optimiert und automatisiert, damit Software schneller, effizienter und zuverlässiger erstellt, getestet und freigegeben werden kann.

Warum DevOps

Moderne Softwareentwicklung setzt immer mehr auf Agilität und ist bemüht, bestehende Systeme ständig zu optimieren.

Der Betrieb hat hingegen das Ziel, möglichst stabile Software, Infrastrukturen und   Systemlandschafen zu betreuen.        Somit    bleiben     beide     IT- Bereiche     oft isoliert  voneinander und jeweils auf   eigene   Ziele konzentriert. DevOps-Ansatz versucht, beide Bereiche zusammenzubringen,    um sowohl eine  schnelle und effiziente Entwicklung als          auch einen stabilen Betrieb zu   gewährleisten. Somit wird der komplette Lebenszyklus einer Softwarekomponente vom selben Team betreut, frei nach dem Motto:

You build it, you ship it, you run it”.

Bei DevOps geht es darum, eine Brücke zwischen traditionell isolierten Entwicklungs- und operationellen Teams zu schaffen. In diesem Modell arbeiten Entwicklungs- und Betriebsteams von der Entwicklung und dem Test über die Bereitstellung bis hin zum Betrieb zusammen.

DevOps Komponenten

DevOps gleicht einer “Endlosschleife”, die von der Softwareplanung, über Code-, Build-, Test- und Release-Phasen über die Bereitstellung, den Betrieb, die Überwachung und das Feedback wieder zurück zur Planung zurückführt.

Eine grundlegende DevOps-Praxis besteht darin, sehr häufige, aber kleine Updates inkrementeller Art durchzuführen.
Durch DevOps soll sich das komplette Projektteam gegenseitig unterstützen und Wissen und Erfahrungen über alle Teammitglieder geteilt werden. So sollen Wissensmonopole verhindert werden.
Zu den gängigen und beliebten DevOps-Methoden zählen Scrum, Kanban und Agile.

DevOps Praktiken
  • Fortlaufende Entwicklung: Planungs- und Codierungsphasen des Lebenszyklus
  • Kontinuierliche Prüfung: durch automatisierte Tests
  • Kontinuierliche Integration: Im Kern von kontinuierlicher Integration steht ein Versionsverwaltungssystem, um den Code zu organisieren, Änderungen zu verfolgen und automatisierte Tests zu ermöglichen.
  • Kontinuierliche Lieferung: Code-Updates sollten so oft wie möglich bereitgestellt werden, um das kontinuierliche Angebot optimal nutzen zu können. Durch die Freigabe von Codes in kleineren Blöcken werden Engpässe vermieden und ein stetiger, kontinuierlicher Integrations-Fluss gewährleistet.
  • Kontinuierliche Bereitstellung: automatische Freigabe von neuem oder geändertem Code in der Produktion. Dies bedarf robuste Test-Frameworks, um sicherzustellen, dass der neue Code fehlerfrei und bereit für die Produktion ist.
  • Kontinuierliche Überwachung: fortlaufende Überwachung des sich in der Produktion befindlichen Codes und zugrundeliegender Infrastruktur. Eine Benachrichtigung über Fehler oder Probleme führt zur Entwicklung zurück.
DevOps Vorteile
  • Schnelle Entwicklung
  • Schnelle Bereitstellung
  • Schnelle Reaktion auf Zwischenfälle
  • Lieferung qualitativ hochwertiger Software
  • Verbesserung der Zusammenarbeit und Kommunikation zwischen den Teams
  • Steigerung der Produktivität durch DevOps-Tools
  • Schnelle Problemlösung/Fehlerbehebung
  • Minimierung von Ausfallzeiten der Anwendung
DevOps – Open source softwares

Die gesamte Prozesskette läuft wie folgt ab:

  1. Entwickler pushen ihren Code in ein Repository
  2. Unittests werden ausgeführt
  3. Packaging + Build
  4. Automatisierte Integrationstests
  5. Releasemanagement
  6. Konfiguration
  7. Monitoring

 Mit den richtigen Tools kann der oben gezeigte Prozess automatisiert werden. In diesem Hinblick haben sich folgende Tools in vielen Unternehmen und Projekten bewährt:

  • Docker
  • Git
  • JUnit
  • Jenkins
  • Apache Maven
  • Selenium
Fazit

Das DevOps-Modell kommt mit einem Umdenken umher: der neue Prozess, der die Entwicklung und den Betrieb vereinen soll, muss erstmal in den Köpfen aller Teammitglieder ankommen. DevOps ermutigt Entwicklungs- und Betriebsteams, über die gesamte Anwendung hinweg, zusammenzuarbeiten. Der IT-Betrieb, der sich eher auf Stabilität der Software stützt und selten neue Deployments durchführt, muss großes Vertrauen im gesamten Prozess bringen, dass Entwicklung und Test ein stabiles Produkt liefern. Dadurch sind häufige Deployments kein Widerspruch zur Stabilität von Anwendungen. Ein weiterer Vorteil bei der Arbeit mit DevOps-Ansatz ist die Geschwindigkeit. Wenn Codeänderungen häufiger und mit geringem Risiko auf negative Auswirkungen auf andere Bereiche oder Komponenten bereitgestellt werden, lassen sich Innovationen dadurch schneller und einfacher realisieren.

Lesempfehlung: Infrastructure as Code

Lesempfehlung: Infrastructure as Code

Wir haben für Sie gelesen!

Lesetipps für Alle, die an Softwarearchitektur, Softwareentwicklung und IT-Projektmanagement interessiert sind.

Infrastructure as Code

Prinzipien, Praktiken und Patterns für eine cloudbasierte IT-Infrastruktur

2. Auflage

Kief Morris

Infrastructure as Code, Kief Morris

Server in der Cloud verwalten

Noch vor ein paar Jahren hielten viele Unternehmen und Banken die Nutzung von Private und Public Cloud Technologien und Infrastructure Automation Tools für ausgeschlossen – die eigenen Anforderungen seien zu komplex und das Unternehmen zu groß. Für Start-ups könnte es funktionieren – eventuell. Jetzt, 6 Jahre nach der 1. Auflage von Infrastructure as Code, sind wir inmitten des Zeitalters der Cloud angekommen. Große sowie eher konservative Unternehmen setzen immer mehr auf die „Cloud-first“ Strategie. Alternativ weichen Unternehmen auf dynamisch bereitgestellte Infrastrukturplattformen in ihren Rechenzentren aus. Wer die Möglichkeiten dieser Plattformen ignoriert, der verliert! Oder riskiert zumindest, dass der Zahn der Zeit immer weiter an der physischen Infrastruktur nagt und Fehler nur langsam und kostspielig behoben werden können.

Das Infrastructure-as-Code-Konzept ermöglicht dagegen die Automatisierung der Infrastruktur mithilfe von Ansätzen aus der Softwareentwicklung. Der Fokus liegt darauf, konsistente und wiederholbare Routinen für die Bereitstellung und Änderung von Systemen und deren Konfiguration zu erzeugen. Änderungen, die am Code vorgenommen werden, werden von der Automatisierung genutzt, um sie zu testen und auf Systeme anzuwenden. Somit ermöglicht das Infrastructure-as-Code-Konzept eine schnelle Bereitstellung von Infrastruktur bei Veränderung des Bedarfs von Rechenleistung.

Über den Autor

Der Autor, Kief Morris, ist Principal Cloud Technologist bei dem Technologie-Beratungsunternehmen thoughtworks. Er betreut und berät Unternehmen und Teams in diesem Cloud-Zeitalter hinsichtlich der passenden Technologien und Methoden. Themen wie Cloud, digitale Plattformen, Infrastructure Automation, DevOps und Continuous Delivery gehören also zu seinem täglichen Geschäft.

Über Infrastructure as Code

Mit dieser 2. Auflage von Infrastructure as Code verspricht Kief Morris ein praktisches Handbuch zu liefern, das Ihnen erklärt, wie Sie eine IT-Infrastruktur im Zeitalter der Cloud aufsetzen und managen. Genauer gesagt zeigt er, wie Sie mit Prinzipien, Praktiken und Patterns aus der Softwareentwicklung eine IT-Infrastruktur mithilfe von Technologien wie Cloud, Virtualisierung und Konfigurationsmanagement verwalten können. Die Magie besteht darin, mittels der Technologien die Infrastruktur von der Hardware zu entkoppeln, um sie dann in Code und Daten umzuwandeln.

Das erwartet Sie

  • Die Grundlagen: wie Infrastructure as Code mittels Tools und Technologien eingesetzt werden kann, um Cloud-basierte Plattformen aufzubauen
  • Die Arbeit mit Infrastructure Stacks: wie Sie kontinuierlich Änderungen an Infrastrukturressourcen definieren, bereitstellen und testen
  • Die Arbeit mit Servern und anderen Plattformen: Verwendung von Mustern für die Bereitstellung und Konfiguration von Servern und Clustern
  • Die Arbeit mit großen Systemen und Teams: aneignen von Workflows, Governance und Architekturmustern zur Erstellung und Verwaltung von Infrastrukturelementen

Dieses Buch darf in Ihren Bücherregalen nicht fehlen…

…wenn Sie in einem Bereich arbeiten, der daran beteiligt ist IT-Infrastrukturen aufzusetzen und zu betreiben:

^

Systemadministration

^

Softwareentwicklung

^

Softwarearchitektur

^

IT-Infrastrukturadministration

^

Technische Projektleitung

Infrastruktur, Container und Cloud Native (CLOUDINFRA)

Erleben Sie in Ihrem Umfeld derzeit den Übergang von einer zentralisierten hin zu einer verteilen IT? Dann wissen Sie sicherlich genauso wie wir, dass dabei eine Vielzahl von Prozessen entsteht und mit ihnen die Herausforderung, diese Fülle von kleinen Systemkomponenten für den Betrieb bereitzustellen. Um diese Herausforderung zu meistern, empfehlen wir Ihnen das 3-tägige Training „Infrastruktur, Container und Cloud Native (CLOUDINFRA)“. Die Teilnehmer erhalten umfassendes Wissen zu den Themen Cloud Native Architekturen, Container Application Design, Logging/Monitoring/Alerting, Container Native Storage und Möglichkeiten zur UI Integration.

Ebenso werden typische Konzepte aktueller Container Manager aufgezeigt und vermittelt, wie sich damit für größere Webanwendungen gängige Qualitätsanforderungen realisieren lassen. Auch Infrastructure as Code wird bei diesem Training im Rahmen der Grundlagen modernder Infrastrukturen und der Automatisierung als Konzept vorgestellt.

Dieses Training ist Teil des weltweit anerkannten Weiterbildungsprogramm „Certified Professional for Software Architecture (CPSA)“ des iSAQB. Für die Zertifizierung zum „Certified Professional for Software Architecture – Advanced Level (CPSA-A)“ sammeln Sie mit diesem Training die entsprechenden Credit Points: 20 CP Kompetenz in Technologie und 10 CP Kompetenz in Methodik. Das 3-tägige Training wird in der ITech Academy auf Deutsch (Online und Präsenz) und Englisch (Online) angeboten.

Besuchen Sie das 3-tägige „Infrastruktur, Container und Cloud Native (CLOUDINFRA)“ Training und sammeln Sie Credit Points für Ihre Zertifizierung zum „Certified Professional for Software Architecture – Advanced Level (CPSA-A)“!

 

CLOUDINFRA-ISAQB

Fazit zu Infrastructure as Code

Kief Morris lässt in sein Buch Erfahrungen aus seiner Arbeit mit Teams, die mit großen und komplexen Infrastrukturen zu kämpfen hatten und denen die Organisation und Arbeit mit Infrastrukturcode zu Beginn schwerfiel, einfließen. Infrastructure as Code ist kein Einsteigerwerk, aber ein gut geschriebenes Buch für Leute, die 1. Nicht vor Theorie zurückschrecken, denen 2. die behandelten Technologien nicht ganz neu sind und die 3. vertraut sind mit Softwareentwicklung und Konzepten wie Agile und Lean. Fans von Patterns und konzeptionellen Ansätzen für die Softwareentwicklung werden mit Infrastructure as Code auf ihre Kosten kommen.

Informiert bleiben über neue Lesetipps und Buchverlosungen

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)'

Anti Pattern: Golden Hammer

Anti Pattern: Golden Hammer

 „Wenn mein einziges Werkzeug ein Hammer ist, sieht jedes Problem wie ein Nagel aus.“ – Abraham Maslow

Beschreibung

Ein goldener Hammer ist eine Art Wunderwaffe, ein bevorzugter Lösungsweg oder ein beliebtes Produkt, mit dem das Team viel Erfahrung hat und der irrtümlich als universell anwendbar angesehen wird. Alternativen werden kaum betrachtet.

Auswirkungen

Das Problem hierbei ist, dass die Lösung oder das Produkt nur scheinbar zu den gegebenen Anforderungen passen.

Es kann unter Umständen passieren, dass das Produkt Teile des Designs oder der Erweiterbarkeit festlegt, indem z.B. nur Schnittstellen desselben Herstellers oder eines bestimmten Betriebssystems verwendet werden können. Der Einsatz einer bestimmten Lösung kann auch zu einer schlechteren Skalierbarkeit und Performanz führen als eine andere Lösung. Als Folge können die Kosten explodieren oder Termine nicht eingehalten werden.

Lösung

Hier ist ein Umdenken bei den Entwicklern und im Management erforderlich. Alternative Lösungsansätze und die hierbei entstehenden Vor- und Nachteile sollten ständig im Auge behalten werden. Es kann auch hilfreich sein, das Projektteam stärker zu diversifizieren, indem mehr Leute aus unterschiedlichen Firmen und anderen Fachgebieten eingestellt werden.

Eine Weiterbildung durch Fortbildungen, Seminare, Bücher etc. hilft dabei, die Entwickler immer auf dem neusten Stand der Entwicklung zu halten, nicht nur im Bereich der Softwaretechnologie, sondern auch auf Organisationsebene.

Bei unserer 3-tägigen Grundausbildung für Softwarearchitekten, dem Foundation Level Training, erhalten Sie das nötige Know How, um Architekturen für kleine und mittlere Systeme zu entwerfen und zu dokumentieren. Am Ende der Softwarearchitektur Schulung haben Sie das Rüstzeug, um problembezogene Entwurfsentscheidungen auf der Basis Ihrer vorab erworbenen Praxiserfahrungen zu treffen.

Entwicklerdokumentation mit PlantUML

Entwicklerdokumentation mit PlantUML

Bei einer unserer letzten Night Schools stellte ich eine neue Möglichkeit vor, auf entwicklungsnahe Art und Weise IT-Systeme zu dokumentieren. Die Night Schools sind unsere internen Weiterbildungsevents, bei der immer abwechselnd ein Kollege/eine Kollegin ein aktuelles Thema aus dem Softwarearchitektur Bereich für das Team aufbereitet und vorstellt.

Die Unified Modelling Language UML ist der aktuelle Standard zur Dokumentation von statischen Strukturen und dynamischen Abläufen in IT-Systemen.  Auch in der Architekturdokumentation wird UML oftmals eingesetzt.

UML hat aber durchaus seine Schattenseiten, da es häufig mit komplexen Modellierungs- oder Zeichenprogrammen à la VISIO erstellt wird. Das Ergebnis der Modellierung ist dann eine Reihe von Word- oder PDF-Dateien mit eingebetteten JPEG- oder PNG-Grafiken. Entwickler dagegen arbeiten mit Textdateien in einer Entwicklungsumgebung, die oftmals an eine komplexe Build-Pipeline angeschlossen ist und alle Arbeitsergebnisse auf Wunsch auch gleich versioniert und deployed. So kann jede Änderung über alle Versionen problemlos zurückverfolgt werden. Dieser Ansatz scheitert leider bei Office-Dateien, da hier jede neue Version einer Datei als gänzlich neues Artefakt behandelt wird. Es kommt bei der Modellierung mit UML nicht nur zu einem Medienbruch, sondern auch die Arbeitsergebnisse können nicht nahtlos in die Entwicklungspipeline aufgenommen werden. In diese Bresche springt nun Plant-UML.

Die Idee von Plant-UML ist, mit Hilfe von einfachen Textdateien, die eine bestimmte Plant-UML-Syntax verwenden, automatisiert UML-Diagramme zu erzeugen und als PNG, SVG oder ASCII-Art anzeigen zu lassen. Dies geschieht interaktiv, sodass der Autor per Knopfdruck gleich das Arbeitsergebnis sehen kann. Auf der Plant-UML Homepage kann dies ganz einfach kostenfrei selbst ausprobiert werden >> http://www.plantuml.com/plantuml/uml/. Unterstützt werden Anwendungsfalldiagramme, Klassendiagramme, Sequenzdiagramme, Aktivitätsdiagramme, State-Machines, Objektdiagramme, Deploymentdiagramme, Komponentendiagramme und Timing-Diagramme. Alle werden mit einer einfachen Syntax definiert und übernehmen das Layout der Objekte im Diagramm automatisch. Trotzdem kann eine ganze Reihe von zusätzlichen Items verwendet werden, um die UML-Diagramme noch aussagekräftiger zu gestalten. Dies geht von konfigurierbaren Farben bis hin zu Legenden und Infoboxen. Mir gefällt am besten, dass Plant-UML sich direkt in den Build-Prozess integrieren lässt und die UML-Diagramme nicht nur in ASCIIdoc-Dokumente eingefügt werden können, sondern diese sich auch bei jedem Build neu erzeugen. Damit wird eine Dokumentation erreicht, die genauso einfach und effektiv verwaltet werden kann wie der Quellcode selbst. Ein Medienbruch bleibt aus.

Neben den UML-Diagrammen kann Plant-UML aber noch mehr: Es ist möglich, Datenbanktabellen mittels Entity-Relationship-Diagrammen zu beschreiben, neue Ideen in Form von Mindmaps darzustellen und Arbeitspakete mit Hilfe von Work-Breakdown-Diagrammen (WBD) zu beschreiben. Es ist sogar möglich, Projektplanungen mittels Gantt-Diagrammen wie in MS Project zu erstellen. Alle diese Diagramme werden ebenso einfach mit Hilfe von Textschnipseln definiert. Der eigentliche Höhepunkt ist aus meiner Sicht aber die Möglichkeit, ein Wireframe einer Oberfläche aus einer Textdarstellung zu erstellen. Probieren Sie es doch einfach mal aus und teilen Sie Ihre Erfahrung mit uns über die Kommentare.

Axel Feix, Software Architekt & Managing Consultant bei ITech Progress

Anti Pattern: Reinvent the Wheel

Anti Pattern: Reinvent the Wheel

Alle guten Dinge sind drei! Es geht weiter in unserer Anti-Pattern Reihe, in der wir gängige Fehler aus der Softwaretechnik aufzeigen und Tipps geben, wie man sie zukünftig vermeidet beziehungsweise nachträglich behebt. Diesmal geht es darum wie man das Rad neu erfindet, beziehungsweise wie man es besser nicht macht, denn wer immer weiter dreht, dreht auch langsam durch.

Bei unserer 3-tägigen Grundausbildung für Softwarearchitekten, dem Foundation Level Training, bekommst du das nötige Know How, um von Anfang an gute und überschaubare Lösungsmuster zu entwickeln. Wer eine bestehende Architektur systematisch verbessern möchte, dem empfehlen wir unser Advanced Level Training IMPROVE – Evolution und Verbesserung von Softwarearchitekturen.

Beschreibung

Bevor man sprichwörtlich das Rad neu erfindet und beispielsweise auch nur eine Zeile Code selbst schreibt, sollte man sich erst genau umschauen, ob das nicht bereits jemand vor einem getan hat. Jedes neu erfundene Rad muss getestet, gewartet und dokumentiert werden und das kann den Aufwand und somit die Kosten gewaltig in die Höhe treiben.

Auswirkungen

In diesem Fall ist das Problem vieler Softwareentwicklungsprojekten, dass die Software meist von Grund auf entwickelt wird. Top-Down Analyse und Design führen dabei oft zu neuen Architekturen und Individualsoftware, ohne dass ein Entwickler sich nach bereits vorhandenen Bibliotheken umschaut.

Ein weiteres Problem sind mangelnde Kommunikation und Technologietransfer zwischen einzelnen Entwicklungsteams oder Abteilungen.

Lösung

Bevor man mit der Entwicklung anfängt, sollte man sich erst erkundigen, ob es bereits eine Bibliothek gibt, welche dem gewünschten Ziel schon sehr nahe kommt. Denn „es gibt eigentlich nichts, was es nicht schon gibt!“