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.

Introduction to enterprise architecture

14,241 views

Published on

This presentation is an introduction to EA, EA processes, EA frameworks, and give some example of EA tools. We also introduce at the end the topic of EA governance. So normally, all you need to know to start you EA journey.

Published in: Technology, Education
  • How can I lose 10 pounds in 10 days naturally? ♥♥♥ https://tinyurl.com/bkfitness4u
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Introduction to enterprise architecture

  1. 1. Introduction to Enterprise Architecture William El Kaim Oct. 2016 - V 2.1
  2. 2. This Presentation is part of the Enterprise Architecture Digital Codex http://www.eacodex.com/Copyright © William El Kaim 2016 2
  3. 3. Plan What is Enterprise Architecture? • Enterprise Architecture vs. Application Architecture • Why Enterprise Architecture? • How to do Enterprise Architecture? • Enterprise Architecture Layers Deep Dive • What is an Enterprise Architecture Framework? • Why Do I Need an Enterprise Architecture tool? • Could I build my own Enterprise Architecture Framework? • What is EA Governance? • Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 3
  4. 4. Enterprise Architecture (EA) Definitions • An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. • The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. • Forrester, Gene Leganza, 2001 • “Enterprise architecture consists of the vision, principles and standards that guide the purchase and deployment of technology within an enterprise” • Gartner Group • “Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise’s future state and enable its evolution.” Copyright © William El Kaim 2016 4
  5. 5. Plan • What is Enterprise Architecture? Enterprise Architecture vs. Application Architecture • Why Enterprise Architecture? • How to do Enterprise Architecture? • Enterprise Architecture Layers Deep Dive • What is an Enterprise Architecture Framework? • Why Do I Need an Enterprise Architecture tool? • Could I build my own Enterprise Architecture Framework? • What is EA Governance? • Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 5
  6. 6. • What is Application Architecture (AA)? • Application Architecture is the set of policies, practices, processes and tools to ensure an optimal and secured design and construction of an information system that best works for its business owner and users. • What is Enterprise Architecture (EA)? • Enterprise Architecture is the Governance and overall Plan to effectively structure, manage, integrate, secure and evolve the information system landscape of the company, aligning to business and IT strategy Architecture Scope is twofold! AA vs. EA •Global Scope •High Granularity •Local Scope •Low Granularity Globally based solution, ensuring company Global architecture to be Coherent! Project based decisions (Local) and delivery optimized within that context (Optimal) Copyright © William El Kaim 2016 6
  7. 7. Architecture Scope is twofold! AA vs. EA EWITA = Enterprise Wide IT Architecture Specific BU organization Specific BU organization Copyright © William El Kaim 2016 7
  8. 8. Plan • What is Enterprise Architecture? • Enterprise Architecture vs. Application Architecture Why Enterprise Architecture? • How to do Enterprise Architecture? • Enterprise Architecture Layers Deep Dive • What is an Enterprise Architecture Framework? • Why Do I Need an Enterprise Architecture tool? • Could I build my own Enterprise Architecture Framework? • What is EA Governance? • Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 8
  9. 9. Why Enterprise Architecture? https://www.youtube.com/watch?v=qDI2oF1bASkCopyright © William El Kaim 2016 9
  10. 10. Why Enterprise Architecture? • The purpose of Enterprise Architecture (and city planning" for information systems) is to define the main principles in the implementation and construction of computer applications, to ensure consistency throughout while decreasing the costs of building and integrating new applications. • This should improve the company’s ability to respond to a constantly changing environment. • The city planning for the information system explains what the applications do, documenting redundancies so they can be reduced. • The application architecture defines or documents (maps) the structure of applications and their services, showing the cooperation between them. Copyright © William El Kaim 2016 10
  11. 11. Why Enterprise Architecture? Manage IS complexity • The introduction of new non-standard technology • imposes a voluntary tax of 5 to 12% on the development budget, and an increase of 21 to 33% on project duration. • Studies have shown that, over time, Enterprise Architectural efforts can result in a reduction of annual IT spending by as much as 20%. • More projects can be completed within a given project budget when Enterprise Architecture Methods/Tools are followed than when they are not. • Repair Cost are greatly reduced through EA by reducing errors in IT solution designs early. Copyright © William El Kaim 2016 11
  12. 12. Why Enterprise Architecture? Manage IS complexity • Alignment • Ensuring the reality of the implemented enterprise is aligned with management's intent • Change • Facilitating and managing change to any aspect of the enterprise • Resilience • Reducing systems development, applications modernization • Convergence • Striving toward a standard IT product portfolio (service and asset reuse) • Integration • Realizing that the business rules are consistent across the organization, that the data and its use are immutable, interfaces and information flow are standardized or controlled and the connectivity and interoperability are managed across the enterprise Copyright © William El Kaim 2016 12
  13. 13. Why Enterprise Architecture? Providing Holistic Views Enterprise Architecture Application Architecture Copyright © William El Kaim 2016 13
  14. 14. Application Infrastructure Operation and service delivery Why Enterprise Architecture? Providing Holistic Views Strategy Technology Function and Services Service and Functional Plan Application Plan Business Business Process PlanProcess Security, Integration, Governance, Etc. Infrastructure Plan Holistic Views Copyright © William El Kaim 2016 14
  15. 15. Why Enterprise Architecture? • Enterprise Architecture is justified for businesses: • which have significant application assets. • which have a long history in information technology. • where information technology is strategic. • It may also be justified in: • Mergers/Acquisitions • Enterprises dependent on software packages • Apart from these cases, city planning projects are rarely flagship projects. • They must be low key, with no negative impact on other projects. Copyright © William El Kaim 2016 15
  16. 16. Plan • What is Enterprise Architecture? • Enterprise Architecture vs. Application Architecture • Why Enterprise Architecture? How to do Enterprise Architecture? • Enterprise Architecture Layers Deep Dive • What is an Enterprise Architecture Framework? • Why Do I Need an Enterprise Architecture tool? • Could I build my own Enterprise Architecture Framework? • What is EA Governance? • Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 16
  17. 17. How To do Enterprise Architecture? EA processes • Understand • My Information System (patrimonial) • Its organization, its structure • its components et its interactions • Manage • Analysis et KPI • Projects Specifications • Govern • Bring under control Cost Risk, and IS risks • Bring under control IS Performance • Bring under control IS evolution Also referred to City Planning or Urbanization Copyright © William El Kaim 2016 17
  18. 18. How To do Enterprise Architecture? From As-Is to To-Be • EA planning entails the definition of a current state (called AS-IS) or as-is architecture in four categories: • business processes • application programs • information/data • and infrastructure technology. • Then the business plans are reviewed and an appropriate future state (called TO-BE) is created for each category. • The future state is compared to the current state in a gap analysis, and a sequencing plan is developed to progress from the current state to the future state. Copyright © William El Kaim 2016 18
  19. 19. How To do Enterprise Architecture? From As-Is to To-Be in Top-Down Approach Business process Function / Service Technical Constraints City Planning Design Strategy Business Functional Application Existing Business Architecture Business Strategy Target Business Architecture Target Functional Architecture Existing Application Architecture Target Application Architecture Copyright © William El Kaim 2016 19
  20. 20. How to Do Enterprise Architecture? From “AS-IS” to “TO BE” Source: ForresterCopyright © William El Kaim 2016 20
  21. 21. How To do Enterprise Architecture? EA processes The IS Urbanization process Elaborate and improve the IS urbanization framework (rules, principles, EA targets) Link IS urbanization with business strategy and IS governance IS Urbanization plans Drive the implementation and the evolution of the master data repositories Standardize and simplify the exchanges between applications Build the link with technical infrastructures Infrastructure basics Participate in the upstream phases of the projects Monitor the architecture of the IS projects Relationships with projects Drive the IS Urbanization process Participate in the projects arbitration committees Management Maintain and deploy the map repository for the existing and target IS (processes, applications, data, etc…) Support& Communication Communicate and train on IS Urbanization Source: Club Urba-EACopyright © William El Kaim 2016 21
  22. 22. How To do Enterprise Architecture? Assess Complexity: Club URBA-EA Index 0 1 2 3 4 1. Knowledge of IS « as is » 2. Master data repositories management 3. Knowledge of IS « to be » 4. IS building management 5. Flows complexity management 6. Urbanization management and communication 6 axis to understand IS urbanization maturity (with 2 to 4 criteria per axis) TO BE AS IS Source: Club Urba-EACopyright © William El Kaim 2016 22
  23. 23. How To do Enterprise Architecture? Example: Carlson Develop “Target” Core Business Architecture Develop roadmap CIS Pre–HAL HAL Transition Post-HAL Before 31/12/04 Q1 ‘05 Q2 ‘06Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07 Q3 ’07 and beyond Before 31/12/04 Q1 ‘05 Q2 ‘06Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07 Q3 ’07 and beyond HAL MI/PM Corporate Information System Scoping, Business Case, Analysis Corporate Information System Implementation Operational Data – Scope, Analysis, Design Operation Data – Build Phase Press Control Systems Implementation Group Planning Process and System Requirements Capture Group Planning Implementation Customer Management Benefits Assessment Customer Management Implementation ODCMGPMSCIS Pre–HAL HAL Transition Post-HAL Before 31/12/04 Q1 ‘05 Q2 ‘06Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07 Q3 ’07 and beyond Before 31/12/04 Q1 ‘05 Q2 ‘06Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07 Q3 ’07 and beyond HAL MI/PM Corporate Information System Scoping, Business Case, Analysis Corporate Information System Implementation Operational Data – Scope, Analysis, Design Operation Data – Build Phase Press Control Systems Implementation Group Planning Process and System Requirements Capture Group Planning Implementation Customer Management Benefits Assessment Customer Management Implementation ODCMGPMS Create a high-level plan that defines how the Technical and Informational architectures will change over time through a set of prioritized initiatives. The implementation of these initiatives will be marshalled through the overarching Core Enterprise Architecture. • Define Roadmap initiatives • Define initiative prioritization and dependencies • Create roadmap Develop the “Target” Core Business Architecture defined in terms of process, systems and organizations by creating target architecture views through interviews and workshops. Then validate with Business Owners. Target: •Core Business Plans •Core Business Component Business Model (CBM) •Core Business Locations Maps •Core Business Org Charts •Core Business Events Schedules • Map (CBM) to Application/Tech/Info Architectures) •Gap Analysis Build a foundation model that provides a functional representation of the Core business at a Conceptual/Contextual level. This model will remain as a “High-Level” static reference point to understand the key aspects of the business. Included in the model will be examples (and relational diagrams) of: •Business Plans •Business Component Business Model •Business Locations Maps •Business Organizational Charts •Business Events Schedules Develop Core Business Architecture model Define “Current” Core Business Architecture Define the “Current” Core business and strategy, defined in terms of process, systems and organizations by creating current architecture views through interviews and workshops. Then validate with Business Owners Current State: •Core Business Plans •Core Business Component Business Model (CBM) •Core Business Locations Maps •Core Business Org Charts •Core Business Events Schedules • Map (CBM) to Application/Tech/Info Architectures) Copyright © William El Kaim 2016 23
  24. 24. How To do Enterprise Architecture? Example: Business Connexion Copyright © William El Kaim 2016 24
  25. 25. How To do Enterprise Architecture? Top-Down vs. Bottom-up • Two major approaches to enterprise architecture (EA) have evolved • a top-down approach that assumes comprehensive scope and strictly follows a formal process • a bottom-up approach that starts with infrastructure technology standardization and then moves up the food chain to target high- priority problem areas and eventually influence business architecture Copyright © William El Kaim 2016 25
  26. 26. How To do Enterprise Architecture? Top-Down vs. Bottom-up • Each approach has its benefits and drawbacks, but it is far from arbitrary which is an appropriate model to choose — it is imperative that the approach fit the culture of the organization. • Organizations that need to address significant inefficiencies and redundancies in their business process or application portfolios and can wait at least a year for measurable benefits should start with the top-down approach. • Organizations that need results that affect the bottom line quickly or those where rampant technology diversity has degraded service delivery quality should start with the bottom-up approach (Brownfield). • The best approach is often a combination of both Copyright © William El Kaim 2016 26
  27. 27. The private sector and start-up favored the bottom- up approach. Positive aspects • The program can have significant impact immediately (six to 12 months). • Early successes build credibility rapidly. Early wins start the EA effort off on the right foot and build much-needed credibility for the more politically complex efforts that follow. • It attacks problems in priority sequence. The potentially overwhelming scope of an EA effort is simplified in a bottom-up approach: the biggest problem is attacked first • Scope and complexity build gradually. Bottom-up allows technologists and managers to learn as they go. • It does not need a large central EA team at the outset. Involves a central project manager and the borrowed expertise of internal SMEs. There is no need for additional staff. Negative aspects • The typical infrastructure origin hampers efforts to expand scope. Once the infrastructure-based EA group has cleaned up technology standards and attempts to broaden its scope, it is often blocked from influencing application development staff for political and cultural reasons — and the effort can stall. • A standards-based approach introduces governance as a police action. The most typical introduction of governance is via an architecture review board that reviews projects designs and rejects nonstandard approaches. This makes architects the bad guys and can hamper IT community buy-in and future attempts at expanded scope. • The initial technology focus appears insensitive to business issues. Governance processes introduced to prevent the introduction of nonstandard technology please neither application developers nor business project sponsors. It smacks of a “technology for technology’s sake” attitude that is far from business- enabling. Copyright © William El Kaim 2016 27
  28. 28. The public sector and regulated business favored the top-down approach. • It begins by establishing a clear view of the existing environment. • The initial data collection activity enables a consensus regarding the current state environment, which is a critical element for effective planning. • Business issues are emphasized at the outset. • The top-down approach is explicitly about improving the business. • Technology plays a subservient role as the enabler of the business. • It establishes broad scope at the outset. • With the appropriate management support, all areas in need of improvement become subject to the EA program’s scrutiny. • Top-down programs can be overly abstract and have little impact in the short term. • The data collection process delays the introduction of governance. • The formal methodology requires training to get started. • The methodology implies business process re-engineering skills. • The EA organization will have to draw important conclusions from the analysis of the as-is architecture data. • But these skills are typically the realm of senior business consultants; it remains to be seen if many organizations that have followed this approach will find value in having assembled their business process portfolios. Positive aspects Negative aspects Copyright © William El Kaim 2016 28
  29. 29. Top-Down vs. Bottom-Up Example: Aventis Top down Bottom up Process re-designed New application developed to support standardised process Data migrated "Big bang" launch Top down approach is effective when : • Existing landscape is simple • System can be implemented and supported centrally • Strong business direction has been given Product / Service re-designed Core modules developed to support standardised process Core module progressively added "seamlessly" to existing landscape Applications retired on a case by case basis Bottom up approach is effective when : • Country/site specifics are significant • Different functions are involved and moving at a different pace (priorities, budget, resources) All existing applications retired Existing landscape adapted as necessary Examples : HR Examples : SAP Copyright © William El Kaim 2016 29
  30. 30. How To do Enterprise Architecture? Key Deliverables Business Architecture Process Architecture Functional Architecture Application Landscape Application Architecture Business Features Information System Cartography & functional zoning, mapping function/application, functional architecture schema, repositories. Application functional coverage analysis, inter-application dependencies and interfaces, application logical architecture Technical architecture (layers), Software components, non functional requirements Operational processes description, activities, business objects Organigrams, actors Infrastructure Architecture Code and infrastructure architecture. Deployment architecture and configuration Information and Data Architecture Information Model master & reference data Interfaces: messages and data exchange Conceptual data schema Technical data schema Business Glossary, Business Objects, Copyright © William El Kaim 2016 30
  31. 31. Plan • What is Enterprise Architecture? • Enterprise Architecture vs. Application Architecture • Why Enterprise Architecture? • How to do Enterprise Architecture? Enterprise Architecture Layers Deep Dive • What is an Enterprise Architecture Framework? • Why Do I Need an Enterprise Architecture tool? • Could I build my own Enterprise Architecture Framework? • What is EA Governance? • Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 31
  32. 32. Enterprise Architecture Layers Deep Dive Service and Functional Plan Technical & Infrastructure Plan Application Plan The Business Vision, goals and processes Business objects, capabilities, services, functions, etc. The Application and Data Technical Design The description of the Technical Infrastructure Business Process Plan TOP DOWN Copyright © William El Kaim 2016 32
  33. 33. Business Architecture • Defines the: • Business Strategies, Processes, And Functional Requirements. • Purpose, goals, structure and plans of the enterprise (like organizational structures, major locations, and relationships with partners and customers) from a business perspective • Major process domains for the enterprise (E.G., Product development, sales, distribution, etc.), specific processes within those domains and operational parameters for the processes (E.G., Transaction volumes, roles, centralized vs. Mobile operation, etc.). • An Enterprise Architecture approach to Business Architecture • Provides the tools the business needs to ensure the quality and consistency of business design and reengineering efforts. • Guides the development of the it/is architecture • Must be accurately documented to ensure it is understood. Copyright © William El Kaim 2016 33
  34. 34. Business Architecture Objectives • This layer focuses on the business processes in the context of a business strategy. • Starting from business needs defined by the business strategy, an enterprise architect, working closely with the different lines of business in an organization, can start modelling the major enterprise business processes. • This will help the architect understand the global and major processes of an enterprise and will promote the approach by involving business representatives. • Using BPM tools, business analysts can simulate the business processes, providing a measurement of the optimization that occurs when doing process reengineering. • The business processes plan is owned by the business. The architect's role consists mainly of capturing the business needs and identifying common business services usable through different business lines in an organization. Copyright © William El Kaim 2016 34
  35. 35. Business Architecture Urbanization axis • Definition of business process and their taxonomy • Categorization of Processes (Governance, operational, support, ...) • Definition of transversal processes (shared services) • Concentrate on target process and critical ones (value chain) • Clear definition of roles (ownership, responsibility, optimization) • Describing processes lifecycles and end to end value chain lifecycle • Define also non core BP, especially for Business Process outsourcing • What is important is not to do a cartography, but to find, analyze, improve, and optimize the value chains. Copyright © William El Kaim 2016 35
  36. 36. Business Architecture Business Process Management • BPM is a management practice that provides for governance of a business process environment toward the goal of improving agility and operational performance. • BPM is a structured approach employing methods, policies, metrics, management practices and software tools to manage and continuously optimize an organization's activities and processes. • Main Mission • Initiate the review and assessment of existing Business Processes end-to-end with Business Process Owners and Sponsors; • Help design and implement process changes with a view to unlock hidden savings, enhance performance and improve customers experiences through efficient organizational changes and effective application of IT. Copyright © William El Kaim 2016 36
  37. 37. Business Architecture Bus. Process Terminology and Hierarchy Business Process Copyright © William El Kaim 2016 37
  38. 38. Business Architecture Example: BP Hierarchy Copyright © William El Kaim 2016 38
  39. 39. Business Architecture Example: BP Hierarchy Copyright © William El Kaim 2016 39
  40. 40. Business Architecture Example: Process/App Cross Reference Copyright © William El Kaim 2016 40
  41. 41. Business Architecture Example: Schlumberger Copyright © William El Kaim 2016 41
  42. 42. Business Architecture Example: Schlumberger Copyright © William El Kaim 2016 42
  43. 43. Business Architecture Example of Matrix: BSI Bank Copyright © William El Kaim 2016 43
  44. 44. Functional Architecture • After designing the major processes of an organization, major functional blocks can be identified. • The Functional Architecture defines the: • Structure of the system’s functions/Services and their subfunctions/subservices and how they are related (city planning). • The execution sequencing of the functions and/or orchestration of services • Principles and policies that govern information ownership, use, and management across the enterprise. • The scope and priority of each application from the landscape • Application context: interfaces with other applications, data produced and consumed (master data, reference data, etc.), actors, etc • Maps with • Application or Business Architecture Copyright © William El Kaim 2016 44
  45. 45. Functional/Service Architecture The need to talk the same language • Common entities and common domain models are defined in such a way that they have common meaning in the organization and can be reused in different lines of business. • A city-planning metaphor can be used in this plan: Assembling the functional building blocks into quarters and zones relate to the different lines of business in the organization. • A common language will promote the reuse of the functional building blocks and the data that will be shared between those blocks. • The canonical models should be shared in an enterprise repository. • Governance considerations should define the way those models should be designed, accessed, validated, and amended. Copyright © William El Kaim 2016 45
  46. 46. Functional Plan Zoning and Mapping • The description on the functional plan is made in business terms, divided in such a way that it can be mapped to functions, information, applications and services within applications. • After identifying those functional building blocks, communication between those blocks should also be defined, which means a canonical data model is defined. • This canonical model can be described using UML models leading to XML representation of the data. • This common language should be shared across the entire organization. Copyright © William El Kaim 2016 46
  47. 47. Functional Plan Urbanization Rules • Distinguish operational process and support process. • Identify link between processes • Define hierarchy between links. • Identify functional block that constitute the process. • Identify triggering event to launch and stop the process. • Model processes and manage process anomalies. Copyright © William El Kaim 2016 47
  48. 48. Disaggregation of the value chain The Capabilities Of A Credit Granting Process… Corporate Credit Building Credit Consumer Credit Payment Entry in Land Register Payment Collaterals Registration Check Contract Get Signature Final Vote & Decision Collaterals Evaluation Product Config- uration First Vote Rating Data Entry Collaterals Acquisition Product Selection Check Contract Get Signature Final Vote & Decision Collaterals Evaluation Product Config- uration First Vote Scoring Data Entry Collaterals Acquisition Product Selection Payment Check Contract Get Signature DecisionVoteScoring Product Selection Data Entry Product Configuration Product Selection Collaterals Registration Collaterals Evaluation Scoring Rating Product Configuration Product Selection Entry in Land Register Collaterals Evaluation Scoring Collaterals Acquisition Get Signature Vote Payment Data Entry Check Contract Decision Processes Functions Copyright © William El Kaim 2016 48
  49. 49. Functions – The New View • Within a traditional bank, operations are captured in 5 areas • Develop Product / Service • Generate Demand • Fulfill Demand • Plan & Manage the Enterprise • Collaboration • Outside of the bank, external entities are shown • Customers and Suppliers/Partners • Service Providers • Channel Partners • Regulatory Institutions 1. Develop Product / Service 2. Generate Demand 5. Collaboration 3. Fulfill Demand 4. Plan & Manage Enterprise Business Partners Service Providers Regulatory Institutions Customer Facing Channel Partners Banking BusinessCustomers Copyright © William El Kaim 2016 49
  50. 50. Functions – The New View • Within the traditional bank, operations are captured in 5 areas • Develop Product / Service • Generate Demand • Fulfill Demand • Plan & Manage the Enterprise • Collaboration • Outside of the bank, external entities are shown • Customers and Suppliers/Partners • Service Providers • Channel Partners • Regulatory Institutions Copyright © William El Kaim 2016 50
  51. 51. 1. Develop Product / Service 2. Generate Demand 5. Collaboration 3. Fulfill Demand 4. Plan & Manage Enterprise Suppliers Logistics Providers Financial Service Providers Customer Facing Channel Partners Enterprise 1.1. Develop Product / Service 2.1. Partner Relationship Mgmt. 2.2. Marketing 2.3. Sales 5.1. Strategic Collaboration 5.2. Planning Collaboration 5.3. Operational Collaboration 4.1. Financial Management 4.2. Project Management 4.3. Human Resources 4.4. Property and Advisory 3.1. Provide Service 3.2. Advanced Planning 3.3. Procurement 3.4. Produce Product 3.5. Logistics Level 2 3. Fulfill Demand 3.3 Procurement Module Map Decomposition Copyright © William El Kaim 2016 51
  52. 52. 5. Collaboration 3. Fulfill Demand 4. Plan & Manage Enterprise Suppliers Logistics Providers Financial Service Providers 3.1. Provide Service 3.2. Advanced Planning 3.3. Procurement 3.4. Produce Product 3.5. Logistics 3.3.1 Sourcing and Supplier Contract Management 3.3.3 Receiving of Indirect / Capital Goods and Services 3.3.2 Purchasing Level 3 3. Fulfill Demand 3.3 Procurement 3.3.2 Purchasing Module Map Decomposition 1. Develop Product / Service 2. Generate Demand Customer Facing Channel Partners Enterprise Copyright © William El Kaim 2016 52
  53. 53. Module Map Decomposition 5. Collaboration 3. Fulfill Demand 4. Plan & Manage Enterprise Logistics Providers Financial Service Providers 3.1. Provide Service 3.2. Advanced Planning 3.3. Procurement 3.4. Produce Product 3.5. Logistics 3.3.1 Sourcing and Supplier Contract Management 3.3.3 Receiving of Indirect / Capital Goods and Services 3.3.2 Purchasing 1. Develop Product / Service 2. Generate Demand Customer Facing Channel Partners Enterprise 3.3.2 Purchasing Level 4 3. Fulfill Demand 3.3 Procurement 3.3.2 Purchasing - Request Resources - Create Purchase Requisitions Request Resources Acquire/Purchase Resources Create Purchase Requisitions Purchase Direct Materials & Supplies Purchase Indirect Materials Purchase Outside Vendor Services Purchase Capital Goods Consolidate Approved Requisitions by Supplier Create Purchase Orders Choose or Default Supplier for Goods Manage RFI/RFQ/ RFP process Manage Open to Buy/Blanket POs Verify/ Negotiate Price Manage Requisition Approva Processl Perform Encumbrance Check Track Open POs Manage Suppliers Manage Supplier Relationships Track Supplier Commitments Maintain Supplier Catalog Manage Purchase Item Catalog Create Auction Bids Manage Automatic Replenish- ment Manage Purchasing Methods Approve & Validate Contract Payments Manage Buyer Performance Provide Supplier Self-Help Create Purchase Requisitions Copyright © William El Kaim 2016 53
  54. 54. Functional Plan Example: Reference Archi. For Banking Copyright © William El Kaim 2016 54
  55. 55. Functional Plan Example: BSI Bank Copyright © William El Kaim 2016 55
  56. 56. Functional Plan Example: Hospital (French) Copyright © William El Kaim 2016 56
  57. 57. Information Architecture • Defines the • Result of modeling the information that is needed to support the business processes and functions of the enterprise. • Data models, information flows, and an analysis of all inputs/outputs and decision- making criteria for each of the activities of the business. • Is often included in functional architecture • Maps with • The Information Architecture spans organizational boundaries and ties the business processes identified in the Business Architecture together by identifying and defining information dependencies. Copyright © William El Kaim 2016 57
  58. 58. Urbanization Rules • Determine functional block or capabilities uniqueness. • Define functional rules related to each functionality. • Define synchronization rules for each flow • Identifier triggering elements for entering or quitting a flow • Identify enrichment rules to define business process • Identify information or data used for from any transformation required during the end to end flow • Analyze flow volume and frequency • Identify Referential data (also called master data) Copyright © William El Kaim 2016 58
  59. 59. Functional Plan / Information Example: Geodis Copyright © William El Kaim 2016 59
  60. 60. Synthesis • Process are decomposed by successive step until business functions appear. • Business functions obtained could be automated or manual and can be common to several processes. • In term of granularity, a function could be macroscopic and call several application services for execution Copyright © William El Kaim 2016 60
  61. 61. Application Architecture • Defines the: • Solution framework focused on developing and/or implementing applications to fulfill the business requirements and to achieve the quality necessary to meet the needs of the business. • Technical standards, shared services, patterns, guidelines and templates for building and integrating applications, and data architecture to be deployed. • Data architecture of an application (database architecture, replication mechanism, data models, etc.). • Technologies required to support general infrastructure requirements (e.g., e-mail, file sharing, desktop computing) as well as hardware and software infrastructure for enterprise data and applications (e.g., DBMS, servers, networks, application server software, data warehousing, etc.). Copyright © William El Kaim 2016 61
  62. 62. Application Architecture • Defines the requirements for the “ilities” • Quality can be measured in terms of reliability, scalability, availability, performance, security, etc. • In addition to the structure and interrelationships of an individual application, Application Architecture also concentrates on optimizing and managing the integration of multiple applications. • Application Architecture is expressed in terms of principles and guidelines governing application design and evolution. • These principles and guidelines address the entire lifecycle of an application from initial development, through sustaining evolution and maintenance, to replacement or retirement. • Maps with • The relationship between the applications and the function/services of the IT Architecture Copyright © William El Kaim 2016 62
  63. 63. Application Architecture Urbanization Rules • Attach/ Mapping functionality and application or application components and services • Identify data flow between applications. • Identify non covered, redundant, partially or fully covered functionalities in applications • Identify processes gap les ruptures or incomplete application coverage. • Identify application common data. Copyright © William El Kaim 2016 63
  64. 64. Application Architecture Urbanization Rules Copyright © William El Kaim 2016 64
  65. 65. Application Architecture Urbanization Rules Copyright © William El Kaim 2016 65
  66. 66. Application Architecture Other Possible Urbanization Axis • Unify Repositories/registries (master data) • Defining and controling Data exchange: Replication, B2B, Backup • Application categorizations following reference architecture or specific framework • Application landscape rationalization • Standardization and control of interfaces • Identification of horizontal shared services • Exhaustive description of application dependencies • Clear description of link with Functional and Infrastructure layers Copyright © William El Kaim 2016 66
  67. 67. Application Architecture Example: Embraer Copyright © William El Kaim 2016 67
  68. 68. Application Architecture Example: Embraer Copyright © William El Kaim 2016 68
  69. 69. Operational Architecture • Also Named • Technical or Infrastructure Architecture • Defines • The technical foundations to support the applications, data, and business processes identified in the other three architectural layers. • Contracts like Service Level Agreement, Business Disaster Recovery Plan, etc. • Defines the tools and processes necessary to establish, monitor, manage and measure all aspects of the technology, application and data assets of the enterprise. Copyright © William El Kaim 2016 69
  70. 70. Operational Architecture • Identifies and plans the computing services that form the technical infrastructure for the enterprise. • These computing services provide the mechanism for achieving scalability, reliability, availability, flexibility, security, integrity, and performance. • The computing services are components which applications and infrastructure developers can utilize in the development, customization, and/or integration of applications in support of the business. Operations and service delivery processes like process framework (ITIL), Service Operational Procedure (SOP) • Must be aligned with the previous layers • The most difficult layer to adapt, the most expensive (recurring cost) and the most outsourced … • Green IT puts also some pressure on teams. Copyright © William El Kaim 2016 70
  71. 71. Product Architecture • Defines • A subset of operational Architecture • Standards and configurations for the enabling technologies and products within the Technical Architecture. • Applications and infrastructure developers utilize these technologies and products for delivering services to the applications and/or business processes. Copyright © William El Kaim 2016 71
  72. 72. Operational Architecture Examples Copyright © William El Kaim 2016 72
  73. 73. Example: Operations Center in 3D Source: EOLUS One island in Second Life Implenia facilities operations center Copyright © William El Kaim 2016 73
  74. 74. Example: IBM Center in 3D Copyright © William El Kaim 2016 74
  75. 75. Plan • What is Enterprise Architecture? • Enterprise Architecture vs. Application Architecture • Why Enterprise Architecture? • How to do Enterprise Architecture? • Enterprise Architecture Layers Deep Dive What is an Enterprise Architecture Framework? • Why Do I Need an Enterprise Architecture tool? • Could I build my own Enterprise Architecture Framework? • What is EA Governance? • Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 75
  76. 76. Why need an Enterprise Architecture Framework? • In a large modern enterprise, a defined framework is necessary to be able to capture a vision of the “entire organization” in all its dimensions and complexity. • Enterprise Architecture is a program supported by frameworks, which is able to coordinate the many facets that make up the fundamental essence of an enterprise at a holistic way. • That’s why architecture frameworks have become critical for enterprise architects. • Just like the old saying, “if you don’t know where you want to go, any road will take you there” Copyright © William El Kaim 2016 76
  77. 77. Enterprise Architecture Framework Objectives • Establish terms and concepts for architectural thinking and provide a uniform way to talk about Enterprise Architecture • Gain a 360-degree view across IT and development projects and propose real-time visibility to make rapid, well-informed decisions • Operationalize best practices and automate portfolio processes • Increase collaboration between Development and Service Delivery teams • Codify current best practices and insights of both the systems and software engineering communities • Promote (micro)Service or Resource Oriented Architecture Copyright © William El Kaim 2016 77
  78. 78. Framework(s) for EA A Standard Exist: ISO/IEC/IEEE 42010:2011 • IEEE 1471 is the short name for a standard formally known as ANSI/IEEE 1471-2000, Recommended Practice for Architecture Description of Software- Intensive Systems. • Within Institute of Electrical and Electronics Engineers (IEEE) parlance, this is a "recommended practice", the least normative of its standards. • In 2007 this standard was adopted by ISO/IEC JTC1/SC7 as ISO/IEC 42010:2007, Systems and Software Engineering -- Recommended practice for architectural description of software-intensive systems. • In 2011 it was superseded by ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description. Copyright © William El Kaim 2016 78
  79. 79. Framework(s) for EA Standard Exist: ISO/IEC/IEEE 42010:2011 • IEEE 1471's contributions can be summarized as follows: • It provides definitions and a metamodel for the description of architecture • It states that an architecture should address a system's stakeholders concerns • It asserts that architecture descriptions are inherently multi-view, no single view adequately captures all stakeholder concerns • It specifies the notions of view and viewpoint, where a viewpoint identifies the set of concerns and the representations / modeling techniques, etc. used to describe the architecture to address those concerns and a view is the result of applying a viewpoint to a particular system. • It establishes content requirements for architecture descriptions and the idea that a conforming architecture description has a 1-to-1 correspondence between its viewpoints and its views. • It provides guidance for capturing architecture rationale and identifying inconsistencies/unresolved issues between the views within an architecture description Copyright © William El Kaim 2016 79
  80. 80. Framework(s) for EA A Standard Exist: IEEE-Std-1471-2000 Source: IEEECopyright © William El Kaim 2016 80
  81. 81. Framework(s) for EA Most Used Frameworks Copyright © William El Kaim 2016 81
  82. 82. Framework(s) for EA: Some History … JTA DOD TRM C4ISR 1999 TOGAF 8.1 2003 DODAF 2003 Zachman 2003 FEAF 1999 IAF V3 2001 XAF 2003 E2AF 2003 FEAF 2003 TEAF 2000 TISAF 1997Adopted By Supported By Influenced Reference ISO/IEC 14252 Zachman 1987 TAFIM TOGAF 1995 EAP 1992 UVA Model 1994 IAF V1 1996 TOGAF 9 2009 TOGAF 10 2003 Copyright © William El Kaim 2016 82
  83. 83. Zachman Framework • The Zachman Framework, invented by John Zachman in the 1980s at IBM, is an enterprise ontology and is a fundamental structure for Enterprise Architecture thinking. • The ontology provides a formal and structured way of viewing and defining an enterprise using a two dimensional classification schema that reflects the intersection between two historical classifications. • The first are primitive interrogatives: What, How, When, Who, Where, and Why. • The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. • The Zachman Framework reification transformations are: Identification, Definition, Representation, Specification, Configuration and Instantiation. • The Zachman Framework is not a methodology in that it does not imply any specific method or process for collecting, managing, or using the information that it describes. Copyright © William El Kaim 2016 83
  84. 84. Zachman Framework IT centric Views Process centric Views View described by its viewpoint Source: ZachmanCopyright © William El Kaim 2016 84
  85. 85. TOGAF 9 • TOGAF was created and is maintained by The Open Group, an independent industry association. • It builds on an earlier framework known as TAFIM, or Technical Architecture Framework for Information Management, originally devised by the U.S. Defense Dept. In early 2009, The Open Group released TOGAF version 9. • The basic TOGAF 9 document contains descriptions of an architecture development method and related techniques, an architecture content framework, an enterprise continuum, TOGAF reference models and a capability framework. • Version 9 creates a model for extensibility, among other enhancements. Copyright © William El Kaim 2016 85
  86. 86. TOGAF 9 Source: Open GroupCopyright © William El Kaim 2016 86
  87. 87. TOGAF 9 Source: Open GroupCopyright © William El Kaim 2016 87
  88. 88. TOGAF 9 Source: Open GroupCopyright © William El Kaim 2016 88
  89. 89. Praxeme Semantic, Pragmatic, Geographic Logical, Software Model Technical,Physical and Material PRAXEME Use Praxeme as EA resilient Methodology and implement your project with the development process of your choice Source: PraxemeCopyright © William El Kaim 2016 89
  90. 90. Framework(s) for EA: Octo Techology IT centric views IT centric views Process centric Views Copyright © William El Kaim 2016 90
  91. 91. More Enterprise Architecture Frameworks… Source: PEFFCopyright © William El Kaim 2016 91
  92. 92. • An architecture framework does not include a methodology or process for enterprise architecture. • It also does not ensure that individual programs and projects fit into a global EA vision. • It does not explicitly recognize the importance of other enterprise IT dimensions and how they’re tied together • For example, the importance of architectural governances or the different ways of transitioning an enterprise. • It does not depend on particular tools What an Enterprise Architecture Framework is not? Copyright © William El Kaim 2016 92
  93. 93. • Each Framework has its own advantages and drawbacks • No framework tells you how and where to start and this is a big question • No framework tells you how to progress or to do it iteratively (methodology and/or EA Governance) • Some sources define a framework by describing what it contains (Togaf), and some define it describing what it does (Zachman). • Recommendations • Chose the one the easiest framework to evangelize to your project architects, CIO, developers, project managers. • Taylor it to your requirements and know what you are not yet covering. • Enhance it iteratively but do not change it each year (if possible) Conclusion: Framework(s) for EA Copyright © William El Kaim 2016 93
  94. 94. Plan • What is Enterprise Architecture? • Enterprise Architecture vs. Application Architecture • Why Enterprise Architecture? • How to do Enterprise Architecture? • Enterprise Architecture Layers Deep Dive • What is an Enterprise Architecture Framework? Why Do I Need an Enterprise Architecture tool? • Could I Build my own Enterprise Architecture Framework? • What is EA Governance? • Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 94
  95. 95. EA Tooling: Just For Drawing? • Enterprise architecture is a discipline that uses drawings and diagrams. • All real world EA contain lots of diagrams, and many are deemed central to the story being told. • This is because enterprise architecture is trying to represent n-dimensional data about businesses and systems in two dimensions. • Architects, engineers, and cartographers have worked for centuries to do the same thing in their domains. • Graphical abstract representations of complex relations are vital if we are to understand, explain, and control IS environments. Copyright © William El Kaim 2016 95
  96. 96. • Establish a common “culture” globally and aligning to best practices, IT policies and business strategy • Architecture Governance • Project Development Methodology • Centralized Documentation • Minimize risks due to local centric architecture choices, for the projects and for the company IT environment • Technical Standards • Leverage common solutions, reduce overall cost and maximize coherence and synergy across systems and development platforms • included software promotion and change management control • Reference Architecture and Building blocks (Service) EA Tooling Benefits Copyright © William El Kaim 2016 96
  97. 97. • Facilitate alignment and integration across projects • Pattern and Best Practices • Design and implement common, continuous and end to end Quality System and SLA • Better management of software supplier • Better management of Operational Practices (ITIL) • Rationalization of operations architecture • Better knowledge of software landscape • Application Portfolio Management • The direction provided by vision and the as-is condition provided by context allow IT and the business to orchestrate the work that will accomplish the long-term vision (To-BE) EA Tooling Benefits Copyright © William El Kaim 2016 97
  98. 98. EA Tooling: Adopt a Layered Vision Service and Functional Plan Infrastructure Plan Application Plan The Business Vision, goals and processes Business objects, capabilities, services, functions, etc. The Application and Data Technical Design The description of the Technical Infrastructure Business Process Plan TOP DOWN Copyright © William El Kaim 2016 98
  99. 99. EA Tooling: Do Not Forget the Mappings! • Business Vision • A process is triggered by events. • Can be within an business activity or transversal. • A process is composed of operations or successive tasks • A process can be seen as realized by functions. • Functional Vision • Tasks are realized by functions set grouped by domain/functionality. • Tasks creates or use information. • Application Vision • Function and information are materialized through application components running on technical architecture Event Copyright © William El Kaim 2016 99
  100. 100. • Each EA tool comes with • A central repository • A metamodel that can be already hard-coded or open • A script language to navigate inside the metamodel • An meta-editor to create objects and relationships within diagram • An editor for architect to describe their models and make simulation and impact analysis • An import/export tool • An administration tool • Complementary modules to generate static web site or to offer a dynamic web access to the repository. • Frameworks that can be obtained freely or bought. EA Tooling: How are they built? Copyright © William El Kaim 2016 100
  101. 101. Ex. Togaf and Tooling Copyright © William El Kaim 2016 101
  102. 102. EA Tooling: Where Are We In 2016? Copyright © William El Kaim 2016 102
  103. 103. • EA modeling tools are mature • Most of them are coming with ready to use metamodels that you can more or less extend and customize. • Two kinds of tools • The ones needing architect to draw: Mega, Casewise, Software AG, Abacus • The ones following a portfolio management approach (ERP for IT): LeanIX (SaaS) • What is difficult is to: • Load all information and ensure coherence and traceability through time and models • Model exhaustively all views • Ensure people model the same way • Provide output from central repository (Office documents, web site) • Control the operational cost of EA tool over the years (version update, maintenance, etc.) EA Tooling: Where Are We In 2016? Copyright © William El Kaim 2016 103
  104. 104. Ex. LeanIX Source: LeanIXCopyright © William El Kaim 2016 104
  105. 105. Ex. LeanIX Source: LeanIXCopyright © William El Kaim 2016 105
  106. 106. Ex. LeanIX Source: LeanIXCopyright © William El Kaim 2016 106
  107. 107. Plan • What is Enterprise Architecture? • Enterprise Architecture vs. Application Architecture • Why Enterprise Architecture? • How to do Enterprise Architecture? • Enterprise Architecture Layers Deep Dive • What is an Enterprise Architecture Framework? • Why Do I Need an Enterprise Architecture tool? Could I Build my own Enterprise Architecture Framework? • What is EA Governance? • Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 107
  108. 108. Could I build my own Enterprise Architecture Framework? • Yes … • Use the IEEE-Std-1471-2000 • Follow these steps • Define your EA Information Model (metamodel) • Define your Views • Implement your framework in a tool Copyright © William El Kaim 2016 108
  109. 109. Define the EA Information Model (Metamodel) • Example describing the key elements of the technical architecture • Described in UML class diagram (class attributes are not described for the sake of clarity) • An application • Has a component architecture (N-Tiers) • Is reusing shared service (business or IT and framework) • Is composed of Software Standard • Is composed of Software Products (Not Standard) • Has software component deployed on several environments Copyright © William El Kaim 2016 109
  110. 110. Define your Views • Depending on your concerns and what you need to describe for specific stakeholders. • Example describing two different set of views : • Canonical views • Aggregated views reusing information from canonical views Copyright © William El Kaim 2016 110
  111. 111. Ex: Native Artifacts Managed in Mega • Software • Application: Custom build or bought software component • Service: Elementary software function that realize a task in order to offer a service to other software component. A service could be public or private. • Hardware • Server. Hardware machine deployed in a datacenter within a specific environment • Database • Site. Used for describing any CWT datacenter. Copyright © William El Kaim 2016 111
  112. 112. Ex: Extended Attributes for Application Application family Application Lifecycle Copyright © William El Kaim 2016 112
  113. 113. Implement your framework in tools View: Application Context (data flow and interfaces) Building this View: Application is seen as a black box and only external relationships/message exchanged with actors and applications are shown. Mega Mega CaseWise Copyright © William El Kaim 2016 113
  114. 114. Implement your framework in tools << N-Tiers Architecture >> N-Tiers Architecture << N-TiersArchitecture >> Access Services << N-TiersArchitecture >> Business Services << N-TiersArchitecture >> Integration Services << N-TiersArchitecture >> Storage Services << N-TiersArchitecture >> Infrastructure Services << N-TiersArchitecture >> Client Tool << N-TiersArchitecture >> Presentation Services Sybase Enterprise Server 12.5 Citrix Client ICA Execute Citrix Server Calls Calls Apache Tomcat Makes query Apache Proxy Internet Explorer Delphi Business Objects XI Client Execute Calls Business Objects XI Server Apache Axis Makes query Makes query Nagios Monitor View: Logical N-Tiers Architecture Building this View: Describe the N-tiers client server architecture and the technical flows between them based on “N-Tiers Architecture” city planning diagram. Mega CaseWise Copyright © William El Kaim 2016 114
  115. 115. Implement your framework in tools (UML) • Create a UML profile • And model Copyright © William El Kaim 2016 115
  116. 116. Plan • What is Enterprise Architecture? • Enterprise Architecture vs. Application Architecture • Why Enterprise Architecture? • How to do Enterprise Architecture? • Enterprise Architecture Layers Deep Dive • What is an Enterprise Architecture Framework? • Why Do I Need an Enterprise Architecture tool? • Could I Build my own Enterprise Architecture Framework? What is EA Governance? • Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 116
  117. 117. What is EA Governance? • EA governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. • EA governance typically does not operate in isolation, but within a hierarchy of governance structures, which, particularly in the larger enterprise, can include all of the following as distinct domains with their own disciplines and processes: • Corporate governance, Technology governance, IT governance, Architecture governance, Security Governance, etc. • Each of these domains of governance may exist at multiple geographic levels • global, regional, and local - within the overall enterprise. • EA governance is thus a broad topic, beyond the scope of an enterprise architecture framework! Copyright © William El Kaim 2016 117
  118. 118. What is EA Governance? • The main objectives of EA is finally to build a culture of knowledge sharing and reuse through a common language. • This should be done in an evolutionary, not a revolutionary, way, with a governance team acting in an operational environment with different scopes: • the global business and strategy scope, • the information systems scope, • and the projects scope. • Support should be provided using the right tooling at each level throughout the organization. • Organizations looking to achieve sustained compliance; to manage and document compliance, will benefit from adopting frameworks around which to build compliance. Copyright © William El Kaim 2016 118
  119. 119. EA Governance Could not be Done in Isolation! Copyright © William El Kaim 2016 119
  120. 120. EA Governance Could not be Done in Isolation! 3-5 Year Plan Project Portfolio Migration & Development Paths Project Driven Tactical Steps Enterprise Architects Progressively Implement The Vision, While Delivering Immediate Benefits The target (we might attain one day) Copyright © William El Kaim 2016 120
  121. 121. Frameworks Are Proliferating To Help With Governance Copyright © William El Kaim 2016 121
  122. 122. Frameworks Are Proliferating To Help With IT Governance • During the past five years, a number of frameworks, methodologies, and practices have been developed for or adopted by IT to better govern and manage performance. • Control objectives for information and related technologies (COBIT), IT Infrastructure Library (ITIL), International Organization for Standardization (ISO) 17799, CMM, PRINCE, MSP, PMBOK, the Balanced Scorecard, and Six Sigma. • It is very easy to get confused by the “alphabet soup” of alternatives, which can lead • to paralysis (you can’t make a decision) • or choosing one and then finding out later that it misses the mark. • Most of these frameworks are not mutually exclusive and are most effective when used in combination with one another. Copyright © William El Kaim 2016 122
  123. 123. Which Governance For Which Objectives? No manual cleansing afterwards and decreased interface time development Data modeling and managing changes, canonical formats, semantics, and ontologies Establish and maintain enterprise data model. Cleanse the data. Comply to regulations data security. Data governance Security and recovery planCOSO, ISO 17799Increase security and reduce risks.Security governance CIO dashboardCOBITIncrease the quality of service.Quality governance Release time accuracyRepository, librarian, “reuse” Increase business and/or IT flexibility and reusability. SOA governance Release time accuracy and planning accuracy TOGAF, TAFIMDecrease heterogeneity. Decrease project integration cost. Increase roadmap planning EA governance IndicatorsMethodologies or Processes ObjectivesIT governance Copyright © William El Kaim 2016 123
  124. 124. Which Governance For Which Objectives? Better project, resources visibility, and planning Project prioritization Increase IT/business alignment. Optimize limited IT ressource allocation. Project portfolio governance (PPM) IT management satisfaction and BU satisfaction Optimize IT ressources allocation. Manage demand prioritization. Application portfolio/life-cycle governance (APM) BU satisfaction and better planning Chargeback, APM+PPM+ITIL Let business drive priorities.Demand management User satisfactionITILImprove help desk response time and operations excellence. Operational IT governance IndicatorsMethodologies or Processes ObjectivesIT governance Copyright © William El Kaim 2016 124
  125. 125. IT Governance Frameworks • For the purpose of compliance in the IT world, there are three main frameworks • COBIT • ITIL • ISO/CEI 27000 series • Of course you can always build your own … • Or specialize the existing ones • Or take the one specialized by a consulting company for you. SECURE ISO/CEI 27000 series Copyright © William El Kaim 2016 125
  126. 126. Steer: COBIT • The primary framework for IT governance is COBIT (Control Objectives for Information and related Technology) • Produced by the Information Systems Audit and Control Association (ISACA) and its IT Governance Institute. • is now issued and maintained by the IT Governance Institute (ITGI) as a framework for providing control mechanisms over the information technology domain. • Now in its third edition, COBIT has been extended to serve as an IT governance framework by providing maturity models, critical success factors, key goal indicators, and key performance indicators for the management of IT. Copyright © William El Kaim 2016 126
  127. 127. Steer: COBIT • At the heart of COBIT are 34 high- level control objectives. • These control objectives are grouped into four main domains: • Planning and organization, • Acquisition and implementation, • Delivery and support, • Monitoring. • Corresponding to each of the 34 control objectives are 318 detailed control objectives Copyright © William El Kaim 2016 127
  128. 128. Steer: COBIT Maturity Model • COBIT Maturity Model provides a basis for assessing each of the functional areas from a basis of the definition and repeatability of each key process. • The key processes reviewed were assigned a maturity ranking of 0 to 5 as follows: • “0” Management is unaware of the need for process or control. • “1” Awareness exists that a process or control should be developed. • “2” Ad hoc (reactionary) management. A process exists and may have been performed several times, by at least 1 individual. • “3” A defined process exists. Initial development of performance metrics. • “4” Management is more proactive, utilizes performance metrics and follows best practices. • “5” Management is very proactive, optimally efficient, and setting/leading best practices. Copyright © William El Kaim 2016 128
  129. 129. Build: CMM • Capability Maturity Model is a development model created after study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. • CMM describes process maturity! • Intended to help software organizations improve the maturity of their software development processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software development processes. • Can be used to measure the maturity of IT processes (in conjunction with IT management frameworks such as ITIL to measure specific processes). Copyright © William El Kaim 2016 129
  130. 130. Build: CMM, PMBOK, Prince 2 • Whether an IT project involving software or hardware, or the implementation of a new project, frameworks could be used to describe a structure for successful project implementation. • The Project Management Body of Knowledge (PMBOK), first created by the Project Management Institute (PMI), describes the process elements of projects of all kinds in terms of inputs like documents, plans, tools, and techniques and outputs such as products. • PRojects IN Controlled Environments (PRINCE2) is a process-based method for effective project management. • Used extensively by the UK Government, PRINCE2 is also widely recognized and used in the private sector, both in the UK and internationally. • The PRINCE2 method is in the public domain, and offers non-proprietorial best practice guidance on project management. Copyright © William El Kaim 2016 130
  131. 131. Run: The IT Infrastructure Library (ITIL) • IT Infrastructure Library (ITIL) defines and leverages best practices for management and operations of IT organizations. • ITIL is a set of policies and concepts for managing information technology infrastructure, development, and operations. • ITIL describes the “what” part for an IT ops professional but does not describe the quality or how to improve processes. • ITIL v3, introduced in June 2007, has gone one step further and defined how IT should be working with the business in designing and transitioning services, whereas ITIL v2 was solely focused on operating services. • ITIL is the de facto-standard for IT operations professionals (datacenter management) • CMM is different from ITIL, as it focuses on the maturity of a process and describes the current maturity stage. With the knowledge of what stage an organization is in, a road map for adoption of ITIL processes can be plotted. Copyright © William El Kaim 2016 131
  132. 132. Secure: ISO/IEC 27000 Series • The ISO/IEC 27000-series comprises information security standards published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission(IEC). • also known as the 'ISMS Family of Standards' or 'ISO27k' for short • Download: http://standards.iso.org/ittf/PubliclyAvailableStandards/ • The series provides best practice recommendations on information security management, risks and controls within the context of an overall information security management system (ISMS), similar in design to management systems for quality assurance (the ISO 9000 series) and environmental protection (the ISO 14000 series). • In particular, the ISO/IEC 27002 provides best practice recommendations on information security management for use by those responsible for initiating, implementing or maintaining an ISMS. Copyright © William El Kaim 2016 132
  133. 133. Secure: Ten Key Controls of ISO/IEC 27002 Source: http://www.iso27001security.com/index.htmlCopyright © William El Kaim 2016 133
  134. 134. Plan • What is Enterprise Architecture? • Enterprise Architecture vs. Application Architecture • Why Enterprise Architecture? • How to do Enterprise Architecture? • Enterprise Architecture Layers Deep Dive • What is an Enterprise Architecture Framework? • Why Do I Need an Enterprise Architecture tool? • Could I Build my own Enterprise Architecture Framework? • What is EA Governance? Conclusion: Resilient and Agile EA Copyright © William El Kaim 2016 134
  135. 135. EA: Can the dream come true? Copyright © William El Kaim 2016 135
  136. 136. Embrace All Development Types • Greenfield development • Fun for developer, new projects, excitement • Brownfield development • Modernization, migration, maintenance • Eat all the innovation/new product budget • IT on diet – No more development • Maintenance mode only - terrible effects • Kill application • Yes you should … Copyright © William El Kaim 2016 136
  137. 137. Heart of Enterprise Architecture • Understand and document • My Information System patrimonial • Its organization, its structure • its components, its interactions • Its information managed and data exchanged • Its relationships with others (ecosystem and B2B dialects) • Manage • Analysis, KPI, IT Portfolio • Govern • Bring under control Cost, IS Performance and evolution risks Copyright © William El Kaim 2016 137
  138. 138. Resilient & Agile Enterprise Architecture • Understand and document • My Information System patrimonial • Its organization, its structure • its components, its interactions • Its information managed and data exchanged • Its relationships with others (ecosystem and B2B dialects) • Manage • Analysis, KPI, IT Portfolio • Govern • Bring under control Cost, IS Performance and evolution risks Deliver value with/to the business on time and on market (Tailored EA framework like eTom, Agile, Lean, MDx, xaaS, BPx, etc.) Agile and elastic platform and Infrastructure to support all architecture, “ilities” and deployment needs (ITIL, PaaS, Virtualization, SAN, etc.) Use EA as a control tower for assessing and ensuring resilience Copyright © William El Kaim 2016 138
  139. 139. Resilient & Agile Enterprise Architecture Strategy Technology Resilient & Agile EA Methodology, policies and rules should be applied at all layers Make EA more dynamic (not only static description) – requires new set of integrated tools Holistic Views Security data and Information Integration SOA Business Architecture Application Portfolio Application Architecture Technical Architecture Business Model Copyright © William El Kaim 2016 139
  140. 140. Twitter http://www.twitter.com/welkaim SlideShare http://www.slideshare.net/welkaim EA Digital Codex http://www.eacodex.com/ Linkedin http://fr.linkedin.com/in/williamelkaim Claudine O'Sullivan Copyright © William El Kaim 2016 140

×