Steuerung des Architekturmanagements durch das IT-Controlling

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Architekturmanagement als Informatik-Prozess
2.1 Definition Architekturmanagement
2.2 Ziele und Aufgaben des Architekturmanagements
2.3 ACMM als evolutionäres Modell des Architekturmanagements

3 IT-Controlling des Architekturmanagements
3.1 Architekturmanagement als Objekt des IT-Controllings
3.2 Definition von Kennzahlen im Controlling
3.3 Anforderungen an Architekturmanagement-Kennzahlen

4 Beurteilung des IT Architecture Capability Maturity Model
4.1 Unterstützung der Zielsetzungen des Architekturmanagements
4.2 Anforderungen an Controlling-Kennzahlen
4.3 Anforderungen an Kennzahlen des Architekturmanagements
4.4 Zusammenfassung

5 Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1 Überblick Architekturverständnisse in der Literatur

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Unternehmen sind heutzutage vielfältigen Einflüssen ausgesetzt, dazu zählen u.a. ver­änderte, unsichere Markt- und Wettbewerbsbedingungen, Globalisierung, Internatio­nalisierung, Marktsättigung, kürzeren Produktlebenszyklen, aber auch technologische Innovationen (Schmelzer und Sesselmann 2004, 1). Diese Entwicklungen erhöhen die Komplexität und Informationsintensität der Unternehmensprozesse, so dass die Rolle der IT als Erfolgsfaktor auch künftig zunehmen wird (Krcmar 2010, 542). Diese Um­stände führen dazu, dass das „Controlling boomt“ (Kütz und Meier 2007), da es eine essenzielle Führungshilfe ist (Küpper 1997, 19). Diese Entwicklungen beeinflussen direkt die gesamte Unternehmensarchitektur. Unter Unternehmensarchitekturen ver­steht man Modelle zur Abbildung von Unternehmen mit deren Strategie, Geschäfts­prozessen sowie in der Informatik und dienen u.a. als Kommunikationsmittel und Ko­ordinationsbasis für Projekte (Krcmar 1990).

Im Folgenden wird der Fokus auf das Architekturmanagement gelegt und es soll un­tersucht werden, inwiefern das Architekturmanagement durch das IT-Controlling an­hand geeigneter Kennzahlen gesteuert werden kann, um einen effizienten und effekti­ven Einsatz der IT im Unternehmen zu gewährleisten.

Im folgenden Kapitel wird zunächst das Architekturmanagement definiert und damit verbundene Ziele und Aufgaben erläutert. Zusätzlich wird das IT Architecture Capab­ility Maturity Model (ACMM) des US Department of Commerce (DoC) als Reifegrad­Modell des Architekturmanagements vorgestellt, um es anschließend hinsichtlich sei­ner Anwendbarkeit als Steuerungsmittel zu beurteilen. Das ACMM wurde als Betrach­tungsgegenstand aufgrund der geringen Komplexität im Vergleich zu anderen Archi­tekturmanagement-Frameworks wie TOGAF (The Open Group 2006) oder Zachman (J.A. Zachman 1987) und der Bekanntheit in der Literatur ausgewählt. Dazu wird das Architekturmanagement zunächst als Objekt identifiziert, das eines speziellen Con­trollings bedarf. Auf Grundlage einer Literaturrecherche werden Anforderungen an Controlling-Kennzahlen im Allgemeinen und für das Architekturmanagement im Spe­ziellen aufgestellt. Zum Abschluss erfolgt dann die Beurteilung des ACMM anhand der zuvor ermittelten Anforderungen.

2 Architekturmanagement als Informatik-Prozess

Zunächst wird ein komprimierter Überblick über verschiedene Architekturverständ­nisse gegeben, um anschließend Derns Architekturpyramide als dieser Arbeit zu Grunde liegendes Modell vorzustellen. Diesbezüglich wird der Begriff des Architek­turmanagements definiert und dessen Ziele erläutert. Abschließend wird das IT Archi­tecture Capability Maturity Model (ACMM) des US Department of Commerce (DoC) vorgestellt, das ein Reifegrad-Modell des Architekturmanagements ist.

2.1 Definition Architekturmanagement

Der Begriff Architekturmanagement setzt sich aus Architektur und Management zu­sammen. Während für den zweiten Bestandteil schon ein intuitives Verständnis aus­reichend sein mag, ist der Begriff der Architektur schwieriger zu fassen und auch in der Literatur finden sich unzählige Definitionen, die sich teilweise nur in Nuancen unterschieden. Man kann hier durchaus von einer „babylonische[n] Sprachverwir­rung“ (Esswein und Weller 2008, 6) sprechen.

Krallmann, Bobrik und Levina analysieren allgemeine und spezielle Architekturdefi­nitionen in der Literatur (vgl. hier und im Folgenden Krallmann, Bobrik und Levina 2013, 25-34; Aier 2006, 101ff.). Allgemein verknüpft eine Architektur im Kontext der Wirtschaftsinformatik Organisation mit der IT und ist daher ein sozio-technisches Sys­tem. Die Architektur als solche kann in die Ebenen Strategie, Organisation, Fachliches Konzept, Technisches Konzept und Technologie aufgegliedert werden. Als Ziele von Architekturen werden vor allem die Nachhaltigkeit und Beherrschbarkeit der Archi­tektur benannt, so dass eine effiziente IT-Unterstützung der Geschäftsprozesse sicher­gestellt ist.

Abbildung 1 zeigt vier in der Literatur weitverbreitete, verschiedene Architekturan­sätze: von Foegen, Dern, Krcmar und Hafner/Schelp/Winter. Die Architekturen wer­den anhand der genannten Ebenen verglichen und deren Ausprägungen gezeigt. Die hauptsächlichen Unterschiede der Ansätze liegen im Detailgrad der Ebenen und der inhaltlichen Tiefe. Es werden für jedes Im Folgenden wird das Architekturverständnis von Dern zu Grunde gelegt und näher erläutert, da in diesem Modell der Schwerpunkt stärker auf das Architekturmanagement liegt (Dern 2009, 16-30). Darüber hinaus ist Derns Architekturverständnis im Vergleich zu den anderen vorgestellten Architektur­verständnissen ganzheitlich ausgeprägt mit den umfassendsten Ausprägungen in den Ebenen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Überblick Architekturverständnisse in der Literatur

angelehnt an Aier 2006, 117 und Krallmann, Bobrik und Levina 2013, 34; erweitert mit Dern 2009, 20

Derns Architekturpyramide ist hierarchisch angeordnet, beginnend mit der Business­Architektur über die Informationsarchitektur als Business/IT-Alignment-Schnittstelle bis zur IT-Basisinfrastruktur als technologische Grundlage. Jede dieser Ebenen wird im Folgenden weiter präzisiert (Dern 2009, 16-30).

Die Business-Architektur, ausgehend von der Strategie als Spitze der Architekturpy­ramide und somit auch Ausgangspunkt, beschreibt formalisiert die geschäftliche Aus­richtung des Unternehmens. Dazu werden die Business-Treiber beschrieben und die Prozess- und die Organisationsarchitektur definiert. Die Prozessarchitektur umfasst dabei die für das Unternehmen notwendigen Businessfunktionen und deren Informa- tionsbedarfe (Dern 2009, 16-30).

Dern (2009) definiert die Informationsarchitektur als Wegweiser für die Gestaltung der IT im Unternehmen. Sie gibt dafür strukturierende Prinzipien und Regeln in Form des IT-Portfolios, der Technologiestrategie und der Architekturstrategie und -prinzi­pien vor. Das IT-Portfolio ist eine Systematisierung aller Informationssysteme und de­ren Abhängigkeiten und Wechselwirkungen. Es wird dabei zwischen dem tatsächlich vorhandenen Ist-Portfolio und den angestrebten Soll-Portfolio unterschieden. Die

Technologiestrategie gibt Leitlinien für die IT-Basisinfrastruktur und allen IT-Archi­tekturen vor und berücksichtigt auch absehbare technologische Entwicklungen. Die Architekturstrategie definiert den Zielzustand der Architekturen mitsamt eines Maß- nahmenkataloges. Eine Definition der Grundsätze aber auch Standards sowie allge­meine Vorhaben in Bezug auf Technologie und Produkt für die Weiterentwicklung des IT-Portfolios und der IT-Architekturen sind in den Architekturprinzipien enthalten (Dern 2009, 16-30).

Die IT-Architekturen - eines für jedes Informationssystem - teilen sich in eine dyna­mische und eine statische Sicht. In der dynamischen Sicht wird aufgrund der Beschrei­bung, Erstellung und Einführung des Informationssystems ein Modell des Software- entwicklunsgprozesses (SE-Prozess) zugeordnet. Die statische Sicht beschreibt die strukturgebenden Komponenten des Informationssystems, auch Anwendungsarchitek­tur genannt: die fachliche Architektur (Funktionalität und Daten), die Softwarearchi­tektur und der System- und Sicherheitsarchitektur (Abbildung auf die IT-Basisinfra- struktur) (Dern 2009, 16-30).

Die IT-Basisinfrastruktur ist die gesamte Hardware mit systemnahen Softwarekompo­nenten, die für die Entwicklung und Betrieb der Informationssysteme benötigt wird. Diese Komponenten werden zu Basisplattformen für Informationssysteme gruppiert. Die IT-Basisinfrastruktur umfasst neben den Basisplattformen noch die Plattform- und die Sicherheitsstrategie (Dern 2009, 16-30).

Dern (2009) definiert für jede Detailarchitektur und z.T. auch für deren Komponente eigene Management-Prozesse. Unter Architekturmanagement wird im Folgenden vor allem die Architekturplanung (Strategie, Prinzipien, Technologie) und -entwicklung unter Berücksichtigung des IT-Portfolios verstanden (Dern 2009, 65). Aspekte der IT- Management-Definition sollen auch für das Architekturmanagement gelten, so dass das Architekturmanagement als Prozess verstanden wird, „der Entscheidungen zur In­formationsarchitektur, zum IT-Projektportfolio und der IT-Basisinfrastruktur auf der Grundlage der Business-Architektur eines Unternehmens herbeiführt“ (Dern 2009, 64).

Zusammenfassend umfasst das Architekturmanagement die Dokumentation, Analyse, Planung, Entwicklung und Steuerung der Informations- und hierarchisch niedrigeren Architekturen (Dern 2009, 64; Heinrich und Stelzer 2009, 62). Im nächsten Abschnitt 2.2 wird auf die Ziele und Aufgaben des Architekturmanagements eingegangen für eine anschließende Beurteilung des ACCM.

2.2 Ziele und Aufgaben des Architekturmanagements

Unter Berücksichtigung der Architektur-Definition (s. Abschnitt 2.1) ist es verständ­lich, dass zahlreiche Zielsetzungen, und sich daraus ergebende Aufgaben, mit dem Architekturmanagement verfolgt werden. Man kann die in der Literatur genannten Ziele in drei Kategorien verdichten: die Erhöhung des Wertschöpfungsbeitrages, eine nachhaltige Weiterentwicklung der IT und eine effizientere und effektivere Steuerbar­keit der IT. Diese Kategorien werden im Folgenden näher erläutert.

Zur Erhöhung des Wertschöpfungsbeitrages gehören weitere Zielsetzungen:

- Unterstützung des Business/IT-Alignments (Schmidt 2009, 67; Dietzsch 2008, 51)
- Kernprozesse des Unternehmens besser unterstützen durch Verkürzung der Durchlaufzeiten und Erhöhung der Qualität der Kernprozesse (Krüger und Seelmann-Eggebert 2003, 253)
- Akzeptanz der IT-Systeme und Zufriedenheit der Anwender steigern (Krüger und Seelmann-Eggebert 2003, 253)
- Erhöhung der Produktivität durch Erhöhung des Kosten-Nutzen-Verhältnisses der Architektur erhöhen, allgemein Erhöhung der IT-Effizienz und IT-Kosten- reduzierung (Krüger und Seelmann-Eggebert 2003, 253; Schmidt 2009, 67)
- die Architektur durch die Organisation besser unterstützen und für die IT-Ar- chitektur verantwortliche Personen etablieren (Krüger und Seelmann-Eggebert 2003, 253)
Für eine nachhaltige Weiterentwicklung der IT
- Soll-/Zielbilder entwickeln (Dietzsch 2008, 51)
- Anforderungen der Fachbereiche erfassen und zukünftige Anforderungen ab­leiten (Dietzsch 2008, 51; Krüger und Seelmann-Eggebert 2003, 31-33)
- Transparenz der Architektur erhöhen (Krüger und Seelmann-Eggebert 2003, 253; Schmidt 2009, 67)
- Flexibilität der Systeme steigern (hier und nachfolgend Krüger und Seelmann- Eggebert 2003, 253)
- Integrationsgrad erhöhen
- Komplexität der IT-Systeme reduzieren
- Redundante Funktionalitäten reduzieren Die Steuerbarkeit der IT
- verbesserte Planbarkeit (Stutz 2009, 27f)
- organisatorische Effektivität (Stutz 2009, 27f)
- Umsetzung der strategischen Planung und Steuerung der IT-Landschaft
- Reduzierung "Time to Market" (Schmidt 2009, 67)
- Verkürzung der Entwicklungszeiten (Schmidt 2009, 67)
- Beherrschung der Komplexität der IT-Landschaft (Aier 2006, 187)
- Standardisierung und Wiederverwendung von Services durch Konsolidierung der IT-Landschaft (Schmidt 2009, 67; Aier 2006, 186)
- Flexibilisierung der IT-Landschaft mittels Modularisierung (Aier 2006, 184)

2.3 ACMM als evolutionäres Modell des Architekturmanagements

Das US Department of Commerce (DoC) hat das IT Architecture Capability Maturity Model (ACMM) entwickelt, das das Architekturmanagement als evolutionäres System modelliert (vgl. hier und im Folgenden The Open Group 2006). Es besteht aus sechs Evolutions-Stufen (None, Initial, Under Development, Defined, Managed und Meas­ured), neun allgemeinen Architekturmanagement-Charakteristiken (IT Architecture Process, Business Linkage, Senior Management Involvement, Operation Unit Partici­pation, Architecture Communication, IT-Security, Architecture Governance, IT In­vestment and Acquisistion Strategy) und zwei komplementäre Berechnungsmethoden zur Bestimmung des Architektur-Reifegrades. Im Folgenden werden die Ausprägun­gen der Architektur-Charakteristiken der jeweiligen Stufe vorgestellt und im An­schluss die Berechnungsmethoden erläutert.

Die Ausgangssituation (None) ist dadurch gekennzeichnet, dass kein explizites Archi­tekturmanagement existiert und somit auch keine Charakteristiken erfüllt werden.

In der ersten Stufe (Initial) wird das Architekturmanagement ad-hoc betrieben und ist weder Technologie-übergreifend ausgestaltet noch auf Business-Prozesse oder Strate­gien ausgerichtet. Es gibt verschiedene Dokumentationen und Standards, welche, so­fern sie überhaupt formal definiert sind, ebenfalls lokal ausgerichtet und ad-hoc ent­wickelt sind. Das IT-Management ist sich nicht/kaum eines bewussten Architekturma­nagements bewusst oder nicht involviert. Gleiches gilt für die Akzeptanz durch das IT-Personal. Eine konkrete Kommunikationsstrategie existiert nicht. Das IT-Sicher- heitsmanagement wird wie das gesamte Architekturmanagement ad-hoc umgesetzt. Es ist keine Governance von Architektur-Standards implementiert. Eine strategische Pla­nung von Investition und Akquisitionen findet kaum oder nicht statt.

Die zweite Stufe (Under Development) ist durch die Implementierung grundlegender Aspekte in allen neun Charakteristiken gekennzeichnet. Ein Basis-Architekturma- nagement-Prozess ist dokumentiert und klare Rollen und Verantwortlichkeiten sind definiert. Gleiches gilt für das IT-Sicherheitsmanagement. Das IT-Management ist sich der Notwendigkeit des Architekturmanagements bewusst. Dem IT-Personal sind die definierten Rollen und Verantwortlichkeiten zugewiesen. Die Zielarchitektur ist identifiziert und an die IT-Vision ausgerichtet. Ein Business-IT-Alignment hat hierfür stattgefunden. Architekturstandards existieren, sind aber nicht notwendigerweise mit der Zielarchitektur verbunden. Grundlegende technische Modelle, Standards und Frameworks sind etabliert und teilweise Bestandteil der Architektur-Governance und konsolidiert. Zusätzlich wird die Architekturdokumentation regelmäßig aktualisiert. IT-Investition und Akquisitionen sind im Rahmen einer Governance wenig bzw. nicht kontrolliert. Zudem existiert eine entsprechende Strategie nicht.

In der dritten Stufe (Defined) ist das Architekturmanagement detailliert definiert, do­kumentiert und kommuniziert. Der Prozess wird weitestgehend eingehalten. Ein Soll/Ist-Vergleich der Architektur hat stattgefunden und ein Migrationsplan entwi­ckelt. Des Weiteren sind die IT-Ziele definiert und entsprechende Methoden identifi­ziert. Die Architektur wird bei der Kapitalplanung integriert und Investitionen kontrol­liert. Darüber hinaus unterstützt das IT-Management aktiv das Architekturmanage­ment. Die meisten IT-Organisationseinheiten akzeptieren und partizipieren am Archi­tekturmanagement. Entsprechend wird die Dokumentation regelmäßig aktualisiert. Das IT-Sicherheitsmanagement ist ganzheitlich in das Architekturmanagement inte­griert. Die meisten IT-Investitionen werden durch eine dokumentierte Governance ab­gedeckt. Eine IT-Akquisitions-Strategie ist existiert und enthält Compliance-Metriken für die Architektur.

In der vierten Stufe (Managed) wird das Architekturmanagement anhand von Metriken gesteuert. Das Architekturmanagement ist Teil der Unternehmenskultur und Qualitäts­metriken sind definiert. Die Dokumentationen werden regelmäßig aktualisiert und überprüft. Die Architektur ist ganzheitlich (Business, Daten, Applikationen, Techno­logie) definiert (vgl. hier z.B. Architekturpyramide Dern 2003). Kapitalplanung und Investitionskontrolle enthalten Feedbackschleifen. Das IT-Management ist direkt in­volviert beim Architektur-Review. Alle IT-Organisationseinheiten akzeptieren und partizipieren beim Architekturmanagement. Die IT-Sicherheit wird anhand von Per­formance-Metriken gemessen. Alle IT-Investitionen werden von einer expliziten Governance erfasst und die Prozesse enthalten Feedbackschleifen zur Verbesserung der Governance. Alle geplanten IT-Investitionen und Akquisitionen werden aus dem Architekturmanagement heraus gesteuert.

In der letzten Stufe (Optimizing) wird das Architekturmanagement kontinuierlich ver­bessert. Es werden bewusste Anstrengungen, auch durch das IT-Management, unter­nommen, das Architekturmanagement kontinuierlich zu optimieren und zu verbessern. Dies wird durch einen Prozess geleitet. Das Business-IT-Alignment wird hierbei un­terstützt und durch konkrete Metriken gesteuert. Feedback aller Organisationseinhei­ten wird genutzt um das Architekturmanagement zu verbessern. Die Dokumentationen werden von allen Entscheidungsträgern bzgl. IT-relevanten Themen genutzt. Die Met­riken des IT-Sicherheitsmanagements werden auch im Architekturmanagement ent­sprechend berücksichtigt. Alle IT-Investitionen und Akquisitionen sind geplant und durch eine explizite Governance gesteuert. Der Governance wird kontinuierlich ver­bessert.

Das ACMM bietet zwei Methoden zur Bestimmung des Reifegrades an. Grundlage ist in beiden Fällen die Bewertung jedes Charakteristikums auf einer situativ gewählten Skala. Die erste Methode (A) ist ein gewichteter Mittelwert der Stufen. Die zweite Methode (B) zeigt die prozentuale Zielerreichung der neun Architektur-Charakteristi­ken auf jeder Stufe.

3 IT-Controlling des Architekturmanagements

Nachdem bisher das Architekturmanagement vorgestellt worden ist, werden im fol­genden Kapitel Grundlagen des IT-Controllings betrachtet. Dazu wird das IT-Control- ling definiert und dessen Betrachtungsgegenstände, Ziele und Aufgaben erläutert. Im Anschluss wird das Architekturmanagement als IT-Controlling-Objekt identifiziert und inhaltlich begründet. Als nächstes werden sowohl allgemeine Anforderungen an Controlling-Kennzahlen definiert, als auch spezielle in Bezug auf das Architekturma­nagement, welches als Controlling-Objekt mittels Kennzahlen gesteuert werden soll.

3.1 Architekturmanagement als Objekt des IT-Controllings

Das IT-Controlling ist ein Fachcontrolling (Kütz 2013, 2) mit der IT im gesamten Un­ternehmen als Betrachtungsgegenstand. Ziel ist die Sicherstellung des wirtschaftlichen Einsatzes aller IT-Ressourcen (Kütz 2013, VII). Diese sollen effizient und effektiv verwendet werden. Konkreter bedeutet dies die Sicherstellung der Verfügbarkeit, Funktionsfähigkeit (Kütz 2013, VII), Qualität und Termineinhaltung (vgl. hier und im Folgenden Krcmar 2011, 152). Es werden die Ebenen Portfolio, Projekte, Produkte bis zur Infrastruktur betrachtet. Das IT-Controlling erfüllt primär sowohl eine Überwa- chungs- als auch eine Koordinationsfunktion. Zusätzlich hat das IT-Controlling eine Servicefunktion im Sinne der Entscheidungsunterstützung u.a. durch ein Berichtwe­sen. Küpper definiert als Funktionen zusätzlich eine Anpassungs- und Innovations­funktion und die Zielausrichtungsfunktion (Küpper 1997, 17-18). Kütz nennt noch weitere Aufgaben des IT-Controlling: Transparenz des Einsatzes und Wirkung der IT, Risikomanagement, IT-Governance (Kütz 2013, 7).

In der zuvor dargestellten Definition des IT-Controllings ist das Architekturmanage­ment nicht explizit als Controlling-Objekt erwähnt. Kütz stellt jedoch dar, dass Ob­jekte des IT-Controllings nicht abschließend aufgeführt werden können und dass statt- dessen für „jedes Themen, für das man ein spezielles Management etabliert“ (Kütz 2007, 8) auch ein entsprechendes Controlling benötigt. Dies entspricht auch der allge­meinen Auffassung der Unterstützungsfunktion des Controllings für das Management.

Küpper definiert die Merkmale Beeinflussbarkeit, Art der Objekte und Messbarkeit der Kontrollgrößen (Präzisionsgrad, Art der Messung, Art und Zahl der Maßgröße) zur Klassifikation von Controlling-Objekten (Küpper 1997, 168), so dass die Identifi­kation als Controlling-Objekt über das allgemeine Controlling-Verständnis hinaus be­gründet wird. Beim Versuch der Klassifikation des Architekturmanagements ist auf­fällig, dass es in den meisten Merkmalen mehrere Ausprägungen beinhaltet, so z.B. bei der Art, sowohl Güter (Tätigkeiten und Informationen) und alle Prozesstypen (technische, informatorisch, menschlich). Aufgrund der Komplexität und des inhaltli­chen Umfangs des Architekturmanagements ist zwar keine eindeutige Klassifikation nach Küpper möglich, jedoch wird jedes Merkmal erfüllt.

Nach der formalen erfolgt zusätzlich eine inhaltliche Identifizierung und Begründung. Diese ist notwendig, um zu beurteilen, inwiefern ein Controlling des Architekturma­nagements (s. Abschnitte 2.1 und 2.2) zu den durch das IT-Controlling verfolgten Ziel­setzungen (s. Definition zu Beginn dieses Abschnittes) beiträgt. Das Architekturma­nagement hat die Informations-, IT- und Infrastrukturarchitektur als Betrachtungsge­genstand; das IT-Controlling hingegen die gesamte IT, sowohl technisch als auch or­ganisatorisch. Somit wird durch das Architekturmanagement der technische Teil ab­gedeckt. Zur Sicherstellung der Verfügbarkeit, Funktionsfähigkeit, Qualität und Ter­mineinhaltung trägt das Architekturmanagement durch Architekturstrategie, -prinzi­pien, -planung und -steuerung bei und gibt entsprechende Vorgaben vor. In Bezug auf die Ebenen des IT-Controllings Portfolio, Projekt, Produkt und Infrastruktur kann das Architekturmanagement Erkenntnisse zum Portfolio (Informationarchitektur), Pro­dukt (IT-Architekturen) und Infrastruktur (IT-Basisinfrastruktur) liefern. Insbesondere die Überwachungs- und die Servicefunktion wird dabei unterstützt. Ebenso werden die Überwachungsfunktion, in Bezug auf die Umsetzung der geplanten Architektur und dessen Vorgaben, und die Servicefunktion, im Sinne der Entscheidungsfunktion durch die Aufgaben im Rahmen der Informationsarchitektur und des Business/IT-Align- ments, unterstützt.

3.2 Definition von Kennzahlen im Controlling

Eine Kennzahl ist ein Abbild der Realität bzw. eine messbare Eigenschaft eines quan­titativen Aspekts eines Systems. Die Kennzahlwerte geben quantitativ erfassbare Sachverhalte in konzentrierter, vereinfachter Form wieder (Kütz und Berend 2011, 5; DeMarco 2008, 99).

Neben die Quantifizierbarkeit hat eine Kennzahl einen Informationscharakter zur Be­urteilung der der Kennzahl zugrundeliegenden Sachverhalte. Sie besitzt folgende Ei­genschaften: Zweckeignung, Nutzbarkeit, Indikatorcharakter, Genauigkeit, Validität,

Messbarkeit, Aktualität, Kosten-Nutzen-Relation, Einfachheit, Unabhängigkeit, Re­dundanzfreiheit, Verlässlichkeit, Vollständigkeit und Nachvollziehbarkeit (Kütz und Berend 2011, 39f.; DeMarco 2008, 101; Krüger und Seelmann-Eggebert 2003, 258; Küpper 1997, 325).

Eine Kennzahl hat eine Informationsfunktion zur Beurteilung, Vergleich, Entschei­dungsprämissen, Ursachen und Indikatoren für schwer messbare und prognostizier­bare Eigenschaften. Darüber hinaus besitzt eine Kennzahl eine Steuerungsfunktion in Form von Vorgaben, Anreizen oder zur Kontrolle (Stutz 2009, 45; Küpper 1997, 321).

Bei Kennzahlen unterscheidet man absolute Zahlen (z.B. Kapitalwert) und Verhältnis­zahlen. Letztere können in Beziehungszahlen (z.B. Rentabilität), Gliederungszahlen und Indexzahlen aufgeteilt werden (Küpper 1997, 318).

3.3 Anforderungen an Architekturmanagement-Kennzahlen

Kennzahlen im Rahmen des Architekturmanagements können als Darstellungssicht auf Architekturen verstanden werden, die Aussagen über den aktuellen Stand der Ar­chitektur z.B. in Bezug auf Leistung, Umfang, Komplexität und Qualität treffen zu können. Mittels Kennzahlen werden unterschiedliche Zustände der Architektur zu un­terschiedlichen Zeitpunkten vergleichbar (Krüger und Seelmann-Eggebert 2003, 109, 155).

Aier und Dogan definieren ein operativ überprüfbares Indikatorensystem für die Nach­haltigkeit von Unternehmensarchitekturen und führen als übergeordnete Indikatoren den Standardisierungsgrad, Integrationsgrad („Generizitätgrad“), Transparenzgrad, Modularitätsgrad, Organisatorische Verankerung und unternehmenseigene Experten­einschätzungen an (Aier und Dogan 2005, 620f). Kennzahlen, die Aussagen zum Ar­chitekturmanagement treffen, sollten sinnvollerweise diese Indikatoren berücksichti­gen.

Darüber hinaus müssen entsprechende Kennzahlen die Architekturmanagement-Ziel­setzungen (s. Abschnitt 2.2) berücksichtigen und die in der Controlling-Definition (s. Abschnitt 3.2) genannten Eigenschaften und Kriterien erfüllen.

4 Beurteilung des IT Architecture Capability Maturity Model

Auf Basis der Ziele und Aufgaben des Architekturmanagements (2.2), der Definition von Kennzahlen (3.2) und der spezifischen Anforderungen an Kennzahlen des Archi­tekturmanagements (3.3) soll nun das ACMM (2.3) und dessen beiden Reifegrad­Kennzahlen auf seine Eignung als Steuerungsinstrument des Architekturmanagements analysiert werden. In Abschnitt 3.1 wurde das Architekturmanagement bereits als Controlling-Objekt identifiziert.

4.1 Unterstützung der Zielsetzungen des Architekturmanagements

Das Architekturcharakteristikum IT-Architecture Process des ACMM unterstützt die verbesserte Planbarkeit der IT. Zusammen mit dem Business Linkage wird das Busi­ness/IT-Alignment - zumindest auf strategischer Ebene und Geschäftsarchitektur - unterstützt. Die Informationsarchitektur wird im ACMM nicht explizit berücksichtigt im Kontext des Business/IT-Alignments. Das Senior Management Involvement und die Operation Unit Participation unterstützen die Architektur durch die Organisation und etablieren für die IT-Architektur verantwortliche Personen. Hierzu trägt auch stark der IT-Architecture Process bei. Durch die Architecture Communication wird bis zu einem gewissen Grad die Akzeptanz der IT-Systeme erhöht. Die Transparenz der Ar­chitektur wird gestärkt. Die betrachteten IT-Security-Aspekte werden im Zielsystem des Architekturmanagements nicht explizit erwähnt. Im Rahmen der Architecture- Governance werden eine Vielzahl von Architekturmanagement-Zielsetzungen ver­folgt: Soll-/Zielbilder werden entwickelt, die Transparenz der Architektur wird erhöht, die IT-Landschaft durch Standardisierung und Wiederverwendung konsolidiert und dadurch auch die Komplexität der IT-Systeme verringert und beherrschbar gemacht, die Flexibilität und Integrationsgrad erhöht und redundante Funktionalitäten elimi­niert. Die IT Investment and Acquisition Strategy schafft außerdem eine verbesserte Planbarkeit in Bezug auf Investitionen und Akquisitionen und trägt zur IT-Kostenre- duzierung bei.

Nicht oder nur teilweise werden die nachfolgenden Zielsetzungen des Architekturma­nagements durch das ACMM unterstützt. Die verbesserte Planbarkeit und organisato­rische Effektivität wird nur im Bereich der IT-Investitionen und Akquisitionen sowie für das Architekturmanagement selber erreicht. Andere relevante Bereiche wie Port- folio, Produkt oder Projekt werden nicht unterstützt. Die Erhöhung des Kosten-Nut- zen-Verhältnisses, sowie allgemein die Erhöhung der IT-Effizienz und eine Reduzie­rung der IT-Kosten werden im ACMM durch keine Modellbestandteile berücksichtigt. Gleiches gilt für eine Verkürzung der Entwicklungszeiten bzw. der Reduzierung der „Time to Market“ von IT-Projekten. Weiter sind Aspekte des Business/IT-Alignments hauptsächlich auf die strategische Ebene ausgerichtet und die Erfassung der Anforde­rungen der Fachbereich und die Ableitung zukünftiger unterbleibt. Zwar wird die Ak­zeptanz der IT-Systeme durch die explizite Architektur-Kommunikation in gewissem Maße verbessert, aber die Zufriedenheit der Anwender wird durch das ACCM nicht weiterverfolgt. Als letzte noch nicht betrachtete Zielsetzung des Architekturmanage­ments bleibt die Verbesserung der Unterstützung der Kernprozesse des Unternehmens mit einer entsprechenden Verkürzung der Durchlaufzeiten und Erhöhung der Qualität der Kernprozesse. Auch hier finden sich keine Modellelemente im ACMM.

4.2 Anforderungen an Controlling-Kennzahlen

Nachdem nun das ACMM mit den Zielsetzungen des Architekturmanagements vergli­chen wurde, werden nun die beiden Reifegrad-Kennzahlen in Hinblick auf die Defini­tion von Kennzahlen im Controlling-Sinne analysiert. Sie bilden den Entwicklungs­stand der Architektur im Unternehmen aggregiert ab und sind so ein Abbild der (abs­trakten) Realität. Es handelt sich jedoch nicht um eine messbare Eigenschaft eines quantitativen Aspekts. Die Quantifizierbarkeit gelingt durch die ordinalskalierten Ar­chitekturcharakteristiken, wobei diese im Rahmen der Berechnung der Reifegrad­Kennzahl nach der Methode A als intervallskaliert angesehen werden. Statistisch be­trachtet ist dies jedoch falsch. Die zweite Kennzahl (Methode B) zeigt bekannterweise die prozentuale Zielerreichung der neun Architektur-Charakteristiken auf jeder Stufe und entgeht somit dieser Kritik. Den Informationscharakter erfüllen beide, wobei Me­thode B einen höheren Detailgrad aufweist. In Bezug auf Zweckeignung und Nutzbar­keit sei auf vorherigen Absatz hingewiesen, die die inhaltliche Dimension und Abbil­dung des ACMM (und dessen Kennzahlen) des Architekturmanagements analysiert.

Der Indikatorcharakter ist durch die Tatsache gegeben, dass je nach ermittelten Reife­grad in beiden Methoden Anhaltspunkte für Verbesserungen der Architektur und des -managements gegeben werden. Im Fall der Methode B kann man sogar konkrete Ar­chitekturcharakteristika identifizieren. Die Genauigkeit der Kennzahlen hängt von der Erhebung im konkreten Anwendungsfall ab, so dass an dieser Stelle keine Aussage getroffen werden kann. Gleiches gilt für Validität, Verlässlichkeit, Vollständigkeit, Aktualität und Kosten-Nutzen-Relation. Während der Nutzen noch unabhängig darge­stellt werden kann, sind die Kosten für die Erhebung nicht allgemein zu bestimmen. Die Einfachheit der Kennzahlen ist in Bezug auf die Konzeption gegeben, jedoch mag sich die Erhebung, wie bereits angeführt, je nach Situation komplex erweisen. Die Kennzahlen sind unabhängig, redundanzfrei und subjektiv nachvollziehbar. Beide Kennzahlen erfüllen sowohl die Informations- als auch Steuerungsfunktion. Es ist möglich Architekturen zu beurteilen, zu vergleichen. Die Entscheidungsprämissen sind dokumentiert und Ursachen bzw. Indikatoren werden zumindest bei Methode B geliefert. Es können Vorgaben in Form zu erreichenden Reifegrad gemacht werden (Methode A) oder in Form von Veränderungen in Prozentpunkten (Methode B) und so auch als Kontrollinstrument genutzt werden.

4.3 Anforderungen an Kennzahlen des Architekturmanagements

Im Rahmen der spezifischen Anforderungen an entsprechende Kennzahlen im Archi­tekturmanagement muss der Umfang der Darstellungssicht auf die Architektur und die Indikatoren im Hinblick auf die Nachhaltigkeit untersucht werden. Es ist mittels der Kennzahlen möglich (beide Methoden) Aussagen über den aktuellen Stand der Archi­tektur, insbesondere in Bezug auf die Leistung zu treffen, insofern die Leistung mit Reifegrad gleichgesetzt wird^[1]. Umfang, Komplexität und Qualität werden nicht direkt im ACMM berücksichtigt. Die aufgeführten Nachhaltigkeits-Indikatoren (Standardi­sierungsgrad, Integrationsgrad, Transparenzgrad, Modularitätsgrad, Organisatorische Verankerung und unternehmenseigene Experteneinschätzungen) werden nur teilweise oder indirekt durch die ACMM-Kennzahlen wiedergegeben; die organisatorische Ver­ankerung durch das Senior Management Involvement und die Operation Unit Partici­pation und die Experteneinschätzungen durch die Datenerhebung zur Bestimmung der Kennzahlenwerte.

4.4 Zusammenfassung

Zusammenfassend kann man sagen, dass im direkten Vergleich der beiden Kennzahlen im ACMM die Methode B als aggregiertes Abbild des Architekturmanagements über­legen ist. Es werden wesentlich mehr Aspekte des komplexen, umfangreichen Sach­verhaltes abgebildet. Insgesamt ist das ACMM als Steuerungsinstrument in einigen Teilen ungenügend, weil wesentliche Aspekte, wie dargestellt, nicht oder nur teilweise berücksichtigt werden. Positiv hervorzuheben bleibt, dass die IT-Security integriert wird und durch die Architecture Governance eine Vielzahl von Zielsetzungen des Ar­chitekturmanagements verfolgt werden, wobei hier durch die starke Aggregation vie­ler Zielsetzungen in ein Charakteristikum die Informationsintensität geringer wird.

5 Fazit

Nach der Definition des Architekturmanagements, sowie seiner Ziele und Aufgaben wurde das IT Architecture Capability Maturity Models (ACMM) vorgestellt. An­schließend wurde das IT-Controlling definiert und das Architekturmanagement als Controlling-Objekt identifiziert und Kennzahlen aus Controlling-Sicht erläutert. Zu­sätzliche Anforderungen an Kennzahlen, die sich aus dem Architekturmanagement er­geben, wurden genannt. Abschließend wurde auf Basis der Architekturmanagement­Definition und den Anforderungen an Kennzahlen das ACMM auf seine Eignung als Steuerungsinstrument untersucht.

Das Ziel dieser Arbeit war herauszufinden, inwiefern das Architekturmanagement durch das IT-Controlling mittels geeigneten Kennzahlen gesteuert werden kann, um einen effizienten und effektiven Einsatz der IT im Unternehmen zu gewährleisten. Als genaueren Betrachtungsgegenstand für Kennzahlen wurde das ACMM ausgewählt. Die Beurteilung anhand der erarbeiteten Kriterien hat ergeben, dass zumindest eine Kennzahl (Methode B) des ACCM als Steuerungskennzahl des Architekturmanage­ments geeignet ist, um das Architekturmanagement zu steuern und es als Prozess kon­tinuierlich zu verbessern. Jedoch werden nicht alle geforderten Aspekte berücksichtigt, so dass diese Kennzahl nur eine von weiteren Kennzahlen zur Steuerung sein kann.

In Bezug auf Limitationen der vorliegenden Arbeit sei auf den geringen erlaubten Um­fang hingewiesen, der eine ausführlichere Behandlung nicht zuließ, so dass auch der genutzte Literaturumfang geringer ausfällt als wünschenswert. Die Anforderungen hätten so auf eine breitere Basis gestellt und konsolidiert werden können. Auch wurde lediglich ein Modell betrachtet und andere nicht in der Beurteilung berücksichtigt. Zur methodischen Vorgehensweise muss man anführen, dass es sich um eine rein litera­turbasierte logisch-argumentative Arbeit handelt. Eine empirische Fundierung ist un­terblieben. Eine Methodenkonstruktion zur allgemeinen Bewertung von Kennzahlen zur Steuerung des Architekturmanagements wurde nicht durchgeführt.

Als weiterführende Fragestellungen bieten sich beispielsweise die Klassifizierung von Kontrollobjekten im Architekturmanagement (vgl. Abschnitt 3.1) an, die an dieser Stelle oberflächlich ausgefallen ist. Es wurde mehrfach auf die Messung bzw. Daten­erhebung für die Wertebestimmung der Kennzahlen hingewiesen, ohne eine genauere Betrachtung. Auch der Frage, inwiefern das Architekturmanagement vom IT-Control- ling abgegrenzt werden kann und welche Überschneidungen vorhanden sind, sollte weiter nachgegangen werden.

Literaturverzeichnis

Aier, Stephan. 2006. „Integrationstechnologien als Basis einer nachhaltigen Unter­nehmensarchitektur.“ Dissertation.

Aier, Stephan und Turgut Dogan. 2005. „Indikatoren zur Bewertung der Nachhal­tigkeit von Unternehmensarchitekturen.“ In Wirtschaftsinformatik 2005: EEco- nomy, eGovernment, eSociety ; mit II8 Tabellen, hg. v. Otto K. Ferstl, 607-26. Heidelberg: Physica-Verlag Heidelberg.

DeMarco, Tom. 2008. Was man nicht messen kann, kann man nicht kontrollieren.

2. Aufl., Nachdr. Bonn: mitp.

Dern, Gernot. 2003. Management von IT-Architekturen: Informationssysteme im Fokus von Architekturplanung und -entwicklung. Edition CIO. Wiesbaden, s.l. Vieweg+Teubner Verlag. http://dx.doi.org/10.1007/978-3-663-10719-4.

. 2009. Management von IT-Architekturen. Wiesbaden: Vieweg+Teubner.

Dietzsch, Andreas. 2008. „Unternehmensarchitektur als Instrument der strategi­schen Unternehmensentwicklung? Erfahrungen bei der PostFinance.“ HMD 45 (4): 49-58. doi:10.1007/BF03341230.

Durst, Michael. 2008. Wertorientiertes Management von IT-Architekturen. 1. Aufl. s.l. Vieweg+Teubner (GWV). http://gbv.eblib.com/patron/FullRe- cord.aspx?p=748313.

Esswein, Werner und Jens Weller. 2008. „Unternehmensarchitekturen — Grundla­gen, Verwendung und Frameworks.“ HMD 45 (4): 6-18. doi:10.1007/BF03341226.

Heinrich, Lutz J. und Dirk Stelzer. 2009. Informationsmanagement: Grundlagen, Aufgaben, Methoden. 9., vollst. überarb. Aufl. Lehrbuchreihe Wirtschaftsinfor­matik. München: Oldenbourg.

J.A. Zachman. 1987. „A framework for information systems architecture.“ IBM Systems Journal (Vol 26, No 3): 276-91.

Krallmann, Hermann, Annette Bobrik und Olga Levina. 2013. Systemanalyse im Unternehmen: Prozessorientierte Methoden der Wirtschaftsinformatik. 6., über­arb. und erw. Aufl. München: Oldenbourg.

Krcmar, Helmut. 1990. Informationsverarbeitungs-Controlling: Zielsetzung und Erfolgsfaktoren. Arbeitspapiere / Universität Hohenheim, Lehrstuhl für Wirt­schaftsinformatik Nr. 14. Stuttgart: Lehrstuhl für Wirtschaftsinformatik, Univ. Hohenheim.

. 2010. Informationsmanagement. 5., vollst. überarb. und erw. Aufl. Berlin:

Springer.

. 2011. Einführung in das Informationsmanagement. Springer-Lehrbuch.

Berlin: Springer.

Krüger, Sascha und Jörg Seelmann-Eggebert. 2003. IT-Architektur-Engineering: [Systemkomplexität bewältigen, Kosten senken, Potenziale freisetzen]. 1. Aufl. Galileo Computing. Bonn: Galileo Press.

Küpper, Hans-Ulrich. 1997. Controlling: Konzeption, Aufgaben und Instrumente.

2., aktualisierte und erg. Aufl. Controlling-Konzepte. Stuttgart: Schäffer-Po- eschel.

Kütz, Martin. 2007. „Grundelemente des IT-Controllings.“ HMD 44 (2): 6-15. doi:10.1007/BF03340263. . 2013. IT-Controlling für die Praxis: Konzeption und Methoden. 2., über- arb. und erw. Aufl. Safari Tech Books Online. Heidelberg: dpunkt-Verl. http://proquest.safaribooksonline.com/9781457184918.

Kütz, Martin und Michael Berend. 2011. Kennzahlen in der IT: Werkzeuge für Con­trolling und Management. 4., überarb. und erw. Aufl. Heidelberg: dpunkt.-Verl.

Kütz, Martin und Andreas Meier. 2007. „Editorial.“ HMD 44 (2): 3. doi:10.1007/BF03340261.

Schmelzer, Hermann J. und Wolfgang Sesselmann. 2004. Geschäftsprozessmanage­ment in der Praxis: Produktivität steigern, Wert erhöhen, Kunden zufrieden stel­len. 4., erw. Aufl. München: Hanser. http://www.sub.uni-hamburg.de/ebook/e- book.php?act=b&cid=3953.

Schmidt, Christian. 2009. Management komplexer IT-Architekturen: Empirische Analyse am Beispiel der internationalen Finanzindustrie. Gabler Edition Wissen­schaft. Wiesbaden: Gabler Verlag / GWV Fachverlage GmbH Wiesbaden. Zugl. Darmstadt, Technische Univ. Diss., 2009. http://dx.doi.org/10.1007/978-3-8349- 8229-2.

Stutz, Matthias. 2009. Kennzahlen für Unternehmensarchitekturen: Entwicklung ei­ner Methode zum Aufbau eines Kennzahlensystems für die wertorientierte Steue­rung der Veränderung von Unternehmensarchitekturen. Schriftenreihe Studien zur Wirtschaftsinformatik 31. Hamburg: Kovač. Zugl. St. Gallen, Univ., Diss., 2009.

The Open Group. 2006. „TOGAF 8.1.1 Online: Architecture Maturity Models.“ Zu­griff: 13. Juni 2017. http://pubs.opengroup.org/architecture/togaf8- doc/arch/chap27.html.

---

^[1] Durst führt aus, dass der Wertbeitrag als proportional zum Reifegrad angesehen werden kann (Durst 2008, 105).