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!“

Anti Pattern: Lava Flow

Anti Pattern: Lava Flow

Endlich ist er da! Der zweite Beitrag 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 etwas heißer zu, denn wir reden über Lava…genauer gesagt über Lava Flow!

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

Man spricht von einem Lava Flow, wenn sich im Laufe der Zeit immer mehr toter Code in einer Anwendung anhäuft, der eigentlich nicht mehr oder kaum noch gebraucht wird. Dieser tote Code zieht sich dann wie zähe Lava durch das System.

Auswirkungen

Dieser „tote Code“ steigert die Komplexität der Anwendung und kann dazu führen, dass irgendwann niemand mehr weiß, welche Codefragmente wie bereinigt werden können. Obendrein kann dieser Code wertvolle Ressourcen verschwenden und sich negativ auf die Performance auswirken.

Typische Merkmale eines Lava Flows sind undokumentierte,  „wichtig aussehende“ Methoden oder Klassen, deren eigentliche Funktion nicht ersichtlich sind, oder Stellen im Code mit Hinweisen wie z.B. „to be replaced“.

Lösung

Der beste Weg zur Vermeidung von Lava Flow ist eine klare Architektur, die vor Beginn der eigentlichen Implementierung entworfen und in einem Configuration Management Process gesichert werden sollte. Das Configuration Management gibt Informationen über verschiedene Versionen und verwendete Tools und dokumentiert Änderungen und deren Auswirkungen auf andere Programmteile.

Hilfreich können auch Tools zur Abhängigkeitsanalyse sein, wie z.B. JarAnalyzer oder JDepend, die statische Abhängigkeiten zwischen Java-Klassen ermitteln.