Category

Artikel

Artikel Java Magazin: Zeitgemäße Softwarearchitektur, Teil 1: Beschränkte Mittel

By | Artikel, Publikationen | No Comments
„Zeitgemäße Softwarearchitektur, Teil 1: Beschränkte Mittel“

Zeitgemäße Softwarearchitektur, Teil 1: Beschränkte Mittel
Autor: Stefan Toth
Artikel im Java Magazin, 05/2014, 7 Seiten, ab S.36
Erschienen 02. April 2014

Haben Sie schon einmal erklärt bekommen wie das mit der Softwarearchitektur richtig funktioniert? Haben Sie schon mal ein Buch gelesen und gedacht: So müssten wir mal arbeiten? Bei mir war beides öfter der Fall und am Ende hat der Projektalltag alles zu Nichte gemacht: Kein Geld, keine Zeit, die falschen Leute oder zu viel „Legacy“. Arbeit an der Softwarearchitektur findet (leider) selten ideale Voraussetzungen. Eine moderne Disziplin muss deshalb mit der Unvollkommenheit unserer Projekte zurecht kommen. Ein Schlüssel dazu: der Umgang mit beschränkten Mitteln…

Artikel im OBJEKTspektrum: TOGAF im Nussschälchen

By | Artikel, Publikationen | No Comments
„Ein Einstieg in das Architekturframework der Open Group“

TOGAF im Nussschälchen: Ein Einstieg in das Architekturframework der Open Group
Autor: Stefan Toth
Artikel im OBJEKTspektrum, 02/2014, 6 Seiten ab S.46
Erschienen 28. Februar 2014

IT-Unternehmensarchitektur ist eine breite Disziplin, in der sich viele Beratungsfirmen, Konzerne und Universitäten tummeln. Seit Ende der 1980er Jahre wurden über 50 so genannte „Architekturframeworks“ entwickelt, die sich des Themas annehmen. Das „The Open Group Architecture Framework” (TOGAF) selbst hat seine Wurzeln in den frühen 1990er Jahren und ist wohl das erfolgreichste nicht-militärische dieser Frameworks. Sollten Sie TOGAF deshalb einsetzen? Was macht TOGAF genau? Wie bettet sich TOGAF in übliche (IT-)Unternehmensaufgaben ein? Ist TOGAF überhaupt noch zeitgemäß? Im Folgenden finden Sie einfach gehaltene Antworten auf diese Fragen.

Beitrag in Tagungshandbuch TAE: Warum Softwarearchitektur dokumentieren?

By | Artikel, Publikationen | No Comments
„Warum Sie Ihre Softwarearchitektur dokumentieren sollten, und wie Sie das anstellen“

Warum Sie Ihre Softwarearchitektur dokumentieren sollten, und wie Sie das anstellen
Autor: Stefan Zörner
Herausgeber (Tagungshandbuch ): Dr. Andreas Birk
Beitrag 3. Symposium Software-Architektur 2013, 7 Seiten, ab Seite 1
ISBN: 978-3-943563-05-4 (Tagungshandbuch)
Erschienen 26. September 2013

Dokumentation wird oft als lästige Pflicht angesehen und in vielen Softwareprojekten vernachlässigt. Die Architektur wird manchmal sogar überhaupt nicht beschrieben. Dabei hilft wirkungsvolle Architekturdokumentation, zentrale Ideen im Team und gegenüber anderen Beteiligten zu kommunizieren. Sie macht zentrale Entscheidungen auch später noch nachvollziehbar. Erfahren Sie, wie Sie Ihre Architektur geeignet festhalten, anstatt sie zu vergessen! Kleine Zutaten unterstützen Sie bereits beim Entwurf der Architektur, begleiten Sie bei Umsetzung und Weiterentwicklung, und fügen sich bei Bedarf zu einer zielgruppengerechten Architekturbeschreibung zusammen. Das Ganze bildet einen pragmatischen Rahmen, der Sie auch bei der Etablierung von Best Practices in Ihrem Unternehmen unterstützt. Er macht Softwarearchitekturen innerhalb Ihres Unternehmens und auch gegenüber Dritten sichtbar. Und methodische Softwarearchitektur als Disziplin greifbar.

Zu diesem Manuskript

Dieser Text vertieft die in der Keynote des 3. Symposiums Software-Architektur 2013 in Ostfildern vorgestellten Ideen und illustriert sie mit einem Fallbeispiel. Er ist kein Redemanuskript. Einzelne Inhalte und Abbildungen erschienen ursprünglich in einem Buch des Autors bzw. Beiträgen in einer Fachzeitschrift.

 

Artikel Business Technology Magazin: Übersetzung von Unternehmenszielen in IT-Projekte

By | Artikel, Publikationen | No Comments
„Scheibchen für Scheibchen. Die schlanke Übersetzung von Unternehmenszielen in IT-Projekte“

Scheibchen für Scheibchen. Die schlanke Übersetzung von Unternehmenszielen in IT-Projekte
Autoren: Stefan Toth, Kim Nena Duggen
Artikel im Business Technology Magazin, 02/2013
Erschienen 29. Mai 2013

Viele Projekte, die sich mit Unternehmensarchitektur beschäftigen, sind starr, aufwendig und ergebnisarm. Es wird viel Zeit auf hoher Flughöhe verbracht und sehr breit gearbeitet. Die beteiligten Personen entfernen sich dabei zunehmend von den eigentlichen Problemen der Umsetzungsprojekte und die Akzeptanz im Unternehmen sinkt. Das muss nicht so sein. In diesem Artikel zeigen wir, wie Sie priorisiert und iterativ an der Unternehmensarchitektur arbeiten können. Scheibchen für Scheibchen werden Aufwände fokussiert und der Weg zur Umsetzung verkürzt.

Artikel HMD 2013: Architektur und Agilität

By | Artikel, Publikationen | No Comments
„Architektur und Agilität – so passt das zusammen“

Architektur und Agilität – so passt das zusammen
Autoren: Stefan Toth, Uwe Vigenschow
Beitrag im HMD – Praxis der Wirtschaftsinformatik, Heft 290 („Agilität in der IT“)
Erschienen April 2013

Softwarearchitektur und Agilität sind kein Widerspruch, sondern lassen sich wirkungsvoll kombinieren, um die Grundlage für qualitativ anspruchsvolle Software zu bilden. Dazu gilt es einerseits, in den Entwicklungsteams eine gemeinsame Definition von Softwarearchitektur zu finden, und andererseits, einen iterativen Architekturprozess konform zur agilen Entwicklung aufzusetzen und zu leben. Der vorgestellte Prozess führt zu einer großen Transparenz von Architekturaspekten und ihrer regelmäßigen Bewertung anhand von aktuellen Szenarien.

Artikel dotnetpro: Kleines Einmaleins der Architekturdokumentation, Teil 2

By | Artikel, Publikationen | No Comments
Mehr als 1000 Worte? Kleines Einmaleins der Architekturdokumentation, Teil 2: Sichten und Werkzeuge

dot_Logo_SchwarzRot_250x50
Artikel, dotnetpro 10/2012, 6 Seiten, S. 98
Autor: Stefan Zörner
Erschienen: September 2012

Abbildungen dürfen auch in einer Architekturbeschreibung nicht fehlen. Welche fertigen Sie an? In welcher Notation? Und welche Werkzeuge helfen? Wiki? UML? Oder etwas dazwischen?
In diesem zweiten Teil der Mini-Serie in der dotnetpro rund um Architekturdokumentation geht es um Sichten, übergreifende Konzepte und Tools rund um Architekturdokumentation.

Artikel dotnetpro: Kleines Einmaleins der Architekturdokumentation, Teil 1

By | Artikel, Publikationen | No Comments
Historisch gewachsen? Kleines Einmaleins der Architekturdokumentation, Teil 1: Einflüsse und Entscheidungen

dot_Logo_SchwarzRot_250x50
Artikel, dotnetpro 9/2012, 5 Seiten, S. 98
Autor: Stefan Zörner
Erschienen: August 2012

Softwarearchitektur ist die Summe fundamentaler Entscheidungen. Halten Sie zentrale Einflüsse und Ideen fest, anstatt sie zu vergessen. Gelangen Sie so zu einer nachvollziehbaren Lösung! In diesem ersten Teil der Mini-Serie in der dotnetpro rund um Architekturdokumentation geht es um architekturrelevante Anforderungen, Einflussfaktoren und Architekturentscheidungen.

Download PDF

Download des PDFs mit freundlicher Genehmigung.
Teil 2 der Miniserie bei dotnetpro: „Mehr als 1000 Worte“

Artikel Business Technology Magazin: Architekturbewertung. Keine Noten, aber mehr Durchblick

By | Artikel, Publikationen | No Comments
„Architekturbewertung. Keine Noten, aber mehr Durchblick“

Architekturbewertung. Keine Noten, aber mehr Durchblick
Autor: Stefan Toth
Artikel im Business Technology Magazin, 01/2010, 6 Seiten, S. 6
Erschienen 7. April 2010

Artikel online lesen bei JAXenter

Software-Architektur ist die Brücke zwischen den Zielen der Auftraggeber und der fertigen Software. Die getroffenen Strukturentscheidungen sind von großer Tragweite, erfordern ein hohes Maß an Erfahrung und müssen darüber hinaus zum richtigen Zeitpunkt und unter den richtigen Voraussetzungen getroffen werden. Trotz dieser Bedeutung ist Architektur zu oft das Werk von Einzelnen und meistens zu weit von der Umsetzung und den eigentlichen Bedürfnissen entfernt. Die Architekturbewertung hat sich zum Ziel gesetzt das zu ändern. Der Weg führt über transparente Architekturentscheidungen – eine gläserne Architektur.

online lesen

 

The Big Picture — Mit Entscheidern kommunizieren

By | Artikel, Kolumne, Publikationen | No Comments

Kolumne „Architekturen dokumentieren“

Folge 12: The Big Picture — Mit Entscheidern kommunizieren

Logo_Kolumne_JavaMagazinRan ans Whiteboard, und erklärt! Als Softwarearchitekt kommunizieren Sie Ihre Konzepte und Endscheidungen im Entwicklungsteam. Für die meisten von uns stellt dies keine große Hürde dar. Denn Architekten sollten zuvor selbst lange als Entwickler oder Spezialist in Projekten gearbeitet haben. Oft nehmen sie ohnehin eine Doppelrolle wahr. Erfahrungshorizont und Sprache der Beteiligten liegen nahe beieinander. Was nicht heißen soll, dass es hier nicht zu Konflikten kommen kann. Aber zumindest die Wellenlänge stimmt meist überein.

Nun sind Entwickler aber nicht die einzigen, mit denen sich Architekten über das gemeinsame Vorhaben austauschen. Die Projektleitung ist an Ressourcenverbrauch und Risiken interessiert, auch Kunden und Auftraggeber wollen über den Projektfortschritt auf dem Laufenden gehalten werden, und ab und an was vorgeführt bekommen. Kommunikationsfähigkeiten sind zentrale Erfolgsfaktoren für einen Architekten [1]. Insbesondere muss er seine Ideen zielgruppenorientiert vermitteln können; er hat es mit sehr unterschiedlichen Empfängern zu tun. Zu den Kommunikationspartnern zählen regelmäßig auch Personen aus dem Management, sei es auf Seiten der Kunden und Auftraggeber, oder auch in Form eigener Vorgesetzter. Diese Leute entscheiden mitunter über die Zukunft Ihres Projektes. Effektiv auch mit dieser Zielgruppe kommunizieren zu können ist entscheidend!

„Wo sind denn auf dem Bild unsere Kunden?“ – Haben Sie schon einmal Entscheidern anhand bestehender Dokumentation die Architektur Ihres Systems erklärt? Versuch einer Antwort: „Kunden greifen vom PC per Browser auf unser System zu, die sind hier nicht mit drauf. Nur unsere Webserver sind drauf.“ Worauf hin der Entscheider denkt: „Tolle Bilder malen die, nicht mal unsere Kunden sind drauf.“ und Sie fragen sich vielleicht: „Weiss der überhaupt, was ein Browser ist?“ [2].
Entscheider lesen nicht das Java Magazin, sondern die Computerwoche („7 Spartipps fürs Rechenzentrum“). Sie operieren auf einem völlig anderen Abstraktionsniveau als wir. Entscheider versuchen vor allem betriebswirtschaftliche Anforderungen zu erfüllen. Dabei geht es um ein vernetztes Denken in den Zusammenhängen der ganzen Firma oder sogar eines Konzerns. Entscheider entwickeln Visionen und Strategien für die Zukunft. Sie verstehen nicht unmittelbar, warum OSGi eine tolle Sache ist. Stattdessen rechnen sie gerade, die gesamte IT mit Hilfe von SAP zu harmonisieren, oder die Individualentwicklung nach Tschechien auszulagern.

Konsequenterweise sind meisten in dieser Kolumne vorgestellten Arbeitsergebnisse der Architekturdokumentation, insbesondere die unterschiedlichen Sichten notiert in UML, nicht entscheiderkompatibel. Nicht notwendiger Weise deshalb, weil sie nicht verstanden werden (was zwar meist der Fall ist), sondern weil die Implikationen auf die betriebswirtschaftlichen Aspekte nicht zu erkennen sind.

Was nicht heißt, dass man für diese Zielgruppe nicht auch mit Abbildungen arbeiten kann, um zu vermitteln, was auf neudeutsch so schön „The Big Picture“ heißt. Nur muss die Argumentation anders ansetzen. Und ein (lediglich unterstützendes) managementtaugliches Bild sieht ebenfalls anders aus: Informelle Notation, viel Symbolik, sinnvoll eingesetzte Farben. Ansprechend im wahrsten Sinne des Wortes. Eine gemeinsame „Big Picture“-Abbildung eignet sich darüber hinaus, früh ein einheitliches Bild vom System im Team zu etablieren. Es besteht hier allerdings die Gefahr, dass es das einzige Bild bleibt, keine Architektursichten erstellt werden, und immer mehr Aspekte in der Abbildung vermischt werden. Trennen Sie es daher klar von Bausteinsicht, Kontextsicht, Laufzeitsicht usw. Es ist im Grunde eine weitere Sicht. Nennen Sie sie z.B. „Architekturüberblick“. Anders als bei den anderen Sichten ist die UML hier keine geeignete Notation. Es spricht nichts dagegen, einen Architekturüberblick frei von Hand zu zeichnen, wie das Beispiel von Scott Ambler in Abbildung 1 zeigt (Quelle: [3]). PowerPoint oder Visio sprechen Entscheider in der Regel mehr an, und es ist bei elektronischen Diagrammen leichter eine Änderung oder Ergänzung möglich. Da das Abstraktionsniveau eines Architekturüberblicks sehr hoch ist, sollte dies jedoch selten nötig sein. Es ist daher kein Drama, die Abbildung nicht in einem Modell mit den übrigen Artefakten zu halten. Nichts desto trotz sollte der Überblick natürlich konsistent zu den anderen Sichten sein. Ansonsten stiftet er schnell Verwirrung, oder wird im Entwicklerteam nicht ernst genommen.

Abb. 1: Beispiel für einen Architekturüberblick von Scott W. Ambler

Abb. 1: Beispiel für einen Architekturüberblick von Scott W. Ambler

 

Der Architekturüberblick unterstützt bei der Kommunikation ähnlich wie Produktkarton und Systemidee [4]. Gut gemacht ist er exzellent geeignet, neue Teammitglieder ins Boot zu holen, Sponsoren zu informieren, oder Bedenkenträger zu überzeugen. Oder auch einem Manager einen groben Überblick darüber geben, was für ein System Ihr Team gerade baut. Der Architekturüberblick ist ein wichtiger Baustein des Projektmarketings, er wird in jedem mit dem Vorhaben verbundenen Powerpoint-Foliensatz auftauchen.

Zurück in den Lenkungsausschuss. Folie zur Ist-Situation. „Oh, da sind ja unsere Kunden. Und da ist der Host. Die Host-Wartungsverträge laufen aus. Eine Verlängerung bindet uns weitere 5 Jahre …“. Dem Entscheider gelingt eine Einordnung Ihres Vorhabens in seinen Kontext. Hier können Sie anknüpfen: „In der Zeit gehen 8 der 13 Host-Entwickler in Rente. Der Markt gibt keine neuen Arbeitskräfte für diese alte Technologie her. Obwohl die Wartungskosten derzeit für das Host-System extrem niedrig sind, gilt es jetzt die Weichen neu zu stellen, damit dies in 3 Jahren auch noch der Fall ist. Ich schlage daher folgende Migrationsstrategie vor, …“. Nächste Folie. Ihr neuer Architekturüberblick. Sie haben Vertrauen gewonnen, und vielleicht auch Unterstützer.

Links & Literatur

[1] U. Vigenschow, Björn Schneider, „Soft Skills für Software-Entwickler“, Dpunkt 2007
[2] “Browser — Was sind denn jetzt noch mal Browser?”, http://netzpolitik.org/2007/kinderreporter-fragen-politiker-nach-dem-internet/
[3] S. Ambler, „Agile Modeling“, http://www.agilemodeling.com
[4] S. Zörner, “Out of the box. Produktkartons”, Java Magazin 7/2009

 

javamagazin_09_2009Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
„The Big Picture — Mit Entscheidern kommunizieren“, Java Magazin, 09/2009, 2 Seiten, S. 78

(mit freundlicher Genehmigung)