Schatten-IT

Jeder hat es schon gesehen, daß Leute, die oft gar nicht in direkt Informatik arbeiten, sich mit Tabellenkalkulationen anfreunden und dort sogar in recht kurzer Zeit sehr nützliche Dinge zustandebringen. Solange dies Dinge sind, die nur für eine Person nützlich sind, sind alle glücklich und jeder hat seine eigenen Tabellen, man tauscht sie vielleicht sogar aus (natürlich nur innerhalb der eigenen Organisation).

Wenn die Tabellen aber richtig gut sind, dann baut man sie irgendwann in Geschäftsabläufe ein. Irgendwelche Daten werden an Mitarbeiter XY gemailt, der baut sie in seine Tabellenkalkulation auf Laufwerk C: ein und mailt das Ergebnis weiter. Schön, daß wir EMail haben und auch große Attachments möglich sind. Blöd ist nur, wenn XY mal krank ist oder Ferien hat oder gar die Tätigkeit wechselt. Solange es noch in derselben Firma ist, funktioniert noch alles weiter wie gehabt, aber auch das kann mal vorbei sein. Oder das Laufwerk C: kann man unter Gedächtnisverlust leiden, warum auch immer. Deshalb ist man so professionell geworden, die Tabellenkalkulationsdatei auf dem Netzwerklaufwerk M: statt auf Laufwerk C: zu haben. So wird sie beim Backup berücksichtigt und XYs Stellvertreter kann sie dort auch finden, wenn XY mal nicht erreichbar ist. Vielleicht wird auch ein CMS oder ECM statt des Netzwerklaufwerks eingesetzt, was schon etliche Nachteile der Lösung eliminiert.

Weil das alles immer noch ein chaotisches Gebastel ist, muß aber eine richtige Lösung her. Eine „Enterprise“-Lösung. Man kauft eine professionelle Software oder entwickelt sie selber oder läßt sie entwickeln. Allein die Entwicklung oder die Integration der eingekauften Lösung brauchen schon mehr als zehnmal soviel Zeit wie XY insgesamt benötigt hat, um seine Lösung zu entwickeln, obwohl diesmal Informatikprofis am arbeiten sind. Vielleicht sollten wir all unser Fachwissen vergessen und dadurch die Produktivität um Faktor 10 steigern?

Zunächst einmal muß man die beiden Lösungen vergleichen. Was man gewonnen hat, ist durchaus relevant, z.B.:

  • Mehrbenutzerfähigkeit
  • Benutzerverwaltung oder besser noch Integration in das Benutzer und Rollenkonzept
  • Migrationspfade für die Daten
  • Lösung ist an die Organisation und nicht an einzelne Personen gebunden
  • Datensicherheit besser beherrschbar als wenn Daten auf Laptop liegen
  • Besseres Backup
  • Erweiterbarkeit

Lohnt sich dafür der zehnfache Aufwand? Wenn die Applikation wichtig ist, normalerweise schon. Und die Tabellenkalkulationslösung ist wahrscheinlich sogar hilfreich gewesen, weil sie dazu beigetragen hat, wirklich gut zu verstehen, was man mit der Applikation tun will.

Aber die Frage, ob die Entwicklung der Applikation nicht zu lange dauert, ist schon berechtigt. Gewonnen hat man in diesem Fall schon, daß gut bekannt ist, was entwickelt werden soll. Aber das „wie“ läßt noch viele Möglichkeiten offen. Ist der Entwicklungsprozeß gut genug? Werden die Leute optimal eingesetzt? Können sie an der Aufgabe arbeiten oder hauptsächlich an administrativen Aufgaben? Ja, das ist eine sehr berechtigte Frage, vielleicht schreibe ich dazu mal etwas. Wird die richtige Architektur eingesetzt? Ist die Lösung zu kompliziert? Oder zu einfach (und funktioniert nachher doch nicht so)? Wird die richtige Technologie eingesetzt? Ich finde es sinnvoller, ab und zu etwas neues zu lernen als den „goldenen Hammer“ zu pflegen, mit dem jede Schraube wie ein Nagel aussieht.

Konkreter: Für eine Applikation, deren Funktionalität in eine Tabellenkalkulation gepaßt hat, ist so ein klassischer „Enterprirse-Stack“ mit Java, EJB, Oracle oder DB2, Weblogic u.s.w. sicher fast immer zu aufwendig.

Share Button

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.


*