Enterprise Information Architecture. Connected Government. Author name is hidden

Transcription

1 Enterprise Information Architecture Connected Government Author name is hidden Date: Friday, 4 September 2015

2 Table of contents Table of contents 1 Introduction 1 2 Conceptual Architecture 1 3 Logical Architecture 3 4 Component Model Component Relationship Diagram Component Descriptions Component Interaction Diagram 6 5 Operational Model 8 6 Conclusion 9 References 10 List of figures Figure 1 - Building blocks for a Citizen Centric and Socially Inclusive e-government 2 Figure 2 - Architecture Overview Diagram for e-government 3 Figure 3 - Logical View Diagram for e-government 4 Figure 4 - Component Relationship Diagram for e-government 5 Figure 5 - Component Interaction Diagram for Co-Production Hub Scenario 7 Figure 6 Operational modelling of Content Resource Manager Service Availability 8 Figure 7 - Operational modelling of Continuous Availability and Resiliency Operational Pattern 9 ii ii

3 1 Introduction In the context our increasingly connected world where information is at our fingertips, Governments are facing growing pressure to be more open, accountable and transparent with its citizens, community organisations and businesses (Saha 2010 p.15). Such a Connected Government or e-government approach requires a transformation in its thinking and information systems. This report will utilise an Enterprise Information Architecture Reference Architecture (EIA RA) approach to analyse and design an Information Centric implementation of an e-government information system that will deliver Connected Government. EIA RA is a template approach to Enterprise Information Architecture. It not only works through a systematic process of design but it assumes that there are tried and true methods and design patterns which form the building blocks of information systems. Yet it allows for changing and evolving technologies (Godinez, et al 2010 pp ). The systematic EIA RA approach to e-government design will include its Conceptual Architecture, Logical Architecture, Component Modelling and Operational Modelling. 2 Conceptual Architecture The goal of an e-government Enterprise Information System (EIS) is to provide a cohesive, Citizen Centric and Socially Inclusive information system that enables a transparent outside in two way interaction with government by a diverse constituent. Capabilities required for such an Information System include: E-Government must operate as a single enterprise, Provide cost effective Citizen and Business and Community organisation oriented services delivering right first time outcomes (King & Cotterill 2007 p. 335), Cater for a diverse constituent in terms of culture, language, ability, education, status and various levels of interaction and informational requirements, Enable citizens and businesses to be engaged at relevant points in policy and decision making processes in a two way consultative manner (Saha 2010 p.10), Enable a Co-production platform (King & Cotterill 2007 pp ) where citizens and businesses are empowered to participate in the management of information pertaining to them. These five requirements of an e-government EIS is not an exhaustive list and only pertains to Citizen Centricity and Social Inclusion aspects, the building blocks of which are portrayed in Figure 1. This figure shows a system as a single enterprise communicating though a Customisable presentation layer which caters for the diverse constituent need. The three types of interactions between constituent and e-government represent (from left to right in Figure 1) a two way consultative interaction on such things as policy formation, a self-serve information gateway for documents, media data, noticeboards, etc. and thirdly, a constituent portal for self-managed participative services such as company regulatory Page 1

4 interaction or constituent welfare management. These interactions with government information and agencies are tightly controlled by policy and security surveillance and enforcement. These building blocks are the basis of an Architecture Overview Diagram (AOD) which translates non-technical operational requirements into a conceptual model (Godinez, et al 2010 p. 77) as portrayed in Figure 2. Building Blocks for a Citizen Centric and socially inclusive E-Government Information System Citizen, Business and organisation Interaction Customisable Presentation Two-Way Interaction Information services Co-Managed information Policy and security oversight Government Information Government Agents / Employees Government Figure 1 - Building blocks for a Citizen Centric and Socially Inclusive e-government The AOD in Figure 2 shows how the various concepts required in an Information Architecture connect to deliver the required Citizen Centric and Socially Inclusive e- Government information system. Data Domains are the heart of the single enterprise approach to e-government, particularly centrally managed Master Data services, Operational Data, Unstructured Content Data and Metadata services. Although these systems will be geographically dispersed, they will be designed to give accurate single source of truth and right information first time performance to both internal government employees / agents and external constituents. This central management and integration is achieved by Service Oriented Enterprise Information Integration. Page 2

5 E-Government Interaction Systems Policy formulation Interaction E-Government Information Systems Information Service Applications Co-Managed Information Service Applications Government Enterprise Search Presentation Services and delivery channels Portal Web Mobile Applications JMS, MQ, FTP, (a)synchronous Connectivity and Ineteroperability Service Integration Data Domains Metadata Services Metadata Master Data Services Master Data Constituents Legislation Govt departments Policies Data Services Operational Data Law Enforcement Planning Policy Development Content Services Content Workflows Unstructured Data Digital Document Archive Information Documents Image repositories Analytical Services Data Warehouse Cloud Services Metering Monitoring Billing Pricing Virtualisation Elastic Capacity Managed service Security and Privacy Services Data Masking Encryption Authentication Authorisation Audit Batch (near) real-time Enterprise Information Integration Service-Oriented Figure 2 - Architecture Overview Diagram for e-government (adapted from Godinez, et al 2010 p. 89) E-Government Interaction and Information Systems provide the functionality of e- Government. These are the systems and services used by both internal employees and external constituents both with their respective presentation services and delivery channels. The Connectivity and Interoperability service provides the data communication channels between all these systems and services. 3 Logical Architecture The logical architecture starts to set out the technical functionality required to deliver the business view oriented conceptual architecture (Godinez, et al 2010 p. 98). Figure 3 Logical View Diagram shows how functional services are logically located in relation to each other. This starts at the base where Cloud hosting services host and support Integration and Information services which provide services to the Application Services which are presented to employees, agents and constituents in the Presentation Layer. These all communicate via the Connectivity and Interoperability Services. Non-functional services dealing with Compliance, Availability, Retention, Security, Capacity and Quality of Service (Godinez, et al 2010 p. 167) are also shown in relation to the services they support. These include Business Process Orchestration and collaboration service, Information Security and Information Privacy and IT Service Compliance and Services. In terms of delivering e-government requirements, there is a clear relationship between the Figure 1 Building blocks and the Figure 3 Logical View. The Application Services below correlate with the Building Block s Two-way Interaction, Information Services and comanaged Information. Page 3

6 Presentation Services and Delivery Channels Web Mobile Applications Portal Business Process Orchestration and Collaboration Connectivity and Interoperability Information Security and Information Privacy Application Services Collaboration Information delivery / search Information Co-production Information Services Metadata Services Metadata Master Data Services Master Data Data Services Operational Data Content Services Unstructured Data Analytical Services Data Warehouse Enterprise Information Integration Services Discover Cleanse Federate Stream Profile Transform Replicate Deploy IT Service and Compliance Services Capabilities for Cloud Service Delivery Services Figure 3 - Logical View Diagram for e-government (adapted from Godinez, et al 2010 p. 98) 4 Component Model The Component Model sets out the actual parts or components that will deliver the functionality shown in the Logical model. A Component can be described as a logically grouped set of specific capabilities or software applications that will deliver specific functionality (Godinez, et al 2010 p. 103). The model sets it out in three parts; Component Relationship Diagram, Component Descriptions and Component Interaction Diagrams. 4.1 Component Relationship Diagram The Component Relationship Diagram depicts the components, interfaces and their relationships (Godinez, et al 2010 p. 104). Figure 4 Component Relationship Diagram shows a depiction of the Logical Model Diagram turned on its side and populated with the Components which will deliver the logical functions. These Components are then described as part of the Component Model. Page 4

7 Delivery Channels Enterprise Search UI Web Mobile Enterprise Portals Productivity / Applications Collaboration UI Infrastructure Security Component Collaboration Services Business Process Services Service Registry and Repository Information Co- Production Hub Catalogue of Portals Collaboration Hub Catalogue of Collaborations Presentation Services (Portal and Web) Business Performance Presentation Services Embedded Analytics Search and Query Presentation Services Message / Web Service Gateway Directory / Security Services Routing Transport Messaging Mediation Connectivity and Interoperability services Enterprise Service Bus (ESB) Publish Subscribe Orchestration Load Balancing Operational Applications Operational Applications Operational Applications Metadata Services Metadata Analytical Services Data Warehouse Content Services Unstructured Data Data Services Operational Data Master Data Services Federate Enterprise Information Integration Discover Stream Profile Cleanse Transform Replicate Deploy IT and Compliance Services Control of Service and Accounting Performance Availability & Fault Security & Privacy Retention Master Data Figure 4 - Component Relationship Diagram for e-government (adapted from Godinez, et al 2010 p. 106) 4.2 Component Descriptions Component Descriptions describe each component in terms of it services, interfaces and functional and non-functional requirements. Depending on the needs of the project these descriptions include an ID for Identification, a Name, High-level description, Service description and a list of Interfaces (Godinez, et al 2010 pp ). For the purpose of this report only the Collaboration Hub and Information Co-Production Hub components differ from the Enterprise Information Architecture Reference Architecture model and are therefore described. Name Collaboration Hub High-level description this component relates to the fourth e-government requirement for interaction between Government and Constituents regarding maters of policy and government. At any point in time there will be many of these discussions and interactions. This Collaboration Hub does not provide those collaboration services but acts as an interaction gateway that on the e-government side allows it to control and secure Page 5

8 constituent access to the these collaborations, and on the Constituent side allows a smorgasbord of possible collaborative interactions. Constituents connect to Collaboration Services through this Collaboration Hub. In terms of security and moderation services, this Collaboration Hub relies on Presentation Service s access to the Directory / Security Services component for authentication and authorisation and relies on collaboration services to monitor and moderate individual collaboration instances. Interfaces on the external presentation side it allows for continuous streaming of updated collaboration such that the Presentation Services can present multiple collaboration interactions to the constituent on a dashboard type web or mobile app page. On the internal interface side, this Connection Hub is a bridge to multiple collaboration instances provided by the Collaboration Services. Name - Information Co-Production Hub High-level description this component relates to e-government requirement one and five where government presents itself to the constituent as a single organisation from a single (in the eyes of the constituent) portal, enabling the constituent to be co-productive with their information (King & Cotterill 2007 pp ). This Information Co-Production Hub allows the constituent to request views of service portals that are related to them and /or their organisation. For example an Australian company may want to be able to access its tax portal, its ASIC company portal and multiple other company government interaction portals through the same generic portal. This component relies on Presentation Services to secure the communication and authorise and authenticate the constituent on a single-sign in basis (one sign in gives access to all authorised portals). Interfaces on the external presentation side, multiple portals are presented simultaneously and are presented to the constituent with some sort of a government service portal menu. On the internal interface side is a gateway / bridge to various government application and portal services. 4.3 Component Interaction Diagram Component Interaction Diagrams depict the dynamic interaction between components in a particular use case scenario (Godinez, et al 2010 p. 104). It is a way of high level interaction testing to verify component configuration and inclusion. Figure 5 depicts the Constituent access to the Co-Production Hub interaction scenario. It shows how the Constituent must first be authenticated at Login before being passed onto the Presentation Services component which subsequently requests the appropriate portals from the Information Co-Production Hub component. This component retrieves the appropriate portals which it sends back to the Presentation Services component for it to aggregate and present to the constituent through the Web page. Figure 5 demonstrates that there are no missing components in this scenario. Page 6

9 Operational Applications Collaboration Services Information Co-Production Portal Access Scenario Delivery Channels Enterprise Search UI Web Mobile Enterprise Portals Productivity / Applications Collaboration UI (1) Login (2) auth. Infrastructure Security Component Business Process Services Service Registry and Repository Information Co- Production Hub Catalogue of Portals Collaboration Hub Catalogue of Collaborations Presentation Services (Portal and Web) Business Performance Presentation Services Embedded Analytics Search and Query Presentation Services Message / Web Service Gateway Directory / Security Services Routing Transport Messaging Mediation Connectivity and Interoperability services Enterprise Service Bus (ESB) Publish Subscribe Orchestration Load Balancing Operational Applications Operational Applications Metadata Services Metadata Analytical Services Data Warehouse Content Services Unstructured Data Data Services Operational Data Master Data Services Master Data Federate Enterprise Information Integration Discover Stream Profile Cleanse Transform Replicate Deploy IT and Compliance Services Control of Service and Accounting Performance Availability & Fault Security & Privacy Retention Figure 5 - Component Interaction Diagram for Co-Production Hub Scenario (adapted from Godinez, et al 2010 p. 141) Page 7

10 5 Operational Model The Operational Model takes the components from the Component Model and distributes them onto geographically distributed nodes (Godinez, et al 2010 p. 147). Data flow connections between nodes are specified between geographically dispersed Locations. Nodes are location specific and physical platforms on which software executes. Each node consists of one or more components known as Deployment Units (Godinez, et al 2010 p. 149). A Component Model will be broken down into many distinct functional and nonfunctional Operational Models. The EIA RA has templates for many standard components such as those portrayed in Figures 6 and 7. The Content Resource Manager Service availability portrays an industry standard method of maintaining high availability for unstructured data. Likewise the Continuous Availability and Resiliency Operational Pattern portrays a standard design to maintain business continuity and manage disaster risk. Both are very important subsystems in an e- Government information system. Application Server Node (SN 1) L-x.x: SN-x.x: SC-x.x Front Office Systems Zone (L-1.1) JDBC / ODBC (SC-1) JDBC / ODBC (SC-2) Location Type Specified Node Specified Connection Corporate WAN Head Office LAN Branch Office LAN Switching Service Node (SN 3) Switching Service Node (SN 2) Content Resource Manager Service Availability Head Office Location (L-1) Document Library Node (SN-4) - Primary Central Indexing Service Search Service Document Library Node (SN-5) - Standby Central Indexing Service Search Service Operational Systems Zone (L-1.2) Resource Monitor RS232 Heartbeat (SC-3) Resource Monitor FTP (SC-5) I/O (SC-4) Shared Block Subsystem Node (SN 6) FTP (SC-6) FTP (SC-7) Document Resource Manager Node (SN-7) - Primary Digital Content Service High Availability Disaster Recovery (HADR) Service Document Resource Manager Node (SN-8) - Replica Digital Content Service High Availability Disaster Recovery (HADR) Service TCP/IP (SC-8) Branch Office Location (L-2) Operational Systems Zone (L-2.1) Document Resource Manager Node (SN-9) Digital Content Service TCP/IP (SC-9) Retention Node (SN 10) Retention Node (SN 10) TCP/IP (SC-10) Data Services Node - Archive (SN 11) Figure 6 Operational modelling of Content Resource Manager Service Availability (adapted from Godinez, et al 2010 p. 184) Page 8

11 Continuous Availability and Resiliency operational pattern Head Office Location (L-1) Disaster Recovery Site Location (L-2) Front Office Systems Zone (L-1.1) File System Services Node (SN 1) I/O (SC-1) File System Services Node (SN 2) I/O (SC-2) L-x.x: SN-x.x: SC-x.x Location Type Specified Node Specified Connection Corporate WAN Head Office LAN Branch Office LAN Switching Service Node (SN 4) ISL (SC-5) Switching Service Node (SN 7) Switching Service Node (SN 3) FC (SC-3) FC (SC-4) ISL (SC-6) FC (SC-7) Switching Service Node (SN 8) FC (SC-8) Block Subsystem Node (SN 5) Block Subsystem Node (SN 6) Block Subsystem Node (SN 9) Block Subsystem Node (SN 10) Figure 7 - Operational modelling of Continuous Availability and Resiliency Operational Pattern (adapted from Godinez, et al 2010 p. 180) 6 Conclusion A Connected Government requiring a Citizen Centric and Socially Inclusive e-government Information System has been designed using industry standard Enterprise Information Architecture Reference Architecture templates. Having outlined five specific capabilities, a system Building Block diagram and an Architecture Overview Diagram were drawn to provide a conceptual non-technical view of the e-government enterprise information system. From this diagram a Logical Diagram was drawn to translate the concepts into an information system which was then broken down into components which could be described and logic tested in the Component Model. Once all the components were set out they could be further broken down into many Operational Models describing geographically located nodes and their data connections. During each step of the design process, reference has been made to the required e-government Citizen Centric and Socially Inclusive capabilities for which the Enterprise Information System is designed. Page 9

12 References Godinez, Mario, Hechler, Eberhard, Koenig, Klaus, Lockwood, Steve, Oberhofer, Martin and Schroeck, Michael 2010, The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight, IBM Press. King, Stephen and Cotterill, Sarah 2007, Transformational Government? The role of information technology in delivering citizen centric local public services, Local Government Studies, Routledge, UK. Saha, P 2010, 'Enterprise Architecture as Platform for Connected Government', National University of Singapore Institute of Systems Science Report, NUS Institute of Systems Science, < Page 10