ITSV GmbH Johann-Böhm-Platz 1
1020 Wien
T: 050 124 844 56 00
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
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!