Architektur = Kommunikation

Architektur = Kommunikation
Warum Architekten im Software-
projekt so viel reden müssen…
Matthias Bohlen
unabhängiger Software-Architekt und
Berater für Methoden und Verfahren
der modernen Software-Entwicklung
mbohlen@mbohlen.de
http://www.mbohlen.de

Matthias Bohlen <mbohlen@mbohlen.de> 2
Agenda
 Architektur und Architekten
 Entwurfs-Entscheidungen
 Warum Kommunikation so unendlich
wichtig ist!
 Gesprächspartner und Lieblingsthemen
 Skills eines guten Architekten
 Fragen und Antworten

Matthias Bohlen - Profil
 Freiberuflicher Berater
Architektur
Modellgetriebene Softwareentwicklung
Objekt- und Komponententechnologien
 Dienstleistungsangebot
Consulting: Architektur, Methoden
Training: Analyse, Design, Programmierung
Schulungen / Seminare / Workshops

Software-Architektur
 besteht aus Struktur, Verhalten und
Entwurfsstil eines DV-Systems
Conrad Whittaker (Ingenieur, SPAWAR SSC-SD, San Diego)
Was ist der Unterschied, wenn ein Architekt oder ein Ingenieur ein Haus bauen?
Das Haus des Architekten wird einstürzen
versus
Die Öffentlichkeit wird verlangen, dass man das Haus des Ingenieurs abreißt.
Prof. Philippe Kruchten (University of British Columbia, Vancouver):
Das Leben von Software-Architekten besteht aus einer
langen und schnellen Abfolge von Entwurfsentscheidungen,
die meist im Dunkel getroffen werden.

Architekten…
 garantieren Erfüllung der
Anforderungen
 klären Einflussfaktoren
 beweisen Konzepte
 entwerfen Strukturen
 entscheiden Alternativen
 bewerten und
balancieren
Anforderungen
 kommunizieren
Entwurfsideen
 beraten in
architekturrelevanten
technischen Fragen
 dokumentieren
 implementieren
 bewerten und
vereinfachen
Architekturen
nach Gernot Starke:
http://www.arc42.de/ArchitekturundArchit.html

Zwei Führungskräfte im Projekt
 Der Software-Architekt wird manchmal auch
"technischer Projektleiter" genannt
 Abgrenzung zum "klassischen" Projektleiter
 Architekt: Technik, Systemstruktur, Regeln zum Bauen
 Projektleiter: Kosten, Termine, Ressourcen
 Beide machen Vorgaben, doch keiner redet dem
anderen hinein!
 "Der Architekt verhält sich zum Projektleiter wie die
Kirche zum Staat."  (zitiert nach Philippe Kruchten)

Der Job des Architekten
Req.
Docs
Projektbeteiligte
Einfluss-
faktoren
Architekt
Lösungs-
strategie
Risiken
und
Vorgehen
Architektur-
Entwurf

Input für Architekten
 Der Architekt muss
mit vielen Projekt-
beteiligten sprechen,
um die Systemidee
zu entwickeln und
Einflussfaktoren auf
die Architektur zu
ermitteln
 Aus diesen heraus
fällt er Entwurfs-
entscheidungen
Architekt
ProjektleiterGeldgeber
Implementierer
QM
Fachbereich
Betreiber

Entwurfsentscheidung – was ist das?
 Ausgangslage
 Wirksame Kräfte
 Zur Verfügung stehende Alternativen
für die Systemstruktur
für das Systemverhalten
für eingesetzte Fertigprodukte, usw.
 Bewertung und Entschluss
 Konsequenzen

Beispiel: Mut zur Korrektur
 Kunde möchte für die neue Anwendung selbst Reports
entwerfen und ausführen können
 Es wird daher ein relativ teures Reportingwerkzeug
beschafft und eingesetzt
 Praxis zeigt: Es ist komplex und funktioniert nicht wie erwartet
 Integrationsaufwand für das Werkzeug steigt ständig
(Kunde und Projektleiter werden nervös)
 Betreiber ist ungehalten, weil das Tool nicht richtig in seine
Serverlandschaft passt
 Kunde ignoriert beständig das Werkzeug, weil er es nicht
versteht
 Kunde "bestellt" seine Reports nun doch bei den Entwicklern

Beispiel: Architekt entscheidet
 Architekt trifft folgende Entwurfs-
entscheidung:
"Lasst uns das Werkzeug weglassen und durch
eine einfache Java/Open Source-Komponente
ohne Layout-Tool ersetzen!"
 Er stellt nun die Folgen der Entscheidung
allen betroffenen Projektbeteiligten dar
PL, Kunde, Entwickler

Konsequenzen darstellen
 Architekt zum Projektleiter:
"Das Werkzeug hat EUR 30.000 gekostet. Die
werden wir verlieren. Wenn unsere Entwickler
durch die einfachere Java-/Open Source-
Lösung jedoch nur 10 Tage einsparen, haben
wir die 30.000 wieder drin!"
Außerdem: "Der Kunde macht seine Reports
(wie sich in der Praxis zeigt) eben doch nicht
selbst! Verhandle doch bitte mit ihm über
Change Requests zur Reporterstellung."
Projektleiter schluckt heftig, doch er akzeptiert.

Mit Menschen sprechen
 Architekt zum Kunden:
"Du willst doch die Reports in Wirklichkeit gar
nicht selbst machen sondern beauftragst sie
ohnehin bei uns. Daher wird es Dir egal sein, ob
wir sie mit einem Werkzeug oder von Hand
layouten, richtig?"
 Kunde:
"Stimmt. Wenn Ihr dadurch die Kosten wieder in
den Griff bekommt, soll mir das recht sein!"

Entscheidungen kommunizieren
 Architekt zu den Entwicklern:
"Hört bitte auf, um das Reportingwerkzeug
herumzuprogrammieren und macht bitte einen
Prototyp als proof of concept für Reporting auf
Basis von Jasper."
"Werft dann bitte die seltsame Komponente
wieder weg, die Ihr gebraucht habt, um die
Engine des Reportingwerkzeuges in die Java-
Webanwendung zu integrieren."
Entwickler: "Hurra, der Klotz am Bein ist weg!"

Entwurfsprozess des Architekten
 kreativ, kommunizierend, koordinierend
 das System aus verschiedenen
Blickwinkeln betrachten
 aus Einflussfaktoren Entscheidungen
herleiten, deren Konsequenzen ermitteln
und übersetzen
 Aufteilung, Struktur, Aussehen und
Verhalten des Systems definieren

Gesprächspartner und deren Ziele
Manager / Geldgeber Projektleiter Fachbereich /
Analytiker
schnell
kostengünstig
pünktlich
im Kostenrahmen
praktisch
vollständig
performant
Implementierungs-
team
Qualitäts-
Management-Team
Betreiber
anspruchsvoll
aufregend
cool
schön
ordentlich
korrekt
standard-konform
beobachtbar
problemlos

Manager / Geldgeber
 Gesprächsthemen
 Kosten
 strategische Vorteile
 Sprachen
 Businessdeutsch
 Powerpoint
 Architekt fragt:
 Welche Features bieten
für den Kunden den
größten geschäftlichen
Vorteil?
 Was sind die großen
Ziele bzw. die großen
Events, zu denen wir
etwas zeigen müssen
(Messe, Produkt-
offensive o.ä.)?

Fachbereich / Analytiker
 Geschäftsprozesse
 Anforderungen bzw.
Features der Anwendung
 Daten existierender
Systeme
 Rechtsvorschriften
 Sprachen
 Fachchinesisch
 Dokumente
 Modelle
 Architekt spricht über:
 Glossar der Fachbegriffe
 Anforderungen und deren
Absicherung durch
fachliche Testfälle
 Datentransformationen
 Prozessintegration
 Benutzeroberflächen
 Unnötig teure
Anforderungen

Projektleiter
 Kosten
 Termine
 Risiken
 Fortschritt
 Sprachen
 Managerdeutsch
 Project
 Powerpoint
 Zeit- bzw. Releaseplan
 Features
 Iterationen
 Teambesetzung bzw.
Skills
 Produktstruktur
 Komponenten
 Schnittstellen
 Hardware-Ausstattung
 Risiken am Horizont
 Fallbackstrategien

Implementierungsteam
 Komponenten
 Klassen
 Abläufe
 Fremdsysteme
 Sprachen
 "Geek speak"
 Code
 Design-Modelle
 Powerpoint
 Zeit- bzw. Releaseplan
 Features
 Iterationen
 Design-Entscheidungen
 Coding-Konventionen
 das "große Ziel"
(immer wieder!)
 Systemstruktur
 Komponenten
 Schnittstellen
 Dynamische Abläufe

QM-Abteilung
 Reviews
 Vorgehensmodelle und
Normen
 Ergebnistypen und
Prozesse
 Sprachen
 ISO-Deutsch
 Modelle
 Dokumente
 Ablagestrukturen
 Testfälle
 Testabdeckung
 Metriken
 Entwicklungsprozess
 Produktstruktur
 Dokumentationsstruktur

Betreiber
 Maschinen und Netze
 Installation
 Administration
 Wartung
 Sprachen
 Technikdeutsch
 Herstellerenglisch
 Dokumente
 Powerpoint
 Anwendungsbausteine
 Deployment
 Logging
 Security
 Backup
 Failover und Restart
 Maschinenanzahl und
-ausstattung
 Umgebungen für Test,
Integration, Produktion

Tool- und Framework-Anbieter
 Produkte
 Module
 Lizenzen
 Sprachen
 Kaufmannsdeutsch
 Herstellerenglisch
 Powerpoint
 Tatsächlichen Nutzen
im Projekt
 Kostenbewertung
 Evaluationsversionen
 Testergebnisse
 Change Requests an
den Anbieter
 Synchronisation von
Releaseterminen

Andere Architekten
 System
 Struktur
 Verhalten
 Stil
 Sprachen
 Patterndeutsch
 Geek speak
 Modelle
 Dokumente
 Powerpoint
 Anforderungen
 Konsequenzen
 Vor- / Nachteile
 Entscheidungen
 Design
 Schönheit / Coolness
 Angemessenheit
 Einfachheit
 Guten/schlechten Stil
 die anderen Leute im
Projekt, die einen nicht in
Ruhe lassen…

Ein guter Architekt…
 hat folgende
"Soft Skills"
 Abstraktionsvermögen
 Überzeugungskraft
 Charisma
 Qualitätsbewusstsein
 Entscheidungsfreude
 Verhandlungsgeschick
 Übersetzertalent für
"Fremdsprachen"
 und noch softer…
 Fähigkeit zum
Selbstmanagement
 äußerst geringe
"Ladezeiten" des
Kurzzeitgedächtnisses
 Einfühlungsvermögen
 Intuition und Humor
 Fähigkeit zum Rückzug
in die Ruhe, wenn nötig

Zusammenfassung
 Architektur lebt vom Input aller Beteiligten
 Eine Architektur zu entwickeln ist nur mit
intensiver Kommunikation untereinander
möglich
 Architekt muss ein Kommunikator
"par excellence" sein!

Diskussion
 Ihre Fragen und Anregungen:
 Ihren Projekterfolg unterstütze ich gerne
als Architekt und Coach
Sie erreichen mich unter:
mbohlen@mbohlen.de
oder Tel. 0170 / 772 8545
? ! 

Einladung
openArchitecture 2005
15. – 17. November 2005
Hilton Hotel, Bonn
Peter Friese, Matthias Bohlen:
"MDA im Jetstream"
Wir fertigen live auf der Bühne, vor Ihren Augen,
eine Anwendung nach Ihren Anforderungen!
http://www.openarchitecture.de/

Architektur = Kommunikation

Weitere ähnliche Inhalte

Was ist angesagt?

Andere mochten auch

Ähnlich wie Architektur = Kommunikation

Mehr von Matthias Bohlen

Architektur = Kommunikation