Unternehmensprofil beck et al. projects · beck et al. projects Theresienhöhe 13, 80339 München, T 089/54 42 53-0, F 089/54 42 53-99, [email protected], Unternehmensprofil

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


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


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


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


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


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


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


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


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)


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


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


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


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


Geschäftsarchitektur


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


Geschäftsarchitektur


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


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


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


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)


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


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


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


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


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


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


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)


Resultate SW-Kartographie: vorher…


Resultate SW-Kartographie: ..und nacher


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


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


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


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


"! 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


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?



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


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



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


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


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.


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.


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.


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.


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.

Documents

Unternehmensprofil beck et al. projects · beck et al. projects Theresienhöhe 13, 80339 München, T 089/54 42 53-0, F 089/54 42 53-99, [email protected], Unternehmensprofil