Michael Beck

Estimated reading time: 6 Minuten

Tech im Fokus

Prüfstein für Architekturprinzipien

Stellen Sie Ihre Architekturprinzipien auf den Prüfstein In vielen Unternehmen existieren Architekturprinzipien, nach denen die IT-Landschaft gestaltet wird. Sie sollen dafür sorgen, dass die IT-Landschaft nachhaltig weiterentwickelt wird und zukunftsfähig bleibt. Bei vielen Kunden beobachte ich jedoch, dass die Architekturprinzipien diesen Zweck nicht erfüllen. Woran liegt das, und wie lässt es sich vermeiden? Gängige Architekturprinzipien…

Bebauung
Software-Architektur

Stellen Sie Ihre Architekturprinzipien auf den Prüfstein

In vielen Unternehmen existieren Architekturprinzipien, nach denen die IT-Landschaft gestaltet wird. Sie sollen dafür sorgen, dass die IT-Landschaft nachhaltig weiterentwickelt wird und zukunftsfähig bleibt. Bei vielen Kunden beobachte ich jedoch, dass die Architekturprinzipien diesen Zweck nicht erfüllen.

Woran liegt das, und wie lässt es sich vermeiden?

Gängige Architekturprinzipien

Ein Grund dafür, dass Architekturprinzipien ihren Zweck oft nicht erfüllen, ist meiner Erfahrung nach, dass viele von ihnen nicht handlungsleitend sind. Schauen wir uns dafür zwei Beispiele an. Die Beispiele sind den beiden weit verbreiteten Frameworks COBIT®5 und TOGAF®9.1 entnommen.

COBIT schlägt als Architekturprinzip vor: “Kaufen oder bauen: Lösungen sollten käuflich erworben werden, es sei denn, es gibt einen guten Grund dafür, sie intern zu entwickeln.” (Quelle: COBIT®5, Rahmenwerk für Governance und Management der Unternehmens-IT, Anhang G).

Eines der Architekturprinzipien von TOGAF lautet: “Ease-of-Use: Applications are easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand.” (Quelle: The Open Group: TOGAF® Version 9.1, Kapitel 23.6.3). Im Weiteren empfiehlt TOGAF, Anwendungen so zu bauen, dass sie intuitiv bedienbar sind und einem einheitlichen Look-and-Feel folgen.

Diese beiden Architekturprinzipien werden wir nun auf den Prüfstein legen.

Prüfstein für Architekturprinzipien

Edelmetalle reibt man über einen Prüfstein, um ihren Reinheitsgrad und damit ihren Wert zu bestimmen. Dabei entsteht auf dem Prüfstein ein metallischer Strich. Farbe und Helligkeit dieses Strichs werden mit der Farbe und Helligkeit des Strichs einer Probiernadel verglichen, deren Reinheitsgrad bekannt ist. Stimmen Farbe und Helligkeit überein, hat das Edelmetall die gleiche Reinheit wie die Probiernadel.

Auch wir nutzen einen “Prüfstein”, um den Wert von Architekturprinzipien zu ermitteln. Unser Prüfstein ist die Frage, ob ein alternatives oder gar gegenteiliges Architekturprinzip zum selben Aspekt der Architektur ebenfalls denkbar wäre. Ist es nicht möglich, eine solche Alternative zu finden, haben wir kein Edelmetall vor uns, sondern lediglich die Beschreibung einer Selbstverständlichkeit. Ist die Bedingung dagegen erfüllt, bewirkt das Architekturprinzip eine Architekturentscheidung – wir haben ein Edelmetall der Architekturprinzipien vor uns.

Lassen Sie uns die beiden oben erwähnten Beispiele über den Prüfstein reiben: Im ersten Beispiel sind mögliche Alternativen “Wir kaufen Lösungen selbst dann, wenn es sinnvoller wäre, sie intern zu entwickeln.” Oder: “Wir entwickeln Lösungen intern, auch wenn es dafür keinen Grund gibt.” Im zweiten Beispiel könnten die Alternativen lauten: “Anwendungen sind so schwer zu bedienen, dass sich die Anwender nicht mehr auf ihre Aufgaben konzentrieren können.” Oder: “Anwendungen sind nur dann leicht zu bedienen, wenn der Anwender ein Experte für die zugrunde liegende Technologie ist.”

Diese Alternativen sind offenkundig keine sinnvollen Architekturprinzipien.

Probieren Sie ruhig aus, ob Sie Alternativen finden, die Sie Ihrem Management vorschlagen würden. Ich bin sicher, es wird Ihnen nicht gelingen. Die beiden Beispiele haben sich auf unserem Prüfstein somit als unedel erwiesen.

Handlungsleitende Architekturprinzipien

Wie können wir die Beispiele veredeln? Dazu müssen wir sie so formulieren, dass es vernünftige Alternativen gibt, denn nur dann beeinflussen sie Entscheidungen; nur dann sind sie handlungsleitend.

Im ersten Fall kann das Architekturprinzip lauten: „Setze IT-Systeme als Eigenentwicklung um, wenn sie wettbewerbsdifferenzierende Geschäftsfähigkeiten umsetzen, ansonsten als Kaufsoftware.“

Lassen Sie uns dieses Prinzip über unseren Prüfstein reiben: Finden wir eine sinnvolle Alternative? Wie wäre es hiermit: „Setze IT-Systeme als Eigenentwicklung um, wenn sie von sehr vielen Anwendern verwendet werden, ansonsten als Kaufsoftware.“ Die erste Variante wird zu einem geringen Anteil an Eigenentwicklungen führen, da erfahrungsgemäß nur wenige Geschäftsfähigkeiten eines Unternehmens wettbewerbsdifferenzierend sind. Der zweiten Variante liegt die Annahme zugrunde, dass es sich stets lohnt, ein IT-System ganz individuell auf die Bedürfnisse eines Unternehmens zuzuschneiden, wenn nur genügend Anwender davon profitieren. In einem Konzern angewandt würde dieses Prinzip zu einem hohen Anteil an Eigenentwicklungen führen. Test bestanden, beide Varianten sind valide Architekturprinzipien.

Im zweiten Fall versuchen wir es hiermit: „Lege für jedes IT-System Usability-Ziele fest und optimiere das System auf diese Ziele hin.“

Eine intuitive Bedien- und leichte Erlernbarkeit mag ein solches Usability-Ziel sein. Für einen Power-User, der ein IT-System täglich nutzt, kann es jedoch aufgabenangemessener und damit ein Usability-Ziel sein, alle für seine Arbeit nötigen Informationen auf einen Blick zu haben, auch wenn das IT-System dadurch erst nach einer Schulung nutzbar ist.

Alternative gefällig? Hier ist sie: „Baue IT-Systeme für Kunden so, dass sie intuitiv bedienbar sind, und für Mitarbeiter so, dass die Mitarbeiter maximal produktiv sind.“ Diese Alternative führt für die Mitarbeiter zu IT-Systemen, die eine Einarbeitung erfordern, sie dann aber bestmöglich unterstützen. Beide Alternativen sind denkbar – Prüfung bestanden.

Fazit

Architekturprinzipien sind in jedem Unternehmen unverzichtbar. Sie dienen als Leitplanken, die sicherstellen, dass IT-Landschaften nachhaltig und zukunftssicher weiterentwickelt werden. Um dies zu leisten, müssen sie handlungsleitend sein. Ob Ihre Architekturprinzipien das sind, können Sie mit unserer Prüfstein-Frage leicht herausfinden.

Machen Sie den Test, legen Sie Ihre Architekturprinzipien auf den Prüfstein.


Über den Autor

Dr. Michael Beck

Bereichsleiter

Michael Beck ist Executive IT Consultant und entwickelt seit 1984 Software. Nach seinem Studium der Physik, Mathematik und Chemie begann er 2000 seine Laufbahn als IT-Berater. Bei MaibornWolff leitet er den Bereich „Collaborative Enterprise Architecture“, der auf das agile Enterprise Architecture Management spezialisiert ist. Michael Beck fühlt sich in allen Branchen gleichermaßen heimisch. Seine Kunden gehören zur Automobilbranche, zum Transportwesen, zur Chemischen Industrie, zur Finanzdienstleistung, zum öffentlichen Sektor, zur Werbebranche, zur Luftfahrt, zum Agrarsektor, zu den Versicherungen und zu den Versorgern. 

Xing: https://www.xing.com/profile/Michael_Beck122/cv