ITSV GmbH Johann-Böhm-Platz 1

1020 Wien

T: 050 124 844 56 00

office@itsv.at

www.itsv.at Datum:

Ort:

Moderation:

Fachliches und technisches Schneiden

von Systemlandschaften

Iteratec GmbH, München-Unterhaching

Michael Klenkhart

24.04.2013

Firmenvorstellung ITSV GmbH

Grundlagen zum Schneiden der Systemlandschaft

Herausforderungen aus der Praxis

Viewpoints aus der Praxis

Lessons Learned

2

Agenda

Die ITSV GmbH –

IT-Services der Sozialversicherung GmbH

Keyfacts

Im November 2004 als 100%ige Tochter der österreichischen

Sozialversicherungen gegründet

Abdeckung der gesamten IT-Wertschöpfungskette

Full-Service-Provider der österreichischen Sozialversicherungsträger

Unsere Kunden

Hauptverband der österreichischen

Sozialversicherungsträger

Pensions- und Unfallversicherungsanstalt

Spartenübergreifende, bundesweite Träger

Gebiets- und Betriebskrankenkassen

Rund 200 Kunden aus dem öffentlichen Bereich

(Ministerien, Kammern, etc.)

Alle Sozialversicherten Österreichs (~ 8,4 Mio.)

3

Firmenvorstellung

Gesetzlicher Auftrag „§ 31 Abs. 5 Z 4 ASVG“

Kompatible EDV Strukturen

Nutzung Standardprodukte (Gleichheitsprinzip)

Grundsätze Gesamtwirtschaftlichkeit und Zweckmäßigkeit

Zusammenarbeitsmodell

Governance Auftrag ITSV

Selbstverwaltung Träger

Full Service Provider

Services für Kunden unabhängig von deren Geschäftsfeld

Überzeugende SV-IT Lösungen aus einer Hand

4

ITSV - Full Service Provider

5

Überzeugende SV-IT Lösungen aus

einer Hand für unsere Kunden

VIER KERNZIELE der ITSV

1. Kundenbeziehungen

2. Application Lifecycle

3. Definition von IT-Strategie, IT-

Architektur

4. Servicierung der

österreichischen SV-Träger

ITSV - Full Service Provider

ITSV Portfolio

Betrieb der Zielrechenzentren der SV Träger

Betrieb Servicecenter

Entwicklung von SV Applikationen

Koordination von SV Programmen und Projekten

Verwaltung von hochsensiblen Daten

2011 640 TB 640.000.000.000 Byte!

2013 1,3 PB 1.300.000.000.000 Byte!

ISO 27001 zertifiziert seit 2011

Statistiken 2012

8,4 Mio. SV versicherte Personen*

3,6 Mio. unselbstständig erwerbstätige Personen**

0,5 Mio. selbstständig erwerbstätige Personen**

0,3 Mio. Unternehmen**

0,1 Mio. mithelfende Angehörige**

302 sonstige Datenvermittlungspartner (Behörden…)

6

*: Schätzung HVB

** Quelle: Statistik Austria 2012

ITSV – STANDORTE

7

Rechenzentren: 2010: 6 RZ Standorte

2011: 3 RZ Standorte

2012: 3 RZ Standorte

2013: 3 RZ Standorte

Mitarbeiterstandorte: 2009: 4 Standorte

2010: 3 Standorte

2011: 2 Standorte

2012: 2 Standorte

2013: 3 Standorte

Firmenvorstellung ITSV GmbH

Grundlagen zum Schneiden der Systemlandschaft

Herausforderungen aus der Praxis

Viewpoints aus der Praxis

Lessons Learned

8

Agenda

Grundlagen zum Schneiden der

Systemlandschaft

Philosophie des Enterprise Architecture Managements der ITSV

Nutzung von internationale Standards TOGAF als EA Methode

Zentrales EAM Team unterstützt Stakeholder

Ansatz EAM

Stakeholder sind ergebnisorientiert

Stakeholder bestimmen deren Viewpoints

Methodiken und Richtlinien des EA Repository nur intern wichtig

Information muss durch EAM strukturiert werden

Aufgaben des EAM Teams

sammeln und konsolidieren von Unternehmensinformation

Aggregation von Information

zur Verfügung Stellung von Viewpoints

9

Viewpoints = Technische und/oder fachliche Schnitte der IT-Landschaft

Schritte um Viewpoint zu entwickeln

Identifikation der Stakeholder

Identifikation der notwendigen Viewpoints

Identifikation des Frameworks

…

Es muss ein gemeinsame Verständnis entwickelt werden

WAS betrachtet wird

WIE dies betrachtet wird

Wie sieht der Kuchen aus und wie wird er präsentiert

Vorgangsweise in allen Frameworks und Vorgangsweisen ähnlich

Grundlagen zum Scheiden der

Systemlandschaft

10

Grundlagen zum Schneiden der

Systemlandschaft

TOGAF (The Open Group Architecture Framework)

Zachman Enterprise Architecture Framework

Hanschke Best-Practice (Framework?)

Oder weitere wie

NAF (NATO Architecture Framework)

FEAF (US Federal Enterprise Architecture Framework)

… (Auswahl aus bis zu 70 Frameworks möglich*)

Schwerpunkt entweder auf

STRUKTURIERUNG (Architektur-Referenzmodell) oder

ENTWICKLUNG (Vorgehens-Referenzmodell)

der Unternehmensarchitektur

11

*lt. Schätzung Wikipedia (http://de.wikipedia.org/wiki/Unternehmensarchitektur#Enterprise_Architecture_Frameworks_.28EAF.29), Angabe

Matthes (Enterprise Architecture Frameworks Kompendium), Hanschke (Enterprise Architecture Management - einfach und effektiv)

Schwerpunkt: Entwicklung der Unternehmensarchitektur

Unterstützung:

Unternehmensarchitektur in

Iterationen (weiter)entwickeln

Mittel: ADM

(Architecture Development Method)

in früher Phase (Architecture

Context) ist zu bestimmen für

WEN

WAS

WIE

aufbereitet werden soll

TOGAF (The Open Group Architecture Framework)

12

TOGAF (The Open Group Architecture Framework)

Unternehmensdaten in Content Meta Model zuordenbar

Stakeholderviews werden nicht vorgegeben

Ein Mittel zur Darstellung ist ArchiMate 2.0

Andere Darstellung müssen erarbeitet werden

Teilweise SEHR theoretisch aufgebaut!

13

arch ArchiMate Diagram

Acteur

Businessservices

internextern

Client Partner ... Employees ...

Business Service 1 Business Service 2 Business Service x

Business Process 1 Business Process 2 Business Process 3 Business Process n

Applikationsschicht

Application Service

1

Application Service

2

Application Service

3

Application Service

4

Application Service

m

Application Service

5

Application 1 Application 2 Application 3 Application 4 Application 5 Application 6 Application xApplication 7

Virtualisation

Virtual Server 1 Virtual Server 2 Virtual Server 3 Virtual Sever k

Infrastucture Service 1 Infrastructure Service 2 Infrastructure Service 3 Infrastructure Service j

Virtual Server 4 Vitual Server 5

Hardware (Reality)

Physical Server 1 Physical Server 2

Power Connector 1 Switch 1Power Connector 2 UPS Storage 1 Storage 2 ...

Schwerpunkt: Strukturierung der Unternehmensarchitektur

Bereitstellung von Sichten zur Beschreibung der

Unternehmensarchitektur WAS (Datensicht)

WIE (Funktionssicht)

WO (Netzwerksicht)

WER (Personen)

WANN (Zeitbezug)

WARUM (Motivation)

für bestimmte Rollen Planer

Besitzer

Designer

Builder

Programmierer

Nutzer

Zachman (Zachman Enterprise Architecture Framework)

14

Bildquelle: Zachman International, http://www.zachman.com

DATEN FUNKTION NETZWERK PERSONEN ZEIT MOTIVATION

Was Wie Wo Wer Wann Warum

Zielsetzung/Bereich

(Kontextabhängig )

→ Rolle: Planer

Unternehmensmodell

(Konzeptionell )

→ Rolle: Besitzer

Systemmodell

(Logisch )

→ Rolle: Designer

Technologiemodell

(Physisch )

→ Rolle: Builder

Detaillierte Darstellung

(Aus dem Kontext heraus)

→ Rolle: Programmierer

Unternehmen

→ Rolle: Nutzer

Zachman Enterprise

Architecture Framework

Nutzbare Daten Anwendungszweck Nutzbares Netzwerk Arbeitsorganisation Eingeschlossener Zeitplan Arbeitsweise

Datendefinitionen Programm Netzwerkarchitektur Sicherheitsarchitektur Zeitplan Regelspezifizierung

Physische Daten/

KlassenmodellTechnologie-designmodell Technologiearchitektur Darstellungsarchitektur Kontrollstruktur Regeldesign

Logisches Datenmodell SystemarchitekturmodellDistributed Systems

Architecture

Human Interface-

ArchitekturProzessstruktur Geschäftsregelmodell

Konzeptionell

Datenmodell/ObjektmodellGeschäftsprozessmodell Geschäftslogistiksystem Arbeitsablaufmodell Ablaufplan Geschäftsplan

Liste von wichtigen

Faktoren im GeschäftListe von Kernprozessen Liste von Geschäftsstellen

Liste von wichtigen

OrganisationenListe von Ereignissen

Liste von

Geschäftszielen/Strategien

Schwerpunkt: Bereitstellung von Sichten zur Beschreibung der

Unternehmensarchitektur

Zachman (Zachman Enterprise Architecture Framework)

15

Bildquelle: Zachman International, http://www.zachman.com

DATEN FUNKTION NETZWERK PERSONEN ZEIT MOTIVATION

Was Wie Wo Wer Wann Warum

Zielsetzung/Bereich

(Kontextabhängig )

→ Rolle: Planer

Unternehmensmodell

(Konzeptionell )

→ Rolle: Besitzer

Systemmodell

(Logisch )

→ Rolle: Designer

Technologiemodell

(Physisch )

→ Rolle: Builder

Detaillierte Darstellung

(Aus dem Kontext heraus)

→ Rolle: Programmierer

Unternehmen

→ Rolle: Nutzer

Zachman Enterprise

Architecture Framework

Nutzbare Daten Anwendungszweck Nutzbares Netzwerk Arbeitsorganisation Eingeschlossener Zeitplan Arbeitsweise

Datendefinitionen Programm Netzwerkarchitektur Sicherheitsarchitektur Zeitplan Regelspezifizierung

Physische Daten/

KlassenmodellTechnologie-designmodell Technologiearchitektur Darstellungsarchitektur Kontrollstruktur Regeldesign

Logisches Datenmodell SystemarchitekturmodellDistributed Systems

Architecture

Human Interface-

ArchitekturProzessstruktur Geschäftsregelmodell

Konzeptionell

Datenmodell/ObjektmodellGeschäftsprozessmodell Geschäftslogistiksystem Arbeitsablaufmodell Ablaufplan Geschäftsplan

Liste von wichtigen

Faktoren im GeschäftListe von Kernprozessen Liste von Geschäftsstellen

Liste von wichtigen

OrganisationenListe von Ereignissen

Liste von

Geschäftszielen/Strategien

Bereitstellung von Sichten zur Beschreibung der

Unternehmensarchitektur

Viewpoint werden in einem Schema strukturiert

Stakeholderviews und Mittel zu deren Darstellung sind dadurch

(großteils) vorgegeben

Vorgehensweise zur Entwicklung der Unternehmensarchitektur

(Prozesse) und Verwertung der Information ist NICHT vorgegeben.

umfassende Sammlung von Viewpoints ohne

Prozessunterstützung

Zachman (Zachman Enterprise Architecture Framework)

16

Bildquelle: Zachman International, http://www.zachman.com

Schwerpunkt: Strukturierung der Unternehmensarchitektur

pragmatischer Ansatz zur Entwicklung von Stakeholderviews

Finde Stakeholder

Vereinbare relevante Darstellungen „aus dem Katalog“

Erhebe Daten und stelle Pflegeprozess sicher

Stelle die Views bereit

Iterativer Entwicklungsprozess

Best Practice bietet Mischform aus

Strukturierte Views wie Zachman

Vorgehensmodel wie TOGAF

Hanschke (EAM einfach und effektiv)

17

Unterstützung:

Vorgehensmodell publiziert und durch Berater unterstützt

„Best-Practice-Unternehmensarchitekturmodel“ vorgegeben

Stakeholderviews durch vorgegebene Auswertungen „Best-Practice-

Visualisierungen“

Schnelle Ergebnisse erreichbar, eigene Konzepte müssen „interpretiert“ werden

Hanschke (EAM einfach und effektiv)

18

Firmenvorstellung ITSV GmbH

Grundlagen zum Schneiden der Systemlandschaft

Herausforderungen aus der Praxis

Viewpoints aus der Praxis

Lessons Learned

19

Agenda

Bebaute Information

WELCHE Informationssysteme werden eingesetzt

WIE kommunizieren diese IS fachlich (TOP Ebene)

WER verwendet diese Informationssysteme WARUM

BETRIESTANDORTE der Informationssysteme

Stakeholder

Management

Competencecenter und andere Entwicklungseinheiten

Änderungsprojekte

Sicherheitsbeauftrage

Betriebseinheiten

Ansatz

„Hanschke“ wurde gewählt und Teilaspekte des TOGAF Content

Metamodels damit bebaut

Erweiterte Viewpoints durch Toolverbund

Vorgehensweise EAM der ITSV

20

Beispiel: Anforderungen View „Informationssystem Steckbrief“

Kriterien eines Informationssystems für Steckbrief

Fachlichkeit/Auftrag: aus Sicht der ENDANWENDER

Informationssystem können Fachlichkeit zentral anbieten = technische

Querlieger (z.B. Berechtigungssystem…)

Eigener, abgrenzbare Programmlogik ist vorhanden (Deployment)

Muss Information eines Informationssystems

Name (Schlüsselmerkmahl in Bebauung)

Beschreibung

Technische Architektur

Verantwortung (Organisationseinheit)

Ansprechpartner

Sicherheitsklasse

Abhängigkeiten (Nutzungsbeziehungen)

Anwender (fachliche Zuordnung zu Kompetenz und Anwendergruppe)

Vorgehensweise EAM der ITSV

21

Beispiel: Anforderungen „Informationssystem Steckbrief“

Aggregierte Information notwendig

Betriebsstandorte

Informationssystemeigenschaften

Typisierung

Architektur

Anwender

Geschäftskompetenz

Nutzung des iteraplan-Repository und

Aufbereitung von zielgruppenspezifischen

Stakeholderviews durch EAM

Vorgehensweise EAM der ITSV

22

Hinweis: Die gezeigten Daten wurden für öffentliche Vorführung erstellt und stellen nicht den IST-Stand der SV Architektur dar!

ITSV GmbH Johann-Böhm-Platz 1

1020 Wien

T: 050 124 844 56 00

office@itsv.at

www.itsv.at Datum:

Ort:

Moderation:

Fachliches und technisches Schneiden

von Systemlandschaften: Teil 2

Iteratec GmbH, München-Unterhaching

Michael Holakovsky

24.04.2013

Ein großes Datenmodell bedeutet nicht automatisch

bessere Viewpoints

Komplexe und detailreiche Viewpoints sind schön

aber schwer wartbar

Beides interessiert die Stakeholder nicht, sie wollen

nur ihre Viewpoints und die möglichst schnell

Viewpoint- oder Datenmodell-

getriebene Bebauung

24

ArchiMate und TOGAF zur

Beschreibung

25

ArchiMate 2.0 Elemente

26

Workshops mit Hersteller

2012 Workshop-Serie mit

verschiedenen Herstellern aus dem

oberen Gartner-Quadranten mit dem

Ziel:

verstehen der unterschiedlichen

Herangehensweisen

Arten von Viewpoints

Automatische Reportgenerierung

Datenpflege

27

Spannungsverhältnisse in der

Bebauung

28

Schnelle Ergebnisse Automatische

Reports

hochspezifische

Viewpoints

Datenpflege

Qualitätssicherung Usability

Viewpoint-getrieben Bebauung

(Entwicklung)

Optimal für hochspezifische Stakeholder

Views

Einfache Strategische Szenarienplanung

Gute Usability (Visio-Style)

Keine Modellierungsvorschriften

notwendig

Schlechte Wartbarkeit der Views

Keine schnellen Ergebnisse 29

arch ArchiMate Diagram

Acteur

Businessservices

internextern

Client Partner ... Employees ...

Business Service 1 Business Service 2 Business Service x

Business Process 1 Business Process 2 Business Process 3 Business Process n

Applikationsschicht

Application Service

1

Application Service

2

Application Service

3

Application Service

4

Application Service

m

Application Service

5

Application 1 Application 2 Application 3 Application 4 Application 5 Application 6 Application xApplication 7

Virtualisation

Virtual Server 1 Virtual Server 2 Virtual Server 3 Virtual Sever k

Infrastucture Service 1 Infrastructure Service 2 Infrastructure Service 3 Infrastructure Service j

Virtual Server 4 Vitual Server 5

Hardware (Reality)

Physical Server 1 Physical Server 2

Power Connector 1 Switch 1Power Connector 2 UPS Storage 1 Storage 2 ...

Datamodell-getriebene Bebauung

(Strukturierung)

Schnelle Ergebnisse

Einfache Wartbarkeit der Viewpoints

Änderung des Viewpoints möglich

Komplexe GUI

Hochspezifische Viewpoints nur

über Export und Customizing

Modellierungsvorschriften

notwendig

30

Firmenvorstellung ITSV GmbH

Grundlagen zum Schneiden der Systemlandschaft

Herausforderungen aus der Praxis

Viewpoints aus der Praxis

Lessons Learned

31

Agenda

Iteraplan: Modellierung von

Mandantenfähigkeit von Systemen

32

SAP Org1 SAP Modul FI-TV

SAP Org2 SAP Modul PA

SAP

Modul FI-TV

Mandant Org1

Option reduziert:

+ Einfach zu modellieren

+ Release leichter wartbar

- wenig Detailinformation

- Viele Informationssysteme

Option modulorientiert:

+ Mehr Details

- noch mehr

Informationssysteme

- unübersichtlich

Option hierarchisch:

+ hohe Detaildichte

+ geeignet für strategische

Aussagen

+ mandantenspezifische

Datenflüsse

- Pflegeaufwand

- Usability

- Releases schwer wartbar

Iteraplan: Modellierung von

Mandantenfähigkeit von Systemen

33

Enterprise Continuum

34

automatisch generierte Viewpoints Datennavigation mit Dritt-Werkzeugen

automatisch generierte Wikiseiten Datenauswertung durch Experten

Beispiele für Viewpoints:

Business Capabilities

35

Beispiele für Viewpoints:

Business Capabilities

36

Beispiele für Viewpoints:

Business Capabilities & TA

37

Beispiele für Viewpoints:

Schnittstellenabhängigkeiten

Spezifische Datenfluss-

darstellung für den Produkt-

verantwortlichen des „System

354“

38

Beispiele für Viewpoints:

Exposure

Visualisierung des „Exposure“

eines bestimmten Ausschnittes

der IT-Bebauung.

Das Konzept der Exposure wird

z.B. im Rahmen des IT

Sicherheitsprozesses verwendet

um bei Sicherheitsüberprüfungen

eine Priorität festzulegen.

Bei Detailanalysen können

dadurch heikle Systemabschnitte

leichter identifiziert werden.

39

Statistiken sind wichtig, z.B.

Verlauf des Nutzungsgrades

40

0

20

40

60

80

100

120

140

160

180

Nutzungsgrad 0

Nutzungsgrad 1

Nutzungsgrad 2-5

Nutzungsgrad 6-10

Nutzungsgrad 11-20

Nutzungsgrad 21-30

Nutzungsgrad >30

Firmenvorstellung ITSV GmbH

Grundlagen zum Schneiden der Systemlandschaft

Herausforderungen aus der Praxis

Viewpoints aus der Praxis

Lessons Learned

41

Agenda

Lessons Learned

Fokusierung auf Stakeholder und deren Viewpoints

Aggregation von Daten und Generierung von Viewpoints aus dem

Datenmodell ist die Aufgabe des EAM

Komplexeres Datenmodell bedeutet nicht notwendigerweise mehr

oder bessere Viewpoints

GUI zur Modellierung ist nicht für die breite Masse geeignet (bei allen

Herstellern)

Regelmässige Abwägung zwischen Modellierungstiefe und

Wartbarkeit

42

Vielen Dank für Ihre

Aufmerksamkeit!