26.05.2008
SCCM setzt Kapazitäten frei
Beim SCCM sehen viele nur die Kosten. Richtig aber ist: Investitionen in SCCM rentieren, denn SCCM befreit den Entwickler nachhaltig von repetitiven, fehleranfälligen und zeitraubenden Verwaltungsarbeiten.
Seit Software entwickelt wird, stellt sich die Aufgabe SCCM. Selbst wer nur ein einziges Modul schreibt und dann davon eine neue Version macht, dem stellt sich die Aufgabe, das alte und das neue Exemplar voneinander zu unterscheiden: Er löst die Aufgabe durch Versionierung – gibt dem neuen Artefakt eine neue Versionsnummer.
Wenn die Aufgaben wachsen, nehmen die SCCM-Aufgaben zu. Wenn er etwa auf eine frühere Version eines Artefakts zugreifen muss, oder wenn er sicherstellen muss, dass er alle zu einer Änderung gehörenden Artefakte auf die nächste Teststufe anhebt, dann benötigt er ein stark automatisiertes SCCM – sonst macht er zu viele Fehler, und die Verwaltung kostet ihm zu viel Zeit.
Kurz: Wer Software entwickelt, löst die SCCM-Aufgaben, er kommt nicht darum herum – wenn nicht automatisiert, dann manuell, wenn nicht rationell, dann unnötig aufwendig. Obwohl SCCM also ein Muss ist, schenkt ihm das Management nicht die Aufmerksamkeit, die es verdiente.
SCCM ist nicht direkt wertschöpfend, so wenig wie die Buchhaltung. Für etwas anscheinend Unproduktives Geld ausgeben? Dafür ist der Manager kaum zu haben. Bei der Buchhaltung und bei Sarbanes-Oxley tun er’s, weil das Gesetz ihnzwingt, beim SCCM tut er es meistens erst dann, wenn die Fehler sich häufen, wenn die Entwickler mehr verwalten als entwickeln, von Brandherd zu Brandherd eilen, um Fehler zu beheben, die wegen Mängel im SCCM verursacht worden sind.
Das Management verkennt den Wert des SCCM, weil es oftmals nicht richtig weiss, worum es beim SCCM geht und welcher Nutzen drin steckt. So lässt es das SCCM links liegen, und täglich stolpern Benutzer, Entwickler – und Manager – über die Folgen eines ungenügenden SCCM: Da fehlt in einer Installation ein Modul, oder es steckt die falsche Version des Moduls in der Installation. Der Benutzer findet im neuesten Release Fehler aus dem vorletzten Release, die aber im letzten korrigiert waren. Ein Entwickler vermisst seine Änderungen, weil ein Kollege das betreffende Modul mit einer anderen Version überschrieben hat. Ein anderer Entwickler stellt fest, dass heute nicht mehr läuft, was gestern noch funktionierte, weil ein Kollege ein Interface geändert hat.
Das Schlimme: Jeder tut was er kann, jeder macht seinen Job nach bestem Wissen und Gewissen, jeder gibt sich Mühe, hat Mühe und vergeudet Zeit! Und das nur, weil das SCCM (zu) wenig organisiert und automatisiert ist. Er muss sich um eine langweilige und fehlerträchtige Arbeit kümmern, die eine Maschine schneller und zuverlässiger löst.
Ist hingegen das SCCM sinnvoll geregelt und automatisiert, geht alles viel leichter: Die Zeit, die der Entwickler früher für das Suchen und Beheben von Fehlern verbrauchte, hat er jetzt zum Entwickeln, denn das SCCM spielt sich zum grössten Teil unbemerkt und automatisch im Hintergrund ab.
Fazit: Angemessenes, so weit wie möglich automatisiertes SCCM vermeidet Fehler und ihre kostspieligen Folgen. Es nimmt dem Entwickler Verwaltungsaufwand ab, so dass dieser mehr Zeit hat zum Entwickeln. Benutzern und Managern bleiben die unangenehmen Folgen ungenügenden SCCMs erspart. Investitionen ins SCCM machen sich rasch bezahlt.
Was für Erfahrungen haben Sie gemacht?
