Architekturmanagement (EAM)

IT-Investitionen lassen sich halbieren

17.11.2010 von Jan-Holger Keuntje
Enterprise Architecture Management (EAM) bietet zwar viele Methoden, IT-Ausgaben zu steuern. Doch führt EAM selten zu Verbesserungen. Ein besseres Architekturmanagement ist notwendig, meint Jan-Holger Keuntje von Steria Mummert.
Jan-Holger Keuntje ist Senior Manager bei Steria Mummert Consulting.
Foto: Steria Mummert Consulting

Jeder zweite Euro, der in IT investiert wird, könnte eingespart - oder zumindest effizienter genutzt werden. Enterprise Architecture Management (EAM) bietet zwar vielfältige Methoden, mit denen IT-Ausgaben besser gesteuert und kontrolliert werden könnten. Doch in vielen Unternehmen führen diese Ansätze nicht zu den gewünschten Verbesserungen. Der Schlüssel liegt in einem effektiven Architekturmanagement.

Ein typisches Szenario: Der Fachbereich stellt die Anforderung, ein neues SAP-Modul einzuführen - die IT setzt dies mit einem Projekt um. Mit der Anforderung wurde also bereits die Lösungsentscheidung, nämlich die Einführung eines SAP-Systems, vorweggenommen. Der Unternehmensarchitekt kann mit Architekturmanagement-Instrumenten, wie einem Bebauungsplan, ex-post nichts mehr ausrichten. Ihm bleibt lediglich die Feststellung, dass für den konkreten Anwendungsfall eine Eigenentwicklung wesentlich günstiger gewesen wäre.

In diesem Zusammenhang lohnt es sich, einen Blick auf die englische Sprache zu werfen: Das Angelsächsische unterscheidet zwischen Demand Management und Requirements Management. Typischerweise beschreibt Demand Management Anforderungen unabhängig von der technischen Lösungsidee.

In der Praxis haben sich Business Capabilities als ein sinnvolles Instrument herausgestellt, um Demands und Anforderungen auf Ebene der Geschäftsarchitektur zu beschreiben. Eine typische Business Capability wäre beispielsweise das Human Capital Management, und ein entsprechender Demand könnte beschreiben, dass die IT-Unterstützung für diese Business Capability verbessert werden sollte. Im Gegensatz dazu beschreibt die Anforderung, SAP HCM einzuführen, ein Requirement, denn hier existiert bereits eine konkrete technische Lösungsidee.

Enterprise Architektur Management sollte in einer integrierten Planungskette zwischen Demand Management und IT Projektportfoliomanagement angesiedelt werden.
Foto: Steria Mummert Consulting

Warum ist diese Unterscheidung so wichtig? Unternehmen, die ihre IT erfolgreich steuern, etablieren das EAM genau in der Lücke zwischen Demands und Requirements: Der Unternehmensarchitekt erstellt einen Bebauungsplan, indem er den Demand, wie die Unterstützung der Business Capability Human Capital Management, in eine konkrete technische Lösungsidee, wie beispielsweise der Einführung von SAP HCM, übersetzt.

Hierdurch wird sichergestellt, dass technische Lösungsentscheidungen nicht lokal, sondern ganzheitlich getroffen werden, und damit insbesondere redundante IT-Lösungen vermieden werden können.

Das Requirement, zum Beispiel eine Lösung wie SAP HCM einzuführen, wird vom Unternehmensarchitekten dann an das IT-Projekt-Portfoliomanagement übergeben, wo es priorisiert, mit Budget ausgestattet wird (oder auch nicht) und anschließend in ein konkretes Projekt überführt wird.

Eine optimale IT-Governance enthält also eine Planungskette, bei der EAM als Bindeglied zwischen Demand Management und IT-Projektportfoliomanagement fungiert. Derzeit arbeiten viele Unternehmen daran, einen solchen integrierten IT-Planungsprozess aufzusetzen.

Wie ein guter Bebauungsplan aussieht

Wie ein guter Bebauungsplan aussieht, beantwortet jedes Unternehmen anders. So finden sich in der Praxis verschiedenste Formen von Anwendungslandkarten genauso wie Prozess-Produkt-Matrizen, in denen die IT-Anwendungen den unterstützten Prozessen und Produkten zugeordnet werden. Hier lässt sich klar beobachten, dass eine reine IT-Anwendungslandkarte mit graphisch visualisierten Schnittstellen nur begrenzt dabei hilft, eine effektive IT-Bebauung zu organisieren.

Bei der Architekturrarbeit sollte zwischen zentraler Unternehmensarchitektur und dezentraler Lösungsarchitektur unterschieden werden.
Foto: Steria Mummert Consulting

Denn: Wie gut oder schlecht eine IT-Anwendungslandschaft ist, entscheidet sich maßgeblich daran, wie gut sie das Business und dessen Demands unterstützt. Mit dieser Dimension tun sich die meisten Unternehmensarchitekten schwer, da es oftmals einfacher ist, sich in der vertrauten Komfortzone der IT zu bewegen, statt die Anforderungen des Geschäftsorganisation inhaltlich zu durchdringen und diese in einer Geschäftsarchitektur abzubilden.

Eine gute Unternehmensarchitektur beschreibt die Geschäftsarchitektur in mindestens drei Dimensionen: Prozesse (die Wertschöpfungssicht), Business Capabilities (die funktionale Sicht) und Produkte. Insbesondere die Darstellung von Business Capabilities wird von immer mehr Unternehmen als wichtiges Konstrukt gesehen, mit dem eine effektive Beurteilung der IT-Unterstützung bzw. des Business/IT-Alignments ermöglicht wird.

Für eine effektive Bebauungsplanung ist es auch wichtig, dass die Geschäftsarchitektur rein fachlich und unabhängig von IT-Anwendungen und technischen Lösungsideen beschrieben wird. Gerade in diesem Punkt zeigt die Praxis, dass die Geschäftsarchitektur oftmals aus den vertrauten IT-Anwendungen abgeleitet wird. Dabei wird es bei einer solchen Herangehensweise schwierig herauszufinden, ob alternative IT-Lösungen die Business Demands vielleicht besser unterstützen könnten.

Unternehmen schaffen zentrale Architekturabteilungen

In vielen Unternehmen entstehen derzeit zentrale Architekturabteilungen für EAM. Häufig entwickeln sich diese Einheiten aus Teams, die sich bisher schwerpunktmäßig mit der Software-Architektur von IT-Anwendungen beschäftigt haben. Neben der Herausforderung, die Dimension der Geschäftsarchitektur nicht (mehr) durch die IT-Brille zu betrachten, muss in der Praxis häufig noch eine weitere Hürde gemeistert werden.

Deutlich wird das mit folgendem Vergleich: Jemand, der als Architekt Gebäude entwirft, sich mit dem modernen Design von Häusern befasst und sich auch mit technischen Details wie der Statik auskennt, dürfte sich schwertun, wenn er eine Stadt planen, also entscheiden soll, wo Industriegebiete gebaut werden oder wo Wohngebiete entstehen sollen.

Übertragen auf die Unternehmensarchitektur bedeutet dies, dass eine ausgeprägte unternehmerische Urteilskraft vonnöten ist, um einen guten Bebauungsplan aufzustellen.

In der Praxis lässt sich keine eindeutige Empfehlung treffen, welche Fähigkeiten ein guter Unternehmensarchitekt haben sollte. Einige Unternehmen gehen gezielt den Weg, dass sie erfahrene IT-Manager mit der Planung und Steuerung der Unternehmensarchitektur betrauen. Andere Unternehmen setzen gezielte Coaching-Maßnahmen auf, um Software-Architekten schrittweise an das weit komplexere Aufgabenfeld eines Unternehmensarchitekten heranzuführen.

Zentrale und dezentrale Architektenrollen trennen

Der Grundsatz "viel hilft viel" ist ein Trugschluss bei der Beantwortung der Frage wie viele Geschäftsprozesse, Business Capabilities oder IT-Anwendungen in einer guten Unternehmensarchitektur abgebildet werden sollen. Spätestens wenn mehrere tausend Prozesse, Business-Capabilities oder IT-Anwendungen in einem Bebauungsplan zusammengefügt werden sollen, ist es fast Unmöglich, den Überblick zu wahren. Denn hier wird dann nicht mehr geplant, sondern konkrete Projektarbeit gemacht.

Ein Unternehmensarchitekt sollte sich daher immer eine Plan/Build/Run-Aufgabenverteilung vor Augen halten: In der Unternehmensarchitektur geht es darum, die IT-Anwendungslandschaft zu planen und nicht die konkrete Lösungsarchitektur zu entwerfen. Dieses ist Aufgabe der Projekte und nicht der Unternehmensarchitektur. In der Praxis hat es sich deshalb als sehr hilfreich herausgestellt, zwischen zentralen und dezentralen Architektenrollen zu unterscheiden.

Jan-Holger Keuntje ist Senior Manager bei Steria Mummert Consulting.