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

[email protected]

http://www.mbohlen.de

Matthias Bohlen <[email protected]> 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

Projektleiter Geldgeber

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

Gesprächsthemen

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

Gesprächsthemen

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

Gesprächsthemen

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

Gesprächsthemen

Reviews

Vorgehensmodelle und

Normen

Ergebnistypen und

Prozesse

Sprachen

ISO-Deutsch

Modelle

Dokumente


Ablagestrukturen

Testfälle

Testabdeckung

Metriken

Entwicklungsprozess

Produktstruktur

Dokumentationsstruktur


Betreiber

Gesprächsthemen Maschinen und Netze

Installation

Administration

Wartung

Sprachen Technikdeutsch

Herstellerenglisch

Dokumente

Powerpoint

Architekt spricht über: Anwendungsbausteine

Deployment

Logging

Security

Backup

Failover und Restart

Maschinenanzahl und -ausstattung

Umgebungen für Test, Integration, Produktion


Tool- und Framework-Anbieter

Gesprächsthemen

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

Gesprächsthemen

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:

[email protected]

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/