Größere Entwicklungsprojekte ohne Chaos realisieren

Im vom technischen Betrieb organisatorisch getrennten Entwicklungsteam spielt hingegen neben dem für budgetäre und politische Aufgaben zuständigen Projektleiter, den einzelnen Entwicklungsteams und dem abschließend tätigen Test-Manager vor allem der Software-Architekt eine zentrale Rolle: Er sorgt dafür, dass die Entwickler über ein Gesamtmodell verfügen, das sowohl die fachlich-logische als auch physisch-technische Seite abbildet. Vor allem bei IT-gestützten Geschäftsprozessen mit verteilten Anwendungen und vielen Schnittstellen erweist sich die Trivialmethodik von Fach- und DV-Konzepten dafür oft als unzureichend. Ein Fachkonzept beschreibt nämlich lediglich die Anforderungen des Kunden und ausgewählte Algorithmen, die dem Konzipierer besonders wichtig oder klar waren.

Besser geeignet für prozesslastige und verteilte Anwendungen sind Realisierungskonzepte, die in einem hinreichend detaillierten Grad bereits die spätere Software und die in ihr laufenden Prozesse beschreiben. Dem Architekten zuarbeitende IT-Analysten erstellen hierfür eine einheitliche und transparente Planungsgrundlage, die darüber hinaus frühzeitige Kostenaussagen ermöglicht. Zum Abschluss des Projekts sollten der Architekt und einige Analysten auch zum Testteam gehören, da sie die ursprünglichen Anforderungen gut beurteilen können. Durchgeführt werden die Tests in diesem abschließenden Projektstadium dann von Experten aus dem IT-Betrieb.

Sowohl das Realisierungskonzept als auch die Organisation der Entwicklerteams leiten sich aus der geplanten Architektur des Gesamtsystems ab. Denn die Architektur verteilt die zu entwickelnden fachlichen Funktionsblöcke bereits auf technische Systeme. Beispielsweise legt die Architektur fest, dass das Teilnehmermanagement eines neuen Bonusprogramms durch die Standardsoftware Siebel abgedeckt werden soll. Die Entwicklung der entsprechenden Funktionalitäten geschieht innerhalb der Software Produktions Umgebung (SPU) von Siebel. Jedes Entwicklerteam für eine SPU entspricht nun jeweils einem so genannten Realprojekt. Ein Realprojekt definiert sich dadurch, dass alle Mitarbeiter eines Entwicklungsteams in der gleichen Entwicklungs-Umgebung wie beispielsweise Siebel arbeiten. Wenn weiterhin auch das Kontakt- und das Prämienmanagement des Bonusprogramms auf Siebel stattfinden sollen, können weitere Mitarbeiter des Siebel-Entwicklerteams diese Aufgaben übernehmen. Dennoch arbeiten alle Mitglieder des Siebel-Teams weiterhin in einem einzigen Realprojekt und erfordern innerhalb einer SPU keine zusätzlich komplexere Projektorganisation.

Demgegenüber entstehen jedoch drei weitere Realprojekte, wenn etwa der Web-Auftritt aus Gründen der einfachen Integration in Redaktionssysteme auf einem Application-Server mit J2EE-Technik realisiert wird, die Kontoführung aus Performance-Gründen auf Oracle und die Finanzbuchhaltung auf SAP läuft. Dieser Entwurf orientiert sich an der Regel, dass eine Architektur vor allem durch die nichtfunktionalen Anforderungen an ein IT-System bestimmt wird. Innerhalb eines Realprojektes arbeitet idealerweise ein Team aus drei bis fünf – maximal zehn – Mitarbeitern – gemeinsam an einem Source-Code. Die Praxis zeigt, dass auch sehr große Gesamtsysteme – etwa CRM-Systeme für mehrere Millionen Kunden – Realprojektteams dieser Größe erlauben. Bei seltenen Größenordnungen von über zehn Mitarbeitern pro Realprojekt empfiehlt sich trotz einheitlicher SPU eine weitere Teilung des Teams. Dieses zusätzliche Realprojekt muss im Realisierungskonzept mit modelliert werden.