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.

Effectiveness Of Service Oriented Architecture In Enterprise Architecture Fazlul


Published on

  • Be the first to comment

Effectiveness Of Service Oriented Architecture In Enterprise Architecture Fazlul

  1. 1. Comparative Analysis of EA Frameworks and Effectiveness of SOA in Enterprise Architecture<br />By: Md Fazlul Alam Chowdhury<br />
  2. 2. Topics Covered<br /><ul><li> Abstract
  3. 3. Introduction
  4. 4. Evaluation of EA Frameworks
  5. 5. EA Frameworks at a Glance
  6. 6. Comparison of EA Frameworks </li></ul> (with respect to their Supported Architecture, ADM, Artifacts, and Deliverables)<br /><ul><li> Effectiveness of SOA in EA Frameworks
  7. 7. Major Roadblocks of SOA in EA
  8. 8. Case Study implementing EA and SOA
  9. 9. Conclusion
  10. 10. Future Work</li></li></ul><li>Abstract<br />Enterprise Architecture has become increasingly popular in recent years and has become a standard way of defining the Enterprise<br />There are numerous Enterprise Architecture Frameworks available in the market of which TOGAF, DoDAF, FEAF, C4ISR, Zachman are the ones to be mentioned<br />This paper outlines the comparative study of EA Frameworks together with implementing SOA in EA<br />
  11. 11. Introduction (What is EA?)<br />What is an Enterprise? An Enterprise is an organization or cross organizational entity that supports the common set of goals, mission or objective<br />What is Enterprise Architecture? An enterprise architecture, or EA for short, is a means to describe the business processes and structures, and to ensure they work together as a smooth, cohesive unit<br />EA defines the enterprise in terms of its business process, technology architecture, services and infrastructure.<br />
  12. 12. Introduction (Why EA?)<br />Efficient and more Effective IT Operations <br />Reduced Redundancies and Complexities in All Sectors of IT Operations<br />Better ROI and avoid future Risk factors<br />Faster, Cheaper and Simpler Procurements<br />Ensuring that all the decisions made are aligned with corporate vision and objective<br />Ref:<br />
  13. 13. Introduction (EA Domains)<br />
  14. 14. Business Standards relate to standard practice in the Business Architecture domain, including standard processes, roles, responsibilities, organization models, etc. <br />Data Standards relate to standard practice in the Data Architecture domain, including standard data models, data governance models, etc. <br />Application Standards relate to standard practice in the Application Architecture domain, including standard applications, application types, and application functionality. <br />Technology Standards relate to standard practice in the Technology Architecture domain, including standard products, product types, and proper usage constraints for technologies. <br />Ref: TAGAF 9,<br />Introduction (EA Domains - Descriptions)<br />
  15. 15. Role of an Enterprise Architect<br />TOGAF or not TOGAF: Extending Enterprise, Architecture beyond RUP, Level: Introductory,VitalieTemnenco, Architect, WSIB<br />
  16. 16. Evaluation of EA Frameworks (i)<br />
  17. 17. Evaluation of EA Frameworks (ii)<br />
  18. 18. This section covers the overview of Enterprise Architecture Frameworks and their evaluation<br />EA Frameworks at a Glance<br />
  19. 19. Popular EA Frameworks<br />C4ISR and DoDAF<br /> - C4ISR stands for Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance<br /> - DoDAF stands for U.S. Department of Defence (DoD) Architecture Framework<br />FEAF<br /> - FEAF (Federal Enterprise Architecture Framework)<br />TOGAF<br /> - The Open Group Architecture Framework<br />Zachman<br />Ref: IBM,<br />
  20. 20. Zachman Framework™<br />Zachman Framework is an EA Framework which provides a structured way of defining an enterprise<br />Zachman's framework is basically a table of some rows and columns which builds two dimensional classification matrix based on the intersection of six communication questions (What, Where, When, Why, Who and How) and six rows representing different perspectives of different stakeholders at different levels<br />Zachman is not a methodology but ontology to describe the Enterprise<br />
  21. 21.
  22. 22. C4ISR Architecture Framework (CAF)<br />C4ISR stands for Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance<br />C4ISR provides a Quantitative Interoperating Model (QIM) for enabling seamless interconnection, effective intercommunication and dependable interoperation between heterogeneous components over the network<br />The C4ISR Architecture Framework Version 2.0 is a framework giving comprehensive architectural guidance for all of these related US Department of Defense (DoD) domains<br />
  23. 23. C4ISRViews<br />Operational View describes the operational elements, tasks, activities, information flows for a particular mission<br />Systems View describes associated systems and their interconnections and performance to the operational view and it’s requirements<br />Technical View describes the minimal set of rules governing the arrangements, interactions, and interdependence of system parts or elements of the system<br />
  24. 24. C4ISR Architectural Guidelines<br />Architectures should be built with a purpose in mind<br />Architectures should facilitate, not impede, communication among humans<br />Architectures should be relatable, comparable, and integratable across DoD<br />Architectures should be modular, reusable, and decomposable<br />
  25. 25. FEA Consolidated Reference Model 2.3<br />FEA stands for Federal Enterprise Architecture, which is a consolidated reference model which builds a comprehensive business-driven blueprint of the entire Federal government<br />Most complete version of FEA has been released in 2006<br />
  26. 26. FEA Core Principles<br />Business-driven: FEA is a business driven architecture which is aligned with government’s strategic plans and executive level direction<br />Proactive and collaborative: FEA has being adopted through active participation by the EA community in its development and use<br />Architecture improves the effectiveness and efficiency: An IT investment should not be made without the approval from the business<br />
  27. 27. FEA Reference Models<br />Performance Reference Model (PRM) is a Framework for Performance Measurement which provides the common measurements by allowing agencies to manage the business of federal government at a strategic level. Agencies EA and measuring the success of IT investments and impacts on strategic outcome are being justified by PRM.<br />Business Reference Model (BRM) provides a framework to facilitate a functional view of the LOBs or Line of Businesses including its internal operations, services which are independent of any agencies. BRM describes the federal government in common business areas and also promotes collaboration between government agencies.<br />Service Component Reference Model (SRM) provides a classification through which performance objectives can be met and support businesses. It identifies the horizontal and vertical business components of federal agencies, their IT investments and assets. SRM recommends service capabilities to support the reuse of business components.<br /> Technical Reference Model (TRM) enables the delivery of service components and capabilities through the categorization of standards and technologies. TRM is fully component driven, technical framework. <br />Data Reference Model (DRM) is a standard based framework that provides standard description and discovery of common data and promotion of uniform data management practices.<br />
  28. 28. DoDAF 2.0<br />DoDAF 2.0 was released in May, 2009 and was prescribed framework for US Department of Defense<br />It works as the comprehensive framework and conceptual model enabling the Architecture Department facilitating the ability to DoD managers at all levels to make key decisions more efficiently and effectively<br />
  29. 29. DoDAF 2.0 6 step process<br />Step 1: Determine Intended Use of Architecture<br />Step 2: Determine Scope of Architecture<br />Step 3: Determine Data Required to Support Architecture Development<br />Step 4: Collect, Organize, Correlate, and Store Architectural Data<br />Step 5: Conduct Analyses in Support of Architecture Objectives<br />Step 6: Document Results in Accordance with Decision-Maker Needs<br />
  30. 30. DoDAF Models<br />All Viewpoint (AV) <br />Capability Viewpoint (CV) <br />Data and Information Viewpoint (DIV) <br />Operational Viewpoint (OV) <br />Project Viewpoint (PV) <br />Services Viewpoint (SvcV) <br />Standard Viewpoint (StdV) <br />Systems Viewpoint (SV) <br />Ref:<br />
  31. 31. TOGAF 9<br />TOGAF 9 has been released in February, 2009<br />The Open Group Architecture Framework has been has been developed by the collaborative effort of 300 members<br />TOGAF is an enterprise framework that provides necessary methods and tools to assist acceptance, production, use, and maintenance of enterprise architecture<br />
  32. 32. TOGAF 9 Architectural Domains<br />Business Architecture: It defines the business strategy, governance, organization, and key business processes.<br />Data Architecture: It describes the structure of an organization's logical and physical data assets and data management resources.<br />Application Architecture: It provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.<br />Technology Architecture: describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.<br />
  33. 33. TOGAF 9 ADM<br />TOGAF Architecture Development Method provides a process for developing the architectures. TOGAF ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures<br />
  34. 34. TOGAF 9 ADM Phases<br />Preliminary Phase The definition of an Organization-Specific Architecture framework and principles. <br />Phase A: Architecture Vision includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals. <br />Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision. <br />Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures. <br />Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project. <br />Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. <br />Phase F: Migration Planning addresses the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan. <br />Phase G: Implementation Governance provides an architectural oversight of the implementation. <br />Phase H: Architecture Change Management establishes procedures for managing change to the new architecture. <br />Requirements Management examines the process of managing architecture requirements throughout the ADM. <br />
  35. 35. This section covers the basic comparisons of EA Frameworks with respect to their Supported Architecture, ADM, Artifacts, and Deliverables<br />Comparison of EA Frameworks<br />
  36. 36. Comparison of EA Frameworks (i)<br />EA Frameworks have been compared on the following EA Items<br />Supported Architecture : By Supported Architecture, we mean the coverage of EA in major Architecture Domains<br />Architecture Development Method: ADM stands for Architecture Development Method, which describes a method defining EA<br />Deliverables: EA Deliverables the produced outputs from EA Development Cycle<br />ViewPoints: Perspective from which view is taken. Ex. Stakeholder ViewPoint<br />
  37. 37. Comparison of EA Frameworks (ii)<br />Artifacts: Artifact represents an individual model of a system or solution, which could be re-used in variety of contexts. Generally, deliverables will contain artifacts and each artifact may exist in many deliverables<br />Building Blocks: Building blocks are tiny pieces of an Architecture that specifies the scope and approach that will be used to address a specific business problem<br />Architecture Repository: Provides the capability to link architectural assets to components of the Detailed Design, Deployment, and Service Management Repositories<br />
  38. 38. TOGAF – Supported Architecture<br />Business Architecture<br />Data Architecture<br />Application Architecture<br />Technology Architecture<br />
  39. 39. TOGAF – ADM<br />Preliminary Phase<br />Phase A: Architecture Vision<br />Phase B: Business Architecture<br />Phase C: Information Systems Architectures<br />Phase D: Technology Architecture<br />Phase E: Opportunities & Solutions <br />Phase F: Migration Planning<br />Phase G: Implementation Governance <br />Phase H: Architecture Change Management<br />Requirements Management<br />
  40. 40. TOGAF – Deliverables (i)<br />Architecture Building Blocks<br />Architecture Contract<br />Architecture Definition Document<br />Architecture Principles<br />Architecture Repository<br />Architecture Requirements Specification<br />Architecture Roadmap<br />Architecture Vision<br />Business Principles, Business Goals, and Business Drivers<br />Capability Assessment<br />Change Request<br />
  41. 41. TOGAF – Deliverables (ii)<br />Communications Plan<br />Compliance Assessment<br />Implementation and Migration Plan<br />Implementation Governance Model<br />Organizational Model for Enterprise Architecture<br />Request for Architecture Work<br />Requirements Impact Assessment<br />Solution Building Blocks<br />Statement of Architecture Work<br />Tailored Architecture Framework<br />Transition Architecture<br />
  42. 42. TOGAF – Artifacts (Preliminary & A)<br />Phase A<br />Catalogs: <br />No catalogs are defined to be created during Phase A. <br />Matrices: <br />Stakeholder Map matrix <br />Core diagrams: <br />Value Chain diagram <br />Solution Concept diagram <br />Extension diagrams: <br />No extension diagrams are defined to be created during Phase A. <br />Preliminary Phase<br />Catalogs: <br />Principles catalog <br />Matrices: <br />No matrices are defined to be created during the Preliminary phase. <br />Core diagrams: <br />No core diagrams are defined to be created during the Preliminary phase. <br />Extension diagrams: <br />No extension diagrams are defined to be created during the Preliminary phase. <br />
  43. 43. TOGAF – Artifacts (B)<br />Phase B<br />Core diagrams: <br />Business Footprint diagram <br />Business Service/Information diagram <br />Functional Decomposition diagram <br />Product Lifecycle diagram <br />Extension diagrams: <br />Goal/Objective/Service diagram <br />Use-case diagram <br />Organization Decomposition diagram <br />Process Flow diagram <br />Event diagram <br />Phase B<br />Catalogs: <br />Organization/Actor catalog <br />Driver/Goal/Objective catalog <br />Role catalog <br />Business Service/Function catalog <br />Location catalog <br />Process/Event/Control/Product catalog <br />Contract/Measure catalog <br />Matrices: <br />Business Interaction matrix <br />Actor/Role matrix <br />
  44. 44. TOGAF – Artifacts (C)<br />Phase C – Application Architecture<br />Catalogs: <br />Application Portfolio catalog <br />Interface catalog <br />Matrices: <br />System/Organization matrix <br />Role/System matrix <br />System/Function matrix <br />Application Interaction matrix <br />Core diagrams: <br />Application Communication diagram <br />Application and User Location diagram <br />System Use-Case diagram <br />Extension diagrams: <br />Enterprise Manageability diagram <br />Process/System Realization diagram <br />Software Engineering diagram <br />Application Migration diagram <br />Software Distribution diagram<br />Phase C – Data Architecture<br />Catalogs: <br />Data Entity/Data Component catalog <br />Matrices: <br />Data Entity/Business Function matrix <br />System/Data matrix <br />Core diagrams: <br />Class diagram <br />Data Dissemination diagram <br />Extension diagrams: <br />Data Security diagram <br />Class Hierarchy diagram <br />Data Migration diagram <br />Data Lifecycle diagram <br />
  45. 45. TOGAF – Artifacts (D & E)<br />Phase E<br />Catalogs: <br />No catalogs are defined to be created during Phase E. <br />Matrices: <br />No matrices are defined to be created during Phase E. <br />Core diagrams: <br />Project Context diagram <br />Benefits diagram <br />Extension diagrams: <br />No extension diagrams are defined to be created during Phase E. <br />Phase D<br />Catalogs: <br />Technology Standards catalog <br />Technology Portfolio catalog <br />Matrices: <br />System/Technology matrix <br />Core diagrams: <br />Environments and Locations diagram <br />Platform Decomposition diagram <br />Extension diagrams: <br />Processing diagram <br />Networked Computing/Hardware diagram <br />Communications Engineering diagram <br />
  46. 46. TOGAF – Artifacts (Requirement Management)<br />Requirements Management<br />Catalogs: <br />Requirements catalog <br />Matrices: <br />No matrices are defined to be created during the Requirements Management phase. <br />Core diagrams: <br />No core diagrams are defined to be created during the Requirements Management phase. <br />Extension diagrams: <br />No extension diagrams are defined to be created during the Requirements Management phase. <br />
  47. 47. TOGAF – Building Blocks<br />Architecture Building Blocks<br />Characteristics<br />Define what functionality will be implemented <br />Capture business and technical requirements <br />Are technology aware <br />Direct and guide the development of SBBs <br />Specification Content<br />ABB specifications include the following as a minimum:<br />Fundamental functionality and attributes: semantic, unambiguous, including security capability and manageability <br />Interfaces: chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards) <br />Dependent building blocks with required functionality and named user interfaces <br />Map to business/organizational entities and policies <br />Solution Building Blocks<br />Characteristics<br />Define what products and components will implement the functionality <br />Define the implementation <br />Fulfil business requirements <br />Are product or vendor-aware<br />Specification Content<br />SBB specifications include the following as a minimum:<br />Specific functionality and attributes <br />Interfaces; the implemented set <br />Required SBBs used with required functionality and names of the interfaces used <br />Mapping from the SBBs to the IT topology and operational policies <br />Specifications of attributes shared across the environment (not to be confused with functionality) such as security, manageability, localizability, scalability <br />Performance, configurability <br />Design drivers and constraints, including the physical architecture <br />Relationships between SBBs and ABBs <br />
  48. 48. TOGAF – Architecture Repository<br />Architecture Metamodel: Describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content<br />Architecture Capability: Defines the parameters, structures, and processes that support governance of the Architecture Repository. <br />Architecture Landscape: Shows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications). The landscape is likely to exist at multiple levels of granularity to suit different architecture objectives<br />Standards Information Base: captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization <br />Reference Library: Provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise<br />Governance Log: Provides a record of governance activity across the enterprise<br />
  49. 49. DoDAF – Supported Architecture<br />Department-level [which includes Department, Capability & Component architectures] Architecture<br />Solution Architecture<br />
  50. 50. DoDAF – ADM<br />Step 1: Determine Intended Use of Architecture<br />Step 2: Determine Scope of Architecture<br />Step 3: Determine Data Required to Support Architecture Development<br />Step 4: Collect, Organize, Correlate, and Store Architectural Data<br />Step 5: Conduct Analyses in Support of Architecture Objectives<br />Step 6: Document Results in Accordance with Decision-Maker Needs<br />
  51. 51. DoDAF – Deliverables (i)<br />All ViewPoints<br />AV-1 Overview and Summary Information<br />AV-2 Integrated Dictionary<br />Capability Viewpoint (CV) <br />CV-1: Vision<br />CV-2: Capability Taxonomy<br />CV-3: Capability Phasing<br />CV-4: Capability Dependencies<br />CV-5: Capability to Organizational Development Mapping<br />CV-6: Capability to Operational Activities Mapping<br />CV-7: Capability to Services Mapping<br />Data and Information Viewpoint (DIV) <br />DIV-1: Conceptual Data Model<br />DIV-2: Logical Data Model<br />DIV-3: Physical Data Model<br />Operational Viewpoint (OV) <br />OV-1: High-Level Operational Concept Graphic<br />OV-2: Operational Resource Flow Description<br />OV-3: Operational Resource Flow Matrix<br />OV-4: Organizational Relationships Chart<br />OV-5a: Operational Activity Decomposition Tree<br />OV-5b: Operational Activity Model<br />OV-6a, 6b, 6c: Introduction<br />OV-6a: Operational Rules Model<br />OV-6b: State Transition Description<br />OV-6c: Event-Trace Description<br />Project Viewpoint (PV) <br />PV-1: Project Portfolio Relationships<br />PV-2: Project Timelines<br />PV-3: Project to Capability Mapping<br />
  52. 52. DoDAF – Deliverables (ii)<br />Systems Viewpoint (SV) <br />SV-1 Systems Interface Description<br />SV-2 Systems Resource Flow Description<br />SV-3 Systems-Systems Matrix<br />SV-4 Systems Functionality Description<br />SV-5a Operational Activity to Systems Function Traceability Matrix<br />SV-5b Operational Activity to Systems Traceability Matrix<br />SV-6 Systems Resource Flow Matrix<br />SV-7 Systems Measures Matrix<br />SV-8 Systems Evolution Description<br />SV-9 Systems Technology & Skills Forecast<br />SV-10a Systems Rules Model<br />SV-10b Systems State Transition Description<br />SV-10c Systems Event-Trace Description<br />Services Viewpoint (SvcV)<br />SvcV-1 Services Context Description<br />SvcV-2 Services Resource Flow Description<br />SvcV-3a Systems-Services Matrix<br />SvcV-3b Services-Services Matrix<br />SvcV-4 Services Functionality Description<br />SvcV-5 Operational Activity to Services Traceability Matrix<br />SvcV-6 Services Resource Flow Matrix<br />SvcV-7 Services Measures Matrix<br />SvcV-8 Services Evolution Description<br />SvcV-9 Services Technology & Skills Forecast<br />SvcV-10abc Introduction to SvcV-10a, SvcV-10b and SvcV-10c<br />SvcV-10a Services Rules Model<br />SvcV-10b Services State Transition Description<br />SvcV-10c Services Event-Trace Description<br />
  53. 53. DoDAF – Artifacts<br />AV-1 : Overview and Summary Information <br />AV-2 : Integrated Dictionary <br />OV-1 : High Level Operational Concept Graphic <br />OV-5 : Operational Activity Model <br />OV-2 : Operational Node Connectivity Description <br />OV-3 : Operational Informational Exchange Matrix <br />SV-1 : System Interface Description <br />TV-1 : Technical Standards Profile <br />
  54. 54. C4ISR – Supported Architecture<br />Operational Architecture<br />Systems Architecture<br />Technical Architecture<br />
  55. 55. C4ISR – ADM<br />Step 1: Determine Intended Use of Architecture<br />Step 2: Determine the architecture’s scope, context, environment, and any other assumptions to be considered<br />Step 3: Based on the intended use and the scope, determine which characteristics the architecture needs to capture<br />Step 4: Based on the characteristics to be displayed, determine which architecture views and supporting products should be built<br />Step 5: Build the requisite products<br />Step 6: Use the architecture for its intended purpose<br />
  56. 56. C4ISR – Deliverables<br />All ViewPoint (Context)<br />AV-1 Overview and Summary Information<br />All ViewPoint (Terms)<br />AV-2 Integrated Dictionary<br />Operational Viewpoint (OV) <br />OV-1 High-level Operational Concept Graphic<br />OV-2 Operational Node Connectivity Description<br />OV-3 Operational Information Exchange Matrix<br />OV-4 Command Relationships Chart<br />OV-5 Activity Model<br />OV-6a Operational Rules Model<br />OV-6b Operational State Transition Description<br />OV-6c Operational Event/Trace Description<br />OV-7 Logical Data Model<br />Systems Viewpoint (SV) <br />SV-1 Systems Interface Description<br />SV-2 Systems Communication Description<br />SV-3 Systems Matrix<br />SV-4 Systems Functionality Description<br />SV-5 Operational Activity to System Function Traceability Matrix<br />SV-6 Systems Information Exchange Matrix<br />SV-7 Systems performance Parameters Matrix<br />SV-8 Systems Evolution Description<br />SV-9 Systems Technology Forecast<br />SV-10a Systems Rules Model<br />SV-10b Systems State Transition Description<br />SV-10c Systems Event/Trace Description<br />SV-11 Physical Data Model<br />Technical Viewpoint (TV) <br />TV-1 Technical Architecture Profile<br />TV-2 Standards Technology Forecast<br />
  57. 57. C4ISR – Artifacts (i)<br />Command Relationships Chart (OV-4)<br />Activity Model (OV-5)<br />Operational Activity Sequence and Timing Descriptions (OV-6a, 6b, and 6c)<br />Logical Data Model (OV-7)<br />Systems Communications Description (SV-2)<br />Systems Matrix (SV-3)<br />Systems Functionality Description (SV-4)<br />
  58. 58. C4ISR – Artifacts (ii)<br />Operational Activity to System Function Traceability Matrix (SV-5)<br />System Information Exchange Matrix (SV-6)<br />System Performance Parameters Matrix (SV-7)<br />System Evolution Description (SV-8)<br />System Technology Forecast (SV-9)<br />System Activity Sequence and Timing Descriptions (SV-10a, 10b, 10c)<br />Physical Data Model (SV-11)<br />Standards Technology Forecast (TV-2)<br />
  59. 59. FEAF – Supported Architecture<br />Enterprise architecture<br />Segment architecture <br />Solution architecture<br />
  60. 60. FEAF – ADM (Reference Model Based)<br />Performance Reference Model<br />Business Reference Model<br />Service Component Reference Model<br />Data Reference Model<br />Technical Reference Model<br />
  61. 61. FEAF – Deliverables<br />DRM provides a high-level overview of the structure, usage, and data-identification constructs Which:<br />Provides an introduction and high-level overview of the contents that will be detailed in Volumes 2-4 of the model<br />Provides the basic concepts, strategy, and structure to be used in future development. <br />
  62. 62. FEAF – Artifacts<br />BRM Artifacts:<br />Services For Citizens <br />Mode of Delivery <br />Support Delivery of Services <br />Management of Government Resources <br />SRM Artifacts:<br />Customer Services <br />Process Automation Services <br />Business Management Services <br />Digital Asset Services <br />Business Analytical Services <br />Back Office Services <br />Support Services <br />
  63. 63. Zachman – Supported Architecture<br />Information System Architecture<br />
  64. 64. Zachman – ADM<br />What - Data<br />How - Function<br />Where - Network<br />Who - People<br />When - Time<br />Why - Motivation<br />
  65. 65. Zachman – Deliverables<br />Zachman is a conceptual framework which provides outlines of building models:<br />Row 1- Scope<br />Row 2 – Enterprise Model<br />Row 3 – System Model<br />Row 4 – Technology Model<br />Row 5 – As-Built<br />Functioning Enterprise<br />
  66. 66. Zachman – Artifacts<br />Ref:<br />
  67. 67. This section covers the mapping of some EA frameworks<br />EA ADM Mapping<br />
  68. 68. TOGAF Vs. DoDAF (ADM)<br />Ref: The Open Group Architecture Framework (TOGAF) and the US Department of Defense Architecture Framework (DoDAF) ,Dr. Fatma Dandashi, MITRE Corporation <br />
  69. 69. Zachman Vs. DoDAF<br />Ref: <br />
  70. 70. This section covers the concept of SOA in Enterprise Architecture and it’s effectiveness<br />Effectiveness of SOA in EA<br />
  71. 71. What is SOA in EA?<br />Service Oriented Architecture (SOA) as an architectural style where it simplifies the business and interprets different parts of the business<br />SOA comprise a number of invocations of these different components, often in an event-driven or asynchronous fashion that reflects the underlying business process needs.<br />Correspondence between EA and SOA is necessary <br />SOA is more than architecture where SOA governance is needed as well as a transition map that allows enterprises to adopt it<br />Ref:<br />
  72. 72. Business Service and SOA<br />A business service operates as a boundary for one or more functions<br />A service in Service Oriented Architecture (SOA) terminology (i.e., a deployable unit of application functionality) which may implement or support a business service.<br />
  73. 73. SOA Advantages<br />SOA provides Business Services across platform<br />Services are Location Independent<br />Services are Independent of particular system or network<br />SOA is a loosely coupled approach <br />SOA Authentication and authorization support at every level <br />SOA provides dynamic connectivity to other services<br />
  74. 74. SOA Benefits<br />Portability<br />Reliability<br />Reusability<br />Lower Cost<br />Business Functionality are closer to Business Units<br />Reduces the need for custom development<br />
  75. 75. Major Roadblocks implementing SOA<br />Adopting SOA in multiple Line of Business or LOB is a trivial task<br />If not Addressed SOA risks in EA Governance , may end up with multiple silos in SOA solutions<br />Business Values need to be established through an enterprise methodology before adopting SOA<br />Need to develop a modeling framework though which a simplified view of SOA can be provided together with the transition plan from current Non-SOA to SOA <br />SOA instrumentation is required to research on post deployment aspects of SOA and thus presenting the KPIs to improve the engineering, operational, and the business aspects of SOA. <br />
  76. 76. Business-led SOA Vs. Developer –led SOA<br />Ref:<br />
  77. 77. SOA Solution Track<br />Ref:<br />
  78. 78. C4ISR SOA Model<br />Ref: The basic data elements of Service Oriented C4ISR Architecture Framework, Service View Description of A Service Oriented C4ISR Architecture Framework, Wang Lei & Luo Ai-min<br />
  79. 79. TOGAF Concepts mapped to SOA<br />Ref:<br />
  80. 80. DoDAF IERs [Information Exchange Requirements] and Service Mapping<br />Ref: A Service Oriented Architecture (SOA) Approach to Department of Defense Architecture Framework (DoDAF) Architecting<br />
  81. 81. Zachman SOEAF<br />Ref: Model Driven Approach to Service Oriented Enterprise Architecture, SedighehKhoshnevis†, Fereidoon Shams Aliee∗, PooyanJamshidi∗ †Shahr-e-Qods Branch of Islamic Azad University, ∗ShahidBeheshti University GC {s_khoshnevis , f_shams , p_jamshidi}<br />
  82. 82. We tried to apply EA defining a new enterprise and later mocked up the system using SOA <br />Case Study - TechPlanet<br />
  83. 83. TechPlanet – A Case Study<br />SaleExpress is an online product sales and delivery company based in North America<br />FastCourier is a world-wide Packaging, Distribution and Logistics Company based in Asia<br />EzyPay is a Financial Company based in Europe<br />SaleExpress recently merged with FastCourier and EzyPay with a new name TechPlanet to establish TechPlanet as the leading online product sales and delivery company across the globe within two years<br />
  84. 84. How EA can play a vital role?<br />Setup TechPlanet Goals or Define Corporate Goals<br />Define benefits of EA in TechPlanet<br />Define EA Principles and Governance<br />Find out Critical Business Problems and Proposed Solutions<br />Find Out Major Constraints<br />Define Proposed Project Scope<br />Define EA<br />
  85. 85. TechPlanet Goals<br />Establish TechPlanet as the leading online product sales and delivery company across the globe within two years<br />Reduce Cost<br />Increase Revenue<br />Improve Customer Service<br />
  86. 86. EA Benefits<br />More Efficient and Transparent System (Improve Productivity, Increased Interoperability and Portability, Reusability, Reduced Redundancy, Lower Cost)<br />Better ROI (Reduced Complexity and Risk, Reduced Development, Implementation and Maintenance Cost)<br />Faster, Cheaper and Simpler Procurement<br />Efficient Maintenance<br />
  87. 87. EA Principles and Governance<br />Global Governance<br />Board<br />European Governance Team<br />Asian Governance Team<br />North American Governance Team<br />
  88. 88. Governance Approaches<br />Governance areas<br /><ul><li>Corporate Governance
  89. 89. Technology governance
  90. 90. IT governance
  91. 91. Architecture governance</li></ul>Governance Principles<br /><ul><li>EA should be aligned with Corporate Governance
  92. 92. Central Governance Board with Distributed Governance Teams</li></li></ul><li>Critical Business Problems<br />Multiple Companies with Multiple Systems and Work Ethics<br />Multiple Line of Business Systems<br />Multiple HR<br />Different KPI for different Companies<br />Lac of Experience in International Market<br />System and Functional Redundancy<br />Outdated infrastructure<br />Inefficient IT Operation<br />Inconsistent route management<br />
  93. 93. Proposed Solution<br />Establish Local Governance with alignment of Corporate Governance<br />Establish a unified Package Delivery and Pickup Model<br />Establish a unified Payment model<br />Establish a unified Financial Model<br />Establish a company wide IT standard<br />Establish an infrastructure refresh program<br />Establish a central routing model<br />
  94. 94. Major Constraints<br />Two Years to place TechPlanet as the leading online product sales and delivery company across the globe<br />Limited funding and Resources<br />Different personnel and work ethics for three different companies and internationally located countries<br />
  95. 95. Stakeholder Map<br />
  96. 96. Goals/Objectives/Services Diagram<br />
  97. 97. Solution Concept Diagram<br />Online Sales System<br />Payment Processing System<br />Package and Delivery System<br />Service Visibility <br />and <br />GPS Based <br />Fleet Tracking<br />Control<br />Simplify<br />Business Operations<br />System Operations<br />Transportation Management<br />
  98. 98. Communication Diagram<br />
  99. 99. Proposed IT Development Framework<br />.NET Framework 4.0 for Online Web Services<br />SAP as the System of Record for Order Processing, HR, Vendor Management<br />BizTalk for Middleware Platform that acts as the intermediary bus to communicate with Available Services, Internal/External Agents, SAP and thus process requests<br />
  100. 100. TechPlanet Business Services<br />Online Sales<br />Financial Processing<br />Packaging<br />Delivery<br />
  101. 101. IT Services implementing SOA<br />User Authentication<br />Online Sales Processing<br />Payment Processing<br />Package Delivery and Tracking<br />Accounting<br />
  102. 102. TechPlanet Implementing SOA<br />
  103. 103.
  104. 104.
  105. 105.
  106. 106.
  107. 107.
  108. 108.
  109. 109.
  110. 110.
  111. 111.
  112. 112. How effective SOA is defining EA?<br />SOA can be applied to the full spectrum of enterprise business and IT, which include business service specification, IT strategic planning, enterprise architecture, solution development, and business operation<br />SOA can be considered as a practical modeling approach for enterprise architecture (EA) development<br />EA benefits are aligned with SOA benefits (Reusability, Portability, Efficiency, Non-Redundant IT operation )<br />
  113. 113. Conclusion<br />DoDAF V2.0 and TOGAF 9 both provide a elaborative and practical design on enterprise architectures<br />The Zachman Framework provides a formal and highly structured way of defining an enterprise but TOGAF/DoDAF support needs for stakeholders perspective by supporting various levels of abstraction and granularity. Zachman pretty much focused on IT Architecture<br />The FEA Practice Guidance uses a segment architecture approach that allows critical parts of the overall Federal Enterprise, called architectural segments, to be developed individually, while integrating these segments into the larger Enterprise Architecture<br />Found TOGAF more concrete defining the EA through it’s ADM Phases. TOGAF defines Governance areas, Architecture Domains, Architecture Landscapes, Capability Maturity Model clearly and provides more elaborative EA Framework<br />SOA plays vital role defining EA. Examining the SOA as a business opportunity and can be looked into it deeply to make the services more efficient, portable and reusable<br />Case study shows us how can we solve a business problem using EA and how can it be transformed to SOA and provide <br />
  114. 114. Future Work<br />It would be really beneficial if we could rank the EA Frameworks for a particular business case or type and thus show the effectiveness of EA Frameworks based on their ranks<br />Working a EA Framework Benchmarking tool which covers different perspectives, businesses, governance and views<br />
  115. 115. References<br />Supporting A Service-Oriented Architecture, Derek T. Sanders J.A. Hamilton, Jr., Ph.D. Richard A. MacDonald, Ph.D., Computer Science & Software Engineering RAM Laboratories, Inc., Auburn University 10525 Vista Sorrento Pkwy, Auburn, Alabama 36849 San Diego California 92121, ,<br />Evaluation of Current Architecture Frameworks, Susanne LeistGregorZellner, University of Regensburg, Institute of Information Management, Universitätsstraße 31, 93040 Regensburg, Germany, +49 941 943 3201, {Susanne.Leist | Gregor.Zellner}<br />Establishing and Maintaining Compatibility in Service, Oriented Business Collaboration, Bart Orriëns, Dept of Information Management,Tilburg University,PO BOX 90153, 5000 LE, Tilburg, The Netherlands,+31 466 2779,,Jian Yang, Department of Computing,Macquarie University, NSW, 2109,Sydney, Australia,+61 2 9850 9584,<br />One Size Does Not Fit All—A Contingency, Approach to Data Governance, KRISTIN WEBER, BORIS OTTO, and HUBERT ¨OSTERLE, University of St. Gallen<br />The Open Group,<br />Service oriented architectures: approaches, technologies and research issues, Mike P. Papazoglou · Willem-Jan van den Heuvel<br />Enterprise Architecture in the Defense World,<br />FEAF,<br />DoDAF Frame work Version 2.0<br />A Comparative Analysis of Enterprise Architecture Frameworks based on EA Quality Attributes , Namkyu Lim1 Tae-gong Lee2, Sang-gun Park1, Korea<br />Model Driven Approach to Service Oriented Enterprise Architecture SedighehKhoshnevis†, Fereidoon Shams Aliee∗, PooyanJamshidi∗<br />Enterprise Service Oriented Architecture (ESOA) Adoption Reference, Yan Zhao, Ph.D., Director, Enterprise Architecture, CGI Federal<br />Service oriented architectures: approaches, technologies and research issues, Mike P. Papazoglou · Willem-Jan van den Heuvel<br />A Framework for Enterprise Resilience Using Service Oriented Architecture Approach, OzgurErol Mo Mansouri Brian Sauser,, School of Systems and Enterprises, Stevens Institute of Technology,Hoboken, NJ USA<br />