Enterprise Architektur

Enterprise Architektur Management@FIDUCIA
People, Tools and Management Jürgen Birkholz, Thomas Irlbacher; AEW6 | JBFOne 2009

Ziel dieses Vortrags Einordnung EAM
Zusammenarbeit der jeweiligen Architekturdisziplinen aus den Bereichen Produktmanagement (PMM), Anwendungsentwicklung (AEW), Systemtechnik (SYT) und IT-Betrieb (ITB) in der FIDUCIA Externe Vernetzung Menschen machen Architekturen, aber auch Tools spielen eine zunehmend wichtige Rolle. Seit 2008 haben wir auf Basis eines EAM-Tools der Firma troux begonnen, ein Architekturwerkzeug in der FIDUCIA zu instanziieren Das M bei EAM bedeutet Management. Das Planen und Steuern der Weiterentwicklung und Umsetzung der Architektur bietet großes Potenzial zur Optimierung der IT

Agenda What EAM is – and is not The Big Picture, Teams & People
(Net)working & More Tools for the „M“ in EAM

EAM = B + S + T

Ist EAM ein Technologie- oder Anwendungskatalog?
Many EA teams become trapped in a vicious cycle of creating and managing current-state architecture documentation — so much so that they never effectively focus on the strategic requirements future-state planning. Ist EAM ein Technologie- oder Anwendungskatalog? Hat EAM etwas mit Durchsetzung oder Vollstreckung zu tun? Current-state inventory (as a component of the architecture repository) is updated with each EA iteration through gap analysis, impact assessment, migration planning and implementation planning. The initial focus of current-state documentation must be to place basic information about solution attributes in the context of the solution taxonomy (for example, business organizational units cross-referenced to critical business information flows) developed from the future-state exercise. This taxonomy provides the context to place current solutions in the taxonomy for future analysis. Many EA teams take this explanation to mean that they must inventory every process, data element, application, service and technology that exists in the organization and take complete responsibility for maintaining that inventory. This interpretation can lead to never-ending, current-state documentation, with limited time and resources to focus on the future state. Although a technology and application inventory may be helpful when defining a current state, this is not an EA. EA is a much broader process that directly reflects the business vision and strategy, as well as the people, processes, organization, information and technology (including applications) that are critical to the business strategy. The current-state architecture should be "business as usual" for every good manager. Managers should have an accurate picture of the current state of the domain they manage, and the EA team should be able to leverage this information. EA provides actionable, prescriptive guidance for project-level decision making, consistent with executing a transition plan toward a described future-state architecture that aligns with the business strategy.

 Nein, aber EAM unterstützt und ermöglicht alle diese Aktivitäten
Ist dann EAM … Eine Geschäftsstrategie? Programm-Management? Strategische IT-Planung? IT-Governance? Geschäftsprozessmanagement? (BPM) Projekt-Portfoliomanagement? Performance-Management? Change management? Standardisierung? Prinzipienformulierung?  Nein, aber EAM unterstützt und ermöglicht alle diese Aktivitäten

Was nun ist EAM? EAM is … "… the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution." Quelle: Gartner Gartner's definition of EA (above, and explored in more detail on the next slide) reflects the goals and aspirations of most enterprise architects who are familiar with EA processes, methodologies and artifacts. It describes EA as an actionable and practical process and approach. EA is a collaborative process that facilitates discussion and resolution between diverse groups of stakeholders across the enterprise, with the objective of ensuring a consistent approach to the execution of the business strategy. However, in many organizations, EA initiatives are often perceived by those outside the practice area as vague, too broad and overlapping other functions. IT and business people will often express concern that EA is an effort by a group that is divorced from day-to-day realities to "control" what they do and "impede" their efforts. As a result, their interactions with enterprise architects is commonly clouded with suspicion, wariness and even disdain. Often, many enterprise constituencies fear that EA is out to control or supplant many other enterprise functions, such as strategic planning, portfolio management, IT governance or business process management (BPM). This is not what true EA is about. However, EA can — and should — support and facilitate many of these other enterprise functions, as the following slides will illustrate.

FIDUCIA EAM-Landkarte – Verortung der Architektur-Disziplinen
Aspekt Zeit und Konkretheit Taktisches Architekturmanagement Operatives Strategisches Geschäftsziele IT-Strategie Referenz- architekturen IT- Plattformstrategie Geschäftsinitiative Projekt- portfolio Zielarchitekturen Technologie- standards Zielplattform Projekt Solution- architektur IT-System IT-Betrieb Aspekt Business und IT Aspekt Business und IT

Business first: Bankfachliche Architektur (PMMAP)
Verantwortung/Einflusssphäre Aufgaben & Themen Weiterentwicklung des agree Bebauungsplans inklusive Roadmap Fortschreibung der Strategie agree Prüfung auf (technische), fachliche und wirtschaftliche Umsetzbarkeit Verifikation von größeren fachlichen Veränderungsschritten in der Infrastruktur Produktportfoliosteuerung Mitwirkung Fachliche Referenzarchitektur Arbeitsmodus Voruntersuchungen Projektarbeit Strategische Projekt-Reviews Unterstützung/Beratung/Coaching Gremien und Communities agree Governance-Board, AR-Board, AMB, Verantwortung Bebauungsplan und Roadmap Zentrale Artefakte

Newly Implemented: Domain Architekten (AEW1)
Verantwortung/Einflusssphäre Aufgaben & Themen Fortschreibung Domänenstrategie Steuerung Projektportfolio pro Domäne Fachlich/technische Baustellenliste Lösungsskizzen Aufwandsermittlung Mitwirkung bei Bebauungsplanung sowie bei Referenz- und Zielarchitektur Servicegovernance Arbeitsmodus Reviews und QS Projektarbeit Fachkonzepterstellung Voruntersuchungen Gremien und Communities Kooperation mit Fachl. Enterprise Architekt Verantwortung Strategische und Operative Weiterentwicklung der Fachlichen Domänen Zentrale Artefakte

Overview & Future State: Fachliche Enterprise Architektur (AEW6)
Verantwortung/Einflusssphäre Aufgaben & Themen Fachliche Referenzarchitektur Architekturrelevanz-Prüfung Lösungsskizzen Mitwirkung bei Bebauungsplanung Application Landscape Komponentengovernance Übergreifende Fragestellungen, Innovationsthemen und Trends Methodik (Fachkonzept) EA-Metamodell Arbeitsmodus Reviews und QS Coaching Voruntersuchungen Gremien und Communities agree Governanceboard, ArT, AMB, SOA-Lab, Sebis Verantwortete Artefakte Fachliche Referenzarchitektur agree Zentrale Artefakte

Design for Operations: Technische Enterprise Architektur & Framework (AEW6)
Verantwortung/Einflusssphäre Aufgaben & Themen Framework (JBF) Identity Access Management (MIAMI) agree Basis Module aSA Integrations- und Verbundarchitektur Produkt- und Technologieauswahl Richtlinien für Design und Implementierung Arbeitsmodus Reviews und QS Coaching Voruntersuchungen Architekturprojekte Gremien und Communities AR-Board, ArT Verantwortete Artefakte Subsystemarchitektur HORIZON Architektur agree Standardarchitektur Zentrale Artefakte

Systems & Standards: Systemarchitektur (SYTAP)
Verantwortung/Einflusssphäre Aufgaben & Themen Verantwortung für alle technischen Domänen Strategieentwicklung Architekturentwürfe Standardsmanagement Beratung Outsourcing Arbeitsmodus Reviews und QS Coaching Voruntersuchungen Architekturprojekte Gremien und Communities AR-Board, ArT agree Governanceboard AK IT-Infrastruktur Verantwortete Artefakte Book of Standards (BoS) Wegweiser technische Strategie Zentrale Artefakte

All together now (seit Herbst 2008)
Bereichsübergreifende Koordination von Architekturthemen ergänzend zur strategischen Arbeit des AR-Board Vernetzung der AR-Disziplinen EAM-Landkarte EAM-Maturity Self-Assesment Checkliste Architekturrelevanz Bereichsübergreifende Dokumentation (SWAD) Standardsmanagement Releaserahmenbedingungen Architektur-Glossar Standards für Architekturdarstellungen

EAM und die Menschen? EA means architecting the enterprise
The traditional standards process, in which IT dictates solutions and expects full compliance, no longer works. Standards must be accompanied by choices, and business users must accept responsibility if their choices yield outcomes that are less optimal than those provided by IT mandates. EAM und die Menschen? EA means architecting the enterprise to enable change  Enterprisearchitekten sind dabei Anwälte, Evangelisten und Berater ... Enterprise architects will not succeed if they are perceived to be solely enforcing rules and policies. They will also not succeed if they are viewed as controlling the use of technologies and processes. Furthermore, they will fail if they are viewed as impeding innovation and creativity. Business and IT users will ignore the efforts of EA and create their own solutions to meet their requirements. EA and architects must be viewed as helping, supporting, advising and guiding the organization to achieve its business strategy through a future-state vision. Therefore, it is the responsibility of the enterprise architect to reach out and work across the organization to educate and encourage the use of the EA.

Wir profitieren in unseren EAM-Aktivitäten von der Mitgliedschaft im
 Gemeinsam entworfene und durchgeführte Schulungen Wissen wird mehr indem man es teilt!  Adaption der EAM-Landkarte Lead: Workstream Visualisierungen

Architekturmanagement
Taktisches Architekturmanagement Operatives Strategisches Geschäftsziele IT-Strategie Referenz- architekturen IT- Plattformstrategie Geschäftsinitiative Projekt- portfolio Zielarchitekturen Technologie- standards Zielplattform Projekt Solution- architektur IT-System IT-Betrieb

Ausgangspunkt der EAM Tool-Landschaft ist die fachliche Architektur

Taktisches Architekturmanagement Operatives Strategisches Geschäftsziele IT-Strategie Referenz- architekturen IT- Plattformstrategie Geschäftsinitiative Projekt- portfolio Zielarchitekturen Technologie- standards Zielplattform Projekt Solution- architektur IT-System IT-Betrieb Standards / Servicetypen

Auslöser war jedoch die Anforderung an ein Service Repository
Technische Infos, z.B ca 4000 JBF Services verwalten

Taktisches Architekturmanagement Operatives Strategisches Geschäftsziele IT-Strategie Referenz- architekturen IT- Plattformstrategie Geschäftsinitiative Projekt- portfolio Zielarchitekturen Technologie- standards Zielplattform Projekt Solution- architektur IT-System IT-Betrieb Technische und Operative Infos, z.B Services Standards / Servicetypen

Relation zwischen Service und Facharchitektur
Fachliche Architektur Modul Software Architektur

Implementierte Services
Drill Down Bündel Fachliche Komponente Softwarekomponente Schnittstelle Schnittstelle: Implementierte Services

Taktisches Architekturmanagement Operatives Strategisches Geschäftsziele IT-Strategie Referenz- architekturen IT- Plattformstrategie Geschäftsinitiative Projekt- portfolio Zielarchitekturen Technologie- standards Zielplattform Projekt Solution- architektur IT-System IT-Betrieb Technische und Operative Infos, z.B Services UML Modell

Standardsmanagement@FIDUCIA
Die in der FIDUCIA geltenden Standards sind im „Book of Standards“ (BoS) festgeschrieben Hier befinden sich auch Informationen über Hardware- und Softwarestandards Diese Standards sind in troux abgebildet und werden miteinander verknüpft -> Servicetypen und mit der Architektur in Relation gebracht

ST eBanking_WebServer
Auf Basis der definierten Standards werden Basis-Servicetypen (Auszug Definition) definiert Ein Basis-Servicetyp (BST) beschreibt eine zulässige Kombination von Basis-Komponenten; diese Kombination kann in unterschiedlichen Servicetypen referenziert werden. BST als solche werden nicht produktiv eingesetzt; erst durch Definition eines Servicetyps (auf Basis des BST) können daraus konkrete Instanzen gebildet werden. BST können geschachtelt werden, d.h. ein BST kann andere BST referenzieren Beispiel zur Illustration: ST eBanking_WebServer eBanking Servicetyp Apache (auf Solaris) BST Apache_Server Solaris (auf Sparc) BST Solaris_Server Hardware (Sparc)

Aus Standards werden Basis-Servicetypen

Taktisches Architekturmanagement Operatives Strategisches Geschäftsziele IT-Strategie Referenz- architekturen IT- Plattformstrategie Geschäftsinitiative Projekt- portfolio Zielarchitekturen Technologie- standards Zielplattform Projekt Solution- architektur IT-System IT-Betrieb Technische und Operative Infos, z.B Services UML Modell Standards / Servicetypen

E A M mit M 4 management Die Weiterentwicklung von agree wird im sogenannten Bebauungsplan aus fachlicher Sicht geplant Die Planung basiert eher auf fachlichen Produkten denn auf Softwarekomponenten Durch die Abbildung des Bebauungsplans auf die Architektur ist auch eine Abbildung der Planung auf Domänen und Komponenten möglich

Taktisches Architekturmanagement Operatives Strategisches Geschäftsziele IT-Strategie Referenz- architekturen IT- Plattformstrategie Geschäftsinitiative Projekt- portfolio Zielarchitekturen Technologie- standards Zielplattform Projekt Solution- architektur IT-System IT-Betrieb Planung, Bebauungsplan Technische und Operative Infos, z.B Services UML Modell Standards / Servicetypen

EAM next Steps Taktisches Architekturmanagement Operatives Strategisches Geschäftsziele IT-Strategie Referenz- architekturen IT- Plattformstrategie Geschäftsinitiative Projekt- portfolio Zielarchitekturen Technologie- standards Zielplattform Projekt Solution- architektur IT-System IT-Betrieb

EAM next Steps Taktisches Architekturmanagement Operatives Strategisches Geschäftsziele IT-Strategie Referenz- architekturen IT- Plattformstrategie Geschäftsinitiative Projekt- portfolio Zielarchitekturen Technologie- standards Zielplattform Projekt Solution- architektur IT-System IT-Betrieb Planung, Bebauungsplan Auswertungen Entwicklungsaufwand Functionpoints etc .Reports etc Technische und Operative Infos, z.B Services UML Modell Problems pro Domäne Nutzungshäufigkeit etc Standards/Servicetypen

Zusammenfassung EAM lässt sich schwer mit einem einzigen Begriff umschreiben, da es letztlich um die Vernetzung einer ganzen Reihe von bisher isoliert betrachteter Disziplinen (auch in der FIDUCIA) geht Für diese Arbeit ist ein Orientierungsrahmen sehr wertvoll Neben der unerlässlichen internen Vernetzung ist auch eine Vernetzung mit Enterprise- Architekten anderer Unternehmen hilfreich Management von Vernetzung von Architekturen ohne entsprechende Toolunterstützung wird nur ganz wenigen Menschen oder in ganz einfachen Umfeldern gelingen (siehe Hausbau) Das „M“ in EAM steht für Management!

Fragen? – Diskussion? EAM = Business + Strategy + Technology
Jürgen Birkholz Anwendungsentwicklung Fachlicher Chefarchitekt 07 21 / EAM = Business + Strategy + Technology Thomas Irlbacher Anwendungsentwicklung Abteilungsleiter Software Engineering 0 89 / – 34 67

Ihr IT-Partner Vielen Dank

Enterprise Architektur

Ähnliche Präsentationen

Präsentation zum Thema: "Enterprise Architektur"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Enterprise Architektur

Ähnliche Präsentationen

Präsentation zum Thema: "Enterprise Architektur"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback