Ob für interne oder für externe Kunden, zuerst muss festgelegt werden, was überhaupt das Ziel, der Zweck und der Nutzen, für die Nutzer, sowie für das Geschäftsmodell, des Portals seien soll. Die Annahme in unserem Fall ist ein nicht triviales Portal mit Benutzerverwaltung, einer gewissen Business-Logik sowie persistenter Speicherung. Die Requirement-Analyse bedarf schon einiges an Aufwänden, da sich die meisten Kunden nicht im Klaren sind was sie wollen, und vor allen Dingen wie es aussehen soll. Die Kunden wissen aber immer, das sie das nicht wollen was gerade fertig gestellt wurde. Auch so Kleinigkeiten wie, “ja der Lieferant hat doch mehr wie eine Adresse” haben IT-Seitig größere Auswirkungen, als es der geneigte Benutzer ahnen kann. Ein anderes Datenmodell, eine andere Handhabung in der Business-Logik, referenzielle Integrität und Fehlerbehandlung wären da einige Beispiele. Was man auf dem Lieferschein in die Ecke kritzeln kann, geht in der IT nicht.

Kommen wir mal zur Erstellung der Software. Nehmen wir mal an das wir ein kleines Team haben, welches mindestens die folgenden Spezialgebiete abdecken kann: UX-Strategie, UI-Design, Front-End Programmierung, Application-Server Programmierung, Datenbankmodellierung und die Testcase-Implementierung. Daneben hätten wir noch den IT-Architekten, das Testmanagement, das Releasemanagement und evtl. wenn man Glück hat, den Betrieb, der schon mal darüber informiert wird was auf sie zukommt. Das ganze wird noch vom Projektleiter zusammen gehalten, monatliche Reports müssen ja auch noch geschrieben werden, beim Projektverzug auch mal wöchentlich. Wenn man ganz besonders Glück hat kümmert sich jemand um die Datensicherheit, die praktische wie Pen-Testing, sowie die Beachtung gesetzlicher Vorschriften.

Hab ich was vergessen? Ja, bestimmt, z.B. die Dokumentation, die muss auch jemand schreiben, oder?

Das Ganze wird noch von einem Agilen-Coach begleitet, man will ja auf Höhe der Zeit sein. Arbeitspakete werden geschnürt und jetzt kann es endlich mit der Implementierung los gehen. Wenn alles gut geht, und das tut es meistens nicht, wird eine Software ausgeliefert und ausgerollt. In einem Testsystem für den geneigten Endkunden, oder vielmehr für eine handverlesene Schar von freundlich gesinnten Kunden - zum ersten Test. Hier stellt man fest, dass einiges nicht geht, fehlt oder nicht so gemeint war. Also zurück zum Agilen-Coach, neue Arbeitspakete, neuer Rollout, neuer Test… und der Eimer hat ein Loch… liebe Liese, liebe Liese.

Hat man sich zum Rollout iteriert, weil die Software fertig ist, oder das Budget alle, je nach dem was zuerst kommt - wird der Rollout geplant. Dieser muss nicht nur zeitlich ein-getaktet und mit allen beteiligten abgesprochen werden, es muss noch die Migration der Altdaten durchgeführt werden, denn man möchte nicht auf die mühsam gesammelten Daten verzichten. Dieses muss vorher geübt werden, Fehler in den Migrationsskripten müssen behoben werden und man dreht weitere Schleifen im Softwareentwicklungsprozess, was wiederum die Kosten treibt. Dann erfolgt das große Zeremoniell der Betriebsübergabe.

Zählt man das ganze zusammen, kommt schon was zusammen. Nicht nur, dass die Software definiert, erstellt und betrieben werden muss, jedes Gewerk hat mittlerweile eine Schar von Spezialisten hervorgebracht, eine Diversifikation hat längst eingesetzt und wird entsprechende der Spezialisierung und Marktlage vergütet.

“Kannst Du mal eben….?” - kann man schon, dann wird es aber scheiße. Jede Änderung an der Software muss einen gewissen Qualitätssicherungsprozess durchlaufen, angefangen vom Peer-Review, Tests - nicht nur der einzelnen Komponente, sondern über alle Stages hinweg, also Staging, Rollout und Übergabe an den Betrieb. “Mal eben” kann, und tut es meist, zu folge schweren Fehlern führen.

“Betrieb: läuft der ganze Kram nicht alleine?” - kurze Antwort: nein… Lange Antwort: Da Software nie fehlerfrei ist, weil diese unter Zeitdruck erstellt oder wegen mangelnder Ressourcen nicht ausgiebig, sprich hinreichend, getestet wurde stürzt hin und wieder ein Prozess ab. Dieser kann automatisch Nachgestartet werden, diese Mechanismen zu implementieren ist nicht trivial, sprich Zeitaufwändig und damit teuer, und auch nicht immer von Erfolg gekrönt sind, müssen weitere technische sowie organisatorische Maßnahmen getroffen werden, um entsprechend schnell reagieren zu können.

“Kann man es auch billiger haben…?” - ja, aber kommt drauf an. Wir haben hier das klassische Dreieck “Budget” - “Qualität” - “Zeit” - man kann aber nur zwei Sachen davon wählen. Was gut werden soll, kostet entweder Zeit oder Geld. Meist fällt die Entscheidung auf Budget und Zeit - d.h. Schnell und Billig. Was das zur Konsequenz hat sehen sie in der nächsten Folge: → “Das andere Ende - IT-Betrieb”