Business Architektur - Transparenz für das Business/IT-Alignment

Ausrichtung der IT am Geschäft fordert Transparenz

Ein wichtiges Ziel des Architekturmanagements als Führungsprozess der Architektur-Arbeiten ist es, die IT auf die Bedürfnisse des Geschäfts auszurichten. In diesem Kontext wird häufig der Satz «Business drives IT» verwendet - die Chance besteht aber auch, dass die IT dem Business neue Potenziale bietet und Chancen eröffnet, dann ist «IT drives Business» durchaus angebracht.

Die Bedürfnisse bzw. die Anforderungen des Geschäfts müssen für ein effektives Business/IT-Alignment möglichst transparent und fassbar sein. Das Management in den Fachbereichen ist also gefordert, die Strategie-Umsetzung transparent darzulegen, Rahmenbedingungen (Finanzen, zeitliche Zielsetzungen) zu definieren und so Prioritäten zu setzen. Eine Methode bzw. ein Werkzeug, welches die kontrollierte und planbare Strategie-Umsetzung unterstützt ist die Balanced Scorecard.

Die umfassende Modellierung des Unternehmens aus verschiedenen Perspektiven (Kunden, Märkte, Prozesse, IT usw.) ergibt im Endeffekt eine so genannte Unternehmensarchitektur.

Rahmenwerk von Zachman

Für die Strukturierung und die Entwicklung von Unternehmensarchitekturen haben sich bisher noch keine Standards etabliert. Ein bekannter und oft verwendeter Ansatz im Sinne eines Rahmenwerks stellt das so genannte Zachman-Framework dar.

John A. Zachman

John A. Zachman ist der geistige Vater des Zachman-Frameworks, welches die vielfältigen Dimensionen einer Unternehmensarchitektur («Enterprise Architecture») darstellt.

Das Zachman-Framework als Basismodell für Unternehmensarchitekturen.

Das Rahmenwerk von Zachman ermöglicht es den Business Analysten im Unternehmen strukturiert auf verschiedenen Ebenen und aus verschiedenen Perspektiven die Firma zu beschreiben und Abhängigkeiten bzw. Auswirkungen von Veränderungen (beispielsweise In-/Outsourcing, Verkauf einer Firmensparte, Aufkauf und Integration eines Mitbewerbers, Erschliessung neuer Marktgebiete usw.) transparenter darzustellen. Die Business Analysten verwenden dazu das Rahmenwerk als Grundlage und analysieren Dimension für Dimension bzw. Perspektive für Perspektive durch. Dabei werden verschiedene Informationen aus dem Unternehmen herangezogen und vernetzt:
  • Kundensegmente
  • Märkte
  • Produktkatalog
  • Service-Dienstleistungen
  • Mitarbeiter und Organisation
  • Prozessbeschreibungen
  • IT-Applikationen / Module und Services
  • Regelwerke

Aus dieser umfassenden Arbeit entsteht ein wertvolles Unternehmensmodell, das die Entwicklung von verschiedenen Szenarien erlaubt und die Unternehmensentwicklung unterstützt. Mit Hilfe eines solchen Unternehmensmodells können Fragen beantwortet werden wie:

Geschäftsführung
  • Weisen die IT-Investitionen eine Parallele zur Entwicklung der Erträge in den Kerngeschäften aus?
  • Welches Deckungsbeitragsvolumen wird von welchem Prozess bzw. welcher Applikation beeinflusst?
  • Welche Geschäftsrisiken entstehen, wenn wir die IT-Kosten kontinuierlich um 10% pro Jahr senken?
  • Welchen Einfluss hat eine Akquisition im Kerngeschäft Anlage- und Vermögensverwaltung auf unsere IT-Applikationen?

Strategisches Sourcing
  • Welche Auswirkungen hat das Insourcing eines Mandanten auf die Logistik/Produktion?
  • Wie flexibel sind die Schnittstellen bei Prozessen und Applikationen für alternative Sourcing-Szenarien?

Business / IT-Architektur
  • Welche Prozesse werden für die Leistungserstellung gegenüber Kunden verwendet?
  • Welche Leistungen bzw. Produkte basieren auf welchen Applikationen?
  • Wie viele Schnittstellen sind in die Abwicklung des Geschäftsprozesses Z involviert?
  • Welche Kundendaten werden in welchen Applikationen als Lead-Daten geführt und warum?

Service-Management
  • Sind die Service-Levels der Applikation A und der Applikation B mit dem von den Kunden erwarteten Service-Level des Geschäftsprozesses Z abgestimmt?
  • Ist die Rollenstruktur des Geschäftsprozesses Z korrekt in der Berechtigungsstruktur der Applikationen A und B abgebildet?
  • Sind die Verfügbarkeitsanforderungen in den SLA's mit den Prioritäten der Marktleistungen abgestimmt?

TOGAF als inhaltliches und methodisches Framework

Die OpenGroup entwickelt seit mehreren Jahren das Architektur-Framework TOGAF - «The OpenGroup Architecture Framework». TOGAF ist sowohl ein inhaltliches Rahmenwerk (vergleichbar mit Zachman, jedoch umfassender beschrieben) wie auch eine Architektur-Entwicklungsmethode (TOGAF ADM, Architecture Development Method).

Die OpenGroup positioniert sich selbst wie folgt:
«Die Open Group ist ein Anbieter-und Technologie-neutrales Konsortium, dessen Vision den grenzenlosen Informationsfluss und den Zugang zu integrierten Informationen innerhalb und zwischen Unternehmen auf der Basis von offenen Standards und globaler Interoperabilität ermöglichen soll.»

Eines der breit angewendeten Elemente aus TOGAF ist die «TOGAF ADM», der Architektur-Zyklus bzw. «Architecture Development Method», basierend auf funktionalen und nicht-funktionalen Anforderungen (Requirements):

Darstellung der iterativen Methode TOGAF ADM

Diese Methode sollte jeweils in unterschiedlichen Iterationen durchlaufen werden:
  • Preliminary / A - Architecture Vision: Iterationen um Umfang, Inhalt und Prinzipien der Architektur-Arbeit zu definieren
  • B, C, D, E und F: Iterationen um Architektur-Inhalte zu erarbeiten und aufeinander abzustimmen
  • E, F: Iterationen um Implementierungsvarianten und Bebauungspläne in Programmen zu entwickeln
  • G, H: Iterationen um Implementierungs-Prozesse und -Entscheide und Change Management zu definieren

Anforderungen im Zentrum
Im Zentrum der TOGAF ADM stehen die Requirements bzw. die Anforderungen. Diese Anforderungen haben Einfluss auf die einzelnen Architektur-Bereiche («Business Architecture») oder -Tätigkeiten («Migration Planning») Die Anforderungen sind somit funktional oder nicht funktional ausgeprägt und bestimmen beispielsweise:

  • Minimale Funktionen für Vertriebsmitarbeiter um Offerten effizient und dennoch regulatorisch korrekt erstellen zu können
  • Zeitliche Aspekte wie Antwortzeiten, Durchlaufzeiten usw.
  • Kritische Prozess-Schritte für den Markterfolg (im Sinne kritischer Erfolgsfaktoren)
  • Schnittstellen als Messpunkte für Prozessqualität
  • Kosten für einen Geschäftsprozess - um Rentabilitätsziele zu erreichen
  • Soll-Bruchstellen in Prozessen für In- und Outsourcing-Optionen
  • Skalierungsanforderungen für das Wachstum des Geschäfts
  • Vertriebskanalübergreifende Datenintegrations-Aspekte
  • Sicherheitsanforderungen für Prozesse mit e-Business-Unterstützung
  • Aufzeichnungsanforderungen in Logfiles (geschäftliche Logbücher, technische Logfiles) 
  • Verantwortlichkeiten für Entscheide im Programm- oder Projektmanagement (Implementation Governance)

Implementierung von TOGAF ADM
Die Architektur-Entwicklung nach der Methode TOGAF ADM bringt vor allem zu Beginn einen beträchtlichen Aufwand mit sich - dies auch um die «Gemeinde» der Business- und IT-Architekten von der Methode und den Artefakten zu überzeugen. Die Verwendung der Methode bringt jedoch einen entscheidenden Vorteil mit: Archtektur-Entwicklung wird entscheidend transparenter und nachvollziehbarer.

Die TOGAF ADM kann für unterschiedliche Szenarien angewendet werden - für ein grössere Unternehmen bedeutet dies beispielsweise folgendes:

  • Szenario 1: Architektur-Entwicklung und Ressourcen-Planung für eine Mittelfrist- oder Grobplanung über 3 Jahre
  • Szenario 2: Architektur-Entwicklung und Ressourcen-Planung für eine Jahresplanung
  • Szenario 3: Architektur-Entwicklung und Ressourcen-Planung für ein Kerngeschäft (Kreditgeschäft, Zahlungsverkehr usw.) 
  • Szenario 4: Architektur-Entwicklung und Ressourcen-Planung für ein Programm oder einen Business Case wie «Syndikatskredite mit e-Business-Support» (fiktives Beispiel)

Grundsätzlich ist die Architektur-Entwicklung nach TOGAF ADM in Europa und der Schweiz noch relativ jung und es sind noch wenige durchgängige Beispiele (Business und IT) verfügbar. Die Gemeinde der TOGAF-Anwender wächst jedoch - nicht zuletzt, weil man für TOGAF eine Architektur-Ausbildung mit einem nicht unbekannten Zertifikatsabschluss (The OpenGroup)  erlangen kann.

Geschäftsorientierung des Architekturmanagements

Die Beantwortung dieser Fragen erfordert immer wieder analytische Vorgehensweisen auf Basis von Modellen. Optimal ist es, wenn für möglichst alle Analyse-Aufgaben das selbe Unternehmensmodell (aus unterschiedlichen Perspektiven, in verschiedenen Granularitäten) verwendet werden kann.

In diesem Zusammenhang kann auch von der Geschäftsorientierung des Architekturmanagements gesprochen werden. Damit ist die Integration des Architekturmanagements in unternehmerische Entscheidungsprozesse gemeint. Das Architekturmanagement für das Business und die IT ist dann geschäftsorientiert, wenn es
  • die wesentlichen Führungsbereiche eines Unternehmens miteinander in Beziehung setzt
  • in die wesentlichen Führungsprozesse des Unternehmens eingebunden ist
  • relevante und aktuelle Führungsinformationen in das MIS frühzeitig und verständlich liefert
  • einen nachhaltigen Nutzen stiftet

Einen nachhaltigen Nutzen kann das Architekturmanagement dann liefern, wenn es einen betriebswirtschaftlichen Fokus einnimmt und beispielsweise aufzeigt, wo die Kostentreiber in der Architektur einer Unternehmung liegen und wie eine Optimierung möglich ist.

Ein weiterer Ansatz zu Erhöhung der Geschäftsorientierung ist die Integration der Business-Architektur in die Unternehmensplanungs-Prozesse (die im Kontext der Lieferung von Führungsinformationen). Dabei sollte die Business-Architektur eigene Artefakte entwickeln und zur Unternehmensplanung als Entscheidungsgrundlage beisteuern, geeignet sind dabei beispielsweise Geschäftsmodelle, Prozesslandkarten usw.