Die Verwaltung einer Stadt ist eine hochkomplexe Angelegenheit. Nichts verdeutlicht diesen Umstand besser als ein Blick auf die IT-Landschaft – besser gesagt: die IT-Landschaften – der Stadt Zürich. Denn jedes der neun Departemente hat in den vergangenen Jahrzehnten seine eigene digitale Infrastruktur aufgebaut. Gesamthaft betreut werden diese auch departementsintern teilweise äusserst heterogenen Umgebungen hardwareseitig zwar von der OIZ (Organisation und Informatik der Stadt Zürich). Doch haben viele Ämter – also die Unterabteilungen der Departemente – wiederum ihre eigenen IT-Verantwortlichen.
So war es bis vor drei Jahren auch im Hochbaudepartement (HBD): Das Amt für Hochbauten, das Amt für Baubewilligungen, das Amt für Städtebau sowie die Immobilien-Bewirtschaftung hatten jeweils ihre eigenen IT-Leiter und -Teams. Das war das Resultat der in den achtziger und neunziger Jahren vorherrschenden Maxime, gemäss der jedes Amt wie eine eigenständige Firma zu führen sei. Dann beschloss der damalige HBD-Chef, der heutige Stadtpräsident Elmar Ledergerber, dem Wildwuchs ein Ende zu bereiten. Er schuf die Stabsstelle eines Leiters Organisation und Informatik, der für die gesamte digitale Verwaltung im HBD zuständig ist. Seit Mitte 2002 hat Lukas Gillioz, der elf Jahre bei der Swissair-Informatik tätig und danach bei Kuoni-Reisen für den Aufbau der Telekommunikation verantwortlich war, diese Position inne. Als Gillioz damals seine Stelle im HBD antrat, sahen sich er und seine 13 Teamkollegen vor die Aufgabe gestellt, den IT-Wünschen von 750 HBD-Mitarbeitern gerecht zu werden – eine echte Herausforderung, wenn man bedenkt, dass das HBD über 12 Standorte, 24 Serversysteme, gut 100 verschiedene Applikationen und rund 500 vernetzte Arbeitsstationen verfügte. Das ist auch heute noch so – aber etwas Entscheidendes hat sich geändert. Denn angesichts der Heterogenität vor allem bei den Applikationen hat Gillioz Anfang 2004 den Startschuss für einen umfassenden IT-Architekturwandel im HBD gegeben.
Auslöser dafür war seine Analyse der künftigen Kostenentwicklung mit der bestehenden IT-Architektur. Das Ergebnis war schlicht alarmierend: Bei einem stetig schrumpfenden IT-Budget, wie es Gillioz realistischerweise in seinen Berechnungen berücksichtigte, würden die Betriebskosten – Applikations-Wartung, Updates und Schnittstellenbewirtschaftung – gleichzeitig ständig steigen. Der fatale Effekt: Für IT-Projekte, also für zukunftsgerichtete Innovationen für eine verbesserte Abwicklung der HBD-internen Geschäfte, würden bald kaum noch Mittel zur Verfügung stehen. Das ist der Albtraum jedes IT-Leiters, kann er doch in dieser Situation bloss noch Altlasten verwalten. Gillioz musste also einen Weg finden, um auch in Zukunft trotz stetig kleinerem Budget genug Mittel für Projekte zu haben – das heisst, er musste die Betriebskosten deutlich senken. Im Rahmen der neue HBD-IT-Strategie erarbeitete er auf Basis des HSG-Schichtenmodells (Hochschule St. Gallen) das Konzept für eine IT-Architektur, mit der dieses Ziel mittelfristig erreicht werden kann.
Klar war von Anfang an, dass die Anzahl der im HBD in Betrieb stehenden Kleinapplikationen zu hoch war. Denn hinter jeder kleinen Spezialapplikation steht in der Regel ein entsprechend kleiner Softwarehersteller, mit dem jeweils ein separater Wartungsvertrag eingegangen wird. Das geht einerseits ins Geld und führt andererseits zu Abhängigkeiten. Gillioz sagt zwar, dass er nichts gegen Abhängigkeiten per se habe, da diese eh nicht zu vermeiden seien. Er sei aber lieber von einem grossen Hersteller abhängig als von einem kleinen, bei denen man nicht wisse, was passiere, wenn sie von der Bildfläche verschwänden – oder wenn die entsprechenden Spezialisten dort den Arbeitgeber wechselten und das HBD dadurch externes Knowhow verliere.
Ausserdem wusste Gillioz, dass auch bei einem Abbau von Kleinanwendungen die Zahl der eins-zu-eins-Schnittstellen zwischen den verschiedenen Anwendungen auf ein Minimum reduziert werden musste. Ein weiteres Problem, das die Betriebskosten immer höher ansteigen lässt, sind die sogenannten Silo-Lösungen, also eine grosse Applikation, im HBD beispielsweise die SAP-Finanzbuchhaltung, die auf einer Oracle-Datenbank und dem Betriebssystem AIX aufsetzt. Oder die Baukostenüberwachung und
-abrechnung PAR2000, die mit DB2 und OS400 läuft. Oder die Geschäftskontrollapplikation GK2000, die auf Lotus Notes/Domino und Windows 2000 getrimmt ist. Solche Silos lassen sich zwar nicht ganz vermeiden, sollten aber ebenfalls auf ein Minimum reduziert werden. Zusammen mit Werner Wittich, Business Unit Leiter ESI beim Schlieremer Softwarehaus Zühlke Engineering, kam Gillioz deshalb zum Schluss, dass die künftige IT-Architektur nicht nur technisch dem EAI-Modell (Enterprise Application Integration), sondern darüber hinaus im Hinblick auf sich ändernde Geschäftsprozesse dem SOA-Ansatz (Service Oriented Architecture) entsprechen sollte.
Konkret bedeutet das, dass die gesamte IT-Architektur des HBD konzeptuell neu geordnet werden musste. Statt in Silo-Lösungen und in Einzelapplikationen beziehungsweise Tools wird jetzt in horizontalen Schichten mit Fokus auf Geschäftsprozesse und Services gedacht. Gestartet wurde das EAI/SOA-Projekt 2004 mit einem «Proof of Concept», in dessen Rahmen Microsoft einen rudimentären Prototypen der Architektur mit Hilfe der Integrationssoftware BizTalk Server realisierte. Dabei wurden probeweise erste Schnittstellenadapter für das einigermassen komplizierte und auch veraltete ERP-System (Enterprise Resource Planning) IRP des HBD erstellt. Das Resultat fiel zufriedenstellend aus. Für Gillioz war dies ein wesentlicher Grund, weshalb er sich definitiv für BizTalk Server als Integrationsplattform entschied. Dieser Probelauf wurde im August 2004 beendet.
Danach begann die eigentliche Phase 1 des Projekts. Diese umfasste die Konzepte für die Integration, die Hardware und die Sicherheit sowie die Fertigstellung der Schnittstellenadapter für IRP. Sodann mussten die Geschäftsprozesse definiert und dokumentiert werden, damit auf dieser Grundlage erste Services in den Bereichen Auftrag, Bestellung, Rechnung und Bauvergabe festgelegt werden konnten. Schliesslich wurde der Service für die Bauvergabe praktisch umgesetzt. Im Februar 2005 schloss Gillioz die Phase 1 ab.
Die Phase 2 wiederum, die Ende April 2005 beendet war, hatte die Integration des ERP-Systems IRP und des neuen Auftragsbearbeitungssystems PROVIS zum Ziel. Dabei wurden weitere neun Services umgesetzt. Nach dem Aufbau des Integrationssystems wurde das Ganze erstmals zu Testzwecken implementiert. Wirklich operativ genutzt werden sollen Teile der neuen EAI/SOA-Architektur laut Gillioz gegen Ende dieses Jahres.
Eine Knacknuss der besonderen Art, die ihm im bisherigen Verlauf des Projekts ganz schön zu denken gegeben hat, will Gillioz mittlerweile ebenfalls aus der Welt geschafft haben: die Architektur/Mensch-Schnittstelle. Da der BizTalk Server einen reinen Maschine-zu-Maschine-Workflow bietet und keine grafische Benutzerschnittstelle zur Verfügung stellt, kann er laut Gillioz ein klassisches Workflow-Tool nicht ersetzen. Vielmehr sei er als technische Ergänzung dazu zu betrachten. Um die Geschäftsprozesse wirklich erfassen, abbilden und verwalten zu können, war im Schichtenmodell deshalb die Einführung eines speziellen Workflow-Layers vonnöten. Als Tool wählte Gillioz die e-Work-BPM-Software (Business Process Management) von Metastorm aus. Doch auch hier zeigte sich, dass das nicht genügt. Denn die Anwender und die Linienverantwortlichen, das musste Gillioz erkennen, sind sich in der Regel nicht gewohnt, ihre Geschäftsprozesse und Arbeitsabläufe mittels eines Workflow-Tools abzubilden. Gillioz kam deshalb auf die Idee, den Leuten zu diesem Zweck Tabellenvorlagen in einer Web-Applikation zur Verfügung zu stellen, in die sie die Beschreibungen ihrer Abläufe eintragen konnten. Ganz im Sinne eines Self-Service können die Verantwortlichen ihre Prozesse eigenständig definieren und im HBD-Portal automatisch visualisieren. Aufgrund dieser Tabellen kann dann in einem ersten Schritt beurteilt werden, welche Prozesse der IT-Unterstützung bedürfen und welche nicht. In einem zweiten Schritt werden die zu unterstützenden Abläufe von Gillioz und seinem Team in die Workflow-Software und falls nötig in den BizTalk Server übertragen. Das bedeute zwar Mehrarbeit, sei aber dennoch effizienter und endanwenderfreundlicher, so Gillioz. Denn wenn jemand ein oder zwei Mal pro Jahr etwas in seinen Abläufen ändern müsse, habe er auf jeden Fall vergessen, wie das im Workflow-Tool funktioniere – auch wenn er einmal für teures Geld darin geschult worden sei.
Insgesamt ist der HBD-IT-Leiter davon überzeugt, mit seiner EAI/SOA-Strategie den richtigen Weg eingeschlagen zu haben. Wie genau – in Franken und Rappen – sich die serviceorientierte Architektur rechnen wird, kann er allerdings noch nicht voraussagen. Klar ist, dass das Konzipieren, Entwickeln und Umsetzen ins Geld geht. Gillioz ist sich aber sicher, dass sich die Sache unter dem Strich und mittelfristig lohnt. Denn einerseits müssen fortan viel weniger Schnittstellen gepflegt und angepasst werden, und andererseits kann neue Software – beispielsweise ein frisches ERP-System anstelle des veralteten IRP – künftig relativ einfach und effizient in die SOA-Umgebung eingepasst werden.
Ausserdem hat Gillioz von den IT-Verantwortlichen anderer Departemente der Stadt Zürich bereits Interessensbekundungen erhalten. Dazu beigetragen haben sicher die regelmässigen Sitzungen mit ihnen und Vertretern des OIZ, in denen allseitig Erfahrungen ausgetauscht werden können. Gillioz ist sich bewusst, dass er mit seinem Projekt in der Zürcher Stadtverwaltung eine eigentliche Pionierarbeit leistet und erwartet deshalb auch nicht, dass alle anderen sofort auf den Zug aufspringen. Dennoch ist er zuversichtlich, dass sich sein Effort auszahlen wird. Denn mittel- und langfristig, betont er, führe – rein schon aus Kostengründen – kein Weg vorbei an der Realisierung einer serviceorientierten IT-Architektur für die gesamte Zürcher Stadtverwaltung.
