IT-Strategie Wertbeitrag

Transkript

1 IT-Strategie Wertbeitrag : IT als Unterstützungsfunktion : IT zur Effizienzsteigerung (Stay in the race) : IT als Enabler (Win the race) : IT als Treiber (Change the rules) Ubiquitous computing: Eingliederung der eh schon vorhandenen Privatgeräte in den Arbeitsablauf Moore s Law: Verdopplung der Anzahl der Schaltkreise auf Halbleitern alle Monate Management-Zyklus: Zielsetzung Planung Durchführung Kontrolle/Auswertung IT-Strategie muss von Geschäftsstrategie abgeleitet werden, muss aktuell und operationalisierbar sein, sowie der Realität entsprechen. Ausgründung: Erwartungen: Kosten sinken auf Dauer, State-of-the-art, Leistungsdruck (Wettbewerbsposition muss erreicht werden), Separation-of-concerns Drittgeschäft für Tochter? Alternative Provider für Mutter? Outsourcing: Erwartungen: State-of-the-art, Finanzen werden durch Vertrag festgelegt, Leistungsdruck gering da Position des Dienstleisters bereits bekannt. Grundregel: Nur was man selber erfolgreich managen kann, kann man erfolgreich outsourcen Offshoring: Kosteneinsparung von 35-50% nicht unrealistisch, Qualität steigt durch hohe Standards und Vielzahl an Dienstleistern. Kapazitätsengpässe entfallen da alleine in Indien jährlich neue IT-Professionals Verantwortung Eigen Extern Lokation Inland Ausgründung Outsourcing Offshore Captive Offshoring Offshore Outsourcing

2 IT Governance Kernfragen IT Governance Willensbildung: Entscheidungsrechte und Verantwortungen o Wer trifft Entscheidungen und zu welchen Aufgabefeldern? o Wer ist verantwortlich, gibt Input, wird informiert? o Welche Prozesse und Gremien werden eingerichtet? Entscheidungsumsetzung o Welche organisatiorischen Berichtslinien werden etabliert? o Welche Anreiz-/Durchsetzungsmechanismen werden geschaffen? o Wie wird die Umsetzung gesteuert und überprüft? Compliance o Welche externen Standards und Vorschriften müssen eingehalten werden? o Welche internen Policies und Spielregeln werden definiert? Kultur o Wie können die Governance-Strukturen in die Führungskultur des Unternehmens eingebettet werden? o Wie können die politischen Kräfteverhältnisse berücksichtigt werden? IT Governance beschäftigt sich mit: Verteilung von Rollen, Verantwortlichkeiten, Entscheidungsrechten, Ownership Schaffung organisatorischer Rahmenbedingungen (Linien- und Gremienstrukturen) Etablierung der zugehörigen Prozesse Setzen von Standards, Policies, Spielregeln, Verkehrsregeln Typische Themen: Strategische Ausrichtung, Investitionsmanagement, Performance-Management, Integritätsmanagement (Architektur, Qualität, Security) Zielkonflikte zwischen Individualinteressen und Gemeinschaftsinteressen Typische Governance-Prozesse: Portfoliemanagement (Priorisierung der Initiativen, Koordination der Abhängigkeiten) Architekturmanagement (Integrität der Anwendungslandschaft) Datenmanagement (Datenkonsistent und Qualität) Security- und Continuity-Management (Schutz vor externen Angriffen (Funktionsverlust, Datenverlust, Dateneinsicht)) Strategisches IT-Controlling (Kosten- und Nutzenmonitor) Qualitätsmanagement (Funktionssicherung, Kostensenkung) Risikomanagement (Sicherung des Projekterfolgs)

3 Typische Standards und Policies: Service Portfolio (Wiederverwendung und Redundanzreduktion) Metadaten-Repository (Semantische Konsistenz) Designrichtlinien (Software-Qualität externer Entwickler) Security-Policy (Schutz vor externen Angriffen) Warenkörbe (Vereinfachung der Hard- und Softwarelandschaft) Preferred-Partner-Listen (Einkaufs-Bündelung) Vorgehensmodell (Reduktion Projektrisiko) Style Business Monarchy It Monarchy Feudal Federal IT Duopoly Anarchy Zahnloser Tiger oder Amtsschimmel möglich Who has decision or input rights? Top Managers IT specialists Each business unit making independent decisions Combination of the corporate center and the business units with or without IT people involved IT group and one other group (e.g. top management or business unit leaders) Isolated individual or small group decision making Forces at work Effektivitätskritische Prozesse (know-how-intensiv, Erfogl durch Kundennähe, Fachprozesskenntnis) Strategie Architektur Portfolio Nachfragemanagement Effizienzkritische Prozesse (Ressourcenintensiv, Erfolg durch Industrialisierung, Skaleneffekte) Anwendungsentwicklung Infrastruktur Services, Help-Desk Wachsender Fokus auf IT-Effektivität Beitrag fachseitiger IT: Innovation, Integrität, Effizienz

4 Organisationsmuster-Varianten: Portfoliomanagement: Management, Abhängigkeiten, Wertoptimierung, Resourcenoptimierung, Fortschrittsmonitoring Phasen Portfoliomanagement-Prozess: 1. Ideengenerierung/-Erfassung 2. Evaluierung/Entwicklung Projektvorschläge 3. Ableitung Szenarien 4. Portfolio-Entscheidung SAM: Strategic Alignment Model CobiT: Control Objectives for Information and related Technology Val IT: Enterprise Value Governance of IT Investments

5 Enterprise Architecture Management Architecture Model 1. Motivate, Collect, Model 2. Communicate, Explain, Involve, Support, Get Feedback 3. Reflect, Adapt There are 3 EA Models: 1. Current (as-is) 2. Planned 3. Target (to-be) Definition EAM: EA management is a continuous management function seeking to improve the alignment of business and IT and to guide the managed evolution of an organization. Based on a holistic perspective on the organization the EA management function is concerned with the management, i.e., the documentation, analysis, planning, and enactment, of the EA. Configure & Adapt: Analyze & Evaluate Develop & Describe Communicate & Enact Notions: View (Representation of a whole system from the perspective of a related set of concerns. Views are the actual description of the system) Viewpoint (Specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.) Library Viewpoint (Viewpoint-definition from literature) Rationale (Describes the reasons, leading to the selection of an architecture as well as the intention an architect pursues with his decisions) Modeling method (Specification of the conventions for constructing and using a model. The modeling method determines the language to be used to describe the model) Model (Represents a certain aspect of an architecture, according to a notation defined through a viewpoint) Four phases of a typical management process: Plan, Do, Check, Act (PDCA) Develop & Describe Communicate & Enact Analyze & Evaluate Configure & Adapt von vorne Communication is the biggest problem, because of terminologies, different interest, no benefit for yourself by up-to-date information

6 System Cartography Template #1: Cluster map split in domains: functional areas, business units, technology stacks, Template #2a: Cartesian map

7 Template #2b: Cartesian map interval map Template #3: Graph layout map

8 Modeling The baker s 7 messages 1. A simple definition of Enterprise Architecture (EA): the art of bringing together actors, actions and information to make an enterprise work. 2. It is not enough to operate: we must also transform! 3. A discipline that is accessible to all. 4. In particular, it must help resolve the 3 key challenges for enterprises - how to: a. Master complexity through modelling b. Favour agility by separating operations and transformation c. Guide synergy by sharing resources and by reusing models 5. Business and IT should not be antagonistic, but associated to build appropriate solutions. 6. Agility is achieved if there is strong reuse of components and if parameterization and rule engines are employed. 7. The approach is the same whether IT is used or not. Key characteristics of a model: Models are always models of something, namely surrogates or representations of natural or artificial originals, which can be models themselves. Models commonlym do not capture all attributes of their corresponding original, but only those which seem to be relevant for the model creator and/or model user. Models are no 1:1 copies of their originals, they are surrogares for the original o For certain cognitive and(or acting, model using subjects, o Within given time intervals and o Under constraints to certain mental or real operations What makes a representing model a good one? Connecting model and modeled domain representation and interpretation: Lucidity: Every construct in the model must represent at most one object from the modeled domain. Overloaded model constructs are forbidden. (injective representation) Soundness: Every construct in the model must represent at least one object from the modeled domain. Construct excess in the representation is avoided. (surjective representation) Laconicity: Every object from the modeled domain must interpret at most one construct in the model. Construct redundancy is forbidden. (injective interpretation) Completeness: Every object in the modeled domain must interpret at least one construct in the model. Model completeness is ensured. (surjective interpretation) Semantic quality: Does the model cover the modeled domain? Pragmatic quality: Can the model be interpreted by the model users? Physical quality: Does the model capture the modeler s domain knowledge? Perceived semantic quality: Does the model correspond to the users knowledge about the domain? Social quality: Does the model facilitate user discussions on the domain?

9 Tool quality: Can the model be interpreted by a modeling tool? Syntactic quality: Does the model conform to a modeling language? Modeling Languages: For Object-Oriented-Languages: MOF (Meta Object Facility), UML For general knowledge representations: RDF, OWL EAM Frameworks Zachman Framework for Enterprise Architecture (1987) Different models depending on the stakeholder: Bubble charts Architects s drawings Architect s plans Contractors s plans Shop plans Building 5 Levels Scope description (ballpark view) Model of the business (owner s view) Model of the information system (designer s view) Technology model (builder s view) Detailed description (out-of-context view) Perspectives Data description Pricess description Network description Extended 1992 Persons (Who?) Time (When?) Motivation (Why?) Engels et al. Quasar Enterprise Basic structure can be divided into two dimensions: Architecture aspects: Different architectures of an enterprise Architecture layers: contextual, conceptual, logical and physical layer of each architecture aspect

10 Business architecture - Structures the business processes and business services in order to match the business goals and to model the organization of the enterprise Information architecture Structures the information required in the business architecture Information systems architecture Structures the application landscape from a business perspective Technology infrastructure architecture Structures the used technical platforms and system software components Creation of a regulation framework Clear separation between business and IT Distinguish between requirements and implementation Business strategy, quality criteria and business architecture are driving the design of the application landscape TOGAF 9 Overview Business goals are emphasized as architecture drivers. TOGAF provides a repository of best practices including: TOGAF Architecture Development Method (ADM) ADM Guidelines & Techniques TOAG Architecture Content Framework Enterprise Continuum TOGAF Reference Models TOGAF Capability Framework Can be used in combination with other frameworks having product relevant/specific sectors, like: Zachman, Spewak, DoD Framework, FEAF, TEAF,

11 Almost complete focus on artefacts, not method: TOGAF and. (not TOGAF or ) TOGAF Architecture Development Method (ADM) Iterative method over the whole process, between phases and within phases Each iteration = new decisions: Enterprise coverage, level of detail, time horizon, Decisions based on: competence/resource availability, value accruing to the enterprise For each phase: Describe current state and the target state. Perform gap analysis

12 Alphabet planningit Other Frameworks: Keller Processes for the IT enterprise architecture, Dern Management of IT architecutres, Schekkerman Enterprise Architecture, Good Practices Guide

13 EAM Tools Challenge of EAM Tools: The glue between different management functions and being connected to different information sources. Approaches: Flexibility vs. Guidance regarding process, method, and information model for supporting EA management Preconfigured vs. Customization regarding the functionality provided by the tool out of the box two approaches exist: EA management solution vs. EA management platform Integration vs. Single-Point-of-Truth regarding the information base of the tool, which in the one approach is collected from a variety of sources, while in the other approach being under data sovereignty of the tool itself (Framework-driven) Combinations are possible!

14 EAMTS2008 Scenarios: Scenarios for Analyzing Specific Functionalities o Importing, Editing, and Validating Model Data o Creating Visualizations of the Application Landscape o Interacting with and Editing of Visualizations of the Application Landscape o Annotating Visualizations with Certain Aspects o Supporting light weight Access o Editing Model Data using an external Editor o Adapting the Information Model o Handling large scale Application Landscapes o Supporting multiple Users and collaborative Work Scenarios for Analyzing EA Management Support o Landscape Management o Demand Management o Project Portfolio Management o Synchronization Management o Strategies and Goals Management o Business Object Management o SOA Transformation o IT Architecture Management o Infrastructure Management Introducing an EAM Tool 1. Create List of Criteria 2. Create List of existing tools 3. Reduce to Shorter List based on criteria 4. Test-Drive the Tools 5. Decide 6. Re-negotiation and Buying Decision

15 Teeuwen Color Color Ambition Yellow Success is the result of co-ordinated ambitions of the people in charge Influencing Blue Everything is makeable, planable, manageable Planning Red A right match between the interests of employees and organization Motivating Green Learning organization and intentional learning Learning White Spontaneous evolution & self-organisation Encouraging Concluding remarks Consider the dominant colour of the environment and choose an effective approach to change Each architect role has his or her own primary colours The transition from Project Architect is not a standard career step, but requires new skills For the individual architect: take a look at which colours are effective in your organisation and assess which architect role is suitable for you For the architecture manager: take a look at which colours are effective in your organisation. Make combinations of people from your group to cover the required colours. Also look at other sources of (non-technical) people if the emphasis is too much on blue