Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20070115 - 03 Présentation CEISAR Club qualimétrie


Published on

From software complexity to information system complexity

Published in: Software
  • Login to see the comments

  • Be the first to like this

20070115 - 03 Présentation CEISAR Club qualimétrie

  1. 1. Club Qualimétrie 15 Jan 2008 CEISAR Centre of Excellence for enterprISe Architecture Pierre-Frédéric Rouberties From software complexity to Information System complexity
  2. 2. Agenda • A word about Enterprise Architecture • A word about the CEISAR • A word about Enterprise Complexity Page 2 • A word about Enterprise Complexity • CEISAR’s view on Enterprise Architecture • From software complexity to Information System Complexity
  3. 3. “How to structure the Information System to help company transformation » Main challenge for the CIOs in the coming years Page 3 to help company transformation » No longer be a constraint, become an enabler
  4. 4. A word about Enterprise Architecture Page 4 A word about Enterprise Architecture
  5. 5. Why EA became necessary ? • After 20 years of existence of IT (70’s and 80’s), the observation was made that : – Information systems had become increasingly complex and costly • One of the cause being (too) many technologies had flourished and the pace of apparition/disparition of technologies was still high – Many projects had failed to deliver the expected benefits Page 5 – CEOs had started wondering about the return on investment of Information Technology – IT systems were hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner – A culture of distrust between the business and technology sides of the organization had developped
  6. 6. EA expected benefits • EA aims at delivering: – Alignment : Closing the gap between technology and business – Agility : Reducing complexity of the business and IT systems Page 6
  7. 7. History of Enterprise Architecture • In France : EA is called “Urbanisme”, born in the banking industry during the 90’s – Urbanisation des systèmes d’information [Jacques Sassoon –1998- édition Hermès] – Urbanisation du business et des systèmes d’information [Gérard Jean 1999 - Hermès] Page 7 – Le projet d’urbanisation [Christophe Longépé 2001 - Dunod] – Club Urba EA • Pratique de l’urbanisme des SI en entreprises - 2003 • Urbanisme des SI et Gouvernance – 2006 - Dunod
  8. 8. Main concepts of « Urbanisme » • Global view of the IS • Layer Approach • « City planning » metaphor • Concepts of Zones Page 8 • Principle of subsidiarity • « Urbanisation » process
  9. 9. History of Enterprise Architecture • American point of view : – Birthday : 1987 • Zachman, J.A. "A Framework for Information Systems Architecture." IBM Systems Journal, Volume 26, Number 3, 1987. • Emphasizes the need for a “holistic” [global] approach to systems architecture – EA was created to address two problems : Page 9 • System complexity—Organizations were spending more and more money building IT systems; and • Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need. – US Government pushing to enforce EA in its agencies • Clinger-Cohen Act of 1996
  10. 10. Some key features of EA • Enterprise Architecture focuses on : – A global awareness of the entire system (Business + IT) : adding a block next to the other in an inconsistent way is no longer possible – A set of multiple views to take all points of view into account – A line of continuity between the various views to enforce alignement – A planning approach, aiming at convergence toward a preferred future state of the Page 10 – A planning approach, aiming at convergence toward a preferred future state of the system – Incremental implementation : step by step convergence towards the target
  11. 11. EA involves two major practices • Engineering – Modelling • Creating a model of the current state of your system (as is) • Designing a model of the desired future state of your system (to be) • In all areas of the enterprise system • To achieve • Management – Communicating • Selling EA • Driving change (many people impacted) – Deciding • Choosing an EA approach • Enforcing it Page 11 • To achieve - reusability, - maintanability, - cost efficiency, - scalability, … – Implemeting • Developping, testing, operating • Enforcing it – Planning • Designing implementation plan and cycles – Measuring/Controlling • Making sure EA is used and delivers benefits In this respect, EA transforms IS/IT Governance Good system engineering practices can be extended to the enterprise
  12. 12. A word about the CEISAR : Page 12 A word about the CEISAR : An Initiative from Ecole Centrale Paris
  13. 13. Many fields exist like Process reengineering, Application Blue print, Component, SOA, OO, Open Source, ... All help to organize and simplfy the Enterprise System. But there is no International Center which unifies all these good approaches and present them as a new consistent, strategic and International domain. ECP decided to create an original organization, the CEISAR, to be as close as possible from Companies Concerns Initiative Page 13 • A strategic and international domain: Enterprise Architecture • The best experts from companies • A federation of several large user companies and provider companies, working together for a common project, and financing it • To deliver a set of useful products: White Papers, and training
  14. 14. Which deliverables ? Page 14 Which deliverables ?
  15. 15. • For each Architecture topic: Best Practices in White Paper – From user case studies – From providers – From our own experience – Using a common language • New Topics every 6 months – Define a common vocabulary (Entreprise Meta-Model) – Approach to define Business Entities (zoom on « Actors ») Deliverables Page 15 – Approach to define Business Entities (zoom on « Actors ») – Approach to simplify Legacy Systems (zoom pn « rule engine ») – Training requirements for Architects – Business Process Management – Gouvernance and Entreprise Architecture • A web site which includes all white papers, and connect members • Training sessions for students • Training sessions and coaching for companies (management, business, IS)
  16. 16. • Global approach – Architecture is more an answer to business than a collection of technologies • Simplicity Do not « reinvent the wheel », but – Consistency, complementarity between topics which belong to different schools • Business Process school • Urbanism school Our Challenge Page 16 • Urbanism school • Component school • SOA school • OO school • ... – Make it understandable by the majority of actors involved in Architecture – Reduce the number of concepts – Apply Architecture approach to CEISAR work: reuse, urbanism
  17. 17. A word about Enterprise Complexity Page 17 A word about Enterprise Complexity
  18. 18. Enterprise and Number of business domains to computerize Sharing dataIS extends to partners, customers, prospects Information System Complexity Page 18 Enterprise and Information System Complexity increases ! Number of technologies which coexist InternationalSophisticated Functions: Rule Engine, Workflow
  19. 19. Flexibility decreases Slow evolutions High cost and Maintenance workload User Specialization And fragmented processes Information System Flexibility Page 19 Flexibility decreases when complexity increases Difficulties to integrate New technologies Difficulties to share (merge, partners, international) Accessibility The CIO sees himself more like a plumber than an Architect.
  20. 20. IS Complexity Company Total Headcount IS headcount AXA 120.000 10.000 BNPP 155.000 13.000 Michelin 116.000 2.000 Total 95.000 4.000 Page 20 Total 95.000 4.000 •500.000 IT objects are managed in production by BNP Paribas •See AXA France Cartography A noble engineer job: How to structure an Enterprise System And provide Agility?
  21. 21. How does complexity impact the Enterprise? • Decrease of agility (from end of requirement to end of deployment) – On Business System like time to launch a new Product or « time to market » – On Organization System like time to adapt an Organization Process – On IT System like time to deliver a new Software Service • Increase of costs – Organization Costs: number of people (internal or external) and all other related costs (equipment, offices, …) – IT costs: IT productivity Page 21 – IT costs: IT productivity • Decrease of IT Service quality – Reliability: defect ratio – performance • Decrease Ease of use – No standard user interface – Process discontinuity • Lack of Knowledge: team and documentation
  22. 22. Diversity versus Standardization • Diversity means: – Creativity, innovation – Freedom to create – Momentum and energy • But also: – Uncontrolled development leading • Standardization means: – Reducing diversity – Reducing freedom – Creating new constraints • But also: Page 22 – Uncontrolled development leading to Chaos – Duplication of efforts – Costs – Reducing complexity – Reducing costs – Maximizing good practices reuse Each company has to find the right balance depending on its stage of maturity and own culture
  23. 23. CEISAR’s view on Enterprise Architecture: Page 23 CEISAR’s view on Enterprise Architecture: Towards a unifying meta-model of the enterprise
  24. 24. Core Business Enterprise Model = (Business + Organization + IT) Models Defines what are the Business Entities and the Business Processes Functional Page 24 Organization IT Defines who (the Actors) executes and when are executed the Business Processes. For the same Business, several Organizations may exist. How a set of Hardware, Software, Data automate all or part of Business and Organization Functional
  25. 25. Function Business Function Organization Function Software Service Business Entity Business Actor * * Business Process Activity Class Block Core Business IT Business Process Domain Business Entity Domain * * * * ** * * Block cartography The Global View of the Enterprise Model Page 25 Organization Function Organization Process Procedure Operation Organization Entity Organization Actor Organization Function Domain * * * * Development Model Operation Model * *
  26. 26. « Architecture » or what is « sharable » in the Enterprise System (business, organization, IT) - How to simplify? Page 26 - The foundation - The backbone for the sustainable development of the Enterprise
  27. 27. • Common definitions for main Business concepts • Common Business Processes or Business Process Models • Common User Functions • Shared Data (like customer, organization, products, …) • Application Blue Print Enterprise Architecture: defined as what can be shared (to be aligned on Enterprise Strategy) Page 27 • Application Blue Print • Common applications • Shared components • Common development environment • Common deployment architecture: OS, DBMS, middleware, tools and approach
  28. 28. Enterprise Model includes: Solutions and Architecture. Architecture is defined as what is shared between Solutions. Business Architecture Business Model WHAT Enterprise Architecture Enterprise Model Page 28 Organization Architecture IT Architecture Organization Model IT Model HOW IS IT AUTOMATED WHO
  29. 29. Enterprise Model includes: Solutions and Architecture. Architecture is defined as what is shared between Solutions. Enterprise Model Business Model (What) IT Model (How is it automated) Business Architecture IT Architecture Business Solutions IT Solutions Page 29 Organization Model (Who) Organization Architecture Organization Solutions
  30. 30. Simplify: but where does Complexity come from? Complexity may come from the 3 Systems: • Business System – Too many Business Entities like many Products – Many Functions because no shared Functions like « Price Contract » • Organization System – Too many different Organization Processes – Too many Organization Functions, compared to Business Functions Page 30 – Too many Organization Functions, compared to Business Functions • IT System – No reuse – Many different deployment technologies – Many different development technologies
  31. 31. Measure complexity of Enterprise System Measure complexity of Enterprise System Measure complexity of Business System Measure complexity of Organization System Measure complexity of IT System Number and complexity of •Business Entities (1) •Nb of Org.Proc/BusProc •Nb of Operations/Process •Nb of hardware •Nb, size of Blocks (LOC) Page 31 •Business Entities (1) •Business Processes •Business Functions •User Interfaces Volumes for •data and •process instances •Nb of Operations/Process •Nb of Actor Types •Org.Functions/Bus.Funct. •Volumes for nb of Actors •Nb, size of Blocks (LOC) •Nb of Interfaces •Nb of Tables + Attributes •Nb of Operation techno. •Nb of Development techno •Pertinence of Block Carto. •Quality of the code •Quality of data •Techno. Obsolescence •Productivity ratios 1-Focus on Products and Services
  32. 32. Measure Architecture Level which decreases unnecessary complexity Measure Architecture level Measure Business Architecture Measure Organization Arch. Measure IT System Arch. •Common Business Entities •Shared Block cartography•Common Org. Description Page 32 •Common Business Entities •Common Process Models •Common Bus. Functions •Shared Block cartography •Common Soft. Services •Common Blocks •Common Classes •Common Data •Common Dev. Environment •Common Operation Envirt •Level of customization done by parameters and rule engine (1) •Common Org. Description •Common Org. Functions (like Rights and Duties) •Consistent User interface 1-Customization for Product, Organization Processes, Security, … thanks to parameters and Rule engine
  33. 33. What is Software Quality Management ? • Main objective is to control software complexity – To optimize its performance – To make it simpler, easier to maintain, reuse, upgrade … – Faster to market and less expensive • Acting on – Software development processes (CMMI) Page 33 – Software development tools – Software modeling techniques – Sharing best practices (patterns) and training • Based on – Best practices – Standard and ad hoc Metrics
  34. 34. Enterprise Architecture as the next playground for Software Quality experts … • Long experience – Software Engineering has defined many metrics to measure system complexity • Transposition is possible – Many concepts can be reused from software quality management at the level of information systems • Example of the « functional complexity » Page 34 – Some companies are starting to manage Application portfolio Complexity • See Axa APR index – Software Quality expertise can be reused and extended … Source : Qualixo/Air France 2007
  35. 35. Your point of view ? Questions & Answers Page 35 Questions & Answers you can contact me at: