Jordan eGovernment Enterprise Architecture Copyright 2007 Government of

Jordan e-Government Enterprise Architecture Copyright © 2007 Government of Jordan. All rights reserved.

AGENDA § Introduction To Enterprise Architecture § Introduce EGAF § Explain Enterprise Frameworks § TOGAF § FEAF § Introduce SOA § Describe Service § Explain Web. Services § XML 2

ENTERPRISE ARCHITECTURE “Enterprise Architecture is the activity of applying a comprehensive process or framework to describe the future structure of an enterprise’s information systems and business processes, so that the enterprise can align with the enterprise IT/business strategy and organizational goals. “

ENTERPRISE ARCHITECTURE ADVANTAGES § Align IT infrastructure and process with enterprise strategy and goals § Supplement the existing e-government strategy and project management methodology with EA Standards & Guidelines § EA sets the standards for informed technical management decisions § EA Promotes "interoperability" among entities

COMPONENTS OF ENTERPRISE ARCHITECTURE § Business architecture: Identify business processes and supporting organizational structure. Help in achieving the business model § Application architecture: the architecture of applications that support the business processes § Technology or infrastructure architecture: addressing the infrastructure that supports the applications § Information/data architecture: addressing the information that supports the applications

ENTERPRISE ARCHITECTURE FRAMEWORKS EA Framework is a tool for systematically documenting the enterprise architecture. EA framework provide the tools and artifacts needed for documenting the architecture. It also has a Technical Reference Model or TRM, that can be referred to for creating the architecture. 6

TOGAF / FEAF / ZACHMAN “EA Framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. “ -The Open Group Architecture Framework (TOGAF) “The EA framework consists of various approaches, models and definitions for communicating the overall organization and relationships of architecture components required for developing and maintaining a (Federal) Enterprise Architecture. “ -Federal Enterprise Architecture Framework (FEAF) “EA Framework draws upon the discipline of classical architecture to establish a common vocabulary and set of perspectives, a framework, for defining and describing today's complex enterprise systems. Enterprise Architecture provides the blueprint, or architecture, for the organization's information infrastructure“ - ZACHMAN 7

CHALLENGES FACED BY JORDAN E-GOVERNMENT PROGRAM § Need to transform e-government strategy and vision into concrete business and IT solutions. § Interoperability Issues among entities. § Lack of reuse of functionality (Re-inventing the wheel). § Lack of e-service maturity at some entities. § Limited funding for e-government related activities at entities. § Limited technical skill sets at entities. § Duplicate data ownership.

ﺇﻃﺎﺭ ﺍﻟﻬﻴﻜﻠﻴﺔ ﺍﻟﺘﻘﻨﻴﺔ EGAF ﻟﻠﺤﻜﻮﻣﺔ ﺍﻹﻟﻜﺘﺮﻭﻧﻴﺔ ﺍﻷﺮﺩﻧﻴﺔ Entity Reference Model Infrastructure Governmental Entities Integration Middle ware Delivery E-Services Applications Software Access Infrastructure E-Government 9 Entity Architecture E-Services Integration Middle ware Access Applications Software Governance Applications Interoperability Framework Delivery E-Services Central Architecture Governance Entity Architecture Interoperability Framework Entity Reference Model Infrastructure Governmental Entities

COMPONENTS OF EGAF • Central Architecture & Building Blocks – Architecture for “common services” such as “Payment Gateway” provided by e-government program that all entities can use. • Entity Reference Architecture – Provide a process that entities can adopt to integrate with central building blocks. Additionally It provides direction for entities to create there own information technology architecture using the “FEAF” Framework. • Interoperability Framework – This framework provide technical standards to streamline interoperability. It provides data standards to create unique standardized XML data dictionaries for common data elements across all entities. This will help in removing any confusion regarding the data ownership, type, relationship or structure. • Governance – The frameworks and architectures described above are subject to the EGAF Governance process, that will ensure that the EGAF remain relevant over time. 10

APPLICATION OF TOGAF FOR CENTRAL E-GOVERNMENT ARCHITECTURE The following slides will demonstrate how “The Open Architecture Framework”- TOGAF was applied to create the architecture for the e-government central platform. 11

TOGAF OFFERING • An Enterprise Framework that provide views, view points and reference models to design, document and describe an architecture. • An architecture development method which is the process that an architect can follow to arrive at the enterprise architecture artifacts. 12

TOGAF ADM 13

TOGAF Architecture Development Method ADM The first part of TOGAF is a methodology for developing architecture design, which is called the Architecture Development Method (ADM). It has following phases: • • • Preliminary phase: Framework and principles Get everyone on board with the plan. Phase A (Architecture vision): Define your scope and vision and map your overall strategy. Phase B (Business architecture): Describe your current and target business architectures and determine the gap between them. Phase C (Information system architectures): Develop target architectures for your data and applications. Phase D (Technology architecture): Create the overall target architecture that you will implement in future phases. Phase E (Opportunities and solutions): Develop the overall strategy, determining what you will buy, build or reuse, and how you will implement the architecture described in phase D. Phase F (Migration planning): Prioritize projects and develop the migration plan. Phase G (Implementation governance): Determine how you will provide oversight to the implementation. Phase H (Architecture change management): Monitor the running system for necessary changes and determine whether to start a new cycle, looping back to the preliminary phase. 14

TOGAF ADM PHASE A: PROCESS OF CREATING VISION DOCUMENT This slide will detail the architecture vision 15

PROCESS OF GATHERING VISION 1. Step 1: Information gathering -The following is a list of all the sources of the preliminary material: a. b. c. d. e. f. g. h. 2. 3. 4. E-Government Strategy document Hosting Strategy document Connectivity Strategy document Anderson Report: Top 30 e-Services analysis Anderson Deliverable 11: Detailed Study and Recommendations on the Access and Delivery Channels for e-Services Implementation Version 3. 2 e-Government Contact Center Initiative launch brief The RFP Best practices Step 2: Started with executing an architecture vision workshop were DEVOTEAM has met with the e-Government program team members to present and discuss the preliminary materi DEVOTEAM then generated the 1 st draft of the architecture vision document. Step 3: Generating principles and executing an architecture vision validation workshop were DEVOTEAM has met with the e-Government program team members to validate the architecture vision draft. Step 4: Documentation and delivery of the 1 st version of the architecture vision deliverable. 16

CONTENT OF VISION DOCUMENT Document Walkthrough “ARCHITECTURE VISION” Covers section 3 and above Total time 10~15 minutes 17

TOGAF ADM PHASE D: TECHNOLOGY ARCHITECTURE 18

PROCESS OF CREATING BASELINE ARCHITECTURE § Architects identified the architecture domains that need to be documented. § Identified key stakeholders and entities that are required to provide input to the architecture baseline. § Developed architecture questionnaire to collect information fro stakeholders and entities. § Document baseline architecture. 19

CONTENT OF BASELINE ARCHITECTURE DOCUMENT WALKTHROUGH “BASELINE ARCHITECTURE” Coverage will be section 2. 3 and above. Total time 10~15 minutes 20

PROCESS OF CREATING TARGET ARCHITECTURE REPORT 21

CONTENT OF TARGET ARCHITECTURE REPORT DOCUMENT WALKTHROUGH “TARGET ARCHITECTURE REPORT” Coverage will be section 3 and above Total time 15~20 minutes. 22

ARCHITECTURE BUILDING BLOCKS – ABB’s The target architecture report identifies key architecture building blocks. Once the target architecture report was accepted by Mo. ICT. The building blocks specification was detailed out. Each building block is described in the following fashion. • The relationship of the building block with the rest of the architecture is explained. • The components of the building block are identified • Each component of the building block is detailed out with functional and non functional features that it should have. 23

CONTENT OF MAJOR BUILDING BLOCKS DOCUMENT WALKTHROUGH OF BUILDING BLOCKS BELOW • Security BB • Contact Center • Payment Gateway • Collaboration BB Total Duration 15~20 minutes 24

APPLICATION OF FEAF FOR ENTITY ARCHITECTURE The following slides will demonstrate how “Federal Enterprise Architecture Framework”- FEAF Was applied to create the architecture for the “Ministry Of Industry & Trade” 25

ADVANTAGE OF FEAF was developed to accomplish the following § Organize Federal information on a federal wide scale § Promote information sharing among Federal organizations § Help Federal organizations develop their architectures § Help Federal organizations quickly develop their IT investment processes § Serve customer needs better, faster, and cost effectively 26

FEAF PROCESS 27

FEAF PROCESS TAILORED FOR ENTITIES 1. Obtain executive buy-in and support includes development of high-level concept of architecture as outlined in this section, in addition to involving key resources in the process. 2. Establish management structure and control is part of the architecture governance effort and will involve Mo. IT at the time of implementation of the governance system. 3. Define an architecture process and approach includes modifications to the generic process as outlined here, as well as definition of such items as scope of work, level of detail, notation and tools. 4. Develop baseline enterprise architecture includes relevant architectural views for the Ministry of Industry and Trade and is documented in this report. 5. Develop target enterprise architecture includes identification of strategic objectives, vision, drivers, requirements and principles as well as definition of the four layers of enterprise architecture. This effort is divided into an Architecture Vision document and a Target Architecture document, both of which will be produced as a part of the showcase for Mo. IT. 28

FEAF PROCESS TAILORED FOR ENTITIES 6. Develop the sequencing plan includes a GAP analysis and a plan on how to bridge the identified gaps. This effort is part of the Mo. IT showcase and will be completed upon acceptance of the target enterprise architecture. 7. Use the enterprise architecture includes integrating the enterprise architecture with investment- and project/program management processes. This is part of the architecture governance effort and will involve Mo. IT at the time of implementation of the governance system. 8. Maintain the enterprise architecture includes the management and continuous improvement processes necessary to evolve the enterprise architecture over time. This is outside the scope of the project. 29

PROCESS FOR CREATING BASELINE ARCHITECTURE 30

CONTENT OF BASELINE ARCHITECTURE Document Walkthrough “Mo. IT BASELINE ARCHITECTURE ” Total time 20~25 minutes. 31

PROCESS FOR CREATING ARCHITECTURE VISION 32

CONTENT OF Mo. IT ARCHITECTURE VISION Document Walkthrough “Mo. IT ARCHITECTURE VISION” Total time 20~25 minutes. 33

PROCESS FOR CREATING TARGET ARCHITECTURE 34

CONTENT OF Mo. IT TARGET ARCHITECTURE Document Walkthrough “Mo. IT TARGET ARCHITECTURE” Total time 20~25 minutes. 35

PROCESS FOR CREATING Mo. IT SEQUENCING PLAN 36

CONTENT OF Mo. IT SEQUENCING PLAN Document Walkthrough “Mo. IT SEQUENCING PLAN” Total time 20~25 minutes. 37

SERVICE ORIENTED ARCHITECTURE Service Oriented Architecture (SOA) is defined as follows: SOA is a best practice IT architecture pattern that promotes implementing business functionality as “independent”, “modular” and “loosely coupled” services. Service consumers access the service using a Service interface, whereas the actual technical implementation of the service is hidden. 38

SERVICES IN SOA A SOA “service” is generally defined as follows: A “service” is a functionality provided as a modular piece of software with a well defined interface. Service can be activated by a service consumer by activating the “service interface”. 39

ATTRIBUTES OF A SERVICE • A service is “loosely coupled”, in that sense changes made to the implementation of the service require no changes from the consumer. • A service is modular and independent from other services. • A service is a reusable unit.

SERVICE ORIENTED ARCHITECTURE 41

SERVICE INDEPENDENCE Services are designed with no affinity to any particular service consumer. This independence allows for Non intrusive reuse of service interfaces. Poorly designed services which are logically locked into their service consumers render the architecture “monolithic” despite the use of SOA. 42

LOOSE COUPLING In SOA services should be loosely coupled. This means that the actual technical implementation of services are hidden and there functionality is available via “service interfaces”. Because of this “loose coupling” the actual technical implementation of a service can be changed if the service interface remains the same. 43

SERVICE INTERFACE- TOOL TO ENABLE SERVICE BLACK BOX NATURE A “service interface” is a contract that establishes the identity of the service and the rules of the service invocation. Listed below are details typically presented in a service interface. § Request Data Parameters § Response Data Parameters § Method of Service Invocation § Exception Conditions § Metadata to identify the function and purpose of the service 44

ADVANTAGES OF SOA § Adapt applications to changing technologies. § Easily integrate applications with other systems. § Leverage existing investments in legacy applications. § Quickly and easily create a business process from existing services. 45

SOA DEVELOPMENT PRINCIPLES § Software that enables the services must be modular. § The software modules must be distributable. § Software developers must write or generate interface metadata that specifies an explicit contract so that another developer can find and use the service (this helps enable loose coupling). § The service interface must be separate from the implementation (code and data) of the service provider module. § Service providers must be shareable — that is, designed and deployed in a manner that allows them to be invoked successively by disparate consumers. 46

CHALLENGES IN MOVING TO SOA § § SOA is much more than just deploying software. Government entities with the help of the e-government program need to analyze their design techniques, development methodology and partners relationships Moving to SOA must be incremental and this requires a shift in the way service-based applications are composed and in the same time considering maximizing existing IT investments at the government entities premises. An SOA program requires high level of collaboration and communication between technical and business staff The e-government program needs to educate the government entities about the importance of complying with IIF standards. 47

WEB SERVICES Due to the emergence of the “world wide web” one of the best ways of enabling SOA is to expose services as “web services” “Web Services” interface are described using web services definition language (WSDL) files. WSDL files are used by the service consumers to invoke web services 48

Web Service Publishing and Discovery Universal Description, Discovery and Integration (UDDI) 49

CONTENT OF STANDARDS FOR SOA BEST PRACTICES AND MATURITY MODEL Document Walkthrough “SOA BEST PRACTICES AND MATURITY MODEL” Total time 20~25 minutes. 50

Thank you for attending Q&A 51