1. Comparative Analysis of EA Frameworks and Effectiveness of SOA in Enterprise Architecture By: Md Fazlul Alam Chowdhury

3. Introduction

4. Evaluation of EA Frameworks

5. EA Frameworks at a Glance

7. Major Roadblocks of SOA in EA

8. Case Study implementing EA and SOA

9. Conclusion

11. Introduction (What is EA?) What is an Enterprise? An Enterprise is an organization or cross organizational entity that supports the common set of goals, mission or objective 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 EA defines the enterprise in terms of its business process, technology architecture, services and infrastructure.

12. Introduction (Why EA?) Efficient and more Effective IT Operations Reduced Redundancies and Complexities in All Sectors of IT Operations Better ROI and avoid future Risk factors Faster, Cheaper and Simpler Procurements Ensuring that all the decisions made are aligned with corporate vision and objective Ref: http://www.mitre.org/news/the_edge/fall_03/images/tucker_1.jpg

13. Introduction (EA Domains)

14. Business Standards relate to standard practice in the Business Architecture domain, including standard processes, roles, responsibilities, organization models, etc. Data Standards relate to standard practice in the Data Architecture domain, including standard data models, data governance models, etc. Application Standards relate to standard practice in the Application Architecture domain, including standard applications, application types, and application functionality. Technology Standards relate to standard practice in the Technology Architecture domain, including standard products, product types, and proper usage constraints for technologies. Ref: TAGAF 9, http://www.opengroup.org/architecture/ Introduction (EA Domains - Descriptions)

15. Role of an Enterprise Architect TOGAF or not TOGAF: Extending Enterprise, Architecture beyond RUP, Level: Introductory,VitalieTemnenco, Architect, WSIB

16. Evaluation of EA Frameworks (i)

17. Evaluation of EA Frameworks (ii)

18. This section covers the overview of Enterprise Architecture Frameworks and their evaluation EA Frameworks at a Glance

19. Popular EA Frameworks C4ISR and DoDAF - C4ISR stands for Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance - DoDAF stands for U.S. Department of Defence (DoD) Architecture Framework FEAF - FEAF (Federal Enterprise Architecture Framework) TOGAF - The Open Group Architecture Framework Zachman Ref: IBM, http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise1/?S_TACT=105AGX04&S_CMP=ART

20. Zachman Framework™ Zachman Framework is an EA Framework which provides a structured way of defining an enterprise 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 Zachman is not a methodology but ontology to describe the Enterprise

22. C4ISR Architecture Framework (CAF) C4ISR stands for Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance C4ISR provides a Quantitative Interoperating Model (QIM) for enabling seamless interconnection, effective intercommunication and dependable interoperation between heterogeneous components over the network 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

23. C4ISRViews Operational View describes the operational elements, tasks, activities, information flows for a particular mission Systems View describes associated systems and their interconnections and performance to the operational view and it’s requirements Technical View describes the minimal set of rules governing the arrangements, interactions, and interdependence of system parts or elements of the system

24. C4ISR Architectural Guidelines Architectures should be built with a purpose in mind Architectures should facilitate, not impede, communication among humans Architectures should be relatable, comparable, and integratable across DoD Architectures should be modular, reusable, and decomposable

25. FEA Consolidated Reference Model 2.3 FEA stands for Federal Enterprise Architecture, which is a consolidated reference model which builds a comprehensive business-driven blueprint of the entire Federal government Most complete version of FEA has been released in 2006

26. FEA Core Principles Business-driven: FEA is a business driven architecture which is aligned with government’s strategic plans and executive level direction Proactive and collaborative: FEA has being adopted through active participation by the EA community in its development and use Architecture improves the effectiveness and efficiency: An IT investment should not be made without the approval from the business

27. FEA Reference Models 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. 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. 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. 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. 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.

28. DoDAF 2.0 DoDAF 2.0 was released in May, 2009 and was prescribed framework for US Department of Defense 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

29. DoDAF 2.0 6 step process Step 1: Determine Intended Use of Architecture Step 2: Determine Scope of Architecture Step 3: Determine Data Required to Support Architecture Development Step 4: Collect, Organize, Correlate, and Store Architectural Data Step 5: Conduct Analyses in Support of Architecture Objectives Step 6: Document Results in Accordance with Decision-Maker Needs

30. DoDAF Models All Viewpoint (AV) Capability Viewpoint (CV) Data and Information Viewpoint (DIV) Operational Viewpoint (OV) Project Viewpoint (PV) Services Viewpoint (SvcV) Standard Viewpoint (StdV) Systems Viewpoint (SV) Ref: http://cio-nii.defense.gov/sites/dodaf20/models.html

31. TOGAF 9 TOGAF 9 has been released in February, 2009 The Open Group Architecture Framework has been has been developed by the collaborative effort of 300 members TOGAF is an enterprise framework that provides necessary methods and tools to assist acceptance, production, use, and maintenance of enterprise architecture

32. TOGAF 9 Architectural Domains Business Architecture: It defines the business strategy, governance, organization, and key business processes. Data Architecture: It describes the structure of an organization's logical and physical data assets and data management resources. 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. 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.

33. TOGAF 9 ADM 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

34. TOGAF 9 ADM Phases Preliminary Phase The definition of an Organization-Specific Architecture framework and principles. Phase A: Architecture Vision includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals. Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision. Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures. Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project. Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. Phase F: Migration Planning addresses the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan. Phase G: Implementation Governance provides an architectural oversight of the implementation. Phase H: Architecture Change Management establishes procedures for managing change to the new architecture. Requirements Management examines the process of managing architecture requirements throughout the ADM.

35. This section covers the basic comparisons of EA Frameworks with respect to their Supported Architecture, ADM, Artifacts, and Deliverables Comparison of EA Frameworks

36. Comparison of EA Frameworks (i) EA Frameworks have been compared on the following EA Items Supported Architecture : By Supported Architecture, we mean the coverage of EA in major Architecture Domains Architecture Development Method: ADM stands for Architecture Development Method, which describes a method defining EA Deliverables: EA Deliverables the produced outputs from EA Development Cycle ViewPoints: Perspective from which view is taken. Ex. Stakeholder ViewPoint

37. Comparison of EA Frameworks (ii) 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 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 Architecture Repository: Provides the capability to link architectural assets to components of the Detailed Design, Deployment, and Service Management Repositories

38. TOGAF – Supported Architecture Business Architecture Data Architecture Application Architecture Technology Architecture

39. TOGAF – ADM Preliminary Phase Phase A: Architecture Vision Phase B: Business Architecture Phase C: Information Systems Architectures Phase D: Technology Architecture Phase E: Opportunities & Solutions Phase F: Migration Planning Phase G: Implementation Governance Phase H: Architecture Change Management Requirements Management

40. TOGAF – Deliverables (i) Architecture Building Blocks Architecture Contract Architecture Definition Document Architecture Principles Architecture Repository Architecture Requirements Specification Architecture Roadmap Architecture Vision Business Principles, Business Goals, and Business Drivers Capability Assessment Change Request

41. TOGAF – Deliverables (ii) Communications Plan Compliance Assessment Implementation and Migration Plan Implementation Governance Model Organizational Model for Enterprise Architecture Request for Architecture Work Requirements Impact Assessment Solution Building Blocks Statement of Architecture Work Tailored Architecture Framework Transition Architecture

42. TOGAF – Artifacts (Preliminary & A) Phase A Catalogs: No catalogs are defined to be created during Phase A. Matrices: Stakeholder Map matrix Core diagrams: Value Chain diagram Solution Concept diagram Extension diagrams: No extension diagrams are defined to be created during Phase A. Preliminary Phase Catalogs: Principles catalog Matrices: No matrices are defined to be created during the Preliminary phase. Core diagrams: No core diagrams are defined to be created during the Preliminary phase. Extension diagrams: No extension diagrams are defined to be created during the Preliminary phase.

43. TOGAF – Artifacts (B) Phase B Core diagrams: Business Footprint diagram Business Service/Information diagram Functional Decomposition diagram Product Lifecycle diagram Extension diagrams: Goal/Objective/Service diagram Use-case diagram Organization Decomposition diagram Process Flow diagram Event diagram Phase B Catalogs: Organization/Actor catalog Driver/Goal/Objective catalog Role catalog Business Service/Function catalog Location catalog Process/Event/Control/Product catalog Contract/Measure catalog Matrices: Business Interaction matrix Actor/Role matrix

44. TOGAF – Artifacts (C) Phase C – Application Architecture Catalogs: Application Portfolio catalog Interface catalog Matrices: System/Organization matrix Role/System matrix System/Function matrix Application Interaction matrix Core diagrams: Application Communication diagram Application and User Location diagram System Use-Case diagram Extension diagrams: Enterprise Manageability diagram Process/System Realization diagram Software Engineering diagram Application Migration diagram Software Distribution diagram Phase C – Data Architecture Catalogs: Data Entity/Data Component catalog Matrices: Data Entity/Business Function matrix System/Data matrix Core diagrams: Class diagram Data Dissemination diagram Extension diagrams: Data Security diagram Class Hierarchy diagram Data Migration diagram Data Lifecycle diagram

45. TOGAF – Artifacts (D & E) Phase E Catalogs: No catalogs are defined to be created during Phase E. Matrices: No matrices are defined to be created during Phase E. Core diagrams: Project Context diagram Benefits diagram Extension diagrams: No extension diagrams are defined to be created during Phase E. Phase D Catalogs: Technology Standards catalog Technology Portfolio catalog Matrices: System/Technology matrix Core diagrams: Environments and Locations diagram Platform Decomposition diagram Extension diagrams: Processing diagram Networked Computing/Hardware diagram Communications Engineering diagram

46. TOGAF – Artifacts (Requirement Management) Requirements Management Catalogs: Requirements catalog Matrices: No matrices are defined to be created during the Requirements Management phase. Core diagrams: No core diagrams are defined to be created during the Requirements Management phase. Extension diagrams: No extension diagrams are defined to be created during the Requirements Management phase.

47. TOGAF – Building Blocks Architecture Building Blocks Characteristics Define what functionality will be implemented Capture business and technical requirements Are technology aware Direct and guide the development of SBBs Specification Content ABB specifications include the following as a minimum: Fundamental functionality and attributes: semantic, unambiguous, including security capability and manageability Interfaces: chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards) Dependent building blocks with required functionality and named user interfaces Map to business/organizational entities and policies Solution Building Blocks Characteristics Define what products and components will implement the functionality Define the implementation Fulfil business requirements Are product or vendor-aware Specification Content SBB specifications include the following as a minimum: Specific functionality and attributes Interfaces; the implemented set Required SBBs used with required functionality and names of the interfaces used Mapping from the SBBs to the IT topology and operational policies Specifications of attributes shared across the environment (not to be confused with functionality) such as security, manageability, localizability, scalability Performance, configurability Design drivers and constraints, including the physical architecture Relationships between SBBs and ABBs

48. TOGAF – Architecture Repository Architecture Metamodel: Describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content Architecture Capability: Defines the parameters, structures, and processes that support governance of the Architecture Repository. 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 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 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 Governance Log: Provides a record of governance activity across the enterprise

49. DoDAF – Supported Architecture Department-level [which includes Department, Capability & Component architectures] Architecture Solution Architecture

50. DoDAF – ADM Step 1: Determine Intended Use of Architecture Step 2: Determine Scope of Architecture Step 3: Determine Data Required to Support Architecture Development Step 4: Collect, Organize, Correlate, and Store Architectural Data Step 5: Conduct Analyses in Support of Architecture Objectives Step 6: Document Results in Accordance with Decision-Maker Needs

51. DoDAF – Deliverables (i) All ViewPoints AV-1 Overview and Summary Information AV-2 Integrated Dictionary Capability Viewpoint (CV) CV-1: Vision CV-2: Capability Taxonomy CV-3: Capability Phasing CV-4: Capability Dependencies CV-5: Capability to Organizational Development Mapping CV-6: Capability to Operational Activities Mapping CV-7: Capability to Services Mapping Data and Information Viewpoint (DIV) DIV-1: Conceptual Data Model DIV-2: Logical Data Model DIV-3: Physical Data Model Operational Viewpoint (OV) OV-1: High-Level Operational Concept Graphic OV-2: Operational Resource Flow Description OV-3: Operational Resource Flow Matrix OV-4: Organizational Relationships Chart OV-5a: Operational Activity Decomposition Tree OV-5b: Operational Activity Model OV-6a, 6b, 6c: Introduction OV-6a: Operational Rules Model OV-6b: State Transition Description OV-6c: Event-Trace Description Project Viewpoint (PV) PV-1: Project Portfolio Relationships PV-2: Project Timelines PV-3: Project to Capability Mapping

52. DoDAF – Deliverables (ii) Systems Viewpoint (SV) SV-1 Systems Interface Description SV-2 Systems Resource Flow Description SV-3 Systems-Systems Matrix SV-4 Systems Functionality Description SV-5a Operational Activity to Systems Function Traceability Matrix SV-5b Operational Activity to Systems Traceability Matrix SV-6 Systems Resource Flow Matrix SV-7 Systems Measures Matrix SV-8 Systems Evolution Description SV-9 Systems Technology & Skills Forecast SV-10a Systems Rules Model SV-10b Systems State Transition Description SV-10c Systems Event-Trace Description Services Viewpoint (SvcV) SvcV-1 Services Context Description SvcV-2 Services Resource Flow Description SvcV-3a Systems-Services Matrix SvcV-3b Services-Services Matrix SvcV-4 Services Functionality Description SvcV-5 Operational Activity to Services Traceability Matrix SvcV-6 Services Resource Flow Matrix SvcV-7 Services Measures Matrix SvcV-8 Services Evolution Description SvcV-9 Services Technology & Skills Forecast SvcV-10abc Introduction to SvcV-10a, SvcV-10b and SvcV-10c SvcV-10a Services Rules Model SvcV-10b Services State Transition Description SvcV-10c Services Event-Trace Description

53. DoDAF – Artifacts AV-1 : Overview and Summary Information AV-2 : Integrated Dictionary OV-1 : High Level Operational Concept Graphic OV-5 : Operational Activity Model OV-2 : Operational Node Connectivity Description OV-3 : Operational Informational Exchange Matrix SV-1 : System Interface Description TV-1 : Technical Standards Profile

54. C4ISR – Supported Architecture Operational Architecture Systems Architecture Technical Architecture

55. C4ISR – ADM Step 1: Determine Intended Use of Architecture Step 2: Determine the architecture’s scope, context, environment, and any other assumptions to be considered Step 3: Based on the intended use and the scope, determine which characteristics the architecture needs to capture Step 4: Based on the characteristics to be displayed, determine which architecture views and supporting products should be built Step 5: Build the requisite products Step 6: Use the architecture for its intended purpose

56. C4ISR – Deliverables All ViewPoint (Context) AV-1 Overview and Summary Information All ViewPoint (Terms) AV-2 Integrated Dictionary Operational Viewpoint (OV) OV-1 High-level Operational Concept Graphic OV-2 Operational Node Connectivity Description OV-3 Operational Information Exchange Matrix OV-4 Command Relationships Chart OV-5 Activity Model OV-6a Operational Rules Model OV-6b Operational State Transition Description OV-6c Operational Event/Trace Description OV-7 Logical Data Model Systems Viewpoint (SV) SV-1 Systems Interface Description SV-2 Systems Communication Description SV-3 Systems Matrix SV-4 Systems Functionality Description SV-5 Operational Activity to System Function Traceability Matrix SV-6 Systems Information Exchange Matrix SV-7 Systems performance Parameters Matrix SV-8 Systems Evolution Description SV-9 Systems Technology Forecast SV-10a Systems Rules Model SV-10b Systems State Transition Description SV-10c Systems Event/Trace Description SV-11 Physical Data Model Technical Viewpoint (TV) TV-1 Technical Architecture Profile TV-2 Standards Technology Forecast

57. C4ISR – Artifacts (i) Command Relationships Chart (OV-4) Activity Model (OV-5) Operational Activity Sequence and Timing Descriptions (OV-6a, 6b, and 6c) Logical Data Model (OV-7) Systems Communications Description (SV-2) Systems Matrix (SV-3) Systems Functionality Description (SV-4)

58. C4ISR – Artifacts (ii) Operational Activity to System Function Traceability Matrix (SV-5) System Information Exchange Matrix (SV-6) System Performance Parameters Matrix (SV-7) System Evolution Description (SV-8) System Technology Forecast (SV-9) System Activity Sequence and Timing Descriptions (SV-10a, 10b, 10c) Physical Data Model (SV-11) Standards Technology Forecast (TV-2)

59. FEAF – Supported Architecture Enterprise architecture Segment architecture Solution architecture

60. FEAF – ADM (Reference Model Based) Performance Reference Model Business Reference Model Service Component Reference Model Data Reference Model Technical Reference Model

61. FEAF – Deliverables DRM provides a high-level overview of the structure, usage, and data-identification constructs Which: Provides an introduction and high-level overview of the contents that will be detailed in Volumes 2-4 of the model Provides the basic concepts, strategy, and structure to be used in future development.

62. FEAF – Artifacts BRM Artifacts: Services For Citizens Mode of Delivery Support Delivery of Services Management of Government Resources SRM Artifacts: Customer Services Process Automation Services Business Management Services Digital Asset Services Business Analytical Services Back Office Services Support Services

63. Zachman – Supported Architecture Information System Architecture

64. Zachman – ADM What - Data How - Function Where - Network Who - People When - Time Why - Motivation

65. Zachman – Deliverables Zachman is a conceptual framework which provides outlines of building models: Row 1- Scope Row 2 – Enterprise Model Row 3 – System Model Row 4 – Technology Model Row 5 – As-Built Functioning Enterprise

66. Zachman – Artifacts Ref: http://en.wikipedia.org/wiki/Zachman_Framework#Information_Systems_Architecture_Framework

67. This section covers the mapping of some EA frameworks EA ADM Mapping

68. TOGAF Vs. DoDAF (ADM) Ref: The Open Group Architecture Framework (TOGAF) and the US Department of Defense Architecture Framework (DoDAF) ,Dr. Fatma Dandashi, MITRE Corporation

69. Zachman Vs. DoDAF Ref: http://en.wikipedia.org/wiki/File:DoDAF_Support_to_the_Builder.jpg

70. This section covers the concept of SOA in Enterprise Architecture and it’s effectiveness Effectiveness of SOA in EA

71. What is SOA in EA? Service Oriented Architecture (SOA) as an architectural style where it simplifies the business and interprets different parts of the business 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. Correspondence between EA and SOA is necessary SOA is more than architecture where SOA governance is needed as well as a transition map that allows enterprises to adopt it Ref: http://blogs.cofc.edu/gradschool/files/2009/07/soacorecomponentsdiagram.jpg

72. Business Service and SOA A business service operates as a boundary for one or more functions A service in Service Oriented Architecture (SOA) terminology (i.e., a deployable unit of application functionality) which may implement or support a business service.

73. SOA Advantages SOA provides Business Services across platform Services are Location Independent Services are Independent of particular system or network SOA is a loosely coupled approach SOA Authentication and authorization support at every level SOA provides dynamic connectivity to other services

74. SOA Benefits Portability Reliability Reusability Lower Cost Business Functionality are closer to Business Units Reduces the need for custom development

75. Major Roadblocks implementing SOA Adopting SOA in multiple Line of Business or LOB is a trivial task If not Addressed SOA risks in EA Governance , may end up with multiple silos in SOA solutions Business Values need to be established through an enterprise methodology before adopting SOA 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 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.

76. Business-led SOA Vs. Developer –led SOA Ref: http://www.opengroup.org/architecture/togaf9-doc/arch/chap22.html

77. SOA Solution Track Ref: http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise1/?S_TACT=105AGX04&S_CMP=ART

78. C4ISR SOA Model 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

79. TOGAF Concepts mapped to SOA Ref: http://www.opengroup.org/architecture/togaf9-doc/arch

80. DoDAF IERs [Information Exchange Requirements] and Service Mapping Ref: A Service Oriented Architecture (SOA) Approach to Department of Defense Architecture Framework (DoDAF) Architecting

81. Zachman SOEAF 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}@sbu.ac.ir

82. We tried to apply EA defining a new enterprise and later mocked up the system using SOA Case Study - TechPlanet

83. TechPlanet – A Case Study SaleExpress is an online product sales and delivery company based in North America FastCourier is a world-wide Packaging, Distribution and Logistics Company based in Asia EzyPay is a Financial Company based in Europe 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

84. How EA can play a vital role? Setup TechPlanet Goals or Define Corporate Goals Define benefits of EA in TechPlanet Define EA Principles and Governance Find out Critical Business Problems and Proposed Solutions Find Out Major Constraints Define Proposed Project Scope Define EA

85. TechPlanet Goals Establish TechPlanet as the leading online product sales and delivery company across the globe within two years Reduce Cost Increase Revenue Improve Customer Service

86. EA Benefits More Efficient and Transparent System (Improve Productivity, Increased Interoperability and Portability, Reusability, Reduced Redundancy, Lower Cost) Better ROI (Reduced Complexity and Risk, Reduced Development, Implementation and Maintenance Cost) Faster, Cheaper and Simpler Procurement Efficient Maintenance

87. EA Principles and Governance Global Governance Board European Governance Team Asian Governance Team North American Governance Team

89. Technology governance

90. IT governance

93. Proposed Solution Establish Local Governance with alignment of Corporate Governance Establish a unified Package Delivery and Pickup Model Establish a unified Payment model Establish a unified Financial Model Establish a company wide IT standard Establish an infrastructure refresh program Establish a central routing model

94. Major Constraints Two Years to place TechPlanet as the leading online product sales and delivery company across the globe Limited funding and Resources Different personnel and work ethics for three different companies and internationally located countries

95. Stakeholder Map

96. Goals/Objectives/Services Diagram

97. Solution Concept Diagram Online Sales System Payment Processing System Package and Delivery System Service Visibility and GPS Based Fleet Tracking Control Simplify Business Operations System Operations Transportation Management

98. Communication Diagram

99. Proposed IT Development Framework .NET Framework 4.0 for Online Web Services SAP as the System of Record for Order Processing, HR, Vendor Management BizTalk for Middleware Platform that acts as the intermediary bus to communicate with Available Services, Internal/External Agents, SAP and thus process requests

100. TechPlanet Business Services Online Sales Financial Processing Packaging Delivery

101. IT Services implementing SOA User Authentication Online Sales Processing Payment Processing Package Delivery and Tracking Accounting

102. TechPlanet Implementing SOA

112. How effective SOA is defining EA? 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 SOA can be considered as a practical modeling approach for enterprise architecture (EA) development EA benefits are aligned with SOA benefits (Reusability, Portability, Efficiency, Non-Redundant IT operation )

113. Conclusion DoDAF V2.0 and TOGAF 9 both provide a elaborative and practical design on enterprise architectures 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 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 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 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 Case study shows us how can we solve a business problem using EA and how can it be transformed to SOA and provide

114. Future Work 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 Working a EA Framework Benchmarking tool which covers different perspectives, businesses, governance and views

115. References 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, sandede@auburn.edu , hamilton@auburn.edu rmacd@ramlabs.com 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}@wiwi.uni-regensburg.de 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, b.orriens@uvt.nl,Jian Yang, Department of Computing,Macquarie University, NSW, 2109,Sydney, Australia,+61 2 9850 9584, jian@comp.mq.edu.au One Size Does Not Fit All—A Contingency, Approach to Data Governance, KRISTIN WEBER, BORIS OTTO, and HUBERT ¨OSTERLE, University of St. Gallen The Open Group, http://www.opengroup.org/togaf/ Service oriented architectures: approaches, technologies and research issues, Mike P. Papazoglou · Willem-Jan van den Heuvel Enterprise Architecture in the Defense World, http://www.enterprise-architecture.info/Images/Defence%20C4ISR/Enterprise%20Architecture%20Defense.htm FEAF, http://en.wikipedia.org/wiki/Federal_Enterprise_Architecture_Framework#FEA_Architecture_levels DoDAF Frame work Version 2.0 http://cio-nii.defense.gov/sites/dodaf20/products/DoDAF_2-0_web.pdf A Comparative Analysis of Enterprise Architecture Frameworks based on EA Quality Attributes , Namkyu Lim1 Tae-gong Lee2, Sang-gun Park1, Korea Model Driven Approach to Service Oriented Enterprise Architecture SedighehKhoshnevis†, Fereidoon Shams Aliee∗, PooyanJamshidi∗ Enterprise Service Oriented Architecture (ESOA) Adoption Reference, Yan Zhao, Ph.D., Director, Enterprise Architecture, CGI Federal Service oriented architectures: approaches, technologies and research issues, Mike P. Papazoglou · Willem-Jan van den Heuvel A Framework for Enterprise Resilience Using Service Oriented Architecture Approach, OzgurErol Mo Mansouri Brian Sauser, oerol@stevens.edu mo.mansouri@stevens.edu brian.sauser@stevens.edu, School of Systems and Enterprises, Stevens Institute of Technology,Hoboken, NJ USA