IT-Bebauung für Sprint- und Marathon-IT

Sprint-Systeme erfordern in der Regel ein agiles Projektvorgehen, DevOps als Liefermodell und andere Organisationsprinzipien als die Bestandsorganisation. Auch bei den technischen Rahmenbedingungen muss es Freiheiten geben. Ein Sprint-Team sollte etwa die Entwicklungsumgebung für einen Prototypen bei einem Cloud-Provider aufsetzen oder einen Crowd-Testing-Anbieter für authentisches Zielgruppen-Feedback beauftragen dürfen. Damit das schnell geht, muss dieses Team nicht alle Vorgaben des unternehmensweiten Einkaufs einhalten.

Komplementär zum Sprint-Projekt entsteht auf der Ebene der IT-Landschaft ein neuer Systemtyp, das "Sprint-System": Solche Systeme werden quasi auf der Überholspur gebaut und ausgerollt - in jedem Fall schneller als Systeme in der Bestandsorganisation. Sie setzen verstärkt auf Vorhandenes, etwa Open-Source-Technologien oder Inhalte von Partnern. Die Sprint-Systeme müssen Vorgaben aus der IT-Bebauung nur bedingt berücksichtigen, sie brauchen keine umfangreichen Schnittstellenverträge, und dürfen mehr stand-alone bauen. Die Integration in die bestehende Systemlandschaft steht hinter der schnellen Umsetzung zurück. Der Preis für diese Freiheit ist, dass die einheitliche IT-Landschaft in Teilen verloren geht. Was heißt das für die IT-Strategie?

Speed-Bebauung: schnell und anders bebauen

"Eine komplette Bebauung an einem Tag?" Die Verwunderung des CIO im eintägigen Workshop ist nachvollziehbar. Wir versprechen ihm Antworten auf seine beiden wichtigsten Fragen: Wie vermeiden wir technischen Wildwuchs, wenn wir Prototypen für 50 neue Funktionen bauen? Und wie bauen wir Systeme so, dass wir sie bei Erfolg in die bestehende Landschaft übernehmen können? Tatsächlich: Am Ende des Tages hat jede der zirka 50 neuen Funktionen ihren Platz im Domänenmodell gefunden, und die Leitplanken für jedes geplante Sprint-System sind definiert. Das ist Speed-Bebauung.

Speed-Bebauung zieht das Tempo nach, das schnelle Feedback-Methoden auf der Anforderungsebene und agile Software-Entwicklung und DevOps auf der technischen Ebene vorgeben. Die Bebauung der IT-Landschaft oder Domäne im Ganzen hat dabei nicht ausgedient, sie geht der Speed-Bebauung voraus und setzt Leitplanken, die einen Wildwuchs bei den geplanten Sprint-Systemen verhindern.

Im Workshop haben wir die neuen Funktionen auf das fachliche Domänenmodell "gemappt", die Zuordnung diskutiert und noch zu entstehende Domänen festgelegt. Anschließend haben wir die bestehenden IT-Systeme wie CRM, Finance oder Vertrieb über die fachliche Sicht gelegt und so das Geschäft des Kunden inklusive der neuen Funktionen mit der IT-Landschaft abgeglichen. Mit diesem klaren Tableau haben wir anschließend die individuellen Leitplanken für jedes Sprint-System festgelegt.

Definition der Leitplanken entscheidet über Flexibilität

Die Sprint-Systeme sind Prototypen, um neue Funktionen auf Kunden-Feedback oder Machbarkeit zu testen. Die Leitplanken definieren, ob ein Prototyp später im Lebenszyklus in ein Bestandssystem integriert wird oder eine eigene Anwendung bleibt. Je nach Geschäftsmodell kann beispielsweise eine Mobile-Payment-Lösung als Erweiterung des bestehenden Finance-Systems konzipiert werden oder als eigenständige Bezahllösung. Das beeinflusst, wie der Technologie-Stack für den Prototyp aussieht; auch diese Entscheidung ist Teil der Leitplanken.

Ein weiterer wesentlicher Punkt ist die Definition der Schnittstellen für den Datenaustausch mit den Um-Systemen. Eventuelle Besonderheiten - zum Beispiel ein Fokus auf Datensicherheit und -integrität für Mobile Payment oder auf Performance für einen Webshop - runden die Leitplanken-Definition ab. In diesem Rahmen dürfen Systeme so gebaut werden, wie es der Prämisse "schnell zum Kunden" dient.

Die klassische Bebauung auf der bestehenden IT-Landschaft ist Voraussetzung für die Entscheidung, welche Systeme ein Sprint- brauchen und welche ein Marathon-Vorgehen brauchen. Dabei gilt die Faustregel: Ein Sprint-System ist nahe am Endkunden, deckt innovative Funktionen ab und die Anforderungen sind (zumindest teilweise) unklar. Ein Marathon-System ist der Stabilität, Datenintegrität und Datensicherheit verpflichtet. Es deckt in der Regel Standardfunktionen ab, die Anforderungen für Erweiterungen sind gut detailliert - zum Beispiel weil sie Compliance-Vorgaben entsprechen müssen oder bestehende Funktionen ergänzen.

In Sprint-Systemen können erste Erfahrungen mit Technologien, Frameworks, Sprachen oder Betriebsmodellen gesammelt werden, die bei Erfolg in den etablierten Stack für Marathon-Systeme übernommen werden. Und es gilt auch umgekehrt: Nicht alles, was in Sprint-Systemen gemacht wird, muss für die nächste Version beibehalten oder in einem anderen System wiederverwendet werden - die Lernkurve darf steil sein.

Damit die Sprint-Systeme in die Marathon-IT überführt werden können, oder Prototypen an die Kernsysteme andocken, braucht es dort sauber definierte Schnittstellen - eine Selbstverständlichkeit, die in einer IT-Landschaft mit zwei Systemtypen noch einmal wichtiger wird.

Produkte und Services nahe am Kunden entwickeln, Features früh ausprobieren, neue Technologien einsetzen: Die IT der zwei Geschwindigkeiten ist in vielen Unternehmen schon Realität. Allerdings ist die Entwicklung nicht immer sichtbar, und ganz sicher ist sie nicht überall willkommen. Dennoch krempelt Technologie etablierte Geschäftsmodelle in vielen Branchen gründlich um. Die Transformation in den vier skizzierten Handlungsfeldern Kultur, Fähigkeiten, Organisation und IT-Landschaft anzustoßen, macht die Transformation zu einer IT der zwei Geschwindigkeiten explizit.

Das Ziel ist eine lebendige IT-Organisation. Sie probiert neue Technologien aus und reagiert schnell auf Kunden-Feedback und Marktentwicklungen, ohne Stabilität und Sicherheit aufzugeben. Für das Gelingen dieser Transformation braucht es Wertschätzung für die Stärken beider Stränge in der IT-Organisation, eine IT-Landschaft, die für unterschiedliche Arbeitsprämisse verschiedene Bebauungsmodi entwickelt und eine Moderation, die die Verschiedenartigkeit und das organisatorische Nebeneinander erklärt. Darüber hinaus ist ein Management wichtig, das den Austausch kommunikativ, personell und insbesondere persönlich fördert.