Yearly Archives

2016

NG-BE 2016: Angular and React – Friends learning from each other

By | Publikationen, Vorträge | No Comments
„Angular and React – Friends learning from each other“

NG-BE 2016

React and Angular share a lot of architectural decisions and have inspired each other as well. They are both component oriented, have automated changed detection and can render both on the server as well as on the client side. However, there are also quite a few differences in how they work and which philosophy they follow. Based on advanced practical examples we will look at the most interesting differences between those two frameworks. This can help you understand your Angular framework even better and gives you insights into what strengths and what weaknesses it has in certain scenarios.

NG-BE Talk on Youtube

follow us on Twitter – @embarced

JUG Hamburg – Machine Learning / Deep Neural Networks mit Java

By | Publikationen, Vorträge | No Comments
„Machine Learning / Deep Neural Networks mit Java“
Logo JUG Hamburg

Machine Learning ist traditionell in der Domäne der Programmiersprache Python. Hier gibt es die meiste Vielfalt an Software und die besten Dokumentation. Das nützt einem aber nicht viel, wenn man aus dem einen oder anderen Grund in diesem Bereich auf Java angewiesen ist.

Anhand eines kleinen Beispiels werden wir uns ansehen, wie du auch mit Java Machine Learning mit Deep Neural Networks umsetzen kann. Dabei werden keine Vorkenntnisse im Bereich Machine Learning vorausgesetzt, wir beginnen mit einer allgemeinen Einführung.

Wer die Beispiele an seinem Laptop nachvollziehen will, bitte vorher klonen und installieren (Link zu Github)

Zur Veranstaltungsseite

follow us on Twitter – @embarced

jax_logo_2017

JAX 2017 – Schliemanns Erben und warum GraphQL?

By | Vorträge | No Comments

Im Mai sind wir auf der JAX 2017 in Mainz dabei. Stefan Zörner zeigt, wie Sie Systemlandschaften wirkungsvoll (nach-)dokumentieren und Oliver Zeigermann stellt zusammen mit Nils Hartmann die Frage: Warum GraphQL und nicht REST? Und es geht um die Frage ob TypeScript und Flow tatsächlich JavaScript für Java-Enwickler sind.

„Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren“
Logo W-Jax

Softwaresysteme wachsen historisch. Das gilt nicht als Idealzustand, aber so ist die Realität nun mal. Für Systemlandschaften gilt es erst recht. IT-Trendwellen schwappen über Unternehmen und hinterlassen ihre Spuren in den Anwendungen. Geglückte Würfe ebenso wie gescheiterte Initiativen.

(De-)Zentralisierung, Objektorientierung, SOA, Standardisierung, Cloud …manche Unternehmen haben Vermächtnisse (engl. Legacy) aus drei Jahrzehnten im Betrieb. In vielen Fällen wird das Wissen darum nur mündlich weitergegeben. Die Konsequenz: langwierige und lückenhafte Einarbeitung, Unsicherheiten bei Änderungen und Neuentwicklungen. Im Extremfall führt dies zu geringem Vertrauen bei Entscheidern. Dabei ist der Aufwand, das Wesentliche fest und aktuell zu halten, gar nicht groß.

In dieser Session zeige ich, wie ihr bestehende Systemlandschaften kartografiert und es allen Beteiligten leichter macht, sich zurechtzufinden und informierte Entscheidungen zu treffen. Mit Anlehnung an Methoden wie arc42 (das initial nur auf Einzelsysteme passt), Beispielen aus echten Ausgrabungen, aber ohne C14.

„TypeScript und Flow – JavaScript für Java-Entwickler?“
Logo W-Jax
TypeScript und Flow – JavaScript für Java-Entwickler?
Sprecher: Oliver Zeigermann
Vortrag auf der JAX 2017
Mittwoch – 10. Mai 2017, 16.45 – 17.45 Uhr
Rheingoldhalle Mainz

JavaScript ist die natürliche Wahl für die Entwicklung im Browser. Für größere Projekte ist JavaScript im Vergleich zu Java jedoch im Nachteil. TypeScript und Flow sind zwei unterschiedliche Ansätze zum Ausgleich der Nachteile. Flow ist ein statischer Typen-Checker. Er wurde von Facebook entwickelt, um in deren JavaScript- und insbesondere React-Code Fehler zu finden. Dazu können zusätzliche Typinformationen hinzugezogen werden. TypeScript ist eine Spracherweiterung von JavaScript, die durch den TypeScript-Compiler in unterschiedliche JavaScript-Versionen zurückübersetzt werden kann. Hier steht eher die Werkzeugunterstützung im Vordergrund. TypeScript wird aktiv von Microsoft entwickelt und ist die primäre Sprache für Googles Angular-2-Framework.

In diesem Talk werde ich in beide Ansätze einführen und die wesentlichen Gemeinsamkeiten und Unterschiede erläutern. Am Ende werden wir klären, ob TypeScript und/oder Flow tatsächlich JavaScript für Java-Enwickler sind.

„Warum GraphQL und nicht REST?“
Logo W-Jax
Warum GraphQL und nicht REST?
Sprecher: Nils Hartmann und Oliver Zeigermann
Vortrag auf der JAX 2017
Donnerstag – 11. Mai 2017, 12 – 13 Uhr
Rheingoldhalle Mainz

Facebook benutzt GraphQL seit Jahren als Schnittstelle für ihre mobilen Anwendungen. GitHub stellt ein neues HTTP-API auf Basis von GraphQL vor. Man kann GraphQL also nicht länger ignorieren. Aber was ist das denn eigentlich? Und warum ist das besser als unser heiliges REST? Ist es das überhaupt?

Dies werden wir in diesem Vortrag klären und auch gleich auf die weiterführenden Fragen eingehen. Darunter: Braucht man eine Implementierung, und wenn ja, welche? Wie bindet man seine eigenen Systeme ein? Welche Art von Query kann man bedienen? Gibt es API-Explorer?

Zur Veranstaltung

IT-Tage 2016: Wie werde ich ihn los – in 10 Tagen? Vom Monolithen zu Microservices…

By | Publikationen, Vorträge | No Comments
„Wie werde ich ihn los – in 10 Tagen? Vom Monolithen zu Microservices…“
Logo IT Tage
Wie werde ich ihn los – in 10 Tagen? Vom Monolithen zu Microservices…
Sprecher: Harm Gnoyke
Vortrag auf den IT-Tagen 2016
Mittwoch, 14. Dezember 2016, 12 – 12.45 Uhr (Saal Maritim I)
Maritim Hotel, Theodor-Heuss-Allee 3, Messe / Frankfurt am Main

Folien Download (PDF)

Viele Projektteams sind eine langjährige Beziehung mit einem Monolithen eingegangen – auch wenn Sie diese Entscheidung gar nicht selbst getroffen haben – und sind mit dieser Situation unglücklich. Mittlerweile gibt es viele große Microservice-Systeme, die ungleich attraktiver erscheinen: Entwickeln in unabhängigen Teams, evtl. sogar mit verschiedenen Technologien, einfaches Austauschen einzelner Services, beliebige Skalierbarkeit sind die bekanntesten Vorteile. Doch wie verabschieden Sie sich möglichst elegant von Ihrem Monolithen und wechseln zu einem Microservice-System?

In diesem Vortrag diskutieren wir zunächst die Beweggründe für einen Wechsel. Ist die Entscheidung gefallen, steht der Umzug an: Was lassen Sie zurück und was nehmen Sie mit ins neue Microservice-System? Wir zeigen eine schrittweise Ablösestrategie und weisen auf typische Stolperfallen hin. Als Abschluss zeigen wir wie sich der Umzug auf die Test-Strategien auswirkt. Insbesondere dort tickt der Neue nämlich anders…

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

Breakout Session auf dem Technical Summit 2016 in Darmstadt

By | Publikationen, Vorträge | No Comments
„Getyptes JavaScript mit TypeScript und Flow“
Technical Summit 2016
Getyptes JavaScript mit TypeScript und Flow
Sprecher: Oliver Zeigermann
Technical Summit 2016
06. Dezember 2016, 17 – 18 Uhr
darmstadtium, Schlossgraben 1, 64283 Darmstadt

Folien Download (github)

JavaScript ist die natürliche Wahl für die Entwicklung im Browser. Für größere Projekte ist JavaScript im Vergleich zu C# oder Java jedoch im Nachteil. TypeScript und Flow sind zwei unterschiedliche Ansätze zum Ausgleich der Nachteile.
Flow ist ein statischer Typen-Checker. Er wurde von Facebook entwickelt, um in deren JavaScript- und insbesondere React-Code Fehler zu finden. Dazu können zusätzliche Typeninformationen hinzugezogen werden.

TypeScript ist eine Spracherweiterung von JavaScript, die durch den TypeScript-Compiler in unterschiedliche JavaScript-Versionen zurückübersetzt werden kann. Hier steht eher die Werkzeug-Unterstützung im Vordergrund. TypeScript wird aktiv von Microsoft entwickelt und ist die primäre Sprache für Googles Angular 2 Framework.

In diesem Talk gibt Oliver Zeigermann eine Einführung in beide Ansätze, erläutert die wesentlichen Gemeinsamkeiten und Unterschiede und zeigt auf, welcher Ansatz wann sinnvoll ist.

Download Vortragsfolien (github)

follow us on Twitter – @embarced

Drei Dinge, die mich bei Architekturdiagrammen mit plantUML nerv(t)en

By | Allgemein, Inhaltliches | 8 Comments

plantIch sehe bei Kunden ab und an plantUML im Einsatz. Und noch häufiger fragen mich Teilnehmer in Workshops, was ich von plantUML halte, wenn es um Diagramme in der Dokumentation von Softwarearchitektur geht. Beispielsweise in den betreffenden Abschnitten von arc42 (Konkret: Kontextabgrenzung, Bausteinsicht, Laufzeitsicht …).

Um ehrlich zu sein fand ich plantUML dafür lange Zeit nicht so toll. Aus verschiedenen Gründen. Bei näherem Hinsehen ließ sich einiges davon aber auf Unkenntnis und Vorurteile meinerseits zurückführen. Und einige Unschönheiten lassen sich mit den richtigen Kniffs und Workarounds umgehen. Ein paar kleine Erkenntnisse zeige ich im Rahmen dieses Beitrags. Und beginne so meinen Frieden zu machen mit dem Werkzeug.

Aber zuvor: Was ist dieses plantUML überhaupt (für diejenigen, die es nicht kennen) und warum finde ich es (immernoch) nicht ganz so toll wie manche meiner Kunden?

plantUML

plantUML generiert UML-Diagramme als Graphik aus textuellen Beschreibungen. Die Syntax dazu ist recht einfach gehalten und schnell erlernt. Hier ein Minibeispiel. Aus der Eingabe links generiert plantUML das Diagramm rechts.cd_schach

@startuml

Schachbrett -> Figur 
Figur --> Farbe
Figur --> enum Art

enum Farbe { 
 SCHWARZ 
 WEISS
}

@enduml

 

Neben den besonders gut unterstützen Klassendiagrammen (wie im Beispiel oben, Details zur Syntax siehe hier) kann plantUML auch andere Diagrammarten der UML generieren (Sequenzdiagramme, Anwendungsfalldiagramme …).

plantUML ist Open Source, in Java geschrieben und leicht integrierbar. Entsprechend gibt es zum Beispiel Plugins für verschiedene Textsysteme (z.B. Asciidoctor), Build-Werkzeuge (z.B. Gradle) und Wikis (z.B. XWiki und Confluence). Gerade in diesen Fällen passt das Text-Format von plantUML sehr gut, fühlt es sich doch in der Versionsverwaltung ebenso wohl wie zwischen Wiki-Markup.

In der Regel nimmt der Autor beim Erstellen kaum Einfluss auf das Layout seiner Diagramme. Ich sehe das als Vorteil, kostet das Kästchenschubsen in graphischen Editoren bei Änderungen doch oftmals viel Zeit.

Drei Dinge, die ich an plantUML nicht mag

Trotz der unbestrittenen positiven Merkmale gibt es Dinge, die mir bei plantUML nicht so gut gefallen. Hier drei aus meiner Sicht besonders gewichtige:

  1. Der Technologie-Stack ist fragil
  2. Für Softwarearchitektur relevante Diagramme fehlen
  3. Die generierten Diagramme sehen altbacken aus

Der Technologie-Stack ist fragil

plantUML ist in Java geschrieben, der Download lediglich ein jar-File. Tatsächlich handelt es sich bei bei dem Tool aber eher um ein Frontend (oder wenn man mag einen Präprozessor) für das Werkzeug Graphviz.

binaryGraphviz ist eine leistungsfähige und recht verbreitete Open Source-Lösung zum Visualisieren von Graphen (also Knoten verbunden durch Kanten). Anders als plantUML wird es Betriebssystem-spezifisch als Binary installiert. Es muss lokal vorliegen (konkret: das Graphviz-Executable „dot“). plantUML greift darauf zu, es verwandelt die plantUML-Eingabe in eine Eingabe in der DOT-Sprache und lässt dann Graphviz die ganze Arbeit machen („Zwerge auf den Schultern von Riesen“).

Das Problem dabei: das Zusammenspiel zwischen plantUML und dot führt regelmäßig zu Reibung. Auch eine saubere Graphviz-Installation verweigert schon mal die Arbeit und führt zu Fehlermeldungen, lustigerweise in Form einer Graphik anstelle des erhofften Ergebnisses. Sieht dann zum Beispiel so aus:

Fehler beim Aufruf von not / Graphviz

In der Praxis heißt das etwa für ein Java-Projekt, das seine Architekturdokumentation in den Build integrieren will, dass es höhere Anforderungen an das Build-System stellt. Also an alle, die das Projekt bauen wollen. Java installieren reicht nicht (wie bei Gradle durch den Wrapper eigentlich üblich), es muss auch noch Graphviz da sein und mit plantUML zusammenspielen.  Das berühmte „It Works on My Machine“ war doch eigentlich überwunden (OK, die Pest ist schlussendlich auch noch nicht ausgestorben). Auch entsprechende Beiträge der Plugin-Benutzer in den Foren von XWiki und Confluence singen ein Lied von dem Problem.

Für Softwarearchitektur relevante Diagramme fehlen

plantUML unterstützt verschiedene Diagrammarten der UML, und die wiederum verschiedenen gut. Bei Klassendiagrammen geht mit Abstand am meisten. Gerade diese Diegrammart benötige ich allerdings in einem Architekturüberblick eher selten, bestenfalls für ein grobes Domänenmodell.

struktur_kleinBesonders wichtig sind mir methodisch gesehen die Kontextabgrenzung (Kapitel 3 in arc42, bzw. der Abschnitt „Context“ bei Simon Brown) und die statische Zerlegung (Kapitel 5 „Bausteinsicht“ in arc42). Eine Kontextabgrenzung lässt sich mit plantUML ganz gut visualisieren übrigens. Meine favorisierte Darstellung von Zerlegungshierarchien mit den Ports der Kompositionsstrukturdiagramme unterstützt plantUML leider nicht. Strukturen lassen sich zwar mit gruppierenden Elementen abbilden; Interaktionspunkte auf der „Membran“ (Ports, siehe kleine Skizze links) gehen hingehen nicht.

Die Diagramme sehen altbacken aus

Geschmäcker sind verschiedenen, mir persönlich gefällt die Darstellung von plantUML tatsächlich nicht sonderlich. Die Buchstaben-Icons bei Klassen, Aufzählungen etc. (E, C, … siehe Schach-Beispiel oben)  sind nicht mein Fall, und vor allem:  Die Farben (gelbe Kästen, rote Linien) haben die Anmutung alter Rational-Werkzeuge (kleine Zeitreise, Video). Die Zeit wünsche ich mir nicht zurück. Den Retro-Look der 90er-Jahre komplett machen dann Komponenten im Stil der UML 1. Als Beispiel hier ein rudimentärer Systemkontext (System mit einem Benutzer als Akteur) in plantUML, rechts wieder das resultierende Diagramm (das System als Komponente in UML 1-Notation):

@startumlsc_altbacken
[Webshop] <<system>>
:Kunde: - Webshop
@enduml

Auf Diagramme mit dieser Anmutung stolpere ich regelmäßig in Projekten. Dass mir die nicht übermäßig gefallen ist mein Problem, wenn die Teams es so mögen … Mein Problem könnt Ihr gleichzeitig beheben, bei plantUML läßt sich nämlich so ziemlich jede Stileigenschaft (Fonts, Farben, Strichbreiten …) konfigurieren. Aber wer hat da schon Lust zu? Der Aufwand mit all den Schaltern schreckt erstmal ab.

Die gute Nachricht: Es gibt recht große Schalter — Hebel sozusagen — welche mit wenig Aufwand viel Wirkung zeigen. Für das Beispiel oben reichen zwei dieser wirkmächtigen Hebel, und es sieht für mich deutlich passabler aus (siehe wieder Graphik rechts):

@startumlsc_modern
skinparam monochrome true
skinparam componentStyle uml2

[Webshop] <<system>>
:Kunde: - Webshop
@enduml

Das gefällt mir richtig gut schon. Derartige Skin-Parameter lassen sich übrigens auch in Dateien auslagern, von aussen in den plantUML-Prozessor reinreichen, etc. — So verschmutzen sie auch nicht alle plantUML-Quelltexte.

Fazit

Der Ansatz, aus text-basierten Beschreibungen Graphiken/Diagramme zu generieren, hat viel für sich. In vielen Fällen nutzen Teams ein Wiki oder Text-Systeme wie Asciidoc, um ihre Architekturdokumentation festzuhalten. Die Frage, wo die Diagramme herkommen, stellt sich dort stets, und plantUML ist zumindest eine Option. Mit wenigen Kniffen finde ich die Ausgabe zumindest optisch passabel, eine große Herausforderung bleibt das fragile Zusammenspiel mit Graphviz.

Ich spiele mit dem Gedanken hier ein geschlossenes Fallbeispiel bereitzustellen. Einen Architekturüberblick, in dem die Diagramme mit plantUML generiert sind, und dessen Inhalte sich an den Sichten von arc42 orientieren. Fänden Sie das interessant?

Getyptes JavaScript mit TypeScript und Flow – Oliver Zeigermann beim Nordic Coding Meetup in Kiel

By | Publikationen, Vorträge | No Comments
„Getyptes JavaScript mit TypeScript und Flow“
Logo Nordic Coding Meetup
Getyptes JavaScript mit TypeScript und Flow
Sprecher: Oliver Zeigermann
Meetup Nordic Coding, Kiel
17. November 2016, 17 Uhr
Wissenschaftszentrum Kiel GmbH, Fraunhoferstrasse 13, Kiel

Folien Download (github)

JavaScript ist die natürliche Wahl für die Entwicklung im Browser. Für größere Projekte ist JavaScript im Vergleich zu C# oder Java jedoch im Nachteil. TypeScript und Flow sind zwei unterschiedliche Ansätze zum Ausgleich der Nachteile.
Flow ist ein statischer Typen-Checker. Er wurde von Facebook entwickelt, um in deren JavaScript- und insbesondere React-Code Fehler zu finden. Dazu können zusätzliche Typeninformationen hinzugezogen werden.

TypeScript ist eine Spracherweiterung von JavaScript, die durch den TypeScript-Compiler in unterschiedliche JavaScript-Versionen zurückübersetzt werden kann. Hier steht eher die Werkzeug-Unterstützung im Vordergrund. TypeScript wird aktiv von Microsoft entwickelt und ist die primäre Sprache für Googles Angular 2 Framework.

In diesem Talk gibt Oliver Zeigermann eine Einführung in beide Ansätze, erläutert die wesentlichen Gemeinsamkeiten und Unterschiede und zeigt auf, welcher Ansatz wann sinnvoll ist.

Download Vortragsfolien (github)

follow us on Twitter – @embarced

SAS_preview_logo

Architektur Kata Live und Diagramme der Moderne – beim Software Architecture Summit

By | Publikationen, Vorträge | No Comments

Im März sind Stefan Toth und Stefan Zörner mit zwei Halbtagsworkshops beim Software Architecture Summit in München mit dabei.

„Architektur Kata Live“
Logo Software Architecture Summit
 
Architektur Kata Live
Sprecher: Stefan Toth
Halbtagsworkshop auf dem Software Architecture Summit, München
Dienstag, 14. März 2017, 10 – 13 Uhr
Novotel München Messe, Willy-Brandt-Platz 1, 81829 München Riem

Was ist Ihrer Meinung nach wichtig, um als Sportler Erfolg zu haben? Genetische Veranlagung? Talent? Geld? Glück? Je nach Sportart werden diese Dinge mehr oder weniger Einfluss haben, fest steht jedoch: Alle Sportler trainieren und steigern ihre Leistungsfähigkeit zwischen den Wettkämpfen. Auch Tänzer, Moderatoren oder Musiker bereiten sich professionell auf ihre Aufgaben vor – sie tanzen, machen Sprechübungen, lernen oder proben. In diesem Workshop wird diese Professionalität auf Softwarearchitektur übertragen. In sogenannten „Kata“ bekommen Sie die Möglichkeit Systeme zu entwerfen und technisch relevante Fertigkeiten einzusetzen. Wiederholt, abwechslungsreich und im Vergleich mit anderen. Wir werden unterschiedliche Application und Architecture Kata durchspielen, Lösungen reflektieren und so auch wichtige Zusammenhänge zwischen Architekturtreibern, Basisarchitekturen und technischen Entscheidungen beleuchten. Ziel ist es relevante und aktuelle Architekturthemen aufzugreifen und Ihnen neue methodische und technologische Impulse mitzugeben.

„Diagramme der Moderne – Softwarearchitektur zeitgemäß visualisieren“
Logo Software Architecture Summit
 
Diagramme der Moderne – Softwarearchitektur zeitgemäß visualisieren
Sprecher: Stefan Zörner
Halbtagsworkshop Software Architecture Summit, München
Mittwoch, 15. März 2017, 10 – 13 Uhr
Novotel München Messe, Willy-Brandt-Platz 1, 81829 München Riem

Die Kommunikation zentraler Architekturideen im Team und gegenüber anderen ist heute wichtiger denn je. Visualisierungen können dabei unterstützen, tun es aber nicht automatisch. In diesem Workshop vermittle ich Erfolgsfaktoren, um mit angemessenem Aufwand wirkungsvolle Abbildungen Ihrer Softwarearchitektur zu erstellen und zu pflegen. Zur Sprache kommen Notationsoptionen, empfohlene Werkzeuge und Vorgehen. Der dicht gepackte halbe Tag liefert Ihnen Checklisten, Tipps, Tricks und Hinweise zu häufigen Fehlern aus der Praxis. Das Gelernte üben die Teilnehmer direkt in kleinen, fokussierten Übungen.

zur Website der Veranstaltung

follow us on Twitter – @embarced

Vortrag W-JAX 2016: Wie Microservices-Ansätze scheitern – fünf Antipatterns

By | Publikationen, Vorträge | No Comments
„Wie Microservices-Ansätze scheitern – fünf Antipatterns“
Logo W-Jax
Wie Microservices-Ansätze scheitern – fünf Antipatterns
Sprecher: Stefan Toth
Vortrag auf der W-JAX 2016
10. November 2016 um 12:00 – 13:00 Uhr (Raum: Ballsaal)
The Westin Grand München, Arabellastrasse 6

Download Vortragsfolien (PDF)

Microservices sind in aller Munde, und immer mehr Initiativen widmen sich dem Thema. Es wird ausprobiert, konzipiert, „refactored“ und neu aufgesetzt. Manche „haben es schon lange so gemacht“ und haben zumindest einen coolen Namen für ihren Architekturstil bekommen. Doch bei all der Breitenwirkung: Microservices sind nicht einfach umzusetzen. Häufig werden technische oder konzeptionelle Fehler gemacht. Manchmal so gravierend, dass die erkauften Vorteile nicht zur Wirkung kommen oder der Ansatz gänzlich scheitert. In dieser Session werden fünf häufig anzutreffende Antipatterns vorgestellt und ihre Auswirkungen besprochen.

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

Vortrag W-JAX 2016: Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren

By | Publikationen, Vorträge | No Comments
„Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren“
Logo W-Jax
Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren
Sprecher: Stefan Zörner
Vortrag auf der W-JAX 2016
10. November 2016 um 10:45 – 11:45 Uhr (Raum: Garmisch)
The Westin Grand München, Arabellastrasse 6

Download Vortragsfolien (PDF)

Softwaresysteme wachsen historisch. Das gilt nicht als Idealzustand, aber so ist die Realität nun mal. Für Systemlandschaften gilt es erst recht. IT-Trendwellen schwappen über Unternehmen und hinterlassen ihre Spuren in den Anwendungen. Geglückte Würfe ebenso wie gescheiterte Initiativen.

(De-)Zentralisierung, Objektorientierung, SOA, Standardisierung, Cloud …manche Unternehmen haben Vermächtnisse (engl. Legacy) aus drei Jahrzehnten im Betrieb. In vielen Fällen wird das Wissen darum nur mündlich weitergegeben. Die Konsequenz: langwierige und lückenhafte Einarbeitung, Unsicherheiten bei Änderungen und Neuentwicklungen. Im Extremfall führt dies zu geringem Vertrauen bei Entscheidern. Dabei ist der Aufwand, das Wesentliche fest und aktuell zu halten, gar nicht groß.

In dieser Session zeige ich, wie ihr bestehende Systemlandschaften kartografiert und es allen Beteiligten leichter macht, sich zurechtzufinden und informierte Entscheidungen zu treffen. Mit Anlehnung an Methoden wie arc42 (das initial nur auf Einzelsysteme passt), Beispielen aus echten Ausgrabungen, aber ohne C14.

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced