System- und Software-Architektur, das Rückgrat jeder IT Unternehmung

Würde man ein Haus bauen, das eine Million kostet, ohne den Zuzug eines Architekten oder Baufachmannes? Wohl kaum.

Baut man in der Praxis ein IT-System, welches Kosten in Millionenhöhe verschlingt, ohne den Beizug eines Software- oder System-Architekten? Die traurige Antwort kennen wir leider auch.

Wie kommen Städte mit den wachsenden Transportproblemen, Energiezufuhr und Umweltbedingungen zurecht, welche zu lange auf eine systematische Zonenplanung, Stadt- und Verkehrsplanung verzichtet haben und sich stattdessen zu lange mit politischen Querelen verweilt haben?

Und wie sieht es mit der Analogie der Stadtplanung zur IT-Unternehmens-Architektur aus, verweilt man sich nicht gerade hier in grösseren Firmen mit "politischen" Zankereien?

Individuelle Architektur und Ästhetik - Architektur und Foto E. Koch

Das Erstellen einer Architektur ist kein "Jekami", gemeint keine Gruppenaktivität. "Gruppenaktivitäten" tendieren zu zuvielen Kompromissen und verwässerter Systematik. So verwegen es tönt, Einzelpersonen erstellen bessere Architekturen, erreichen zwar keine Perfektion, aber kommen näher zur idealen Lösung. Architektur und Doktrin sind nicht weit voneinander entfernt.

Das Systematische muss aber neben aller Kreativität enthalten sein und Komplexität ist fehl am Platz. Im Gegenteil, einfache, aber durchdachte Konzepte mit System haben eine längere Lebensdauer. Dazu gehört in einer IT-Architektur:

• Modularität
• Schnittstellen
• Kommunikations-Infrastruktur vom Netz bis zur Software (Middleware)
• Normen und Richtlinien

Dass so ein Vorgehen kostenwirksam ist, lässt sich nicht verschweigen (Architektur in der Baubranche ist ja auch nicht vernachlässigbar). Man muss sich hier die Frage stellen, wie es mit den Kosten aussieht, wenn man sich um eine IT-Architektur herummogelt. Es entstehen Kosten in vielen Jahren danach, die zwar immer "nur" in einzelnen Projekten anzufallen scheinen, aber von einer mangelhaften oder fehlenden IT-Architektur herrühren. In jedem Projekt wird "das Rad" oft wieder neu erfunden; gleiche Technologien, Methoden und Werkzeuge werden neu evaluiert und erprobt. Anschlüsse an andere Applikationen werden durch zeitaufwendige und umständliche Art komplexer als nötig. Bestehende Komponenten können nicht benutzt werden, da die Schnittstellen nicht verwendbar sind.

Und wenn das alles so einfach wäre, wieso macht man es dann nicht? Sind Technologie und Methodik so schwierig? Nein, dies ist nicht der Faktor. Der einzige Faktor ist der Mensch und seine Kooperationsbereitschaft. Gerade in der IT-Branche ist es erstaunlich, wie viel Arroganz anzutreffen ist, welche eine Zusammenarbeit mit anderen Fachleuten schwierig macht. Wo man Arroganz antrifft, ist dahinter nur zu oft auch mangelndes Fachwissen anzutreffen (in der Medizin genauso wie in IT und anderen Gebieten). Dadurch dass es menschlich ist, seine Schwächen zu verbergen, gleiten Kooperationsversuche in politisches Gemetzel ab. Es müsste ein Albtraum eines jeden Managers sein, zu sehen, wie viel Geld dabei verloren geht. Wenn man dadurch verursachte fehlende Flexibilität und Reaktionsfähigkeit einer IT-Organisation hinzurechnet, welche neuen Businessanforderungen nicht gerecht werden können, dann würde sogar der Verwaltungsrat keinen ruhigen Schlaf mehr finden.

Eine IT-Architektur wird nicht über Nacht entstehen und sie wird nicht entstehen, solange keine Person dafür verantwortlich zeichnet. Auch wird eine im Elfenbeinturm erstellte IT-Architektur, so wohltönend die zu Papier gebrachten Grundsätze auch sind, nicht in die Praxis umsetzbar sein und von den Projektleitern glattwegs in den Wind geschlagen.

Aber man kann immer etwas tun, wenn die Lösung auch unmöglich scheint. Schrittweise beginnen, das Wichtigste zuerst, und die Toleranz eine Verbesserung auch im Nachhinein machen zu dürfen, führt zum Ziel. Eigentlich ist IT-Architektur wie Qualitätssicherung, wozu sie auch gehören sollte. Sie kommt nicht nur in einer Phase des Projektes zum Zug, sondern muss während dem ganzen Projektzyklus gelebt werden. Dazu gehört viel Kommunikation und Information zu anderen Projekten und umgekehrt.

Stadtplanung vom Feinsten: Edinburgs New Town - Foto ^© Georg Gerster

IT-Architektur ist ein Kommunikationsjob. Ohne Kooperation mit den Projekt-Architekten geht gar nichts, sondern sie wird nach Strich und Faden sabotiert. Entwickler wehren sich typischerweise im ersten Moment gegen jede Art von Richtlinien und sehen erst nach einiger Zeit ein, dass sie ihnen dienen. Oft werden IT-Architekturen auf einer zu abstrakten Ebene angesetzt. Viele Architekten stellen sich vor, dass nur allumfassende und bis in Detail geplante Architekturen von Interesse sind. Es ist aber für eine erfolgreiche Architektur wichtiger, dass sie von den Ausführenden (Projektmitarbeiter) verstanden wird, also kommuniziert werden kann und dies auch wird. Vom Groben ins Detail hilft auch hier.

Dazu gehören:

• "Landkarte", das Applikationslandschaftsbild des Unternehmens
• Eine Kommunikationsplattform mit "Zonenplan" und Ausbaustrategien für die Applikationen (Transportwege im übertragenen Sinne)
• Normen für die nach aussen publizierte Applikations-Schnittstellen
• Datenmodelle für firmenrelevante Daten und in einem weiteren Schritt die Business-Klassenmodelle, welche ersteres miteinschliessen
• Definition von Darstellungsmethoden (z.B. UML, RUP)
• Definition der Basis-Technologien, wie Kommunikationsmiddleware, Programmiersprachen
• Satz von Basiswerkzeugen, wie Datenbank-Systeme, Entwicklerwerkzeuge, Dokumentationswerkzeuge, Middleware, CASE-Tools, Changemanagement Tools, Betriebssysteme, Sprachen. Dies hat aber eher geringere Wichtigkeit.

Auch wenn die gewählte Technologie und die Werkzeuge nicht von höchster Wichtigkeit sind, darf man die Kosten nicht vergessen. Ein falscher Strategieentscheid bei der Technologie, welche nur von einem Hersteller verfügbar ist und nicht mindestens auf de facto-Standards beruht, kann ein IT-Unternehmen zu einem späteren Zeitpunkt in hohe Migrationskosten stürzen. Oder wenn man auf ein Produkt setzt, bei dem die Laufzeit-Lizenzkosten im Laufe der Zeit in schwindelerregende Höhen schiessen, kann das Kosten zum explodieren bringen. Was in der Elektronikindustrie klar gefordert ist, sollte auch in der IT-Branche Fuss fassen, nämlich ein Second-Source- oder Third-Source-Hersteller eines Produktes zu haben. Dies ist natürlich besser möglich, wenn auf offene Industrie-Standards gesetzt wird, wie die von W3 (XML), OMG (CORBA) u.a. Aber wie sieht dies beispielsweise bei JAVA aus, eine Sprache, die Sun Microsystems ihr eigen nennt? Auch da gibt es gewisse Risiken.

Nun, das sind nur einige Aspekte zu IT-Architektur. Wichtig dabei ist, dass man daran geht und in enger Kommunikation mit der Geschäftsleitung (Zielsetzer für das Unternehmen) und mit den internen und externen Applikationslieferanten einen Plan (Siedlungsplan) und gewisse Normen vereinbart und all dies dem laufenden Bedarf und Bedürfnissen des Unternehmens zweckmässig anpasst.

Andres Koch

Editorial

Liebe Leserin
Lieber Leser