Enterprise (IT) Architecture Management Teil 3: Bedarfsmanagement
Topic: Enterprise Architecture Management Überblick und Einführung 1. Iasa Vorstellung 2. Überblick der EAM-Serie 3. Anforderungsmanagement 4. Portfolio-Analyse und Bewertung 5. Lifecycle- & Änderungsmanagement 6. Iasa EAM-Ausblick 2
Topic: Enterprise Architecture Management Überblick und Einführung 1. Iasa Vorstellung 2. Überblick der EAM-Serie 3. Anforderungsmanagement 4. Portfolio-Analyse und Bewertung 5. Iasa EAM-Ausblick 3
Introduction Herr Rhoades hat über 20 Jahre Erfahrung in der Steuerung, Entwicklung und Umsetzung von IT- Strategien und -Lösungen für Großunternehmen in den USA, Europa und Asien. Als Enterprise Architect, unterstützt Herr Rhoades die Geschäftsstrategie und -ziele des Unternehmens durch die Entwicklung der IT-Strategie und das Management der Unternehmensarchitektur. Als Chapter Präsident in Deutschland für Iasa, der weltweit größte IT-Architekten-Verband, fördert Herr Rhoades das Bewusstsein und die Bedeutung von Enterprise Architecture Management und dem Beruf des IT-Architekten in der IT-Branche. 2015-01-15 4
Iasa ist the preeminent knowledgebased association focused on the IT architecture profession 8000 Mitglieder 25 Chapters in 50 Ländern 120.000 Netzwerk Wir alle sind Iasa! 2015-01-15 5
Iasa Mission Iasa is committed to improving the quality of the IT architecture industry by developing and delivering standards, education programs and developing accreditation programs and services that optimize the development of architecture profession. Research Partnerschaften Innovation Standardisierung Outreach Bekanntheit Anerkennung Mitwirkung Bildung Skills Erfahrung Training Zertifizierung Community Bewährte Methoden Netzwerk Mentoring 2015-01-15 6
Nutzen für die Iasa Mitglieder Get certified and Gain Recognition Experience-based certifications affirm an Architect s abilities Architects gain recognition through certifications, speaking engagements, and contributions to the community Potential for cross-certification with isaqb Receive Discounts 50% Bootstrapping discount for CITA-S certifications Iasa and industry conferences, O Reily Books, Lucid Charts Iasa content repository, knowledge communities, and selected online courses Network with colleagues Exchange ideas and best practices with other companies and colleagues through local and global events Work with a mentor to get help with your problems Discover new companies, products, and methodologies 2015-01-15 Make a difference Advance a topic of your choosing, Create original content (e.g. blog, presentations, news stories, etc.) Establish best practices, contribute to interest groups, and share ideas Create formal qualifications, e.g. training and certification material Become a mentor to help others 7
Topic: Enterprise Architecture Management Überblick und Einführung 1. Iasa Vorstellung 2. Überblick der EAM-Serie 3. Anforderungsmanagement 4. Portfolio-Analyse und Bewertung 5. Iasa EAM Ausblick 8
Ziele der EAM-Serie Ich bin ein Enterprise Architekt und nun? Das Ziel der EAM-Serie ist, Architekten einen Überblick über EAM und dessen bewährten Vorgehensweisen und Methoden zu geben, um sie bei der Durchführung und Einführung von EAM zu unterstützen. In der Serie werden die folgenden Themen grob erleuchtet: Was ist EAM? Was bringt EAM? Wann wird EAM angewendet? Wie macht man EAM? Wer macht EAM? 2015-01-15 9
Überblick der EAM-Serie EAM Überblick und Einführung EAM Definition Ziele und Nutzen EAM im Unternehmen Jan Vorgehen, Methoden und Werkzeuge EAM-Prozess EAM Frameworks EAM-Werkzeuge März Bedarfsmanagement Anforderungsmanagement Portfolio-Analyse und Bewertung Lifecycle- & Änderungsmanagement Capability-Based Planning: von Strategie bis zur Umsetzung Heute Juli Der Enterprise Architekt: Hindernis, Vermittler, Designer, Enabler oder Innovator? Sept. Ggf. Weitere Themen, z.b. IT Bebauungsmanagement Roadmap und Strategieentwicklung Governance Lifecycle- & Änderungsmanagement Nov. 2015-01-15 10
Topic: Enterprise Architecture Management Überblick und Einführung 1. Iasa Vorstellung 2. Überblick der EAM-Serie 3. Anforderungsmanagement 4. Portfolio-Analyse und Bewertung 5. Iasa EAM Ausblick 11
Anforderungsmanagement? How the customer explained it How the Project Leader understood it How the Analyst designed it How the Business Consultant described it How it was documented How the Programmer wrote it How it was installed How it performed under load How Marketing described it How the Customer was billed How it was supported What the Customer really wanted 2015-01-15 12
Anforderungsmanagement steht in der Mitte! Anforderungen werden in allen Phasen identifiziert, Anforderungen fließen in und aus alle Phasen 2015-01-15 13
Anforderungsdefinition Eine Anforderung ist eine Aussage über eine zu erfüllende Eigenschaft oder eine zu erbringende Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen Strategisch ist eine Anforderung, wenn sie eine Auswirkung auf die langfristige geplante Verhaltensweise des Unternehmens zur Zielerreichung hat oder wenn sie die strategischen Ziele unterstützt. Quelle: vgl. C. Rupp Requirements-Engineering und -Management 2015-01-15 14
Bedarfsmanagement im Unternehmenskontext Unternehmens- und Strategieentwicklung Vertrieb Innovations- Management Produkt Management Bedarfsmanagement Controlling Enterprise Architektur Management (EAM) Betrieb Projekt Management 2015-01-15 15
Anforderungsmanagement Prozess 1. Ermitteln und dokumentieren 2. Bewerten und priorisieren 3. Bebauen 4. Planen 5. Umsetzen und überprüfen * 6. Wertbeitrag verifizieren * Überprüfung der Gültigkeit, Konformität und Fertigstellung im Projekt 2015-01-15 (z.b. durch ATAM (Architecture Tradeoff Analysis Method) 16
Anforderungslebenszyklus erfasst definiert analysiert und bewertet fachlich freigegeben bebaut Kosten-Nutzen- Betrachtung erstellt geplant technisch freigegeben umgesetzt in Produktion Wertbeitrag verifiziert 2015-01-15 17
Operativ Taktisch Strategisch Quellen der Anforderungen Welche sollten vom Enterprise Architect berücksichtigt? Innovationsmanagement Geschäftsmodell Unternehmensziele Strategieentwicklung Investitionen Marktumfeld Änderung einer Geschäftsfunktionen Rechtsvorschriften Lösungsentwicklung Change-, Incident-, Problemmanagement Wartungsprojekte Operative Prozessänderungen 2015-01-15 18
Klassifizierung der Anforderungen Strategisch Zeitraum: >1 Jahr Detailierungsgrad: Grob Art: Strategie-orientiert, Prinzipien, Randbedingungen Themen: Investitionsthemen, z.b. Konkurrenzfähigkeit etc. Taktisch Zeitraum: 6-18 Monate Detailierungsgrad: Grob Art: Geschäftsfähigkeiten und -funktionen Themen: Abrechnung, CRM etc. Operative Zeitraum: 1-6 Monate Detailierungsgrad: Detailliert Art: Realisierungsorientiert, Systemfunktionen, NFAs Themen: Rechnungsstellung, Verfügbarkeit, Sicherheit etc. 2015-01-15 19
Arten der Anforderungen Meistens definiert Funktionale Anforderungen Oft definiert Nicht-Funktionale Anforderungen Systemübergreifende Sicherheit, Effizienz, Skalierbarkeit, Wartbarkeit, Verfügbarkeit, Fehlertoleranz, Bedienbarkeit etc. Randbedingungen / Constraints Termine, Budget, Ressourcen, Umfang/Scope, Technologien, Partner, Organisation (z.b. Struktur, Benutzergruppen, Kultur) etc. Selten definiert bzw. als Anforderung benutz Risiken Annahmen und Prämissen Prinzipien Interne und externe Richtlinien Standards 2015-01-15 20
Anforderungsspezifikation Bezeichnung: Klassifizierung: Zuständigkeit: Zuordnung der Unternehmensarchitekturelemente: Beschreibung: Begründung (Notwendigkeit / Nutzen): Quelle: Messkriterien (z.b. Binär und Nicht- Binär-Bewertbar, Ist-, Soll-, Min- und Max-Wert): Priorität: Testbarkeit: Betroffene Architekturelemente, falls bekannt: Annahmen: Abhängigkeiten: 2015-01-15 21
Eigenschaften von Anforderungen Characteristic Cohesive Complete Consistent Non-Conjugated (Atomic) Traceable Current Feasible Unambiguous Mandatory Verifiable Explanation The requirement addresses one and only one thing. The requirement is fully stated in one place with no missing information. The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation. The requirement is atomic, e.g., it does not contain conjunctions. For example, "The postal code field must validate American and Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate American postal codes" and (2) "The postal code field must validate Canadian postal codes." The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented. The requirement has not been made obsolete by the passage of time. The requirement can be implemented within the constraints of the project. The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are prohibited. The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated. An optional requirement is a contradiction in terms. The implementation of the requirement can be determined through one of four possible methods: inspection, demonstration, test or analysis. 2015-01-15 22
Anforderungserhebung Zuständigkeiten Wer ist für die Anforderungserhebung zuständig? Architekt, z.b. technische Standards? Geschäftsanalyst, z.b. funktionale und nicht-funktionale Anforderungen? Projektmanager, z.b. Scope? Kunde, z.b. funktionale Anforderungen? Enterprise Architect, z.b. aus der IT-Strategie? Architekten müssen sich auf die architekturbestimmende Anforderungen konzentrieren Aber wie wissen wir welche Anforderungen für eine Unternehmensarchitektur relevant sind? Systemübergreifende Anforderungen statt systemspezifische Anforderungen sollten betrachtet werden 2015-01-15 23
Anforderungserhebung Vorgehen Zerlegung / Unterteilung Heuristische Analyse mit Hilfe von Checklisten und Erfahrungswerten Szenario-Analyse Leistungskette-Analyse Geschäftsfähigkeiten-Analyse Portfolioanalyse auf Basis der strukturellen Architekturelementen in der Unternehmensarchitektur 2015-01-15 24
Anforderungserhebung Zerlegung / Unterteilung Abrechnungssystem Zahlungssystem Rechnungsstellung Zahlungsarten (z.b. Kreditkarte) Verbindung mit Service Providers Transaktions- Management Sicherheit 2015-01-15 25
Anforderungserhebung Heuristische Analyse Nutzung von Checklisten und Erfahrungswerten Checkliste der typischen Funktionalen-Anforderungen, Nicht-Funktionalen-Anforderungen und Randbedingungen mit Beispielen Lister der üblichen Fragen, z.b. Haben die Zuständigkeiten sich geändert? Ist die Struktur anders? Müssen die funktionale bzw. technische Schnittstellen geändert werden? Kategorie Anforderung Beschreibung Beispiel Funktionale Risiko Constraint Mandantenfähigkeit Vendor- Abhängigkeit Einhaltung des Liefertermins Fähigkeit des Systems, bei mehreren Entitäten parallel eingesetzt werden zu können Verminderung von Risiken, die aus der Geschäftsbeziehung zum Lieferanten resultieren Anforderungen, die sich aus Vorgaben für die Einhaltung von Terminen ableiten NFA Modularität Zerlegung des Systems in wiederverwendbaren Modulen Kernsystem muss gleichzeitige Bedienung mehrerer Organisationen ermöglichen Geschäftskritische Anwendungen dürfen nicht von einem Hersteller abhängig sein Das System muss bis spätestens Oktober dieses Jahres umgesetzt werden Die Komponenten müssen eine minimierte Kopplung und maximierte Kohäsion aufweisen 2015-01-15 26
Anforderungserhebung Szenario-Analyse Laut TOGAF, ein Szenario ist eine Darstellung einer Geschäftsanforderung bzw. -problem, das die folgenden beschreibt: Ein Geschäftsprozess, Applikation bzw. eine Gruppe von Applikationen, die die Architektur befähigen Eine Geschäfts- bzw. Technologieumgebung Die Personen und IT-Komponenten ( Akteure ), die ein Szenario umsetzen Das gewünschte Ergebnis der Implementierung Diagramm: TOGAF Diagramm: Scenarios to Strategy Inc. (S2S), 2015-01-15 27
Anforderungserhebung Leistungskette-Analyse Diagramm: Tata Consulting sites.tcs.com 2015-01-15 28
Anforderungserhebung Strukturelle Analyse der Architekturelementen Geschäftsarchitektur Ziele, KPIs Domänen Business Capabilities, fachliche Funktionen bzw. Services Prozesse Produkte Organisation Anforderung Informationsarchitektur Informationsobjekte Informationsfluss Data Governance Anwendungsarchitektur Anwendungen Schnittstellen Komponenten Infrastrukturarchitektur Software und Hardware Server Storage und Netzwerk Komponenten Rechenzentren ( Blech ) 2015-01-15 29
Anforderungserhebung Geschäftsfähigkeiten-Analyse Strategie Anforderungen Ziele Produkte und Services Abgeleitet von: Umgesetzt durch: Business Capability Prozess Technologien Organisation Information 2015-01-15 30
Topic: Enterprise Architecture Management Überblick und Einführung 1. Iasa Vorstellung 2. Überblick der EAM-Serie 3. Anforderungsmanagement 4. Portfolio-Analyse und Bewertung 5. Iasa EAM Ausblick 31
Anwendungssteckbrief Anwendungssteckbrief: Applikation 1 Stammdaten Kurzbeschreibung ID App 1 Einführung 2023 Info, info, info, info, info, info, Info, info, info, info, info, info, Info, info, info, info, info, info Kunde Vertrieb Änderungen Häufig Info, info, info, info, info, info Domäne Verkauf buchen Kosten Hoch Info, info, info, info, info, info Prozess Buchen Personal 27 Ablösung 2018 Kontaktinfo link Funktionalitäten Info, info, info, info, info, info, Info, info, info, info, info, info, Info, info, info, info, info, info Info, info, info, info, info, info Info, info, info, info, info, info Info, info, info, info, info, info Architektur & Infrastruktur 16 HP Linux, 1 z/os MF, 3 Verteiler, Benutzte Software: MQ, C:D, DB2, JBoss, Apache, Schnittstellenart: MQ, C:D, FTP, Web Services, RCP Online / Batch Information App App Programmiersprachen: Java, COBOL Info, info, info, info, info, info Info, info, info, info, info, info App Zweck Aufnahme der Stammdaten, Kernfunktionen und Architektur je Anwendung Nutzen Prägnante Beschreibung der IT- Anwendungen im Portfolio Basis für weitere Analyse Kostenstruktur Risiken Komplexität Summe: 700.000 Funk. Qualität Hoch NFAs Mengen Services 100.000 Tech. Qualität Mittel SLA Hoch Benutzer 200T Personal - Entw. 100.000 Op. Effizienz Hoch Sicherheit Sehr Hoch Transaktion. 6T / Sek Personal - Betrieb 100.000 Ext. Risiken Gering Kritikalität Kritisch Datenmengen 500 GB Server / MF 100.000 Nutzen Verfügbar. Sehr Hoch LoC 1 Mio. Software/MW/DB 100.000 Strategie Gering Disaster R. Mittel Programme 30T Storage 100.000 Wert Hoch Effizienz Sehr Hoch Masken 3300 Netz/Infrastruktur 100.000 Compliance Neutral Schnittstellen 327 2015-01-15 32
Bewertungskriterien Architecture Assessment Application Quality Operational Efficiency External Risks Business Importance Functional Quality Economic Viability Vendor Viability Business Impact of Outage Suitability Accuracy Development Environment Market Changes Compliance Importance Interoperability Compliance Completeness Architecture Quality Std. Conformity Complexity Changeability Consistency Security Maintenance Reusability Methodology Operational Environment Installation Administration Support Methodology Political Environment Organizational Standing Financial Importance Strategic Importance Operational Quality Reliability Performance 2015-01-15 33
(Kosten-)Nutzen-Risiken Betrachtung Nutzen Wirtschaftlichkeit (Kosten, Nutzen, Wertbeitrag, ROI) Agilität, Time-to-Market Strategiekonformität (fachlich und technisch) Erfüllungsgrad der Anforderungen Kundenzufriedenheit Qualität (z.b. Wiederverwendung, Skalierbarkeit, Wartbarkeit, Betriebsführbarkeit, Zuverlässigkeit, Komplexität, Sicherheit etc.) Integrationsfähigkeit Reduzierung Vendor-Abhängigkeit Compliance / Standardkonformität Sicherheit und Datenschutz Steigt Neutral Neutral Steigt Steigt Sinkt Steigt Neutral Steigt Neutral Risiken Kosten Umsetzungsdauer / Realisierungstermin Lieferantenzuverlässigkeit Funktionale Risiken (z.b. Kunden-Akzeptanz, wesentliche Prozessänderung, Komplexität etc.) Technische Risiken (z.b. Technologien, Komplexität) Organisatorische Risiken (z.b. Ressourcen- und Skills- Verfügbarkeit, Unternehmenskultur, Stakeholder- Unterstützung) Mittel Mittel Mittel Neutral Hoch Hoch Kosten Services 100.000 Personal - Entw. 100.000 Personal - Betrieb 100.000 Server / MF 100.000 Software/MW/DB 100.000 Storage 100.000 2015-01-15 34
Auswertung Topic Scoring Functional Quality Architecture Quality Operational Quality Business Customer Standards Alignment Satisfaction Usability Conformity Complexity Changeability Security Reliability Efficiency 1 = High Risk 2 = Med. Risk 3 = Low Risk 1 = High Risk 2 = Med. Risk 3 = Low Risk 1 = High Risk 2 = Med. Risk 3 = Low Risk 1 = High Risk 2 = Med. Risk 3 = Low Risk 1 = High Risk 2 = Med. Risk 3 = Low Risk 1 = High Risk 2 = Med. Risk 3 = Low Risk 1 = High Risk 2 = Med. Risk 3 = Low Risk 1 = High Risk 2 = Med. Risk 3 = Low Risk 1 = High Risk 2 = Med. Risk 3 = Low Risk Weight 1,0 1,0 1,0 1,0 1,0 1,0 1,0 1,0 1,0 Application Assessment Assessment Assessment Assessment Assessment Assessment Assessment Assessment Assessment Entire Portfolio 2 2 0 2 2 2 3 2 2 App 01 2 2 3 1 3 1 2 2 2 App 02 1 1 2 2 2 3 1 2 1 App 03 2 3 0 3 3 3 3 1 3 App 04 2 2 2 2 2 2 3 3 2 App 05 3 1 3 3 2 1 2 1 1 App 06 3 3 3 2 2 2 3 3 2 App 07 2 3 2 3 1 2 2 1 3 App 08 1 1 1 3 1 3 2 3 3 App 09 2 2 3 1 1 0 2 2 2 Zweck Bewertung der einzelnen Anwendungen Bewertung der Gesamtlandschaft Nutzen Transparenz über die Risiken im Portfolio Basis für viele Analysemöglichkeiten 2015-01-15 35
Bebauungsplan Produkte entwickeln Produkte verkaufen Produkte disponieren Produkte abrechnen Zweck Die Anwendungsverortung stellt die Hauptprozesse den Organisationseinheiten Domänen, Produkten oder Standorten in einer Matrix gegenüber Org. Einheit 1 Org. Einheit 2 Org. Einheit 3 Org. Einheit 4 App 1 App 2 App 3 App 2 App 4 App 5 App 6 App 7 Nutzen Transparenz über die genutzte Anwendungen in Geschäftsprozessen, Organisationseinheiten, Standorten etc. Ermittlung Lücken bzw. Redundanzen in Geschäftsprozessen 2015-01-15 36
Kosten in T pro Jahr Kostenanalyse 1800 1600 1400 1200 1000 800 600 400 200 0 App 1 App 2 App 3 App 4 App 5 App 6 App 7 App 8 App 9 App 10 Applikationen Zweck Darstellung der Gesamtkosten Nutzen Transparenz über die Gesamtkosten und Kosten- Unterstützt Entscheidungen zu Priorisierungen Achtung Kosten sind schwer zuzuordnen, da viele Ressourcen gemeinsam benutzt werden 2015-01-15 37
Standard Competitive Differentiation Autonomie Anwendungsstrategie Automatisiert und Integriert IIntegrierte Individualsoftware mit automatisierten Schnittstellen Agil Konfigurierbare und orchestrierbare Individual- oder Kauf-Komponenten ggf. mit Anpassungen Zweck Graphische Darstellung der strategischen Ausrichtung Nutzen Unterstützt Entscheidungen zu geeigneten Umsetzungsmöglichkeiten niedrig hoch Automatisierung Flexibilität Standard Kaufsoftware ohne Anpassungen mit automatisierten Schnittstellen Automatisiert & Standard Standard Kaufsoftware ohne Anpassungen mit manuellen Schnittstellen Manuell & Standard niedrig Veränderungsdynamik high Quelle: Strategisches Management der IT-Landschaft, Hanschke 2015-01-15 38
Geschäftswert Nutzen Investment-Management Kosten-Nutzen-Risiken Betrachtung Low High Low High Support Invest Invest Evaluate Produkt App4 Produkt Produkt App3 App2 Divest Tolerate Tolerate Divest Low Qualität High Low Risiken High Zweck Überblick des Verhältnis zwischen Qualität und Wertbeitrag Nutzen Transparenz über den Stand der betrachteten Elementen Input für Investitions-entscheidungen 2015-01-15 39
Strategiebeitrag Strategie- und Wertbeitrag Zweck Graphische Darstellung der Geschäftsbedeutung der Anwendungen Niedrig Hoch Potenzial App1 App4 Strategisch Risiken bzw. Qualität Stabil Zu Beobachten Handlungsbedarf Nutzen Unterstützt Investitions- Priorisierung Transparenz über das Verhältnis zwischen Geschäftsbedeutung und Kosten der Anwendungen Größe = Kosten App3 Unterstützung Kerngeschäft App2 Niedrieg Wertbeitrag Hoch 2015-01-15 40
Topic: Enterprise Architecture Management Überblick und Einführung 1. Iasa Vorstellung 2. Überblick der EAM-Serie 3. Anforderungsmanagement 4. Portfolio-Analyse und Bewertung 5. Iasa EAM-Ausblick 41
Iasa EAM Veranstaltungen 16.07.2015: Capability-Based Planning: von Strategie bis zur Umsetzung http://goo.gl/c7q54i 31.07.2015: Iasa Deutschland Corporate Membership Walk-through http://goo.gl/7zr0kr 17.09.2015: Der Enterprise Architekt http://goo.gl/kctgg6 21-23.09.2015: 10. Jahrestagung Enterprise Architecture 2015 http://goo.gl/ttxudl 29-30.10.2015: IT Strategy, Governance & Transformation 2015 www.thoughtleaderglobal.com/itgrc2015 Oktober - November (siehe Iasa Deutschland Webseite - www.iasadeutschland.de): Architecture Capability Assessment Modern times - Architectures for a Next Generation (of) IT Mapping Business Capabilities Effective Strategy Implementation 2015-01-15 42
Danke für Ihre Aufmerksamkeit! Roger E. Rhoades President, Iasa Germany Chapter rrhoades@iasaglobal.org +49 160 974 964 65 www.iasaglobal.org Jennifer King Group Event Coordinator - Germany jking@iasaoffice.org www.iasaglobal.org Fragen? 2015-01-15 43