As an innoQ fellow, Gernot participates in the strategic development of the company’s consulting and implementation products. He supports clients as a consultant for software architecture in general and documentation in particular.
Darf ich Ihnen VENOM vorstellen – ein eCommerce-System für ziemlich komplizierte Produkte (Komplettausstattung von Supermärkten, Gartenplanung, Regal- und Möbelplanung und ähnlich abgefahrene Dinge) – inklusive kompletter Logistik, Lieferung, Verzollung, Aufbau, Abnahme, Inbetriebnahme… nennen wir es “very normal system”. Das System ist historisch/hysterisch gewachsen, wird von einer zerfahrenen, ziemlich desolaten Firma (SAMM Inc.) entwickelt und betrieben und drohte vor einiger Zeit, “den Bach hinunter” zu gehen. SAMM Inc. zog die Reißleine, und beauftragte ein (agiles) Team damit, die Rettung von VENOM (und SAMM) vorzubereiten und durchzuführen – “Succeed or die”, hieß die Devise. Diese (völlig fiktive) Situation ist in Wirklichkeit völlig real: Hören Sie über “rise and fall of the system”, sehen Sie die Auswirkungen desaströser Architekturarbeit und verkorkster Entwicklungs- und Betriebsprozesse.
Erleben Sie anschließend, wie methodische Verbesserung von Software funktionieren kann, die Rettung von VENOM: Von der systematischen Architekturbewertung über die Entwicklung angemessener Verbesserungsmaßnahmen bis hin zur effektiven Umsetzung zeige ich auf, wie Modernisierung und Evolution sich mit Projektalltag und Feature-Druck vereinbaren lässt.
Disclaimer: Eventuelle Ähnlichkeiten mit realen Softwaresystemen und Entwicklungsorganisationen wären rein zufällig – obwohl ich diverse der hier geschilderten Situationen selbst erleben durfte oder erleiden musste.
Darf ich Ihnen VENOM vorstellen – ein E-Commerce-System für ziemlich komplizierte Produkte (Komplettausstattung von Supermärkten, Gartenplanung, Regal- und Möbelplanung und ähnliche abgefahrene Dinge) inklusive kompletter Logistik, Lieferung, Verzollung, Aufbau, Abnahme, Inbetriebnahme, nennen wir es „very normal system“.
Das System ist historisch/hysterisch gewachsen, wird von einer zerfahrenen, ziemlich desolaten Firma (SAMM Inc.) entwickelt und betrieben und drohte vor einiger Zeit, „den Bach herunter“ zu gehen. SAMM Inc. zog die Reißleine und beauftragte ein (agiles) Team damit, die Rettung von VENOM (und SAMM) vorzubereiten und durchzuführen – „Succeed or die“ hieß die Devise.
Diese (völlig fiktive) Situation ist in Wirklichkeit völlig real: Hören Sie über „rise and fall of the system“, sehen Sie die Auswirkungen desaströser Architekturarbeit und verkorkster Entwicklungs- und Betriebsprozesse.
Erleben Sie anschließend, wie methodische Verbesserung von Software funktionieren kann, die Rettung von VENOM: Von der systematischen Architekturbewertung über die Entwicklung angemessener Verbesserungsmaßnahmen bis hin zur effektiven Umsetzung zeige ich auf, wie Modernisierung und Evolution sich mit Projektalltag und Featuredruck vereinbaren lassen.
Disclaimer: Eventuelle Ähnlichkeiten mit realen Softwaresystemen und Entwicklungsorganisationen wären rein zufällig – obwohl ich diverse der hier geschilderten Situationen selbst erleben durfte oder erleiden musste.
Software Architecture Summit Berlin 201719. September 2017
Lernen Sie VENOM kennen, ein großes und über mehrere Jahre lang auch erfolgreiches IT-System. Hören Sie Erfolgsberichte begeisterter Anwender und Trauerreden beteiligter Entwicklerinnen, Horrorgeschichten aus Betrieb und Support. Die Protagonisten dieses Systems sind zufriedene und erschrockene Benutzer, motivierte, engagierte und frustrierte Entwickler, scham- und rücksichtslose, effektive und chaotische Manager, Admins und Betreiber und andere.
VENOM stößt an vielerlei Grenzen, das Management wechselt häufig die Fahrtrichtung, das Entwicklungsteam alterniert zwischen Stress, Depression und Euphorie.
Das Management beauftragt „Verbesserung“ – und dann erleben Sie, wie’s gehen kann. Soviel sei verraten: Nicht jeder Ansatz führt zu Erfolg – und manches drohende Desaster kann sich dann doch noch zum Positiven wenden. Außerdem sollen Vollbremsungen bei hoher Geschwindigkeit schon so manches Vehikel vor der Kollision mit der (harten) Wand bewahrt haben.
Das hier beschriebene VENOM-System (für very normal system) ist einerseits völlig fiktiv, aber andererseits basieren viele der zugrunde liegenden Entscheidungen, Strukturen und Konzepte maßgeblich auf real existierenden Systemen. Die Verbesserungsansätze, die Sie erleben werden, entstammen sämtlich der Realität.
Software Architecture Summit Berlin 201718. September 2017
Anhand eines großen Systems zeigen Ralf und Gernot, wie Sie mit ziemlich wenig Aufwand angemessene und vernünftige Dokumentation für unterschiedliche Stakeholder produzieren – sodass Entwicklungsteams dabei auch noch Spaß haben.
Das Rezept: AsciiDoc mit arc42 mischen, Automatisierung mit Gradle und Maven hinzufügen und bei Bedarf mit PowerPoint, Grafik- oder Modellierungstools Ihrer Wahl kombinieren – schon bekommen Sie schicke HTML- und PDF-Dokumente generiert, auf Wunsch auch Confluence und docx als Zugabe.
Wir zeigen, wie Sie Doku genau wie Quellcode verwalten können, stakeholderspezifische Dokumente erzeugen und Diagramme automatisiert integrieren können.
Zwischendurch bekommen Sie zahlreiche Tipps, wie und wo Sie systematisch den Aufwand für Dokumentation reduzieren können, geschickt Aufgaben im Team verteilen und ganz nebenbei lesbare, verständliche und praxistaugliche Ergebnisse produzieren. Zum Schluss zeigen wir, wie Sie Teile dieser Doku automatisiert testen können.
Unser “ganz normales System” (VENOM, "very normal system“) unterstützt eCommerce-Prozesse für ziemlich komplizierte Produkte (Komplettausstattung von Kaufhäusern und Apotheken, Gartenplanung, Regal- und Möbelplanung und ähnliche abgefahrene Dinge) - inklusive kompletter Lieferung, Verzollung, Aufbau, Abnahme, Inbetriebnahme….
Das System, über viele Jahre eher hysterisch als historisch gewachsen, wird von einer ziemlich desolaten organisierten Firma (SAMM Inc.) entwickelt und betrieben. Es drohte vor einiger Zeit, „den Bach herunter“ zu gehen. SAMM Inc. zog die Reißleine, und beauftragte ein (agiles) Team damit, die Rettung von VENOM (und SAMM) vorzubereiten und durchzuführen - „Succeed or die", hieß die Devise.
Diese (überaus fiktive) Situation ist in Wirklichkeit völlig real. Lernen Sie „rise and fall of a system“ aus der Nähe kennen, sehen Sie die Auswirkungen desaströser Architekturarbeit sowie verkorkster Entwicklungs- und Betriebsprozesse. Und dann - erfahren Sie von Maßnahmen, die wirklich helfen könnten (oder auch nicht) - und sehen Sie (am realen Beispiel), wie methodische Verbesserung von Software(architektur) funktionieren kann.
Disclaimer: Ähnlichkeit mit real existierenden Unternehmen ist rein zufällig.
Das bewährte arc42 Template ist gerade in Version 7 erschienen - mit deutlichen Erweiterungen im Ökosystem. Grundsätzlich bleibt arc42 V7 kompatibel mit den Vorgängerversionen, ist insgesamt noch kompakter und pragmatischer geworden.
Es ist ein bekanntes Phänomen: Obwohl zu Beginn beim Entwickeln des Projekts alles sauber und ordentlich zuging, degeneriert das System mit der Zeit – das Phänomen der „verfaulenden Software“ schlägt zu. Änderungen werden dann immer riskanter, schwieriger und langwieriger. In der Entwicklung und im Betrieb mehren sich die Probleme, die zu beheben immer mehr Zeit in Anspruch nimmt. Gleichzeitig steigen aber auch Änderungs- und Betriebskosten, während die Zufriedenheit von Entwicklern, (fachlichen) Auftraggebern, Testern, Administratoren und anderen Beteiligen ständig abnimmt. Vermutlich kennt jeder Leser diese Situation: Willkommen in der Legacy-Hölle.
The term architecture is used with slightly different meanings throughout the IT industry. This post clarifies what (software) architecture is all about - and which misunderstandings might linger on your way to common understanding.
Auf heise Developer wird das neue Buch „arc42 in Aktion: Praktische Tipps zur Architekturdokumentation“ von Gernot Starke und Peter Hruschka besprochen. In diesem Buch werden zahlreiche konkrete Tipps zur Nutzung dieses Dokumentations-Template geboten.
Seit über zehn Jahren gibt es arc42, die pragmatische Vorlage/Arbeitshilfe für Architekturdokumentation. Im diesem Vortrag von der W-JAX 2015 stellt Gernot Starke diverse Optionen für den Praxiseinsatz von arc42 vor - von Werkzeugen bis hin zur Organisation von Dokumentation im Projekt.
Anhand von Beispielen wird gezeigt, wie Architektur- und Codedokumentation zusammenspielen und wie eine pragmatische und nützliche (technische) Projektdokumentation aufgesetzt werden kann. Insbesondere sehen Sie textbasierte (AsciiDoc-)Dokumentation im Zusammenspiel mit Modellierungswerkzeugen wie Enterprise Architect und Visual Paradigm im Einsatz - und wie das zusammen mit Git auch entwicklerfreundlich funktioniert.
