Software kann man bekanntlich nicht anfassen, die Analyse von zigtausend Programmzeilen würde Jahre dauern, also vermittelt der Anbieter dem Kunden seine Systemarchitektur gerne durch ein Diagramm. Dies sieht immer nach Baukastenprinzip aus. Der erstaunte Zuseher findet dort Ebenen mit bestimmten Aufgaben, Module die sich gegenseitig unterhalten, Schnittstellen und so weiter und so fort…
Meist sieht das wie obige Grafik aus, manchmal sogar noch komplexer, je nachdem wie gut der Anbieter seine Welt vermitteln kann oder will. Für die Bauklötze werden Begriffe wie Schichten, Layer, Module, Moduls, Objekte, Objects, Klasse, Class, Rahmenwerk, Framework und viele andere mehr verwendet.
Diese Architekturdiagramme haben alle eines gemeinsam, sie stimmen mit der wahren Welt nicht überein. Selbstverständlich strebt die Informatik spätestens seit der Softwarekrise in der Mitte der 1960er-Jahre danach, Software in Module aufzuteilen, in Objekte zu kapseln oder in Ebenen zu abstrahieren. Auch sind 90% dieser Architekturdiagramme aller Ehren wert. Jedoch ist die Vorstellung eines Baukastens viel zu naiv.
Stellen sie sich vor: Ein 3 Jahre altes Modul soll für etwas ähnliches Neues erweitert werden. Das bedeutet für das „Neue“ weniger Aufwand, aber alles „Alte“ muss nachgezogen und nachgetestet werden. Unter Projektdruck wird da z. B. schnell und schmutzig das alte Model kopiert, umbenannt und aufgerüstet. Nach einer Zeit entsteht aus den Anfangs wohlgetrennten Ebenen so etwas wie Filz. Auch andere technische Einflüsse sorgen dafür, dass vieles eben doch kein Baustein ist, sondern mit Messer und Heisskleber eingepasst wurde.
Manchmal wird auch eine uralte Softwarebasis mit einem topmodernen Überbau versehen, so dass es von außen frisch lackiert aussieht. In der IT Industrie heißt das Enterprise Application Integration (EAI), wie das beim Gebrauchtwagenhändler heißt, wissen Sie ja. Im Prinzip keine schlechte Idee. Der Nachteil ist, durch die moderne Schicht wird eine Flexibilität suggeriert, die das alte Schätzchen darunter gar nicht hergibt. Also muss doch wieder jemand in den Keller kriechen, das ist Spezialistenarbeit, teuer und langwierig.
Den Architekturdiagrammen kann das ein oder andere Mal angesehen werden, dass Sie nur etwas vorgaukeln. Ein guter Projektmanager kann aus dem Mix aus Technologien oder Vermischung von Schichten schon einiges ableiten und klärende Fragen stellen. Auch zu detaillierte Diagramme sind ein Indiz für nicht erst gemeinte Offenheit. Lassen Sie am besten einen technisch versierten Menschen aus Ihrem Haus mit einem langjährigen Ingenieur des Anbieters sprechen, um zu klären was Realität und was Wunschdenken ist.
Quintessenz
- Architekturdiagramme helfen eher die Ideen des Anbieters zu verstehen, als die Qualität des Produktes bewerten zu können. Lassen Sie sich nicht blenden.
- Die gewählten Bezeichnungen für die Bauklötze und Ebenen sind auf diesem Niveau unwichtig. Eher eine Frage des Zeitgeistes.
- Planen Sie eine technische Integration, so ist unbedingt eine technische Analyse notwendig. Auch eine Offenlegung des Quellcodes ist anzuraten.
- Im übrigen gilt oben gesagtes vermutlich auch für Ihre eigenen Produkte. Lauschen Sie auch den Ausführungen des technischen Beraters der Anbieterseite. Holen Sie sich Hilfe vor Abschluss des Geschäfts.
Weiterlesen
Dieser Artikel ist Teil meiner Reihe IT Fundamentals. Auf diese Reihe können Sie sich gerne abonnieren, tragen Sie einfach Ihre E-Mail-Adresse ein, dann erhalten Sie stets einen Link zum neuesten Artikel.
Ich hoffe es hat Ihnen gefallen. Viele Grüße Werner Roth