Enterprise Information Architecture Connected Government Author name is hidden Date: Friday, 4 September 2015Enterprise Information Architecture - Connected Government ii Table of contents Table of contents ii 1 Introduction 1 2 Conceptual Architecture 1 3 Logical Architecture 3 4 Component Model 4 4.1 Component Relationship Diagram 4 4.2 Component Descriptions 5 4.3 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 9Enterprise Information Architecture - Connected Government Page 1 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. 25-33). 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. 346-350) 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 regulatoryEnterprise Information Architecture - Connected Government Page 2 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. Citizen, Business and organisation Interaction Two-Way Interaction Information services Co-Managed information Policy and security oversight Government Information Government Agents / Employees Government Building Blocks for a Citizen Centric and socially inclusive E-Government Information System Customisable Presentation 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 eGovernment 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.Enterprise Information Architecture - Connected Government Page 3 Master Data Services Master Data Constituents Legislation Govt departments Policies Data Services Operational Data Law Enforcement Planning Policy Development Content Services Unstructured Data Digital Document Archive Information Documents Image repositories Metadata Services Metadata Content Workflows Analytical Services Data Warehouse Data Domains Batch (near) real-time Enterprise Information Integration Service-Oriented Security and Privacy Services Data Masking Encryption Authentication Authorisation Audit Cloud Services Metering Monitoring Billing Pricing Virtualisation Elastic Capacity Managed service 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 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 eGovernment. 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 Management 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’.Enterprise Information Architecture - Connected Government Page 4 IT Service and Compliance Management Services Capabilities for Cloud Service Delivery Services Master Data Services Master Data Data Services Operational Data Content Services Unstructured Data Metadata Services Metadata Analytical Services Data Warehouse Information Services Enterprise Information Integration Services Discover Cleanse Federate Stream Profile Transform Replicate Deploy Application Services Collaboration Information delivery / search Information Co-production Presentation Services and Delivery Channels Web Mobile Applications Portal Business Process Orchestration and Collaboration Connectivity and Interoperability Information Security and Information Privacy 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.Enterprise Information Architecture - Connected Government Page 5 Discover Enterprise Information Integration Cleanse Federate Profile Transform Replicate Deploy Stream IT and Compliance Management Services Retention Management Control of Service and Accounting Security & Privacy Management Availability & Fault Management Performance Management Master Data Services Master Data Data Services Operational Data Content Services Unstructured Data Metadata Services Metadata Analytical Services Data Warehouse Connectivity and Interoperability services Enterprise Service Bus (ESB) Messaging Mediation Orchestration Load Balancing Publish Subscribe Routing Transport Infrastructure Security Component Operational Applications Operational Applications Operational Applications Collaboration Services Business Process Services Service Registry and Repository Presentation Services (Portal and Web) Business Performance Presentation Services Embedded Analytics Search and Query Presentation Services Message / Web Service Gateway Directory / Security Services Delivery Channels Mobile Applications Web Enterprise Portals Productivity / Collaboration UI Enterprise Search UI Collaboration Hub Information CoProduction Hub Catalogue of Portals Catalogue of Collaborations 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. 104-106). 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 secureEnterprise Information Architecture - Connected Government Page 6 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. 346-350). 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.Enterprise Information Architecture - Connected Government Page 7 Discover Enterprise Information Integration Cleanse Federate Profile Transform Replicate Deploy Stream IT and Compliance Management Services Retention Management Control of Service and Accounting Security & Privacy Management Availability & Fault Management Performance Management Master Data Services Master Data Data Services Operational Data Content Services Unstructured Data Metadata Services Metadata Analytical Services Data Warehouse Connectivity and Interoperability services Enterprise Service Bus (ESB) Messaging Mediation Orchestration Load Balancing Publish Subscribe Routing Transport Infrastructure Security Component Operational Applications Operational Applications Operational Applications Collaboration Services Business Process Services Service Registry and Repository Presentation Services (Portal and Web) Business Performance Presentation Services Embedded Analytics Search and Query Presentation Services Message / Web Service Gateway Directory / Security Services Delivery Channels Mobile Applications Web Enterprise Portals Productivity / Collaboration UI Enterprise Search UI Collaboration Hub Information CoProduction Hub Catalogue of Portals Catalogue of Collaborations Figure 5 - Component Interaction Diagram for Co-Production Hub Scenario (adapted from Godinez, et al 2010 p. 141) (1) Login (2) auth. Information Co-Production Portal Access ScenarioEnterprise Information Architecture - Connected Government Page 8 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 eGovernment information system. Content Resource Manager Service Availability Document Library Node (SN-4) - Primary Central Indexing Service Resource Monitor Search Service Document Library Node (SN-5) - Standby Central Indexing Service Resource Monitor Search Service Document Resource Manager Node (SN-7) - Primary Digital Content Management Service High Availability Disaster Recovery (HADR) Service Document Resource Manager Node (SN-8) - Replica Digital Content Management Service High Availability Disaster Recovery (HADR) Service Document Resource Manager Node (SN-9) Digital Content Management Service Shared Block Subsystem Node (SN–6) Data Services Node - Archive (SN–11) Retention Management Node Retention Management Node (SN–10) (SN–10) Switching Service Node (SN–3) Switching Service Node (SN–2) Application Server Node (SN–1) Head Office Location (L-1) Front Office Systems Zone (L-1.1) Operational Systems Zone (L-1.2) Branch Office Location (L-2) Operational Systems Zone (L-2.1) L-x.x: Location Type SN-x.x: Specified Node SC-x.x Specified Connection Corporate WAN Head Office LAN Branch Office LAN JDBC / ODBC (SC-1) FTP (SC-6) RS232 Heartbeat (SC-3) FTP (SC-5) TCP/IP (SC-8) FTP (SC-7) JDBC / ODBC (SC-2) I/O (SC-4) TCP/IP (SC-9) TCP/IP (SC-10) Figure 6 – Operational modelling of Content Resource Manager Service Availability (adapted from Godinez, et al 2010 p. 184)Enterprise Information Architecture - Connected Government Page 9 Continuous Availability and Resiliency operational pattern Switching Service Node (SN–4) Switching Service Node (SN–3) File System Services Node (SN–1) Head Office Location (L-1) Front Office Systems Zone (L-1.1) Disaster Recovery Site Location (L-2) File System Services Node (SN–2) Block Subsystem Node (SN–5) Block Subsystem Node (SN–6) Block Subsystem Node (SN–9) Block Subsystem Node (SN–10) Switching Service Node (SN–8) Switching Service Node (SN–7) L-x.x: Location Type SN-x.x: Specified Node SC-x.x Specified Connection Corporate WAN Head Office LAN Branch Office LAN I/O (SC-1) I/O (SC-2) FC (SC-3) FC (SC-4) ISL (SC-5) ISL (SC-6) FC (SC-8) FC (SC-7) 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.Enterprise Information Architecture - Connected Government Page 10 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,