Enterprise (IT) Architecture Management. Teil 3: Bedarfsmanagement

Transkript

1 Enterprise (IT) Architecture Management Teil 3: Bedarfsmanagement

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. Lifecycle- & Änderungsmanagement 6. Iasa EAM-Ausblick 2

3 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

4 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

5 Iasa ist the preeminent knowledgebased association focused on the IT architecture profession 8000 Mitglieder 25 Chapters in 50 Ländern Netzwerk Wir alle sind Iasa!

6 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

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

8 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

9 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?

10 Ü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

12 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

13 Anforderungsmanagement steht in der Mitte! Anforderungen werden in allen Phasen identifiziert, Anforderungen fließen in und aus alle Phasen

14 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

15 Bedarfsmanagement im Unternehmenskontext Unternehmens- und Strategieentwicklung Vertrieb Innovations- Management Produkt Management Bedarfsmanagement Controlling Enterprise Architektur Management (EAM) Betrieb Projekt Management

16 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 (z.b. durch ATAM (Architecture Tradeoff Analysis Method) 16

17 Anforderungslebenszyklus erfasst definiert analysiert und bewertet fachlich freigegeben bebaut Kosten-Nutzen- Betrachtung erstellt geplant technisch freigegeben umgesetzt in Produktion Wertbeitrag verifiziert

18 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

19 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

20 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

21 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:

22 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

23 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

24 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

25 Anforderungserhebung Zerlegung / Unterteilung Abrechnungssystem Zahlungssystem Rechnungsstellung Zahlungsarten (z.b. Kreditkarte) Verbindung mit Service Providers Transaktions- Management Sicherheit

26 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

27 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),

28 Anforderungserhebung Leistungskette-Analyse Diagramm: Tata Consulting sites.tcs.com

29 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 )

30 Anforderungserhebung Geschäftsfähigkeiten-Analyse Strategie Anforderungen Ziele Produkte und Services Abgeleitet von: Umgesetzt durch: Business Capability Prozess Technologien Organisation Information

32 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: Funk. Qualität Hoch NFAs Mengen Services Tech. Qualität Mittel SLA Hoch Benutzer 200T Personal - Entw Op. Effizienz Hoch Sicherheit Sehr Hoch Transaktion. 6T / Sek Personal - Betrieb Ext. Risiken Gering Kritikalität Kritisch Datenmengen 500 GB Server / MF Nutzen Verfügbar. Sehr Hoch LoC 1 Mio. Software/MW/DB Strategie Gering Disaster R. Mittel Programme 30T Storage Wert Hoch Effizienz Sehr Hoch Masken 3300 Netz/Infrastruktur Compliance Neutral Schnittstellen

33 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

34 (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 Personal - Entw Personal - Betrieb Server / MF Software/MW/DB Storage

35 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 App App App App App App App App App Zweck Bewertung der einzelnen Anwendungen Bewertung der Gesamtlandschaft Nutzen Transparenz über die Risiken im Portfolio Basis für viele Analysemöglichkeiten

36 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

37 Kosten in T pro Jahr Kostenanalyse 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

38 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

39 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

40 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

41 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

42 Iasa EAM Veranstaltungen : Capability-Based Planning: von Strategie bis zur Umsetzung : Iasa Deutschland Corporate Membership Walk-through : Der Enterprise Architekt : 10. Jahrestagung Enterprise Architecture : IT Strategy, Governance & Transformation Oktober - November (siehe Iasa Deutschland Webseite - Architecture Capability Assessment Modern times - Architectures for a Next Generation (of) IT Mapping Business Capabilities Effective Strategy Implementation

43 Danke für Ihre Aufmerksamkeit! Roger E. Rhoades President, Iasa Germany Chapter Jennifer King Group Event Coordinator - Germany jking@iasaoffice.org Fragen?