(IT) Service Management und (Enterprise) Architecture · (IT) Service Management und (Enterprise)...

(IT) Service Management und

(Enterprise) Architecture

Ein akademischer Blick auf die Themen

„Run the Business“ und „Change the Business“

Dr. Stephan Aier

Projektleiter

Institut für Wirtschaftsinformatik

Universität St. Gallen

Müller-Friedberg-Strasse 8, CH-9000 St. Gallen

Tel: +41 71 224 3360 Fax: +41 71 224 2189

[email protected]

www.iwi.unisg.ch

© Mai-10, IWI-HSG

Seite 2

Hintergrund

Integrations- und Architekturmanagement @ IWI-HSG

http://ccif.iwi.unisg.ch

Kompetenzzentrum Integration Factory (CCIF)

We

rW

as

Wie

Modellierung

Analyse

Planung

Integrations-

Patterns

Integrations-

methoden

Management

Unternehmens-

architektur

Management

Integration

Modelle Methoden

Ablauf-

organisation

Aufgabe Aktivität

Geschäftsobjekt

---------------------

Informationsobj.

erzeugt/

konsumiert

ist Teil von

Aufbau-

organisation

Organisations-

einheitStandort

Ist

lokalisiert

an

MitarbeiterStelle besetzt

Rolle

enthält erfüllt

ist Teil von

führt aus

ist Teil von

führt aus

Geschäftsprozess Leistung

ist Teil von

ist Teil von

ist verbunden mit

erzeugt,

konsumiert

ADOben

Workshops

Projekte

Schulungen

KonferenzenVeröffentlichungen Netzwerk

http://ccif.iwi.unisg.ch/

© Mai-10, IWI-HSG

Seite 3

Konsequenzen für das gemeinsame Thema: Business/IT Alignment 3

St. Galler Sicht auf das Verhältnis IT Service Management, EA, ITIL und TOGAF2

Bestandsaufnahme: IT Service Management (ITIL) und EA (TOGAF) in der Praxis1

Fazit und Ausblick4

IT Service Management und Enterprise Architecture

© Mai-10, IWI-HSG

Seite 4

Worum geht es?

Kritische Erfolgsfaktoren für das IT/IS-Management

“The first, and most obvious, IS critical success factor is

service”

Quelle: Rockart, J.: The Changing Role of the Information Systems Executive - A Critical Success

Factors Perspective, in: Sloan Management Review, 24, 1, 1982, pp. 3-13..

2. Communication (two-way)

3. IS Human Resources

Repositioning the IS function „from a limited ‚automated

back office„ to a more ubiquitous function involved in all

aspects of the business.”

© Mai-10, IWI-HSG

Seite 5

Worum geht es?

Es geht um Business/IT Alignement

„Unter den verschiedenen Integrationsausprägungen

kommt der Integration zwischen fachlichen Architekturen

und IT-Architekturen besondere Bedeutung zu.“

Quelle: Aier, S.; Winter, R.: Virtual Decoupling for IT/Business Alignment – Conceptual Foundations, Architecture Design and

Implementation Example, in: Business & Information Systems Engineering, 51, 2, 2009, pp. 150–163.

Business/IT Alignment stellt seit mehreren Jahren über alle

Unternehmens-Grössenklassen und über alle Branchen

hinweg das Hauptthema der CIOs dar.

Quelle: Luftman, J.; Kempaiah, R.; Rigoni, E.: Key Issues for IT Executives 2008, in: MISQ Executive, 8, 3, 2009, pp. 151-159.

© Mai-10, IWI-HSG

Seite 6

Welche Benefits werden von ITIL erwartet?

Improvement of… Hochstein et

al., 2005

Potgieter et al.

2005

Kießling et al.

2009

Cater-Steel et

al. 2008 Cervone 2008

Service Quality X X X X X

Standardization of

Service X X X

Customer

Satisfaction X X X

Return on

Investment X X X

Reduction of

Downtime X X

Best Practice X

Financial

Contribution Control X

Call Fix Rate X

Morale of IT X Quelle: Mauricio Marrone, Lutz M. Kolbe: Providing More than Just Operational Benefits: An Empirical Research, Schumann, M., Kolbe, L., Breitner, M.,

Frerichs, A. (Hrsg.): Multikonferenz Wirtschaftsinformatik (MKWI 2010), Göttingen, 23.02.2010, Universitätsverlag Göttingen, Göttingen, 2010, S. 287-298

© Mai-10, IWI-HSG

Seite 7

Wie die korrelieren ITIL-Reife und Erfolg:

Innerhalb der IT und beim Business?

Level 1: Ad Hoc Processes are ad hoc and

disorganized

Level 3: DefinedProcesses are documented

and monitored for compliance

Level 5: OptimizedGood practices are followed

and automated

Total realized

benefits0 4 5

Total realized

benefits backed by

metrics

0 2 4

Total realized

benefits

acknowledged by

business

0 1 3

Business/IT

Alignment2 3 4

0: trifft gar nicht zu … 5: trifft vollständig zuQuelle: Mauricio Marrone, Lutz M. Kolbe: Providing More than Just Operational

Benefits: An Empirical Research, Schumann, M., Kolbe, L., Breitner, M., Frerichs,

A. (Hrsg.): Multikonferenz Wirtschaftsinformatik (MKWI 2010), Göttingen,

23.02.2010, Universitätsverlag Göttingen, Göttingen, 2010, S. 287-298

© Mai-10, IWI-HSG

Seite 8

Unsere pauschale Wahrnehmung der ITIL-Praxis (Aus einem ITIL V2 Crash Course)

Quelle: Steinberg, R.; Goodwin, M.: ITIL Crash Course, in:

Infoworld, 23.10.2006, 2006, pp. 22-30.

© Mai-10, IWI-HSG

Seite 9

TOAGF ist in unserer

Wahrnehmung der Standard für

EAM in der Praxis.

Wir sehen aber auch, dass

TOGAF weit davon entfernt ist

Enterprise Architecture

Management zu beschreiben –

auch nicht in TOGAF 9.

Enterprise Architecture Management und TOGAF Architecture Development Method (ADM)

© Mai-10, IWI-HSG

Seite 10

EAM-Literatur: Häufig IT-fokussiert, selten

Stakeholder- und Nutzungsorientiert

Dokumentation

und Planung

Keine

Keine

IT, Fachbereiche,

Geschäftsleitung

Management

Science

[Ross 2003]

[Ross 2006]

[Ross/Beath 2006]

[Ross et al. 2006]

Dokumentation

und Planung

Living Enterprise

EA3 Cube

IT, Fachbereiche,

Geschäftsleitung

ERP,

Governance

[Bernard 2005]

[Bernard 2006]

Dokumentation

und Planung

verschiedene

[Ferstl et al.

1994]

SOM

IT

Organisations-

lehre

SOM

[Ferstl et al.

1994]

[Ferstl/Sinz 1995]

[Ferstl/Sinz 1996]

[Ferstl/Sinz 2005]

[Ferstl/Sinz 2006]

Dokumentation und

Planung

ADOben

eigene

Modellierungs-

sprache

IT, Fachbereiche,

Geschäftsleitung

Business

Engineering

[Leist 2004] [Winter

2005] [Braun/Winter

2005] [Bucher et al.

2006] [Winter/Fischer

2006] [Braun/Winter

2007] [Fischer/Winter

2007] [Fischer et al.

2007]

Dokumentation

und Planung

verschiedene

Archimate

IT, Fachbereiche

IT-Architektur

[Jonkers et al.

2003] [Jonkers et

al. 2004]

[Lankhorst et al.

2004] [Lankhorst

2005]

[van der Torre et

al. 2006]

Dokumentation

und Planung

MEMO Center

eigene

Modellierungs-

sprache

IT, Fachbereiche

Systement-

wicklung Wissens-

management

MEMO

[Frank 1994]

[Frank 1995]

[Frank 1999a]

[Frank 1999b]

[Frank 2002]

Basis für Entschei-

dungsfindung

-

-

IT

IT-Architektur

[Ekstedt 2004]

[Simonsson et al.

2006] [Lindström et

al. 2006]

[Johnson/Ekstedt

2007]

Business/IT-

Integration

SEAMCad

eigene

Modellierungs-

sprache

IT, Fachbereiche

Organisationslehre

Systemtheorie

SEAM

[Wegmann 2002]

[Balabko/

Wegmann 2006]

[Lê/Wegmann

2006] [Rychkova/

Wegmann 2006]

Dokumentation und

Planung

ARIS Toolset

eEPK

Fachbereiche

Prozessgestaltung

Systementwicklung

ARIS

[Scheer 1996]

[Scheer 2001]

[Scheer/Jost 2002]

[Scheer/Schneider

2005]

Dokumentation

und Analyse

EA Builder

eEPK

(modifiziert)

IT, Fachbereiche

Organisations-

lehre Architektur-

gestaltung

[Aier/Schönherr

2004]

[Aier/Schönherr

2005]

[Aier/Schönherr

2006]

[Aier/Schönherr

2007]

Analysen auf Basis

der EA

Analyse der EA

Dokumentation

und Planung

Dokumentation

und Planung

Nutzung der EA

KeineKeineToolunterstützung

KeineKeineNotation

Abbildung der EA

ITIT, Fachbereiche,

Geschäftsleitung

Stakeholder/

Zielgruppe

IT-ArchitekturIT-ArchitekturHerkunft

Infrastrukturebene

Softwareebene

Integrationsebene

Organisations-

ebene

Strategieebene

Verständnis der

EA

TOGAF

[The Open Group

2001]

[The Open Group

2003]

[The Open Group

2007]

[Keller 2000]

[Keller 2001]

[Keller 2002]

[Keller 2005]

[Keller 2006]

Dokumentation

und Planung

Keine

Keine

IT, Fachbereiche,

Geschäftsleitung

Management

Science

[Ross 2003]

[Ross 2006]

[Ross/Beath 2006]

[Ross et al. 2006]

Dokumentation

und Planung

Living Enterprise

EA3 Cube

IT, Fachbereiche,

Geschäftsleitung

ERP,

Governance

[Bernard 2005]

[Bernard 2006]

Dokumentation

und Planung

verschiedene

[Ferstl et al.

1994]

SOM

IT

Organisations-

lehre

SOM

[Ferstl et al.

1994]

[Ferstl/Sinz 1995]

[Ferstl/Sinz 1996]

[Ferstl/Sinz 2005]

[Ferstl/Sinz 2006]

Dokumentation und

Planung

ADOben

eigene

Modellierungs-

sprache

IT, Fachbereiche,

Geschäftsleitung

Business

Engineering

[Leist 2004] [Winter

2005] [Braun/Winter

2005] [Bucher et al.

2006] [Winter/Fischer

2006] [Braun/Winter

2007] [Fischer/Winter

2007] [Fischer et al.

2007]

Dokumentation

und Planung

verschiedene

Archimate

IT, Fachbereiche

IT-Architektur

[Jonkers et al.

2003] [Jonkers et

al. 2004]

[Lankhorst et al.

2004] [Lankhorst

2005]

[van der Torre et

al. 2006]

Dokumentation

und Planung

MEMO Center

eigene

Modellierungs-

sprache

IT, Fachbereiche

Systement-

wicklung Wissens-

management

MEMO

[Frank 1994]

[Frank 1995]

[Frank 1999a]

[Frank 1999b]

[Frank 2002]

Basis für Entschei-

dungsfindung

-

-

IT

IT-Architektur

[Ekstedt 2004]

[Simonsson et al.

2006] [Lindström et

al. 2006]

[Johnson/Ekstedt

2007]

Business/IT-

Integration

SEAMCad

eigene

Modellierungs-

sprache

IT, Fachbereiche

Organisationslehre

Systemtheorie

SEAM

[Wegmann 2002]

[Balabko/

Wegmann 2006]

[Lê/Wegmann

2006] [Rychkova/

Wegmann 2006]

Dokumentation und

Planung

ARIS Toolset

eEPK

Fachbereiche

Prozessgestaltung

Systementwicklung

ARIS

[Scheer 1996]

[Scheer 2001]

[Scheer/Jost 2002]

[Scheer/Schneider

2005]

Dokumentation

und Analyse

EA Builder

eEPK

(modifiziert)

IT, Fachbereiche

Organisations-

lehre Architektur-

gestaltung

[Aier/Schönherr

2004]

[Aier/Schönherr

2005]

[Aier/Schönherr

2006]

[Aier/Schönherr

2007]

Analysen auf Basis

der EA

Analyse der EA

Dokumentation

und Planung

Dokumentation

und Planung

Nutzung der EA

KeineKeineToolunterstützung

KeineKeineNotation

Abbildung der EA

ITIT, Fachbereiche,

Geschäftsleitung

Stakeholder/

Zielgruppe

IT-ArchitekturIT-ArchitekturHerkunft

Infrastrukturebene

Softwareebene

Integrationsebene

Organisations-

ebene

Strategieebene

Verständnis der

EA

TOGAF

[The Open Group

2001]

[The Open Group

2003]

[The Open Group

2007]

[Keller 2000]

[Keller 2001]

[Keller 2002]

[Keller 2005]

[Keller 2006]

Quelle: Aier, S.; Riege, C.; Winter, R.: Unternehmensarchitektur – Literaturüberblick und Stand der Praxis, in: Wirtschaftsinformatik, 50, 4, 2008, S. 292-304.

© Mai-10, IWI-HSG

Seite 11

EAM-Praxis (1):

Fachliche Schwerpunkte wichtig aber nicht umgesetztGeschäftsprozesse

Schnittstellen

Produkte/Dienstleistungen

Strategische Vorhaben / Projekte

Applikationen

Strategische Unternehmensziele

Applikationsdomänen

Interaktion mit Kunden

Informationsflüsse

Fachliche Services

Datenstrukturen

Softwarekomponenten

Software-Plattformen

IS-Funktionalitäten

Informationsobjekte

Rollen und Verantwortlichkeiten

Organisationseinheiten

Marktsegmente

Vertriebskanäle

Hardwarekomponenten

Netzwerkkomponenten

Interaktion mit Zulieferern

Standorte

Wichtigkeit Umsetzungsgradunwichtig/

nicht existent

teilweise wichtig/

partiell vorhandenmehrheitlich wichtig/

definiert

wichtig/

kontrolliertsehr wichtig/

optimiert

Quelle: Aier, S.; Riege, C.; Winter, R.: Unternehmensarchitektur – Literaturüberblick und Stand

der Praxis, in: Wirtschaftsinformatik, 50, 4, 2008, S. 292-304.

© Mai-10, IWI-HSG

Seite 12

EAM-Praxis (2): Viele Analysen und

Nutzungsszenarien wichtig, wenige umgesetzt

Schnittstellenanalyse

Abdeckungsanalyse

Abhänigkeitsanalyse

Heterogenitätsanalyse

Wichtigkeit

Umsetzungsgrad

unwichtig/

nicht existent

teilweise wichtig/


definiert

wichtig/

kontrolliert

sehr wichtig/

optimiert

Planung IT Strategie

IT-Business-Alignment

Prozessoptimierung

Architekturkonformität von Projekten

Management des Anwendungsportfolios

Qualitätsmanagement

Security Management

Business-Continuity-Planning

Planung Unternehmensstrategie

IT-Konsolidierung

Standardsoftware-Einführung

Compliance Management

Sourcing-Entscheidungen

Wichtigkeit

Umsetzungsgrad

unwichtig/

nicht existent

teilweise wichtig/


definiert

wichtig/

kontrolliert

sehr wichtig/

optimiert

Quelle: Aier, S.; Riege, C.; Winter, R.: Unternehmensarchitektur –

Literaturüberblick und Stand der Praxis, in: Wirtschaftsinformatik,

50, 4, 2008, S. 292-304.

© Mai-10, IWI-HSG

Seite 13




Fazit und Ausblick4


© Mai-10, IWI-HSG

Seite 14

Positionierung von ITIL und TOGAF

strategisch,

ganzheitlich,

change

operativ,

detailliert,

run

IT-fokussiert Ausgeglichen

zwischen

Business/IT

TOGAF

ITIL

© Mai-10, IWI-HSG

Seite 15

Heisst Business/IT Alignment das Business mit IT glücklich zu machen?

Business/IT Alignment im Grossen

Quelle: Hagen, C., Integrationsarchitektur der Credit Suisse, in: Aier, S., Schönherr,

M. (Hrsg.), Enterprise Application Integration - Flexibilisierung komplexer

Unternehmensarchitekturen, GITO-Verlag, Berlin, 2003, S. 61-81.

Applikationskonsolidierung

Plattformmigration

App Z

App X

App Y

IT Effizienz

Geschäftsnutzen

Treiber: Fach-/Funktionsbereiche,

Time-to-Market, Effektivität

Tre

iber: IT

-/Unte

rnehm

ens-

arc

hite

ktu

r, Effiz

ienz

Abschaltung App Z

Neues schönes CRM

Effizienz im Grossen lässt sich nur dauerhaft nur durch Konsistenz,

Konsolidierung und Vereinheitlichung – also Infrastruktur – schaffen.

Schnelle kleine

Geschäfts-

Anwendung

© Mai-10, IWI-HSG

Seite 16

Architekturziele bauen aufeinander auf und haben Tradeoffs

Ohne Zielbildung kein konsequentes Management!

Agilität und Innovation

Gute Vorbereitung auf zukünftige, noch nicht spezifizierbare Änderungsbedarfe

FlexibilitätBessere Anpassbarkeit an heute

schon spezifizierbare Anpassungsbedarfe

Vereinfachung, KonsolidierungSchaffung feingranularer, wiederverwendbarer

Funktionalitätsbündel

Ziel: Mehrfachverwendung von Funktionalitäten

TransparenzAktualisierung und Vervollständigung veralteter, lückenhafter, inkonsistenter

Dokumentationen

Ziel: Messbarkeit von Nicht-Alignment, von fehlender Abdeckung fachlicher

Bedarfe, nicht benötigter IT-Funktionalitäten

Agilität und Flexibilität sind die

„Königsdisziplinen“ – dafür

müssen aber die (mühsamen)

Hausaufgaben gemacht sein.

© Mai-10, IWI-HSG

Seite 17

Es gibt genügend Partial- und Detailarchitekturen

Es braucht eine breite und flache Gesamtsicht

Unternehmens-

strategie

Daten-

strukturen

Unternehmensarchitektur

Detail-Strukturen

Prozesse

Software-

Komponenten

Server und

Plattformen

Märkte

Unternehmensarchitektur sollte die Abhängigkeiten von „Business-to-IT“

transparent machen.

Dies wird nur dann nachhaltig gelingen, wenn man sich nicht in Details verliert.

© Mai-10, IWI-HSG

Seite 18

„Outside-In“ vs. „Inside-Out“

Warum nicht einfach TOGAF nehmen?

GeschäftsleitungUnternehmens-

entwicklung

Compliance

ProjektMgmt

BetriebInformatik

Controlling

Projekt Selekt.

Bus. Inform. Mgt.

Op. Risk Mgt.

Architek. SignOn

Appl. Portfolio Mgt.

IT Alignment

Strat. Optionen

Service Mgt.

Incident Mgt.Schutzobj-

Inventar

Business Continuity

Planning

Metadatenmgt.

Proj. Scanning

Prozess-Arch

Future Screening

Kooperationsmgt.

EA

„Outside-in“ ist der anstrengendere aber auch nachhaltigere (weil partizipative)

Weg zur Transparenz.

© Mai-10, IWI-HSG

Seite 19




Fazit und Ausblick4


© Mai-10, IWI-HSG

Seite 20

Die Alignment-Architektur entkoppelt

fachliche und IT-Architekturen

Strategie-

ebene

Software-

ebene

Organisations-

ebene

Alignment-

ebene

Infrastruktur-

ebene* Gestalten = Prozess der Erst- und Weiterentwicklung

nn Quartale

nn Monate

nn Jahre

Weiterentwicklung der Organisation• Prozesslandkarten

• Prozessmodelle

• Aufbauorganisationsmodelle

• Informationslandkarten

Weiterentwicklung der Strategie• Geschäftsnetzwerkmodelle

• Kundenprozessmodelle

• Leistungsmodelle

• Zielsystem

Permanentes Business/IT Alignment• Domänenmodelle

• Applikationslandschaften

• Capabilities und fachliche Services

Weiterentwicklung der Software• Softwarekomponenten und

Software-Services

• Datenmodelle

Weiterentwicklung der IT-Infrastruktur• Plattforminfrastruktur

• Netzwerkinfrastruktur

Business und IT sind unterschiedlich!

z.B. in ihrer Änderungsfrequenz. Es

braucht eine strukturelle Antwort für ein

nachhaltiges Business/IT Alignment

© Mai-10, IWI-HSG

Seite 21

Business Engineering: Transformation ist vielgestaltig

Alignment: Mehr als nur fachlich getriebene Projekte

Strategie-

ebene

Software-

ebene

Organisations-

ebene

Alignment-

ebene

Infrastruktur-

ebene

Fachlich getriebene

Projekte

(Top-down)

Technisch getriebene

Projekte

(Bottom-up)

Alignment-Projekte

Vereinfachungs-/

Flexibilisierungs-

projekte

(SOA)

Vernetzungs-

projekte

(Fast) jedes Veränderungsprojekt ist anders und braucht daher

eine andere informatorische und methodische Unterstützung.

© Mai-10, IWI-HSG

Seite 22

Welche IT-Artefakte realisieren welche Capabilities/Services – und welche Capabilities braucht es für welche Geschäftsprozesse?

Welche organisations- und realisierungsunabhängigen „Schnitte“ sollten gewährleistet sein?

Wo ist Serviceorientierung sinnvoll, wo nicht?

Wo kann standardisiert werden, wo nicht?

Komponenten der

Alignment-Architektur

Quelle: Aier, S.; Winter, R.: Virtuelle Entkopplung von fachlichen und IT-Strukturen für das

IT/Business Alignment – Grundlagen, Architekturgestaltung und Umsetzung am Beispiel der

Domänenbildung, in: Wirtschaftsinformatik, 51, 2, 2009

… … …

… … …

fachliche Architektur

IT-Architektur

Prozess P1

Softwaresystem S1

P2

S2

… … …

Domäne D1

Applikation A1.1 A1.2

Fachlicher

Service

1.1.1

Alignment-Architektur

Software-

service

1.1

Software-

service

1.2

Traditionell

gestaltetes

Softwaresystem

Software-

serice

2.1

Prozess-

service

1.1

Prozess-

service

1.2

Prozess-

service

1.3

Prozess-

service

1.4

Aktivität

2.1

D2

A2.1

Fachlicher

Service

1.1.2

Capability

1.2.1

Fachlicher

Service

2.1.1

… … …

Es braucht die Bereitschaft, in

Services zu denken, die nicht

Software sind.

© Mai-10, IWI-HSG

Seite 23

Entwicklungsrichtungen

Positionierung von ITIL und Enterprise Architecture

strategisch,

ganzheitlich,

change

operativ,

detailliert,

run


zwischen

Business/ITITIL

Enterprise

Architecture

© Mai-10, IWI-HSG

Seite 24

Muster wie „ein neues Requirement führt zu einer neuen Applikation“

– stellen lokale Sichtweisen dar

– welche für die lokale Umsetzung wichtig sind

– aber auf lange Sicht destruktiv wirken

Auf lange Sicht braucht es zusätzlich die Sicht auf das Grosse Ganze

Nur so lassen sich globale Optima finden

Unternehmen sind nicht-lineare Systeme, sie

benötigen nicht-lineare Optimierungen

© Mai-10, IWI-HSG

Seite 25

Kernprodukte– Transparenz: Ein Bild vom grossen Ganzen.

– Konsistenz und Konsolidierung herstellen: Welche Quickwins für Konsolidierung und Kostensenkung gibt es?

– Konsistenz und Konsolidierung sichern: Überblick über wichtige Projekte und Abstimmung, durch Prinzipien/Richtlinien/Standards und Vorstrukturierung, durch Domänen-/Capabilitymodelle

– Umsetzung begleiten: Durch aktive Mitarbeit der Architekten (!) in den Projekten.

– Kompetenz beweisen: Geschätzter Ansprechpartner für Entscheidungen sein

Anspruchsvollere Produkte– Laufende und proaktive Identifikation von Verbesserungsmöglichkeiten

– Bereitstellung von verbindlichen EA-Roadmaps

– Festschreibung einer gelebten EA-Governance

Wichtige Ansatzpunkte– Nachhaltige Transparenz

– Die richtige Qualifikation von Architekten und Nicht-Architekten

– Nicht alles auf einmal wollen

Um das grosse Ganze zu managen braucht es eine

Reihe zum Teil anspruchsvoller Produkte

© Mai-10, IWI-HSG

Seite 26

Was bedeutet das für das Verhältnis von EA und ITIL?

divide et impera

“Every successful process will grow until it

dies under it„s own weight”

Quelle: Ivar Jacobson.

strategisch,

ganzheitlich,

change

operativ,

detailliert,

run


zwischen

Business/ITITIL

Enterprise

Architecture

© Mai-10, IWI-HSG

Seite 28

IT-Services welche die realen Bedürfnisse des Business treffen sind der kritische Erfolgsfaktor der IT

Diese Bedürfnisse können jedoch oft nicht präzise formuliert werden, ändern sich über Zeit, mit oft viel zu hoher Dynamik, darum sehen wir drei Stossrichtungen:

Stossrichtung 1: Mehr Gesamtsicht und besseres Alignment

– Unterstützung bei der Abstimmung von Strategie, Organisation und IT

– durch Nachführung und Analyse der Abhängigkeiten zwischen den Schlüsselelementen der verschiedenen Ebenen

– so, dass sich Änderungen konsistent umsetzen und strategische Optionen fundiert diskutieren lassen.

Stossrichtung 2: Bessere Anpassbarkeit „im Grossen“

– Identifikation anpassungskritischer Kernstrukturen auf Organisations-, Alignment- und Softwareebene sowie

– serviceorientierte Restrukturierung dieser Kernstrukturen.

Stossrichtung 3: Professionalität im Detail

– Gestaltung, Betrieb und Management der Strukturen im Detail muss professionell gestaltet sein

– Best Practices sind vorhanden

– Messbarkeit ist die Voraussetzung für Management

Diese Stossrichtungen sind im Kern verschieden und benötigen darum auch unterschiedliche Ansätze.

Ab einem gewissen Integrationsgrad überwiegen die Integrationskosten den Integrationsnutzen

Fazit

© Mai-10, IWI-HSG

Seite 29

Theoretisches Verständnis erlangen ist das eine – Impact generieren ist

manchmal etwas anderes (aber komplementäres)

Darum arbeiten wir in zwei Richtungen

– Erweiterung des Body of Knowledge in unserer Community (Beispiele: EA-

Planung, Geschäftsprozesssteuerung, prinzipiengeleitetes Design)

– Anwendung, Validierung und Verbesserung des Body of Knowledge (Beispiele:

Aufbau von EA-Programmen, Tooleinsatz, Wiederbelebung von Architektur)

IWI-HSG hat dafür eine solide Basis geschaffen durch

– das Business Engineering Framework,

– Methoden und Modelle für Unternehmensarchitekturmanagement und

serviceorientierte Restrukturierung,

– Werkzeuge für Unternehmensarchitekturmanagement

„Business-to-IT“: ADOben sowie

– die Plattform und das Netzwerk für professionellen Austausch und

Weiterentwicklung der Themen: Kompetenzzentrum Integration Factory.

Ausblick

© Mai-10, IWI-HSG

Seite 31

Regelmässige Veranstaltungen

über das F&E-Netzwerk hinaus

Informationen und Anmeldung:

http://awf.unisg.ch

http://www.dw2010.ch

http://www.ea2010.ch

Dreimal jährlich:

St. Galler Anwenderforum

nächste Veranstaltung am 31. Mai 2010:

Informationslogistik und Business Intelligence

Alle zwei Jahre:

Konferenz DW/EA 2010

09./10. November 2010

http://awf.unisg.ch/

http://awf.unisg.ch/

http://www.dw2010.ch/

http://www.ea2010.ch/

© Mai-10, IWI-HSG

Seite 32

Aktuelle Bände der Business Engineering-Reihe

– Winter, R. (Hrsg.): Management von Integrations-projekten, Berlin etc.: Springer, erscheint Mai 2009

– Dinter, B.; Winter, R. (Hrsg.): Integrierte Informa-tionslogistik, Berlin etc.: Springer 2008

EA-Forschungs-Web SitesCC IF: http://ccif.iwi.unisg.ch

ADOben: http://adoben.iwi.unisg.ch

Ausgewählte deutschsprachige Aufsätze (meist PDF-Download auf http://www.iwi.unisg.ch oder http://alexandria.unisg.ch)

– Aier, S.; Riege, C.; Winter, R: Unternehmensarchitektur – Literaturüberblick und Stand der Praxis, in:

Wirtschaftsinformatik, 50, 4, 2008, S. 292-304.

– Fischer, R.; Winter, R.: Ein hierarchischer, architekturbasierter Ansatz zur Unterstützung von IT-Business Alignment,

in: Oberweis, A. et al. (Hrsg.): eOrganisation – Service-, Prozess-, Market-Engineering, Band 2, Karlsruhe: Universitätsverlag

Karlsruhe 2007, S. 163-180

– Hafner, M.; Schelp, J.; Winter, R.: Architekturmanagement als Basis effizienter und effektiver Produktion von IT-

Services, in: HMD - Praxis der Wirtschaftsinformatik, 41, 237, 2004, S. 54-66.

– Winter, R.; Schelp, J.: Dienst-Orientierung im Business Engineering, HMD 241 (2005), S.45-54

– Aier, S.; Winter, R.: Virtuelle Entkopplung von fachlichen und IT-Strukturen für das IT/Business Alignment –

Grundlagen, Architekturgestaltung und Umsetzung am Beispiel der Domänenbildung, in: Wirtschaftsinformatik, 51, 2,

2009, S. 175–191

Zum Nachlesen…

http://www.iwi.unisg.ch/

http://alexandria.unisg.ch/

(IT) Service Management und (Enterprise) Architecture · (IT) Service Management und (Enterprise)...

Documents

Transcript of (IT) Service Management und (Enterprise) Architecture · (IT) Service Management und (Enterprise)...