Archiv für den Monat: Mai 2008

Gedanken zur Telekom-Affäre

Veröffentlicht am von

„Wer nichts zu verbergen hat, hat auch nichts zu befürchten.“ Mit diesem Totschlagargument werden Verfechter des Datenschutzes zu gerne abgespeist und subtil als Unterstützter von Terroristen und Kinderpornographen diffamiert.

Schneller als selbst von den größten Pessimisten erwartet, demonstriert die Deutsche Telekom nun, was von diesem Satz zu halten ist: Wenn auch nur ein Bruchteil der Vorwürfe zutreffen, über die der SPIEGEL diese Woche berichtet hat, ist das der GAU der Vorratsdatenspeicherung. Sollte die Telekom tatsächlich Verbindungsdaten aus dem öffentlichen Netz für ihre wirtschaftlichen Ziele missbraucht haben, wäre das wohl nur noch von einer staatlichen Bespitzelungsaffäre a la Watergate zu überbieten.

Wieder einmal zeigt sich, dass Daten, die gesammelt werden, auch missbraucht werden. Die vorgesehene Geldstrafe von bis zu 500.000 Euro ist für einen Telekommunikationskonzern ein Strafzettel wegen Falschparkens. Ich hoffe, dass es der Staatsanwaltschaft gelingt, auch persönliche Schuld nachzuweisen.

Als Trost bliebt uns noch das Bundesverfassungsgericht. Die Affäre dürfte die Position der Überwachungsfreunde vor Gericht kaum gestärkt haben. Welche Konsequenzen wären jetzt nötig?

Erstens muss die Sammelwut eingedämmt werden. Privatwirtschaftlich erhobene Daten müssen strengen Verwendungsrichtlinien unterliegen, deren Verletzung empfindliche Strafen nach sich zieht – bis hin zum Lizenzentzug.

Zweitens muss die staatlich erzwungene Datensammlung gestoppt werden. Wer Unternehmen zwingt, Datenbasen aufzbauen, gegen die das Stasiarchiv blass wirkt, muss sich nicht wundern, wenn dort auch hineingelinst wird.

Und drittens muss jede(r) Einzelne Datenschutz wieder als eine der Grundlagen unserer Demokratie begreifen und entsprechend handeln.

Aber noch dürfte das Wunschdenken sein. Oder haben Sie vielleicht etwas zu verbergen?

Start zu neuen Ufern

Veröffentlicht am von

Seit gestern ist es offiziell: Ich werde ab der Ausgabe September/Oktober 2008 als neuer Chefredakteur des OBJEKTspektrum die bisherige Chefredakteurin Frances Paulisch ablösen. Die Aufgabe ist spannend und es wird sich einiges tun. Das ist einer der Gründe, warum die letzten Wochen nicht mehr ganz so viel Zeit war zum Bloggen.

Für’s erste haben wir eine, wie ich finde, sehr gute Redaktion zusammengestellt, die mir bei der Auswahl der Artikel und Betreuung der Autoren helfen wird. Das heißt, in Zukunft erhalten Autoren Reviews zu ihren Manuskripten und Begründungen, warum ein Artikel angenommen wurde oder eben nicht. Zudem gibt es ab sofort einen regelmäßigen Aufruf zu Beiträgen, den man sich in Kürze abonnieren kann.

Für mich ist es ein wichtiger Schritt, mich neben meiner Beratungsarbeit auch stärker publizistisch zu engagieren. Ich hoffe, den Ruf des OBJEKTspektrum halten und in Richtung Qualität auch ausbauen zu können. Dafür sind wir natürlich auf gute Autoren angewiesen und auch auf jene, die noch gar nicht wissen, dass sie gute Autoren sind. Ich hege die Hoffnung, dass beide Gruppen unter den Lesern dieses Blogs überproportional vertreten sind – und rechne auf Ihre/Eure Unterstützung 🙂

Selbstverständlich werde ich auch weiterhin den größten Teil meiner Arbeitszeit der Beratung und Schulung zu agiler Entwicklung und Organisation widmen. Dafür macht mir die Arbeit einfach zu viel Spaß.

Kommen Projekte ohne Architektur aus?

Veröffentlicht am von

Ich höre immer wieder den Vorwurf an Teams, die mit XP arbeiten, sie hätten „keine Architektur“. Das halte ich für eine fundamentale Fehlinterpretation des Begriffs „Architektur“. Jedes Programm hat eine Architektur. Die mag adäquat sein, oder nicht, sie mag explizit dokumentiert sein, durch Tests abgesichert sein, oder unbewusst entstanden. Aber immer gibt es eine Architektur.

Die Vorstellung, man müsse eine Architektur explizit vor Beginn der Realisierung dokumentieren, damit sie kontrollierbar bleibe, halte ich ebenfalls für falsch. Ich habe viele Architekturdokumentationen erlebt, die zwar nett aussahen, mit der realen Architektur aber höchstens noch rudimentäre Ähnlichkeit besaßen. Umgekehrt habe ich exzellente Architekturen erlebt, die nirgends explizit dokumentiert waren. Sie waren höchstens durch Unit Tests und Mockobjekte abgesichert.

Wenn es um den wirtschaftlichen Nutzen einer Architektur geht, zählt die reale Architektur im Code. „Architekturen“, die nur auf der virtuellen Powerpointmaschine existieren und nichts mit dem real existierenden Code zu tun haben, sind wertlos. Ich habe eindrucksvolle und gut funktionierende Architekturen gesehen, die in traditioneller Technik zu Projektbeginn entworfen wurden. Gerade in XP Projekten entstehen aber auch immer wieder ausgezeichnete Architekturen ohne den großen ersten Wurf.

Architektur und Agilität

Veröffentlicht am von

Will man einmal richtig Spaß haben, so werfe man in eine Gruppe von „Agilisten“ und „Traditionalisten“ das Stichwort „Architektur“: Als hätte man ein Zündholz in einen Strohhaufen geworfen entflammt sofort eine äußerst emotionale Diskussion, deren Randbereiche zwei Statements markieren: „Ohne eine saubere Anfangsanalyse und solide Anfangsarchitektur kommt kein ernsthaftes Projekt aus“ und „Wir brauchen keinen Architekten, die Architektur entsteht beim Programmieren“. Zwischen diesen beiden Extremen findet man fast jede denkbare Zwischenposition.

Ich habe viele dieser Diskussionen verfolgt und bin mittlerweile zu dem Schluss gelangt, dass hier mindestens drei verschiedene Themen munter durchmischt werden:

  • Wann wird die Architektur erstellt? Ist die Architektur eine eigene Phase zu Projektbeginn, wird sie zu Beginn jeder Iteration erstellt, oder entsteht Sie während des Programmierens durch Refaktorisieren?
  • Wie wird die Architektur repräsentiert? Existiert ein eigenes Dokument oder repräsentiert der Code die Architektur — wobei dann oft Werkzeuge eingesetzt werden, um grafische Darstellungen aus dem Code zu extrahieren und wichtige Eigenschaften zu prüfen, zum Beispiel automatisierte Test, um Abhängigkeiten zu prüfen.
  • Wer ist für die Architektur verantwortlich? Gibt einen oder mehrere Architekten? Als Entscheider oder als Moderatoren? Oder ist das Entwicklungsteam gemeinsam verantwortlich?

Ich denke, auf welche „Seite“ man sich bei diesen drei Fragen schlägt, hängt entscheidend von der Frage ab, was man sich von der Architektur erwartet. Die Antwort darauf wird oft stillschweigend als „selbstverständlich“ vorausgesetzt, ohne zu sehen, dass dort der eigentliche Konflikt liegt:

In traditioneller Sicht soll die Architektur Änderungen an bestehendem Code vermeiden. Sie sollte also so flexibel sein, dass zukünftige oder absehbare Anforderungen möglichst schon abgedeckt sind und ohne Änderungen an bestehendem Code oder zumindest der Architektur implementiert werden können. Architektur versucht die zukünftige Entwicklung vorauszusehen.

In agiler Interpretation soll Architektur Änderungen des Codes und ihrer selbst ermöglichen. Eine gute Architektur kann schnell an neue funktionale und nicht-funktionale Anforderungen angepasst werden. Sie ermöglicht möglichst viele zukünftige Entwicklungen. Änderbarkeit ist daher das Leitmotiv agiler Praktiken wie einfaches Design, testgetriebene Entwicklung, Refaktorisieren und Redundanzvermeidung.

Steht man auf dem Standpunkt, Änderungen an der Architektur seien schlecht und zu vermeiden, so wird man fast zwangsläufig zu dem Ergebnis kommen, dass die Architektur vor der Realisierung von einem starken Architekten erstellt werden müsse und daher nicht im Code repräsentiert werden kann.

Sieht man Änderungen als willkommenes Designwerkzeug, kann man die drei Fragen deutlich entspannter angehen. Die Antworten können sich nach anderen Faktoren richten, wie Kritikalität, Team- und Führungskultur und Erfahrung in der Domäne. Fast alle Kombinationen sind hier möglich; viele von ihnen auch in bestimmten Situationen sinnvoll.

In meinen Projekten kamen einige Teams ohne Architekten aus, andere ernannten irgendwann ein Mitglied zum Hüter der Architektur. Immer waren durch Refaktorisieren entstehende Architekturen in fast allen Qualitätsmerkmalen den zu Beginn erstellten Architekturen deutlich überlegen — und dazu auch noch wesentlich billiger. Zudem halte ich mir gerne Optionen offen.