Vom Entwickler zum Architekten: Teil 1

Einem erfahrenen Softwareentwickler kann es passieren, dass er im Lauf der Zeit immer mehr in die Arbeit eines Softwarearchitekten rutscht und den Übergang vom Schreiben von Code zum Design von Systemen vollzieht – zuerst für Offerten, bald aber auch in der Umsetzungsphase. So ist es auch mir ergangen. Trotz eines Informatikstudiums im Rücken fühlte ich mich in der Vergangenheit bei kniffligen Architekturaufgaben aber manchmal etwas unsicher: Mache ich das richtig? Gibt es vielleicht einen besseren Weg Architekturfragen anzupacken als den von mir eingeschlagenen? Um meine Methodik der Erstellung von Softwarearchitekturen auf eine solidere Basis zu stellen, habe ich beschlossen, mich im Rahmen eines Kurses intensiver damit auseinanderzusetzen. Meine Erfahrungen auf diesem Weg möchte ich in drei Blogposts schildern – willkommen bei Teil 1!

Folgende Fragen haben mich in den letzten Jahren als Softwarearchitekt beschäftigt:

  • Was genau umfasst eine Softwarearchitektur?
  • Was genau umfasst die Arbeit eines Softwarearchitekten?
  • Gibt es eine Methodik, der ich folgen kann?
  • Wie kann ich die Softwarearchitektur den diversen Stakeholdern im Projekt gut kommunizieren?
  • Wie kann die Güte einer Architektur gemessen werden?

Der oben angesprochene Kurs, der in meiner Zertifizierung als Softwarearchitekt ISAQB Foundation Level gipfelte, hat mir dabei geholfen, diese Fragen zu klären. Und auch Fragen, die ich mir bisher nicht gestellt hatte (aber besser hätte sollen). Im Vorfeld des Kurses hatte ich mich intensiv mit dem Buch «Effektive Softwarearchitekturen – Ein praktischer Leitfaden» von Dr. Gernot Starke auseinandergesetzt. Da mein Informatikstudium bereits ein paar Jahre zurückliegt, kam das Studium dieses Buches gelegen, um festgefahrene Mechanismen und Meinungen meinerseits zu hinterfragen und aufzubrechen.

Architektensicht: Der Blick auf das grosse Ganze

Die Gretchenfrage

Beginnen wir mit der Gretchenfrage: Was ist Softwarearchitektur?

In erster Linie unterstützt die Architektur den herausfordernden Übergang von der Problemanalyse zur konkreten technischen Lösung. Schliesslich wird ein zu implementierendes System basierend auf seinen Komponenten und deren Beziehungen untereinander beschrieben. Wichtig ist, dass Architektur weit mehr ist als das Skizzieren einer technischen Lösung! Eine gute Architektur ermöglicht:

  • Herr werden über Einflüsse: Neben den funktionalen Anforderungen wird die Architektur unter anderem auch von Budget, Qualitätsanforderungen (auch «nicht-funktionale Anforderungen» genannt), organisatorischen Randbedingungen, rechtlichen Vorgaben oder gar von Politik beeinflusst. Softwarearchitektur kann diese Einflüsse aufzeigen und behandeln.
  • Herr werden über Komplexität: Architekturen dienen dazu, komplexe Anforderungen explizit zu machen und sie in umsetzbare Strukturen zu übersetzen.
  • Effektive Kommunikation: Architektur kann technische Systeme aus verschiedenen Blickwinkeln («Sichten») zeigen und hilft so allen Beteiligten, verständlich und wirksam miteinander über ein System zu sprechen. Diesem Thema widme ich Teil 2 dieser Blogserie.
  • Iterative Verbesserungen: Eine Softwarearchitektur entsteht iterativ und somit begleitend zur eigentlichen Entwicklung des Systems. Entscheidungen, die zu Beginn des Projektes gefällt wurden, sollen während der Umsetzung kritisch hinterfragt und gegebenenfalls angepasst werden.
  • Ziele im Blick behalten: Die Architektur eines Systems soll langfristige Ziele abbilden und mögliche Zielkonflikte mit (eher kurzfristigen) Projektzielen auflösen.
  • Unterstützung des Lebenszyklus: Richtig angegangen unterstützt Architektur den gesamten Lebenslaufs eines Systems: Von der Anforderungsanalyse über Entwicklung bis zum Betrieb von Systemen.

Nun da wir eine Idee davon bekommen haben, was Softwarearchitektur ist: Was ist denn die Rolle des Architekten? Softwarearchitekt zu sein bedeutet viel mehr, als nur Anforderungen des Kunden in eine geeignete technische Struktur abzubilden und dann den Entwicklern die Umsetzung zu überlassen.

Folgende Grafik zeigt die wesentlichen Aufgaben des Softwarearchitekten.

Stacks Image 114

(Quelle: Arc42)

Von der Wichtigkeit des breiten technischen Portfolios

Der Architekt klärt die Anforderungen und Randbedingungen und giesst diese in ein System, indem er Strukturen (Komponenten und ihre Beziehungen) sowie querschnittliche Konzepte entwirft und festhält. Er kommuniziert die Architektur gegenüber den relevanten Stakeholdern – zum Beispiel dem Product Owner, dem Entwicklungsteam, der Projektleiterin, dem Testteam, dem Betreiber etc.) – und begleitet die Umsetzung. Die Pfeile in der obigen Grafik signalisieren, dass es sich um einen agilen Prozess handelt. Ein Softwarearchitekt ist also nicht «nur» ein «Techie», er ist auch Vermittler zwischen den Stakeholdern. Im Endeffekt verantwortet er das System, das umgesetzt wird. Dieser Umstand setzt mich etwas unter Druck: Kenne ich

genügend gut, um stets zur richtigen Entscheidung zu gelangen? Nützlich ist hier der Aufbau eines eigenen breiten technischen Portfolios, das man im Sinn des persönlichen Wissensmanagements stetig erweitert (was bei EBP angesichts der Fülle unserer Projekte gut gelingt). Meines dokumentiere ich vorzu in Form eines Mindmaps.

Das ewige Balance-Spiel: Ausgleich von Zielkonflikten

Darüber hinaus stellt sich immer die Frage, ob man mit seinen Architekturentscheidungen allen Anforderungen und Rahmenbedingungen gerecht wird. Folgendes Zitat von Philippe Kruchten bringt das bisweilen herrschende Gefühl etwas düster auf den Punkt:

«The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark».

Offenbar bin ich nicht alleine mit meinen Sorgen! Zeit, diese zu teilen: Softwarearchitektur darf nicht im stillen Kämmerlein entstehen. Wenn Sie mit Architekturfragen betraut sind: Beziehen Sie die wesentlichen Stakeholder früh in den Prozess mit ein – etwa die (Senior-)Softwareentwickler und -entwicklerinnen, an die Sie technische Abklärungen delegieren. Holen Sie rechtzeitig Feedback ein von den Security-Profis und den Betriebsspezialisten. Diese und ähnliche Schritte steigern meiner Erfahrung nach die Qualität von Entscheidungen massgeblich. Und sie sorgen gleichzeitig dafür, dass das Wissen im Projekt besser verteilt und somit ein gängiges Projektrisiko eliminiert ist.

Next up: In Teil 2 meiner Blogserie möchte ich gezielt auf ein weiteres Kästchen im obigen Bild eingehen, nämlich auf das Kommunizieren der Architektur.

e-geo-Interview mit Ralph Straumann: «Data Literacy ist eine grosse Herausforderung»

Mit dem letzten Newsletter schloss das Impulsprogramm e-geo.ch Anfang November 2016 seine Tätigkeiten ab. Ralph Straumann, Projektleiter in unserem Tätigkeitsfeld Systemberatung + Analytik wurde in diesem letzten, dem 28. Newsletter von e-geo.ch neben anderen GIS-Exponentinnen und -Exponenten interviewt. Das Interview dreht sich rund um unsere innovativen Themen: Data Science, die Zukunft von GIS und die digitale Transformation.

e-geo.ch und die NGDI. Bildquelle: e-geo.ch
e-geo.ch und die NGDI. Bildquelle: e-geo.ch

Personen in der Geoinformationsbranche ist e-geo.ch ein Begriff. Für alle anderen paraphrasiere ich aus der Newsletter-Einleitung von Christian Kaul: e-geo.ch war seit 2003 das Programm zur Förderung des Aufbaus einer Nationalen Geodaten-Infrastruktur (NGDI). Die Trägerorganisationen von e-geo.ch waren der Bund, die Kantone und die SOGI. Mit der neuen Geoinformationsgesetzgebung auf Stufe Bund (GeoIG) wurde 2008 ein grosser Meilenstein erreicht. Ab 2011 rückten dann Umsetzungsfragen zwischen Bund und Kantonen in den Fokus. Im Austausch zwischen den Trägerorganisationen zeigte sich dann ab Januar 2015, dass e-geo.ch zwar viel erreicht hat aber für die Umsetzung ein neuer Rahmen gesucht werden soll.

Der letzte e-geo-Newsletter bietet einen Rückblick in die „Pionierzeit“ und auf verschiedene Highlights des Impulsprogramms. Er zeigt aber auch aktuelle Herausforderungen der Geoinformation und fragt: Was kommt danach? Verschiedene Fachleute geben ihre Einschätzungen ab zu spannenden Visionen und Trends der Branche. Der Text aus dem Interview mit Ralph Straumann:

«Data Literacy ist eine grosse Herausforderung»

Das BAKOM nennt in einer Studie vier grosse Trends, die auch für die Geoinformation relevant sind, nämlich Information, Cloud, Mobile und Social. Wir alle produzieren immer mehr Daten, schon allein, weil wir mit dem Smartphone herumlaufen. Wir nutzen aber auch immer mehr Informationen in der einen oder anderen Form. Das wird ermöglicht durch die Cloud und ihre skalierbare Rechnerleistung. «Mobile» ist ein Trend, weil immer mehr Internetnutzung über das Handy läuft, und «Social» steht für die Netzwerke, wo man sich miteinander austauscht. Diese vier Trends gelten natürlich nicht nur für GIS, aber an ihnen kann man recht viel fest machen, was im Moment passiert.

Niederschwelligere Angebote

Weiter stelle ich fest, dass unser Feld sich öffnet. Es gibt neue Werkzeuge, die das Arbeiten mit Geodaten viel weniger exklusiv machen. Früher hatte man die grossen, teuren GIS-Systeme. Dazu gibt es heute Alternativen, kommerzielle und freie. Diese Entwicklung wird unter anderem vorangetrieben durch den Datenjournalismus, der in den letzten Jahren aufgekommen ist und auch häufig mit Karten zu tun hat. Aus dieser Richtung kommen viele neue Herangehensweisen von Leuten, die nicht so in den Paradigmen drin sind wie wir GIS-Leute. Das finde ich spannend, und das meine ich, wenn ich von «Mainstreaming» und «Consumerisation» spreche.

Geomorphometrie: Valleyness im Tessin (Straumann, 2010)

Komplexe Datenwissenschaft

Als Trend sehe ich auch die «Data Science», die Datenwissenschaft, die seit ein paar Jahren immer mehr in den Vordergrund tritt und in der wir bei EBP auch aktiv sind. Das Ziel der «Data Science» ist, mit den umfangreich anfallenden Daten Prozesse und Strukturen zu optimieren. Ein klassisches Beispiel ist Amazon: Wenn ich dort Bücher bestellt habe, sagt mir Amazon, welche Bücher mir auch noch gefallen könnten. Dieses Empfehlungssystem ist eine einfache Anwendung, aber es gibt auch noch andere Beispiele, wo das viel weiter getrieben wird, auch im Zusammenhang mit Geodaten.

Trajektorien in Zürich von lokalen und auswärtigen Flickr-Nutzerinnen und -Nutzern (Straumann, Çöltekin & Andrienko, 2014)
Trajektorien in Zürich von lokalen und auswärtigen Flickr-Nutzerinnen und -Nutzern (Straumann, Çöltekin & Andrienko, 2014)

Weniger einfache Tätigkeiten

Diese Trends haben für unsere Branche natürlich Konsequenzen, indem einfache GIS-Arbeiten in Zukunft vielleicht weniger gefragt sein werden. Vor fünf Jahren konnte es durchaus sein, dass ein Kunde zu uns kam mit einer Datenbank, in der die Adressen seiner Kunden hinterlegt waren und die er auf einer Karte sehen wollte. Solche einfachen Auswertungen kann es zwar immer noch geben, aber die Funktionalität dafür ist je länger je mehr in gängigen Desktop-Programmen eingebaut, so dass die Leute das selber machen können.

Aber die Kundenstandorte nicht nur zu kartieren sondern zu analysieren, zum Beispiel bezüglich der Frage, wo ein neuer Standort eröffnet werden soll und wie sich dieser auf das Betriebsergebnis oder die Versorgung auswirkt – das sind nach wie vor spannende Fragestellungen, die wir mit «Location Intelligence» beantworten können.

Es ergeben sich aber gerade noch weitere neue Fragen: Wir beraten unsere Kunden zum Beispiel zu den aktuellen Entwicklungen rund um das Internet of Things, Bots, Echtzeitdaten und Smart Cities bzw. Smart Infrastructure. Für diese Themen braucht es Fachwissen und spezielle Kompetenzen.

«Data Literacy» als Bürger(innen)pflicht

Ein besonderes Anliegen ist mir persönlich die «Data Literacy», das heisst die Befähigung von Nicht-Fachleuten, Daten und darauf aufbauende Analysen richtig «lesen» und interpretieren zu können – ganz besonders, wenn auf dieser Grundlage geschäftliche oder politische Entscheidungen getroffen werden. In unserer direkten Demokratie stimmen wir zudem über Fragen ab, die immer öfter ein gewisses Verständnis für Datenanalyse voraus setzen. Wir als Gesellschaft müssen also lernen, diese Dinge zu verstehen, damit umzugehen und manches auch kritisch zu hinterfragen.

Sie können das im e-geo-Newsletter erschienene Interview mit Ralph Straumann hier als PDF beziehen oder hier die gesamte Publikation herunterladen.

Vielen Dank an Swisstopo und Claudia Fahlbusch von escribo für die Erlaubnis zur Publikation dieses Texts auf unserem Blog.

Esri Developer Summit 2012

Schon zum zweiten Mal hat es mich ins beschauliche Palm Springs an den Esri Developer Summit verschlagen. Der diesjährige Summit stand ganz im Zeichen der 10.1-Produktpalette und „Online, online, online“. Im Folgenden schildere ich meine persönlichen Eindrücke der Konferenz.

ArcGIS 10.1

Auch wenn im Juli noch ein SP5 für die 10er-Palette erscheinen wird, ist es nun doch an der Zeit, die 10.1-Ära einzuläuten. Im Juni 2012 wird es endlich soweit sein. Eine Liste aller Neuerungen findet man auf Esris Website. Ich freue mich insbesondere auf: „Esri Developer Summit 2012“ weiterlesen