Introduction to enterprise architecture


Published on

Introduction to enterprise architecture

You will learn the difference between application architecture and enterprise architecture, but also how to create your own framework and build it in tools with Mega, casewise or UML.

Published in: Technology, Education

Introduction to enterprise architecture

  1. 1. Introduction to Enterprise Architecture 1
  2. 2. Disclaimer This presentation is a journey into the Enterprise Architecture world through my personal lens. My work as an innovator means I am used to trying, testing and imagining! I’m referring sometimes to external sources (links are provided) Course Given at La Rochelle University in France in 2009 2
  3. 3. Objective of this course Understand What is your IS patrimonial Its organization, its structure its components et its interactions Manage Analysis and KPI Projects Specifications Govern Bring under control Cost Risk, and IS risks Bring under control IS Performance Bring under control IS evolution 3
  4. 4. Plan AA vs. EA Enterprise Architecture Frameworks Top-Down or Bottom-up? EA process How to my Describe EA? Building Your Own Framework Example s with Mega / Casewise / UML On the road to resilient EA 4
  5. 5. Application architecture vs. Enterprise Architecture 5
  6. 6. Architecture Scope is twofold! AA vs. EA 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. •Local Scope •Low Granularity Project based decisions (Local) and delivery optimized within that context (Optimal) 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 •Global Scope •High Granularity Globally based solution, ensuring CWT Global architecture to be Coherent! Note: we assume here that the french concept of “Urbanisme” translates into “Enterprise Architecture” 6
  7. 7. Application Architecture Resources To Learn Coding Conventional wisdom (at least today) is that in the way you know how to read and write English, you need to have some understanding of the code that builds the Web and mobile. As a person who’s grown up in the digital age, You need to know how to code. “Those who code have the power to transform their dreams into reality.” “Coding will help you keep [your job], or help you make a case for a raise.” “You should learn to program because it’s easy, it’s fun, it will increase your skill set, and… it will fundamentally change your perspective on the world.” What’s more, “If you want to start a technology company,you should learn to code.” Program or be programmed… 7
  8. 8. Application Architecture Resources To Learn Coding MIT Courseware Online Intro to Computer Science & Programming class MIT and Harvard partnered up to create edX Codecademy uses a curriculum of exercises to teach the basics of coding in a variety of languages PHP Academy Coursera: offer online courses from myriad universities for free Khan Academy: an amalgam of Coursera and Codecademy Codingbat: simply a series of live coding problems GitHub, Pastebin, or SourceForge - It is a repository for coders to paste their personal code 8
  9. 9. More on Enterprise Architecture (EA) Framework or "blueprint" for how the organization achieves the business objectives at hand and in the future. The Enterprise Architecture looks at the key business, information, application, and technology strategies and their impact on business functions. Each of these strategies is a separate architectural discipline and Enterprise Architecture is the glue that integrates each of these disciplines into a cohesive framework. Strategies are built following business and IT principles, standards and best practices. 9
  10. 10. Architecture Scope is twofold! AA vs. EA Specific BU organization Specific BU organization EWITA = Enterprise Wide IT Architecture 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. Fixing technology solutions during the … Cost to fix Requirements phase 1 Architecture 5x Coding 10 x Unit/System Testing 20 x 11
  12. 12. Enterprise Architecture and App. Architecture should be aligned Governance City Planning EA (urbanisation) Business Process Business function Application landscape Standard Operational Architecture details Technical Architecture details Data Architecture details AA (Application architecture) Integration Architecture details Local Standards Common / Shared Remember! 12
  13. 13. EA Usage and Benefit Alignment Ensuring the reality of the implemented enterprise is aligned with management's intent 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 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) 13
  14. 14. CEISAR 14
  15. 15. Enterprise Architecture Frameworks 15
  16. 16. 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” 16
  17. 17. 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, wellinformed 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 Service Oriented Architecture 17
  18. 18. What an Enterprise Architecture Framework is not? 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 18
  19. 19. Framework(s) for EA A Standard Exist: IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems. 19
  20. 20. Framework(s) for EA Most Used Frameworks 20
  21. 21. Framework(s) for EA History … Zachman 1987 Zachman 2003 DOD TRM TAFIM DODAF 2003 C4ISR 1999 JTA ISO/IEC 14252 TOGAF 8.1 2003 TOGAF 1995 TEAF 2000 E2AF 2003 EAP 1992 Reference TISAF 1997 Adopted By Influenced Supported By UVA Model 1994 IAF V1 1996 FEAF 1999 FEAF 2003 IAF V3 2001 XAF 2003 21
  22. 22. Framework(s) for EA Zachman View described by its viewpoint Process centric Views IT centric Views 22
  23. 23. Framework(s) for EA - TOGAF The Open Group Architecture Framework Neutral Broad Acceptance Holistic Perspective. Process / Planning Tool Enterprise Architecture Development Methodology History in Defence Open Standard 23
  24. 24. TOGAF 9 24
  25. 25. TOGAF 9 25
  26. 26. TOGAF 9 26
  27. 27. Praxeme Free and French! PRAXEME Semantic, Pragmatic, Geographic Logical, Software Model Technical,Physical and Material Use Praxeme as EA resilient Methodology and implement your project with the development process of your choice 27
  28. 28. Framework(s) for EA: Octo Architectes bivalents technique & métier la double compétence permet d’analyser et de concevoir à un niveau général sans nécessité du détail, elle facilite la communication dans tous les univers (métier, MOA, MOE, production). Expertises techniques réalisation opérationnelle (savoir faire), engagement sur le terrain. Analyse par patterns recherche des formes structurantes et récurrentes du SI aux niveaux technique et métier. Compréhensible par tous, le pattern permet de mieux communiquer. Mise en place de communautés d’expertise, destinées à mieux partager le savoir-faire de la DSI. 28
  29. 29. Framework(s) for EA: Octo Process centric Views Octo (French Consulting Company) proposed Conceptual framework for IT urbanization IT centric views IT centric views 29
  30. 30. Framework(s) for EA CIO Council v.s. CIGREF Stratégie Business Métier Data IS Application Technology Source : CIO Council Référentiels Strategy Fonctionnel IS Application Technique Source : CIGREF 30
  31. 31. Framework(s) for EA Conclusion 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, and some define it describing what it does. 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) 31
  32. 32. Top-Down or Bottom-up? 32
  33. 33. General Architecture Processes Domain knowledge Product experience Quality requirements Architecture Design Top/Down Approach Architecture development Architecture description Assessment Application Architecture Recovery and Optimization Application Architecture Evolution Reengineering Bottom/Up Quality attributes Approach Design documents Code 33
  34. 34. Top-Down or Bottom-up? Two major approaches 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. 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 34
  35. 35. Top-Down or Bottom-up? Do not Forget Holistic Views! Strategy Business Process Security Integration Governance Etc. Function and Services Business Process Plan Service and Functional Plan Application Application Plan Holistic Views Infrastructure Operation and service delivery Infrastructure Plan Technology 35
  36. 36. The private sector and start-up favored the bottomup approach. It works well with the focus on quick tangible results. Positive aspects The program can have significant impact immediately. Cleaning up the technology architecture can be accomplished in 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. The technology-oriented starting point begins in IT’s sweet spot. 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 businessenabling. 36
  37. 37. The public sector and regulated business (finance) favored the top-down approach. Used to define and document business needs then align IT to them Positive aspects 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. Negative aspects 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. 37
  38. 38. Top-Down or Bottom-up? Top Down Approach Top-down 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. 38
  39. 39. Top-Down vs. Bottom-Up Example: Aventis Top down Bottom up Process re-designed Process re-designed New application developed to support standardised process Core modules developed to support standardised process Data migrated Core module progressively added "seamlessly" to existing landscape "Big bang" launch Existing landscape adapted as necessary All existing applications retired Applications retired on a case by case basis Top down approach is effective when : Bottom up approach is effective when : • Existing landscape is simple • System can be implemented and supported centrally • Strong business direction has been given • Country/site specifics are significant • Different functions are involved and moving at a different pace (priorities, budget, resources) Examples : HR Examples : SAP 39
  40. 40. 1. EA Process 40
  41. 41. EA Process Top Down Approach Business process Function / Service Strategy Business City Planning Design Business Strategy Existing Business Architecture Target Business Architecture Target Functional Architecture Functional Application Technical Constraints Existing Application Architecture Target Application Architecture 41
  42. 42. Management Urbanization Process Club URBA-EA The IS Urbanization process Drive the IS Urbanization process Participate in the projects arbitration committees Link IS urbanization with business strategy and IS governance Drive the implementation and the evolution of the master data repositories Participate in the upstream phases of the projects Standardize and simplify the exchanges between applications Support & Communication Elaborate and improve the IS urbanization framework (rules, principles, EA targets) Monitor the architecture of the IS projects Build the link with technical infrastructures Maintain and deploy the map repository for the existing and target IS (processes, applications, data, etc…) Communicate and train on IS Urbanization IS Urbanization plans Infrastructure basics Relationships with projects 42
  43. 43. EA Process Club URBA-EA Index 6. Urbanization management and communication 4 1. Knowledge of IS « as is » 3 2 5. Flows complexity management 1 0 4. IS building management 6 axis to understand IS urbanization maturity (with 2 to 4 criteria per axis) 2. Master data repositories management 3. Knowledge of IS « to be » TO BE AS IS 43
  44. 44. EA Process Example: Carlson Develop Core Business Architecture model Define “Current” Core Business Architecture Develop “Target” Core Business Architecture Develop roadmap Pre–HAL HAL Transition Before 31/12/04 Q1 ‘05 Q2 ’05 Q3 ‘05 OD Operational Data – Scope, Analysis, Design Q4 ‘ 05 Q1 ‘06 Q2 ‘06 Post-HAL Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07 Q3 ’07 and beyond Operation Data – Build Phase CIS HAL MI/PM Corporate Information System Scoping, Business Case, Analysis Corporate Information System Implementation GPMS Press Control Systems Implementation Group Planning Process and System Requirements Capture Group Planning Implementation CM Customer Management Benefits Assessment Customer Management Implementation Before 31/12/04 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 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) 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 Q1 ‘05 Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q2 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07 Q3 ’07 and beyond 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 44
  45. 45. How to Describe my EA? 45
  46. 46. How to Manage Enterprise Architecture? Map Offers a Framework For Urban Renewal Urban planning offers a useful analog on which to base a MAP program. In the IT/Business equivalent of urban renewal, CIOs work with business leaders to understand a future community (business) vision that will guide work over the coming years. IT staff create capability maps of the key business functions as the context and lexicon required to discuss the pending business change that will drive application change. 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) 46
  47. 47. How to Describe EA? Adopting a Layered Vision Business Process Plan The Business Vision, goals and processes Business objects, capabilities, services, functions, etc. Service and Functional Plan The Application and Data Technical Design Application Plan Infrastructure Plan The description of the Technical Infrastructure Plan / Layer / Architecture / landscape / etc. 47
  48. 48. How to Describe EA? What is important is the Mapping! Business Vision Event 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 48
  49. 49. How to Describe EA? Process vs. Functionally Driven Vision Functionally Driven Process Driven Roles and responsibilities are aligned by functional area. Roles and responsibilities are aligned by business process. Business leaders have little process visibility beyond their functional area. Business leaders have broad visibility of the end-to-end business process. Handoffs are implicit. Handoffs are explicit. Business rule changes rely on IT department to schedule changes to application code. Business rules and process steps are changed by business process owners. Cost accounting is aligned by functional area. Cost accounting is aligned by process steps. Risk analysis is led by business leader experience, intuition and data analysis. Risk analysis is led by simulations based on current operational conditions. 49
  50. 50. Building Your Own Framework 50
  51. 51. 1. Defining the EA Information Model 51
  52. 52. Defining the EA Information Model Introduction We defined a conceptual framework and some views related to it for enterprise architecture. In order to be able to implement it, we need information models. We need also to feed the information model with data, from existing (or not) information sources. Information Models and information (data) will be implemented in a repository 52
  53. 53. Defining the EA Information Model IEEE Standard: Viewpoints and models Called Information model in this document 53
  54. 54. Defining the EA Information Model Conceptual Framework Implementation Propose views on the model in order to fit to stakeholders' needs Specific model, reuse core model. Customizable and extensible Front End Application Specific Modelq Viewpoints CORE Models Application are based on predefined (or not) viewpoints CORE Model needed to ensure Coherence and enterprise-wide Traceability and impact analysis. Investment Protection 54
  55. 55. Defining the EA Information Model CORE (Meta)Model The CORE model is a pre-requisite for any IT landscape based project It has been implemented in Rochade The CORE model represent the nervous system of IT portfolio possible Front-end applications, guaranteeing thus a native traceability between all IT defined layers The CORE metamodel can be reuse globally or partially 55
  56. 56. Let’s take an example … myEA framework myEA framework is an example on how to design and implment your own framework. For the sake of simplicity we will take the example of the technical layers of EA. 56
  57. 57. myEA framework 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 A Shared Service Can be a business service, technical service or framework Is reusing service (business or IT or framework) Is composed of Software Standard Is composed of Software Products Has a component architecture (N-Tiers) Is deployed on several environments Is described by its service profile Its usage is governed by the service framework 57
  58. 58. myEA framework A software product Is describing tools bought or created to build the application that are not standard Is composed of other tools if it is a packaged software product (ex: Microsoft Office Suite) A software product is composed of software components Is categorized depending on is technical function Has a generic name Has specific components (deployed at run time) 58
  59. 59. myEA framework A software standard Describe a standard software product Has a profile (Word file) Is categorized depending on is technical function Contains information concerning standard lifecycle can have several kinds of dependency links like: Depend on, Incompatible with, Used for service, Replaced by, Exception is, etc. Software Standard Framework Is a shared service Is categorized depending on is technical function Has a generic name Has specific components (deployed at run time) 59
  60. 60. myEA framework Component Architecture Used for describing n-tiers client-server architecture Deployed software component Has a version Is deployed on a Hardware component Has communication ports Data center Are connected by Network link Are sustaining platform and environment 60
  61. 61. Let’s take an example … myEA framework 61
  62. 62. myEA framework Application Component Architecture description n-tiers N-tiers architecture Composed of / Dependency / Replaced by Component Architecture Test, Integration, Production Source Application Destination Application Interface consist of Application functional Interface Environment Software product is not standard but can become a standard is composed of Can be business service and/or technical service and/or framework Shared Service Software Product composed of / Dependency is composed of / dependency Composed of / Dependency has Has Software Standard as of today Software Standard Software Component Are related to standard or not Hardware Standard as of today Software Component 62
  63. 63. myEA framework N-tiers flows description n-tiers An Application Composed of / Dependency / Replaced by Application component flows architecture Component Architecture Source Application Destination Application Interface consist of Dependency links between n-tiers architecture and software components Environment is composed of Shared Service Software Product composed of / Dependency is composed of / dependency Composed of / Dependency has Has Software Standard Software Component 63
  64. 64. myEA framework Technical Service/Framework Description Component Architecture Shared Service has its own environment Application Shared Service has its own n-tiers architecture Shared Service is composed of software product Environment Service Country coverage Service Profile Country Coverage Shared Service Software Product Service Profile is composed of / dependency Service Framework Software Standard Service framework description (IT process) Shared Service is composed of software Standard 64
  65. 65. myEA framework Deployed Software component and flow Data Package Application Interface A functional interface is between internal Application (EAI) or external application (B2B) Format of data exchanged Hardware Component Technical Flow Technical interface (port, IP address, etc.) A Flow comprises interfaces (functional and technical), data exchanged and the type of flow (peer to peer, hub and spoke, pub/subscribe, etc.) Port Provide Use Software Component is deployed on Dependency Component deployed Deployed Software Component Protocol, Composed of 65
  66. 66. myEA framework Data center and LAN/WAN communications Network Link LAN/WAN link between data center Application Connected to DataCenter Data center description Contains Environment Hardware Component is composed of Shared Service platform (by country) and Environment (by type) 66
  67. 67. myEA framework Recommendations Information Model should be build first and adjusted depending on the conceptual framework used Information models and conceptual framework should be independent of tools Should be able to implement it in Mega, Visio, Rose or Rochade (and keep it in sync. with evolving information models specification) The Core Information model is required for all projects providing thus a common supply chain information nervous system Coherence and compatibility are ensured between viewpoints and conceptual framework 67
  68. 68. Defining the Information Model Takeaway Provide exhaustive description within the Information model of : Dependency/incompatibility between entities Software standards, services, etc. Cross reference between two entities Software components on hardware components Manage multiple granularity levels Application is composed of other applications Describe all needed conceptual framework and their relationships and/or granularity level PA and EA 68
  69. 69. 2. Defining the Views of myEA framework 69
  70. 70. Defining the Views of myEA framework AA Conceptual Framework 70
  71. 71. Defining the Views of myEA framework EA Conceptual Framework Aggregated Views Aggregated Views Relate and aggregate Relate and aggregate information from information from several canonical several canonical viewpoints viewpoints Canonical anonical C View View Services and events Application Portfolio Management Functional Architecture City Planning Map Domain Functional Decomposition Function and application Mapping and covrage 71
  72. 72. 3. What about Tools? 72
  73. 73. 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 ndimensional 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 our environments. So practitioners must understand some of the subtle but significant simplifications that the authors of these diagrams have made to get everything on one page. As a result, it is a godsend in communicating with high-level managers who have limited knowledge of business processes and technology, as well as short attention spans. 73
  74. 74. EA Tooling How are they built Each EA tool comes with A central repository (could be proprietary like Mega) A metamodel that can be already hard coded (Mega) or open (Casewise) 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. 74
  75. 75. EA Tooling Numerous Tools On The Market Nevertheless modeling by itself is useless (Visio Effect) Impact and risk analysis, simulation, and governance are not also supported “Which EA tool do you use to support your EA framework modeling and publishing approach?” 75
  76. 76. EA Tooling EA modeling tools are mature enough for the mainstream but still require decreasing operations costs with automatic data collection No EA modeling tool satisfies every user Scenario of a single modeling tool but with tradeoffs Scenario with multiple tools What is difficult is to Model exhaustively all plans Manage coherence and traceability through time and models Ensure people model the same way Provide output from central repository (Office documents, web site) 76
  77. 77. EA Tooling Things To Know Import and export functions remain weak points Some are still using a proprietary DBMS Metamodel customization is no longer a major differentiator Products are mature, the market is mature, but none of the vendors have a clear mid-term road map. The EA market follows the current wind. Support for both a Web-based architecture and standalone mode is a differentiator The criteria associated with change management make the difference. EA tool are now extended with Risk Management, Application Portfolio Management, and social communications 77
  78. 78. 4. Implementing in tools you model (Mega or Casewise) 78
  79. 79. Canonical Views Application Environment CWT Diagram Naming Building this View Application Environment Application is seen as a black box and only external relationships/message exchanged with actors and applications are shown Application External partner Mega 79
  80. 80. Canonical Views Application Tree CWT Diagram Naming Building this View Application Tree Describe all application from the family Application Family Applications Casewise 80
  81. 81. Canonical Views Application Technology CWT Diagram Naming Building this View Application Technology Describe all technologies used by an application following the Application Architecture city planning diagram Mega 81
  82. 82. Canonical Views Business and Technical Services CWT Diagram Naming Building this View Business and Technical Services Describe business services required/offered by the applications and the technical services Mega Casewise 82
  83. 83. Canonical Views Application N-tiers Architecture CWT Diagram Naming Application 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 Casewise 83
  84. 84. Aggregated Views Application Deployment Platforms CWT Diagram Naming Building this View Dev/Test/Pre-production/Production Deployment Platforms Describe datacenter and network connections between them Datacenter 2 Datacenter 1 Mega 84
  85. 85. Technical Standard View Technical Standards CWT Diagram Naming Building this View Technical Standard View Describe Standard Technical API and Frameworks Casewise 85
  86. 86. Example: EA Architecture Framework Enterprise Architecture Project Architecture Company Business Map Business Processes Map Business Processes Process(es) in scope Functions & Services Function(s) to be delivered Applications Map IS - IT Views Business context in scope City Planning IS & IT Views Business Views Business Organizations Application Landscape Application Context & Flows in scope Company Standards and Architecture Patterns Application & Data Architecture Logical & Technical Application & Data Architecture Company Infrastructure & Backbone Services Technical Infrastructure Application Infrastructure Operations & Operations & Services Delivery Services Delivery 86
  87. 87. Example: EA Architecture Framework City Planning Views in Mega What Framework to be used for mapping technologies or applications Mega Diagram City Planning Objects to be used Application Software Solution Software Suites Software Component Shared Services Service Description type Structural 87
  88. 88. City Planning Views in Mega IS Domain Model << IS Domain Model Framework >> << IS Domain Model Framework >> Business Process Security << IS Domain Model Framework >> << IS Domain Model Framework >> Services Quality << IS Domain Model Framework >> User Interface << IS Domain Model Framework >> Application & Data Logic << IS Domain Model Framework >> Application Technologies << IS Domain Model Framework >> Application & Data Integration << IS Domain Model Framework >> Data Technologies << IS Domain Model Framework >> Computing Platforms << IS Domain Model Framework >> Network Mega 88
  89. 89. City Planning Views in Mega Portal Framework << Portal Fram ework >> Presentation layer << Portal Fram ework >> << Portal Fram ework >> << Portal Fram ework >> Web Client WAP client PDA client << Portal Fram ework >> Portal Layer << Portal Fram ework >> << Portal Fram ework >> << Portal Fram ework >> << Portal Fram ework >> << Portal Fram ework >> Presentation Personalization Taxonomy Collaboration Content Management << Portal Fram ework >> << Portal Fram ework >> << Portal Fram ework >> Authentication User Mgt and Authorization Integration << Portal Fram ework >> Integration Layer << Portal Fram ework >> << Portal Fram ework >> << Portal Fram ework >> Messaging service Publish-Subscribe Service Web Services << Portal Fram ework >> << Portal Fram ework >> << Portal Fram ework >> << Portal Fram ework >> Authentication Source Structured data Unstructured Content Technology and Application Mega 89
  90. 90. City Planning Views in Mega SOA Framework << SOA Fram ework >> << SOA Fram ework >> << SOA Fram ework >> Management End User Services Security << SOA Framework >> Composite service << SOA Fram ework >> Business Service << SOA Fram ework >> Service Infrastructure << SOA Fram ework >> Enterprise Systems Mega 90
  91. 91. 5. Implementation in UML 91
  92. 92. Conceptual framework Application Architecture Conceptual Framework Aggregated Views Aggregated Views Relate and aggregate Relate and aggregate information from information from several canonical several canonical viewpoints viewpoints Security Architecture Deployment Architecture Application Application Internal Contex Logical (flow & Components interfaces) Application Data Application Infrastructure Business Continuity Canonical anonical C View View Application COTS Application n-tiers Technical Architecture Service Level Management 92
  93. 93. Implementation in UML Creating the UML profile Definition of all elements we would like to manage natively and that are not part of UML The ULML profile is based on the information model 93
  94. 94. Implementation in UML Creating the UML profile We can associate a specific icon to the UML element created ("stereotype") 94
  95. 95. Implementation in UML Creating the Views 95
  96. 96. Implementation in UML Application Data Flow Description 96
  97. 97. Implementation in UML Application Data Flow - Actors 97
  98. 98. Implementation in UML Application Data Flow - Interaction 98
  99. 99. Implementation in UML Application Data Flow - Communication 99
  100. 100. Implementation in UML Functional Interfaces Description 100
  101. 101. Implementation in UML Shared Service (Pattern) 101
  102. 102. Implementation in UML Shared Service – Catalog of services (Pattern ) 102
  103. 103. Implementation in UML Software Standard 103
  104. 104. Implementation in UML Software Product 104
  105. 105. Implementation in UML N-tiers Technical Architecture 105
  106. 106. Implementation in UML Data Center and their network 106
  107. 107. Implementation in UML Platform Description 107
  108. 108. Implementation in UML Environment Description 108
  109. 109. Application component description Internal Logical Component 109
  110. 110. Application component description Internal Logical Component 110
  111. 111. Conclusion about myEA! 111
  112. 112. Conclusion Metamodel and framework should be designed first and independently from the tool Then select your tool and use it as a knowledge Mgt tool Link it to developer wikis, continuous build platform, devops scripts Depending on the company core focus the framework may evolve From discovery of technical infrastructure and application landscape to information security and integration between company bricks. Documentation and training is key 112
  113. 113. EA in 2nd life (Michelin) Training in the Island 113
  114. 114. EA in 2nd life (Michelin) Teaching enterprise architects how to build roadmaps 114
  115. 115. On the Road to Resilient EA 115
  116. 116. IT Midlife Crisis World Economic Recession, IT is the first to suffer The timing of contractions in sectorlevel sales and EBITA indicates that the four most recent recessions began with a core underlying shock that then spread through the economy in a fairly predictable way. Three began with similar declines in the IT sector When real EBITA growth resumes in these sectors, it may be a useful indication that the economy is turning around. 116
  117. 117. What is Enterprise Architecture City Planning (Urbanisation des SI) 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 117
  118. 118. What is Enterprise Architecture City Planning (Urbanisation des SI) Understand and document My Information System patrimonial Its organization, its structure its components, its interactions Its information managed and data exchanged Deliver value with/to the business on time and on market (Tailored EA framework like eTom, Agile, Lean, MDx, xaaS, BPx, etc.) Its relationships with others (ecosystem and B2B dialects) Manage Analysis, KPI, IT Portfolio Govern Bring under control Cost, IS Performance and evolution risks Agile and elastic platform and Infrastructure to support all architecture, “ilities” and deployment needs (ITIL, PaaS, Virtualization, SAN, etc.) Resilient EA Use EA as a control tower for assessing and ensuring resilience 118
  119. 119. Resilient Enterprise Architecture Described via a layered approach Resilient EA Methodology, policies and rules should be applied at all layers Strategy Business Model Business Architecture Make EA more dynamic (not only static description) – requires new set of integrated tools Application Portfolio Holistic Views Application Architecture Security data and Information Integration SOA Technical Architecture Technology 119
  120. 120. Resilient Enterprise Architecture Some Deliverables Business Architecture (cartographie des métiers) Glossaire de termes Métier, Description des objets métiers Business (Métier) Function (Fonctionnelle) IS (Informatique) Process Architecture (cartographie des processus) Description des processus opérationnels, des activités, des objets métiers Functional Architecture (cartographie fonctionnelle) Plan d’occupation des sols Décomposition fonctionnelle Projection fonction/application schéma d’architecture logique Master data et référentiels Master Data Schéma de description des échanges Application Landscape (cartographie applicative) Couverture fonctionnelle de l’application schéma inter-applicatif schéma d’architecture logique Schéma conceptuel de données Application Architecture (cartographie architecture technique) Schéma d’architecture de contexte technique, de composants, de données applicatives, d’architecture technique (n-tiers, couches) Schéma de données techniques Infrastructure Architecture (cartographie architecture technique) Schéma d’architecture d’infrastructure, de déploiement Modèle d’information et règles de gestion Information and Data Architecture Organigramme, acteurs 120
  121. 121. EA – The dream! Comes true? 121
  122. 122. Linkedin Blog Twitter aim Travel 2.0 Contact: vl20 122
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.