MIDRANGE 10/2016 - page 42

42
MARKTÜBERSICHT
SW-ENTWICKLUNG UND -MODERNISIERUNG
MIDRANGE
MAGAZIN · 10/2016
47 Jahre Software-Entwicklung und Projektmanagement
Generationenwechsel =
Sourcecode ade?
Software-Entwicklung, Software-Modernisierung und Software-Ablöse stellen so manchen
IT-Verantwortlichen vor die schwierige Entscheidung der Produktwahl. Eine weitere praxis­
bewährte Alternative zu den klassischen Software-Techniken bereichert dieses Marktsegment.
U
m Applikationen entwickeln oder
verändern zu können, müssen Sie
unbedingt kompilieren können und
über ausreichende Kenntnisse an Pro-
grammiersprachen und IT-Know-how
verfügen. Das Erlernen dieser oft ser-
ver- und datenbankspezifischen Pro-
grammier- bzw. Script-Sprachen kann
Monate oder gar Jahre dauern.
Eine spontane Applikationswar-
tung im produktiven Umfeld ist
bedingt durch Objektsperren
etc. risikobehaftet und in der
Praxis kaum möglich. Die An-
zahl der Source- und ausführba-
ren Objekte wird immer unüber-
schaubarer und geht teilweise
in die Zehntausende. Entwick-
lungs- und Testumgebungen
sowie Versionierungskonzepte
gefolgt von Namenskonventionen kön-
nen ihrem ursprünglichen Zweck nicht
mehr gerecht werden. Bedingt durch
„natürliche“ Fluktuation und die „an-
geborene“ Kreativität von Programmie-
rerinnen und Programmierern entstan-
den mehr und mehr Source-„Leichen“
in einer „unantastbaren“ Grauzone.
Selbst wenn Sie zu den Glücklichen
zählen, die ihre Sourcen im Griff ha-
ben, stehen Sie vor dem Problem, Ihre
Applikationen für heterogene Server‑,
Datenbank- und Client-Umfelder ab-
stimmen zu müssen. Mangels perso-
neller Ressourcen im Zeichen rasant
zunehmender Technologieänderungen
und kürzerer Lebenszyklen von Ap-
plikationen mehren sich die Entschei-
dungsrisiken, was folglich zu massiven
Kosten- und Terminüberschreitungen
bei IT-Projekten führen kann.
Migration und die Guifizierung
von historischen Applikationen lösen
weder die funktionalen Defizite, noch
erhöhen sie die Wartbarkeit. Vielmehr
wird dabei Sourcecode generiert, der
bis zum Zehnfachen anwachsen kann,
kaum lesbar ist und einen weiteren
Komplexitätshype auslöst.
Bei zugekaufter Software (Stan-
dard-Software, Quelle: Wikipedia) ist
im Regelfall der Sourcecode für den
Anwender nicht verfügbar. Sollte dies
wider Erwarten doch möglich sein, be-
steht die berechtigte Annahme, dass
man sich nicht zurechtfindet. Und
wenn doch, dann besteht dennoch die
Gefahr, dass der Software-Hersteller
Support, Wartung und Release-Wechsel
gesondert berechnet, verweigert oder
nicht vollends unterstützt – was letzt-
lich zu einem erheblichen Verlust von
Vorteilen einer Standard-Software füh-
ren kann.
Da Sourcecode auch bei DB-Defini-
tionen, Datenströmen etc. Anwendung
findet, besteht sehr oft der Irrglaube,
dass bei einem Serverwechsel von
OS400 auf andere die Bequem-
lichkeit der integrierten Daten-
bank ohne Einbußen weiterhin
verfügbar wäre. Bedingt durch
Produktzwänge auf den soge-
nannten offenen Plattformen
kann hier nur von einem Wech-
sel in ein anderes „proprietäres“
System gesprochen werden.
Manche
Software-Konzerne
zwingen ihre Kunden oder Dritt­
anbieter zu kostenpflichtigen
Zusätzen, um auf ihre eigenentwickel-
ten Datenbanken zugreifen zu können.
Die Vorteile von Standard-Software,
professionell präsentiert und durch at-
traktive Einstiegskosten dem Manage-
ment schmackhaft gemacht, dürfen
nicht darüber hinwegtäuschen, dass
die Abhängigkeit vom Software-Haus
langfristig gegeben ist. Erzwunge-
ne Kompromisse bis hin zu Firmen­
umstrukturierungen können ebenso
wie überbordende Funktionen und
starre Abläufe die Folge sein.
Um Kunden ihre Flexibilität und
Spontaneität bei der Applikationsge-
staltung sowie Anwendern ihre ver-
© Emsenhuber
1...,32,33,34,35,36,37,38,39,40,41 43,44,45,46,47,48,49,50,51,...52
Powered by FlippingBook