Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
beck et al. projects Theresienhöhe 13, 80339 München, T 089/54 42 53-0, F 089/54 42 53-99, [email protected], www.bea.de
Unternehmensprofil
beck et al. projects
9. Januar 2009
Neues Bild!!!!
0-51-201
51-92-214
102-133-224
153-174-234
204-215-244
251-145-0
51-92-214
102-133-224
153-174-234
204-215-244
204-215-244
Volker Maiborn, Holger Wolff 25.06.2009 2
Leistungsspektrum
Auf wenige Kernkompetenzen fokussiert B
e r
a t u
n g
U m
s e
t z
u n
g
plan
build
run Betrieb & Support
IT-Service-Management
B e
r a
t u
n g
U m
s e
t z
u n
g
D CH
ROM D
0-51-201
51-92-214
102-133-224
153-174-234
204-215-244
251-145-0
51-92-214
102-133-224
153-174-234
204-215-244
204-215-244
Volker Maiborn, Holger Wolff 25.06.2009 3
Profil
beck et al. projects steht für …
2005 2006 2007 2008
Umsatz
+24%
0-51-201
51-92-214
102-133-224
153-174-234
204-215-244
251-145-0
51-92-214
102-133-224
153-174-234
204-215-244
204-215-244
Volker Maiborn, Holger Wolff 25.06.2009 4
beck et al. projects wächst weiter
2008 2006 2007 2005
3,8
4,9
6,5
+27%
+24%
Umsatz in Mio !
! " Knappe Verdopplung von Umsatz und Mitarbeitern seit
2003
! " Ziel: bis 2010 unter die TOP50
der deutschen System-integratoren
! " (>10 Mio! Umsatz, >100 MA)
! " 18% durchschnittliches
Wachstum p.a.
! " Als beck et al. Gruppe unter
die TOP30 der deutschen
Systemintegratoren bis 2012
10,0
2010
7,2
+33%
+11%
0-51-201
51-92-214
102-133-224
153-174-234
204-215-244
251-145-0
51-92-214
102-133-224
153-174-234
204-215-244
204-215-244
Volker Maiborn, Holger Wolff 25.06.2009 5
Kunden
In 2008 arbeiten wir für …
0-51-201
51-92-214
102-133-224
153-174-234
204-215-244
251-145-0
51-92-214
102-133-224
153-174-234
204-215-244
204-215-244
Volker Maiborn, Holger Wolff 25.06.2009 6
Team
Bei bea.p engagieren sich aktuell 51 (angestellte) Mitarbeiter
Wertenetz
0-51-201
51-92-214
102-133-224
153-174-234
204-215-244
251-145-0
51-92-214
102-133-224
153-174-234
204-215-244
204-215-244
Volker Maiborn, Holger Wolff 25.06.2009 7
Consulting für Strategisches IT-Management
Astrid Blechschmidt
Unsere Kunden sind namhafte nationale
und internationale Unternehmen aus den
unterschiedlichsten Branchen.
Wir bieten unseren Kunden ein umfangreiches
Beratungsangebot von der IT-Strategie auf der Grundlage
ihrer Prozesse über die Prozessberatung bis hin zur Auswahl
von Lösungswegen.
Unsere zentralen Themen sind:
•! Analyse IT-Landschaft
•! Beratung IT-Strategie
•! IT und Geschäftsprozessmanagement
•! Businessanalyse
•! Requirements Engineering
Aktuelle Kundenprojekte im Bereich IT-Beratung:
"! CODIAC „Consolidation of direct customer activities“, TUI AG
"! „Globe“: Integration „EKMS“ in neue Systemlandschaft, Thomas Cook AG
"! Business Analyse „Internationales Buchungssystem der
Europäischen Bahnen“, Railteam Broker, SBB
"! IT-/ Prozess- Berater mit branchen-übergreifendem
Know how
"! IT Consultants
"! Business Analysten
"! Projektmanager
Unsere Erfahrungen aus den Kundenprojekten werden
kontinuierlich analysiert und sind für uns ein wichtiger
Bestandteil unserer Beratungsleistung. Hierdurch können wir
objektive und unabhängige Aussagen sowohl in der Analyse
bestehender IT-Prozesse als auch in der Evaluierung neuer
Lösungskonzepte treffen.
Unsere Stärke ist die Kombination aus
branchenübergreifenden Projekt-
erfahrungen mit einem fundierten
technischen und betriebs-
wirtschaftlichen Fach-Know-How.
0-51-201
51-92-214
102-133-224
153-174-234
204-215-244
251-145-0
51-92-214
102-133-224
153-174-234
204-215-244
204-215-244
Volker Maiborn, Holger Wolff 25.06.2009 8
Software-Engineering
+ Consulting Software-Architektur & Requirements Engineering
Dominik Neff
! " JAVA / JEE
! " IBM Websphere
! " JBoss
Aktuelle Kundenprojekte im Bereich Software-Engineering:
!" FITS, Continental AG (Java – Rich Client)
!" UMS, Deutsche Telekom AG (C++, Java)
!" Subito/Odin, Infineon Technologies AG (Lotus Notes)
!" VPA, Infineon Technologies AG (.Net)
!" GCC , Daimler AG (Websphere)
Unsere Kunden sind namhafte nationale
und internationale Unternehmen aus den
unterschiedlichsten Branchen, die mit
effektiven Softwarelösungen
Wettbewerbsvorteile erzielen.
Kay Krüger-Barvels René Glettler
!" Team von 20 Mitarbeiter
(Stand 10/08), überwiegend
Diplom-Informatiker
Unsere Technologie-Schwerpunkte
Wir liefern unseren Kunden aus allen Branchen
maßgeschneiderte und individuelle Software Lösungen.
Wir konzipieren fundierte und stabile Software Lösungen und
setzen diese um. Wir unterstützen den Kunden dabei in allen
Phasen des Software Lifecycles. Neben Software Entwicklung und
Architektur sehen wir das Requirements Engineering als weitere
Kernkompetenz an.
Wir sind mit den Geschäftsprozessen
unserer Kunden vertraut und verstehen
uns als Unterstützer für das Erreichen
der Geschäftsziele.
0-51-201
51-92-214
102-133-224
153-174-234
204-215-244
251-145-0
51-92-214
102-133-224
153-174-234
204-215-244
204-215-244
Volker Maiborn, Holger Wolff 25.06.2009 9
Software Testmanagement
Wir haben die “Die Eleganz des Testens“ entwickelt:
Aus unseren zwölf Testfallermittlungsmethoden wählen wir je
nach Projektzustand die passende Kombination an
Testmethoden aus, um ein effizientes, schnelles und qualitativ
hochwertiges Testergebnis zu ermöglichen.
Eric Jochum
!" Team von 15 Mitarbeiter
(Stand 10/08), überwiegend
Diplom-Informatiker
!" Nach ISTQB zertifizierte Tester
!" Aktive Mitarbeit in der GI-TAV
!" Branchenübergreifende Projekterfahrungen
Das Team von bea Testmanagement versteht sich in allen
Facetten des Testmanagements, bei den unterschiedlichsten
Softwareprojekten, in unterschiedlichen Branchen und zu jedem
Zeitpunkt als der Berater auf Augenhöhe mit dem Kunden.
Zu unseren Kernkompetenzen gehören:
•" Prozessanalyse
•" Testprojektmanagement (beratend & operativ)
•" Testfallermittlung und -Durchführung,
•" Testautomatisierung,
•" Last- und Performanztests
•" Schulung (ISTQB)
Unser professionelles Testmanagement stellt nahezu fehlerfrei
und zuverlässig laufende Software im Unternehmen sicher.
Der frühe Einsatz von Testmanagement ermöglicht ein früheres
Auffinden von Spezifikations- oder Implementierungsfehlern,
womit eine kostengünstige Korrektur möglich wird.
Die Ergebnisse eines
erfolgreichen Testmanagement:
Durch unsere systematischen Ansätze
ist das bea Testmanagement
unabhängig vom Fachgebiet in jeder
Branche einsetzbar.
Unsere Kunden
sind namhafte nationale und internationale Unternehmen aus den
unterschiedlichsten Branchen
Testfallermittlung & -durchführung
Testautomatisierung
Last- und Performancetests
Testprojekt-Metriken
Testmanagement
PROZESS ANALYSE
SCHULUNGEN
0-51-201
51-92-214
102-133-224
153-174-234
204-215-244
251-145-0
51-92-214
102-133-224
153-174-234
204-215-244
204-215-244
Volker Maiborn, Holger Wolff 25.06.2009 10
Detaillierte Informationen
www.bea.de
Projektsteckbriefe
Case Studies
Unternehmensprofil
© SBB • Informatik • 11.04.08 1
Transparenz schaffen, Strukturen erkennen, Landschaften gestalten.
Eine Fallstudie zur Einführung von EAM bei der SBB
Holger Wolff, (ex) Chief Architect SBB, Leiter IT-AQ (Architecture & Quality)
Dokument Klassifizierung: Vertraulich Autor(en): H. Wolff Status: final Version: 1.0 Letzte Änderung: 23.10.2008 Urheberrecht: Dieses Dokument ist urheberrechtlich geschützt. Jegliche kommerzielle Nutzung
bedarf einer vorgängigen, ausdrücklichen Genehmigung der SBB AG. Ablage: Verteiler: Teilnehmer der IIR Tagung Enterprise Architecture Management (EAM)
© SBB • Informatik • 11.04.08 2
Summary
Welches Problem war zu Lösen ?
Wie haben wir das Problem gelöst?
Lessons learnt
1 Intransparenz – niemand hatte einen Gesamt-überblick
2 Redundanz – extrem viele fachliche und technische Redundanzen
3 Sehr hohe Risikoexposition – durch fehlende Standards, fehlende Governance und schlechte Qualität.
4 5 Initiativen zur Einführung Von EAM
5 Klare, messbare Ziele, definieren, lösungs- orientiert denken.
6 Rhythmus und Disziplin, EAM ist eine Prozess-disziplin.
7
Was kann ich empfehlen, was hat gut funktioniert?
8 Things to change: was würde ich heute anders machen.
Die erfolgreiche Einführung von Enterprise Architecture Management bei der SBB
© SBB • Informatik • 11.04.08 3
Das IT Management muss künftig auf Unternehmensebene stattfinden.
!! Anforderungen der Geschäftsarchitektur beziehen sich meist auf Prozesse, die durch mehrere (integrierte) Anwendungen unterstützt werden.
!! Betrachtung der IT Architektur von mehreren Anwendungen wird sehr schnell sehr komplex
Portfolio I
Portfolio G
Portfolio P
Portfolio I
Portfolio G
Portfolio P
unternehmensweite IT- Architektur
© SBB • Informatik • 11.04.08 4
Die divisions- und domänenübergreifende Vernetzung von Anwendungen wird zu einer Schlüsselkompetenz der IT – die Divisionen sind keine Inseln!
Vorteile: !! kein grosser Aufwand für Architektur Nachteile: !! gleiche Funktionalitäten mehrfach vorhanden
(Ineffizienz) !! gleiche Daten mehrfach vorhanden (Gefahr von
Inkonsistenz) !! Geschäftsprozesse nicht sichtbar !! Business denkt in Anwendungen, nicht in
Geschäftsprozessen
Bisher stand die einzelne Anwendung im Fokus
!! Hochgradige Vernetzung der P-Systeme vor allem mit P-OP (SYFA, SURF, ProSURF und AFI)
!! Soll- und Ist-Fahrplandaten fliessen von I zu P-Systemen, I ist andererseits jedoch auch von Daten aus CERES abhängig
!! Vernetzung und Wiederverwendung von Services innerhalb der Domäne M&V (MCS – POS, MCS-Automaten, MCS-Basissysteme, etc.)
Erkenntnisse
© SBB • Informatik • 11.04.08 5
Die Priorität verschiebt sich von den individuellen „Anwendungssilos“ zur integrierten Gesamtarchitektur.
!! „Design for Integration“ –! keine einzelne IT-Anwendung wird
isoliert entworfen und implementiert.
–! die Gesamtarchitektur steht im Vordergrund.
!! „Design for Flexibility“ –! Anwendungen müssen änderbar,
erweiterbar, neu zusammenfügbar sein.
Portfolio I
Portfolio G
Portfolio P
unternehmensweite IT- Architektur
Geschäftsarchitektur
© SBB • Informatik • 11.04.08 6
Das Änderungsmanagement der IT- Architekturen wird komplexer und muss stärker zentralisiert werden.
!! Änderungszyklen der Geschäftsarchitektur werden kürzer.
!! Änderungszyklen der unternehmensweiten IT Architektur werden somit ebenfalls kürzer.
!! Unternehmenseinheitliches Releasemanagement nötig.
–! Übergreifendes Programm- und Release- management erforderlich
–! Steigende Anforderungen an das Management von übergreifenden Projekten und Services
–! Identifikation von „Show Stoppern“
Portfolio I
Portfolio G
Portfolio P
unternehmensweite IT- Architektur
Geschäftsarchitektur
© SBB • Informatik • 11.04.08 7
Die Aufgaben der IT wandeln sich drastisch:
Neuausrichtung des IT-Managements
Ausweitung des IT-Architektur Managements auf die Unternehmensebene
Integration der Anwendungsarchitekturen in eine unternehmensweite
IT-Architektur
Weiterentwicklung der Anwendungsarchitekturen
Komplexes Änderungs- management der IT-Architekturen
© SBB • Informatik • 11.04.08 8
Der Sanierungsstau der SBB Informatik hat sich über die letzten 20 Jahre aufgebaut. Ohne eine massive Kurskorrektur drohen Stagnation und Ausfälle.
1990-2000 2000-2005 2006-2007 2008-20xx
Grosse, isolierte, unvernetzte Silo`s (zB. Prisma2) und wichtige Plattformen entstehen unter der Ägide der Z-IT. Die wenige Querverbindungen zwischen den Systemen werden (wie in dieser Zeit üblich) als Punkt-zu-Punkt Verbindungen realisiert. Anfang der 90er erstes IT Outsourcing und empfindlicher Know-how Abfluss bei den Host-Systemen. Wichtige Hostanwendungen (zB. Scheduling „Bagias“) werden nicht mehr konzeptionell weiterentwickelt.
„solide Interne Silos“ „dezentraler Wildwuchs, eine komplexen Gesamtlandschaft entickelt sich unkontrolliert und ohne Planung“
Grosse, neue, nun stark vernetzte Anwendungssysteme (zB. MCS) entstehen unter der Hoheit der Divisionen. Die Z-IT ist faktisch entmachtet, zentrale Governance findet nicht statt. Keine Gesamtarchitektur über die immer komplexer werdende Gesamtlandschaft. Sehr bunte Technologielandschaft mit allem, was der Markt hergibt. Grosse neue Systeme werden auf den „alten“ Grundmauern errichtet ohne dass eine Bereinigung oder eine strukturelle Überarbeitung stattfindet. Siegeszug von SAP, aber auch hier strukturelle Defizite.
„Analyse des Wildwuchs, Verwaltung des Mangels“
Schwieriger Neuanfang: Rezentralisierung der IT, Sourcing06, komplexe Großprojekte (RCS, NeTS, IPS) und die flächendeckende Bestandsaufnahme der IT passieren gleichzeitig. Grosse Projektportfolios und ein enormes Wachstum müssen bewältigt werden. Fokus auf Analyse, (noch) nicht auf Sanierung.
„struktureller Neu-beginn mit dem IT Masterplan“
Die Bereinigung der strukturellen Defizite beginnt. Die aus diversen Studien und Audits gewonnenen Erkenntnisse werden im Rahmen des IT Masterplanes konsequent umgesetzt.
Epoche
Charak-teristik
Historie
© SBB • Informatik • 11.04.08 9
Zentrale Plattformarchitekturen der SBB stammen aus Zeiten, in denen Vernetzung nach innen und aussen, Security und Agilität keine Rolle gespielt haben.
1990-2000 2000-2005 2006-2007 2008-20xx
„Interne Silos, solide gebaut“
„dezentraler Wildwuchs, eine komplexen Gesamtlandschaft entickelt sich unkontrolliert und ohne Planung“
„Analyse des Debakels. Verwaltung des Mangels“
„struktureller Neubeginn mit dem IT Masterplan“
Epoche
BAGIAS Ablösung (IT Masterplan)
BAGIAS, die zentrale Jobsteuerung der SBB ist seit Anfang der 90er in Betrieb. Seit ca. 15 Jahren erfolgt keine
konzeptionelle Weiterentwicklung mehr, seit ca. 5 Jahren kein Herstellersupport mehr. Neue Architekturen „process
driven, event driven“ sind heute nicht möglich.
Risiken im operativen Betrieb nehmen dramatisch zu, da Know-how erodiert. Von einem Ausfall wären nahezu alle
Kernsysteme und weite Teile von SAP betroffen.
Ablösung im Rahmen des
Projektes IAM (IT Masterplan)
SAM ist seit Ende der 80er Jahre bei der SBB als Directory Synchronisationstool im Einsatz. Der
Hersteller ist untergegangen, seit 2006 kann die SBB keine Wartungsverträge mehr abschliessen.
Siemens DirX
SAM
Siemens DirX wird seit Ende der 90er bei der SBB als zentraler Directorydienst eingesetzt. Ursprünglich als Telefonbuch konzipiert ist DirX heute die zentrale Drehscheibe aller
Verzeichnisdienste. Am Markt spielt Siemens heute als Directory Lieferant keine Rolle mehr, der Marktanteil liegt im Promille Bereich. Das Produkt muss dringend ersetzt und vor allem die
Verzeichnisdienste müssen strukturell komplett neu aufgesetzt werden.
Risiken im operativen Betrieb nehmen stark zu, da für Teile der Plattform keinerlei Support existiert. Neue Anforderungen können
nur sehr langwierig und teuer umgesetzt werden.
Beispiele
© SBB • Informatik • 11.04.08 10
Niemand in der SBB IT kennt (kannte) die System-Zusammenhänge und Ihre Abhängigkeiten
!! Architekturmanagement und Kartografie der Landschaft fehlen komplett
!! Die Heterogenität der Schnittstellenverfahren und die daraus resultierende Komplexität hat sich ungeplant entwickelt
!! Es besteht nur geringe konzeptionelle Integrität für Businessobjekte über die Systeme hinweg (z.B. Artikel)
© SBB • Informatik • 11.04.08 11
Anwendungsportfolio (2007) der SBB Division Personenverkehr (P)
Kunde Vor der Reise Reise Nach der Reise
Andere
Host
DB
C++
Java
Ak
tualitä
t d
er
Tech
no
log
ie
MCS BATS
Fahrpläne (Internet & Basis)
AFI
APFZ-Z
CERES2
CERES3
LEA Piper
KUBA
Railt
icke
ting
ZPG2
BackOffice
DiDok
Pricing
Prisma Verkauf
Verbindung
Vis-P
FRASY HOP
PTC-PKT
Prisma2
tik.Traveloffice
Resarail
Prisma Pay Zentral
EPR
Domänen:
Services
Operation
M&V
+ Projekte
Legende:
Beispiel: P-IT Portfolio
© SBB • Informatik • 11.04.08 12
Vorher !! 1 Bedarf = 1 Projekt = 1 neue Anwendung !! Komplexität explodiert
Bedarfe Projekte Anwendungen
N
N
N
N
X
Wiederver- wendung
Bedarfe Projekte Anwendungen
Mit EA !! Wiederverwendung von Anwendungen !! Konsolidierungen / Ablösungen !! Komplexität besser im Griff
NErweiterung
N
X Ablösung
als Projekt- auftrag X
Projekte fusionieren
Enterprise Architektur (EA) Management bei SBB IT - Architektur umsetzen
Architekturweiche – Die Projektbildung als Schlüssel zur Reduktion der Komplexität der Anwendungslandschaft
© SBB • Informatik • 11.04.08 13
Die SBB implementiert EAM im Rahmen von 5 Initiativen.
Strategische Stossrichtungen
Informationsbasis für EAM bereitstellen
Struktur in die Schnittstellen bringen
Homogenität und Standardisierung erhöhen
Strategische Stossrichtungen und Wertbeitrag der ICT
Transparenz
Effizienz und Interoperabilität
Wartbarkeit und Betreibbarkeit
Risiken minimieren
Nutzen/Hebel
Kartographie der Anwendungslandschaft Dokumentation und Inventarisierung der gesamten Anwendungslandschaft mithilfe eines geeigneten Tools
Einführung von Prozessen als Basis für Architekturgovernance Q-Gates, etc.
Implementierung einer EAI Plattform Sanierung der Interfaceproblematik
Erarbeiten dedizierter Roadmaps für die TOP25 Applikationen z.B. Piper, MCS, PRISMA, etc.
Erstellen einer Enterprise Roadmap Bebeauungsplan für die gesamte Anwendungslandschaft der SBB entwickeln
I 1
Handlungsfelder
I 2
I 3
I 4
I 5
Kernkompetenzen vertiefen
© SBB • Informatik • 11.04.08 14
Wie gehen wir vor? Unsere Roadmap:
Q4 Q4
2007 2008
Q3 Q1 Q1 Q2 Q3 Q4
2006
Q2 Q3
Komplettierung und permanente Nachführung
Einführung
Initialerfassung
Konzeption
Q-Gates non SAP Q-Gates all
EAM in Projekt Portfoliomgmt. etabliert
Kartographie der Anwendungslandschaft
Einführung von Prozessen als Basis für Architekturgovernance
Implementierung einer einheitlichen Schnittstellentechnologie (EAI Plattform)
Erarbeiten dedizierter Architektur- Roadmaps für die TOP25 Applikationen
Erstellen einer Enterprise Architektur- Roadmap basierend auf der Domänenstrategie
Handlungsfelder
Level 1: Big Picture
Level 2: Initiativen
2006 2007 2008 2009 2010 +
18 – 24 Monate
48 – 60 Monate
"! Für die flächendeckende Einführung veranschlagen wir 18 bis 24 Monate.
"! Der Umbau der SBB Anwendungslandschaft wird mindestens 4 bis 5 Jahre benötigen.
EAM Initiativen
Umbau der Anwendungslandschaft
© SBB • Informatik • 11.04.08 15
Transparenz zu schaffen erfordert eine akribische Detailarbeit.
Applikationsfokus Sourcing 06
Applikationen Sourcing 06 •! 590 Applikationen •! u.a. auch MS Office
Applikationen
Businessapplikationen # Beispiel I:
+ Applikationsliste Intranet EA + 655 Applikationen
Applikationen mit Beteiligung SBB Informatik (Plan / Build / Run)
#! Applikationslisten der Divisionen #! 378 Applikationen
Applikationsfokus Divisionen
direktes 1:1 Mapping über Name nur bei 71 Applikationen möglich
direktes 1:1 Mapping über Name nur bei 47
Applikationen möglich
© SBB • Informatik • 11.04.08 16
Ende 2006: vermutlich 455 Business Anwendungen
aktuell: 455 Business Anwendungen
167
I
0
455
146
Z 38
37 P
G
455
!! die vollständige Inventarisierung der zentralen Anwendungen ist unabdingbare Voraussetzung für ein erfolgreiches Architekturmanagement.
alle
ca. 25
30
Im Rahmen des P-IT Audits erhoben, aber noch nicht in
einem Tool erfaßt
Im Rahmen der EAM Initiative von I erfaßt und mit
Hilfe eines EAM Tools verwaltet
30
ca. 25
Von den ca. 450 Businessanwendungen sind heute nur 20% umfassend inventarisiert und beschrieben.
I 1
37
Alle Anwendungen G erhoben und in einer zentralen
Architekturdatenbank erfasst
© SBB • Informatik • 11.04.08 17
Ende 2008: nach Abschluß der kompletten Erfassung: > 1.000 Business Applikationen Gliederung in 9 Toplevel Domänen
Statistik
!! 1038 Business-Applikationen
!! 1292 Schnittstellen
!! 180 Technologien
!! 414 Geschäftsprozesse
!! 478 Organisationseinheiten
!! 645 Personen
!! 182 Informationsobjekte
(high level SBB-Entitäten)
© SBB • Informatik • 11.04.08 18
Resultate SW-Kartographie: vorher…
© SBB • Informatik • 11.04.08 19
Resultate SW-Kartographie: ..und nacher
© SBB • Informatik • 11.04.08 20
Fazit Bestandsaufnahme
!! Keine einheitlichen auf gemeinsame Kriterien basierenden Portfolios ( kein „Big Picture“ )
!! Fehlende Zielarchitektur
!! Redundante Business-Funktionalität in der Applikationslandschaft (z.B. Zeiterfassung)
!! Nebeneinanderlebende unterschiedliche Entwicklungslinien
!! Ungenügend dokumentierte Geschäftsprozesse (Potenzial für Businessarchitekturmanagement)
!! Applikationsintegration auf ad hoc Basis (nur Projektsicht dominiert)
!! Zuwenig projektübergreifende Abstimmung & Koordination
!! Demand / Supply Kommunikation zuwenig etabliert
!! Übergreifende Aspekte der Architekturen wenig genutzt (verpasste Synergiepotenziale)
!! Eine Plattformarchitekturplanung (Releaseplanung der Plattformen) existiert.
!! In den meisten Architekturdisziplinen ungenügende interne Kapazität
!! Governance für die Durchsetzung der Architekturplanung war bisher schwach
!! Projektfokus dominiert Betriebsfokus
!! Systematische Definition des Migrationsbedarfs fehlt (Optimierungspotenziale werden nicht genutzt)
Ausgangslage
© SBB • Informatik • 11.04.08 21
Wo liegen unsere Komplexitätsprobleme?
Fehlende Übersicht !! Wir haben kein zuverlässiges Inventar der Applikationen !! Aus Sicht Unternehmen gibt es 600-1000 Toplevelkomponenten (=Applikationen). Davon
ungefähr 400 „Business Applikationen“ !! Strukturierungshilfen für Applikationen fehlten bisher # neu: Domänen
!! Beziehungen/Abhängigkeiten zwischen Applikationen nur teilweise bekannt
Redundanzen !! Wir haben grosse unkontrollierte Datenredundanzen !! Wir haben grosse funktionale Redundanzen !! Wir haben z.T. unnötige technologische Vielfalt (z.B. Integrationsverfahren)
Ursachen !! Viele Geschäftsfelder im Konzern SBB !! Ein Bedarf # ein Projekt # eine neue Applikation !! zuwenig Koordination/Steuerung über Projektgrenzen hinweg
© SBB • Informatik • 11.04.08 22
Architekturmanagement ist integraler Bestandteil der ICT Strategie der SBB.
People
IT Controlling & Performance Management
Architektur- management
Organisation, Governance und
Prozesse IT Sourcing
IT Projekte IT Betrieb
Business Process Integration
IT Strategie
Führung
Unterstützungs- leistungen
Optimierung
Kerndienst- leistungen
Alignment Divisionen / IT 2
1
3 4
5 6
7
8
9
1 Vision, Rahmen
2 IT-Verständnis und Unterstützung der Kerngeschäftsprozesse. Orientierung am Wertbeitrag für das Geschäft der Divisionen
3 IT Projekte als zentrale Dienstleistung der IT: Projektmanagement und Projektportfolio Optimierung
4 IT Betrieb: Management von Servicebereitstellung, -betrieb und Service-Portfolios
5 Architekturmanagement als zentrale Kernfunktion der Z-IT
6 Struktur, Rollen, Fähigkeiten, Kapazitäten in der Organisation und deren Governance (inkl. IT Security)
7 Sourcing: aktives Management der Provider
8 IT Controlling: Budgetplanung, Effizienzmanagement
9 People: Führung, Qualifikation, Entwicklung zentrale Elemente der Leistung der SBB IT
© SBB • Informatik • 11.04.08 23
EAM unterstützt und lenkt die Leistungserbringung der Informatik.
!! EAM unterstützt den Kunden und das Account Management in der Projektbildung: vom IT-Bedarf zum „richtigen“ Projekt (Ziele, Scope, Architekturprinzipien)
!! EAM unterstützt und lenkt das Projekt- und Operations-Management durch Beratung und Überwachung der Architekturvorgaben
!! Zentrale Aufgaben von EAM –! Entwicklung von Architekturvorgaben
(Zielarchitektur, Bebauungspläne, Referenzarchitekturen, Richtlinien)
–! Projektbildung –! Beratung in Architekturfragen –! Überwachung der Architekturvorgaben –! Nachführung der Modelle
!! Alle EAM Aufgaben stützen sich auf ein gemeinsames konsistentes Modell in der EA Datenbank
EAM
EA Datenbank
Unterstützung Projektbildung
Account Management
Projekt Management
Operations Management
Kunde (Demand)
Nachführung Modell
Überwachung Vorgaben
Entwicklung Vorgaben
© SBB • Informatik • 11.04.08 24
"! Strategien zu zentralen Themen wie Open Source, Betriebsplattformen (Zukunft Host), etc. entwickeln
"! Für jede Domäne abgestimmte Bebauungspläne mit Verknüpfung Geschäftsbedarf, Anwendungen und Technologielifecycle.
Strategien, Bebauungs-
pläne und Roadmaps
erstellen
Vorgaben durchsetzen
SW-Kartographie nachführen
IT-Lösungen definieren (Architekturweiche)
"! Die EAM Datenbank als gemeinsame, verknüpfte Informationsbasis über Technologien, Anwendungen und Prozesse ausbauen und aktuell halten
"! Einhaltung der Architekturvorgaben in den Projekten wird in den QG geprüft
"! Nutzung Wiederverwendungspotential
"! Konsistenter Einsatz der Entwicklungslinien
Vorgaben organisieren und definieren
"! Vorgabenportal: Alle technischen Vorgaben werden zentral verwaltet und zur Verfügung gestellt
Beraten und Informieren "! Studien, Reviews und Assessments
A B C D A B D
!"
X
Y
Z X+
Y
Z
P2 P2 P1 P1
E A B D E F
Z
P2
X++
QG
Organisation, Rollen, Prozesse, Prinzipien
Die Architekturprozesse informieren und lenken organisations- und projektübergreifend
© SBB • Informatik • 11.04.08 25
Bei welchen konkreten Fragen hilft uns die EA Datenbank ?
Welche Anforderungen hat das Geschäft an die IT? Wie gut werden
sie erfüllt?
Geschäftsziel
Technologie
Daten Geschäfts-
prozess Applikation
Applikations-schnittstelle
Welcher Handlungsbedarf
liegt an?
Welche Schnittstellen hat eine Applikation?
Handlungs-bedarf
Welche Applikationen existieren? Welche Funktionalität bietet eine
Applikation?
Wie gut ist der technische Zustand einer Applikation? Gefährdet er das Geschäft?
Wie lange steht die Technologie noch zur Verfügung? Wie entwickeln sich die Wartungskosten?
Welche Daten werden verwaltet?
Welche Daten braucht das Geschäft? Fehlen Daten?
Welche Applikationen benutzen welche Daten?
Kennt man die Redundanzen? Sind
sie kontrolliert?
Organisation, Rollen, Prozesse, Prinzipien
© SBB • Informatik • 11.04.08 26
Erfolgreiches Enterprise Architecture Management entsteht nur aus einem gemeinsamen Kreislauf mit dem operativen Architekturmanagement.
Design Business Architecture
Design Systems Architecture
Application Architecture
System Architecture
Business Architecture
!!Services !!Security
!!Platforms !!Environments
!! Objectives !! Requirem. !! Business
processes
!!Service & support levels
!!Infrastructure systems
!! Strategies !! Constraints !! Business
components
!!Data !!Interfaces
!!Applications !!Components
Strategy
Implementation
Design Application Landscape
Design Software Architecture
Design Reference
Architecture
Design Enterprise
Architecture
Adopt new Objectives
Quelle: Klaus D. Niemann
© SBB • Informatik • 11.04.08 27
Wir führen Architekturmanagementprozesse ein. Wir definieren Architekturprinzipien. Und wir präzisieren die Rollen und Verantwortlichkeiten.
!! Bei der konkreten Durchführung des Architekturmanagements, also des Betriebes der Architekturmanagementprozesse, werden die Verantwortlichkeiten über Rollen klar zugeteilt. Die inhaltliche Arbeit wird über Architekturprinzipien ausgerichtet.
Organisationsstrukturen verankern das Archite-kturmanagement im Unternehmen
Rollen und Verantwort-lichkeiten ermöglichen die Einforderung von Leistungen und Entscheidungen
Prozesse erzwingen ein zielgerichtetes, abgestimmtes und vollständiges Vorgehen
Architekturprinzipien machen die Ausrichtung der Architekturen trans-parent und stellen eine Entscheidungsbasis
Organisation Rollen Prozesse Architekturprinzipien
OE
OE OE OE
OE
Organisation, Rollen, Prozesse, Prinzipien
© SBB • Informatik • 11.04.08 28
Architekturprinzipien gewährleisten Konsistenz und damit nachhaltige Steuerimpulse.
!! Architekturentscheide erfolgen Prinzipenbasiert. !! Wo Prinzipien fehlen, werden diese erarbeitet. !! Prinzipien werden strukturiert in
–! Ziel –! Herleitung / Begründung –! Konsequenzen –! Kennzahlen
!! Die standardisierte Beschreibung von Geschäftsanforderungen sowie deren Vereinheitlichung und Priorisierung sind die Voraussetzungen für das Anforderungsmanagement und damit Grundlage für das Architekturmanagement.
!! Eine Service-orientierte Architektur erleichtert die Integration von Applikationen und erhöht die Flexibilität der Applikationslandschaft.
!! Die Integration von am Markt verfügbaren Standardkomponenten wird der Eigenentwicklung vorgezogen.
!! Durch Fokussierung auf wenige Werkzeuge, Technologien und Lieferanten wird die Effizienz der Bereitstellung von Applikationen gesteigert.
!! Daten haben einen Wert für das Unternehmen und werden entsprechend gemanaged (Redundanzen reduzieren)
Strategie
Architekturprinzip
Architekturentscheid
Vorgabe
Eine Auswahl grundlegender Architekturprinzipien
Absichten und Initiativen
© SBB • Informatik • 11.04.08 29
Die Investitionen in EAM lassen sich permanent messen und beurteilen.
Perspektive Thema KPI Häufigkeit
Effektivität Kundensicht Kundenzufriedenheit EA Beratung (extern, intern)
halbjährlich
Effizienz Heterogenität Anzahl Entwicklungslinien, Technologiekatalog quartalsweise
% IT Entwicklungsbudget ausserhalb Standard Entwicklungslinien, Technologiekatalog
quartalsweise
% IT Betriebsbudget (inkl. Wartung) ausserhalb Entwicklungslinien, Technologiekatalog
quartalsweise
Anzahl Business-Applikationen (Veränderung neu gebaut – abgelöst) quartalsweise
Anzahl Schnittstellenverfahren (Veränderung neu gebaut – abgelöst) quartalsweise
EA Prozess Durchdringung Budget Projekte mit Architektur-Check / Total Budget quartalsweise
% Applikationen mit Beschreibung Ist-Zustand quartalsweise
% Applikationen mit Beschreibung Soll-Zustand quartalsweise
% Projektbudget mit Bebauungsplänen quartalsweise
Ausführung Anzahl Architekturanfragen hängig, in Bearbeitung, abgearbeitet quartalsweise
Durchschnittliche Behandlungszeit für Architekturanfragen quartalsweise
Anzahl zertifizierte Architekten quartalsweise
© SBB • Informatik • 11.04.08 30
Selbstverständnis der SBB Architekten.
!! Eine gut funktionierende Architekurgruppe in der SBB ist nicht überheblich, obwohl sie weiß, dass sie durch ihre umfassende Kenntnis von übergreifenden Geschäftsprozessen eine erhebliche Machtstellung hat.
!! Sie drängt sich nicht nach jeder Aufgabe und versucht nicht, ein Monopol auf das Erbringen von IT-Leistungen zu errichten.
!! Sie setzt dennoch konsequent Rahmenbedingungen unter dem Gesichtspunkt von Gesamt-Architektur, Betriebssicherheit, Dokumentationsgrad und Schnittstellenkonformität.
!! Sie behält die Zügel in der Hand, indem sie die Freiheitsgrade an die nachgewiesene Professionalität der unterschiedlichen Projektteams anpasst.
!! Sie hilft den Projekten beim Aufbau kompetenter Teams mit informatischem Tiefgang und unterhält zu diesen eine partnerschaftliche, kollegiale Beziehung.
© SBB • Informatik • 11.04.08 31
Lösungsorientierung statt Problemfixierung
Lösungsorientierung geht davon aus, dass
!! positive Veränderungen in komplexen Situationen auf Basis kleiner Schritte geschehen.
!! für diese Schritte nur wenige Informationen über das, was bisher schon etwas besser funktionierte, genügen.
!! bei Analysen nicht die Frage "wie ist es - wie kam es dazu?" sondern die Frage "was macht den Unterschied zwischen besser/schlechter aus?" ins Zentrum rückt.
!! anstelle des "theoretisch umfassend Verstehenwollens" das konkrete Handeln in kleinen Schritten tritt.
© SBB • Informatik • 11.04.08 32
Grundideen der Lösungsfokussierung:
!! Repariere nicht was nicht kaputt ist
!! Finde heraus was gut funktioniert und passt - und mache mehr davon
!! Lösungen statt Probleme: Nicht das Problemverständnis vertiefen sondern erkunden, wie es ist, wenn es besser ist.
!! Interaktion statt isolierter Individualität: Unser Verhalten entwickelt sich in der Interaktion mit anderen. In der Lösungsfokussierten Arbeit wird nicht über Meinungen, Glaubenssätze oder Werte diskutiert sondern über beobachtbares Handeln.
!! Beachte und nutze das, was da ist - nicht das Fehlende: Nicht die Lücke zwischen "Ist" und "Soll" ermitteln sondern das, was - wenn auch nur selten - heute bereits etwas besser ist.
!! Die Chancen im Gestern, Heute und Morgen sehen: Chancen in der Zukunft und im Heute zu überlegen ist ein vertrauter Gedanke. Eher unüblich ist es, auch im "Gestern" bewusst das zu erkunden, was sich früher bereits als Chance zeigte - um auch das zu nutzen.
© SBB • Informatik • 11.04.08 33
Resultate SW-Kartographie: Mit dem neuen Domänenmodell nutzen wir Synergien besser als bisher.
$! Synergiepotenziale erkennen und nutzen
$!Skills, Knowledge
$!Systeme, Frameworks
$! Austauschbarkeit, Fallbacks, Flexibilität
$! Impact / Abhängigkeiten / Nutzen eines Vorhabens frühzeitig erkennen
$! Einfache, nicht proprietäre Schnittstellen gegen aussen
$! bringt notwendige Flexibilität
Nutzen der Domänenorganisation
Die IT Supply Organisation organisiert sich nach Domänen, um die Anforderungen des
Business optimal abzudecken.
© SBB • Informatik • 11.04.08 34
Lessons learnt - Empfehlungen
!! Gute Enterprise Architektur entsteht nur im permanenten Wechselspiel aus operativem Architekturmanagement (in Projekten) und Enterprise Architekturmanagement (auf Domänen -oder Unternehmensebene).
!! Enterprise Architekten ziehen ihre Reputation, ihre Designkompetenz, ihre Autorität gegenüber den Projekten nur aus regelmässigen eigenen Projekteinsätzen in relevanten Business Projekten.
!! Unterbleibt dieses Wechselspiel, dieser Dialog mit den Projekten, verkommt AQ zu einer klassischen „Elfenbeintum – Stabsabteilung“, die über wenig Ansehen gegenüber den anderen Units verfügt und keinen relevanten Einfluß auf das reale Architekturgeschehen in den Projekten und im Unternehmen hat. Ineffektive Architekturstäbe dieser Art lassen sich leider in vielen Unternehmen beobachten.
!! Unterbleibt dieser Austausch, kommt es ferner über kurz oder lang zu einer Frontenbildung zwischen EAM (akademisch, analytisch) und Softwareentwicklung (pragmatisch, resultorientiert), die viele Friktionsverluste verursacht.
!! Der gemischte Einsatz aller Architekten (aus der SW- Entwicklung und dem Architekturbereich) im Architekturmanagementkreislauf ist somit Grundvoraussetzung für ein erfolgreiches Architekturmanagement.