Assignment
milangrg49
ICT_Task1_sample.pdf
Enterprise Information Architecture
Connected Government
Author name is hidden
Date: Friday, 4 September 2015
Enterprise 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 9
Enterprise 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 regulatory
Enterprise 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, Busi ness and organis ation Interaction
Two-Way Interaction Information services Co-Managed informatio n
Policy and security oversight
Government Information Government Agents /
Employees
Government
Building Blocks for a Citizen Centric and socially inclusive E-Government Information System
Customi sable 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 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.
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
Enterprise Information IntegrationBatch (near) real-time Service-Oriented
Security and Privacy Services
Data M ask ing Encryption
Authentication Authorisation
Audit
Clou d Services
Metering Monitoring
Billing Pricing
Virtualisation Elastic Capacity
Managed service
E-Go vern ment In teraction Systems
Policy formulation Interaction
E-Go vern ment Information Systems
Information Service Applications
Co-Managed Inf ormation Service App lications
Government Enterpri se Search
Presentation Services and delivery channels
Portal Web
Mobil e Applications
Connectivity and Ineteroperability Service IntegrationJMS, MQ, FTP, (a)synchronous
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 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 ‘co- managed 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
Information delivery / search Information Co-productionCollaboration
Presentation Services and Delivery Channels
Mobile Applications PortalWeb
Bu si
ne ss
P ro
ce ss
O rc
he st
ra ti
on a
nd C
ol la
bo ra
tio n
Co nn
ec tiv
it y
an d
In te
ro pe
ra bi
lit y
In fo
rm at
io n
Se cu
ri ty
a nd
In fo
rm at
io n
Pr iv
ac y
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
En te
rp ri
se In
fo rm
at io
n In
te gr
at io
n D
is co
ve r
Cl ea
ns e
Fe de
ra te
St re
am Pr
of ile
Tr an
sf or
m Re
pl ic
at e
D ep
lo y
IT a
nd C
om pl
ia nc
e M
an ag
em en
t S er
vi ce
s
Re te
nt io
n M
an ag
em en
t Co
nt ro
l o f S
er vi
ce a
nd
Ac co
un tin
g Se
cu ri
ty &
P ri
va cy
M
an ag
em en
t Av
ai la
bi lit
y &
F au
lt M
an ag
em en
t Pe
rf or
m an
ce
M an
ag em
en t
Master Data Services
Master Data
Data Services
Operational Data
Content Services
Unstructured Data
Metadata Services
Metadata
Analytical Services
Data Warehouse
Co nn
ec tiv
it y
an d
In te
ro pe
ra bi
lit y
se rv
ic es
En te
rp ri
se S
er vi
ce B
us (E
SB )
M es
sa gi
ng
M ed
ia tio
n O
rc he
st ra
tio n
Lo ad
B al
an ci
ng Pu
bl is
h Su
bs cr
ib e
Ro ut
in g
Tr an
sp or
t
In fr
as tr
uc tu
re S
ec ur
it y
Co m
po ne
nt
Operational Applications
Operational Applications
Operational Applications
Collaboration Services
Busi ness Proces s Services
Service Registry and Repository
Presentation S ervices (Portal and Web)
Busi ness Performance Presentation S ervices
Embedded Analytics
Search and Query Presentation S ervices
Message / Web Service Gateway
Directory / Security Services
D el
iv er
y Ch
an ne
ls
M ob
ile
Ap pl
ic at
io ns
W eb
En te
rp ris
e Po
rt al
s Pr
od uc
tiv ity
/
Co lla
bo ra
tio n
U I
En te
rp ris
e Se
ar ch
U
I
Collaboration H ub
Information Co- Production 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 secure
Enterprise 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
En te
rp ri
se In
fo rm
at io
n In
te gr
at io
n D
is co
ve r
Cl ea
ns e
Fe de
ra te
St re
am Pr
of ile
Tr an
sf or
m Re
pl ic
at e
D ep
lo y
IT a
nd C
om pl
ia nc
e M
an ag
em en
t S er
vi ce
s
Re te
nt io
n M
an ag
em en
t Co
nt ro
l o f S
er vi
ce a
nd
Ac co
un tin
g Se
cu ri
ty &
P ri
va cy
M
an ag
em en
t Av
ai la
bi lit
y &
F au
lt M
an ag
em en
t Pe
rf or
m an
ce
M an
ag em
en t
Master Data Services
Master Data
Data Services
Operational Data
Content Services
Unstructured Data
Metadata Services
Metadata
Analytical Services
Data Warehouse
Co nn
ec tiv
it y
an d
In te
ro pe
ra bi
lit y
se rv
ic es
En te
rp ri
se S
er vi
ce B
us (E
SB )
M es
sa gi
ng
M ed
ia tio
n O
rc he
st ra
tio n
Lo ad
B al
an ci
ng Pu
bl is
h Su
bs cr
ib e
Ro ut
in g
Tr an
sp or
t
In fr
as tr
uc tu
re S
ec ur
it y
Co m
po ne
nt
Operational Applications
Operational Applications
Operational Applications
Collaboration Services
Busi ness Proces s Services
Service Registry and Repository
Presentation S ervices (Portal and Web)
Busi ness Performance Presentation S ervices
Embedded Analytics
Search and Query Presentation S ervices
Message / Web Service Gateway
Directory / Security Services
D el
iv er
y Ch
an ne
ls
M ob
ile
Ap pl
ic at
io ns
W eb
En te
rp ris
e Po
rt al
s Pr
od uc
tiv ity
/
Co lla
bo ra
tio n
U I
En te
rp ris
e Se
ar ch
U
I
Collaboration H ub
Information Co- Production 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 Scenario
Enterprise 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 non- functional 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.
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 (SN–10)Retention Management Node
(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, <http://unpan1.un.org/intradoc/groups/public/documents/unpan/unpan041801.pdf>
- Table of contents
- 4.1 Component Relationship Diagram
- 4.2 Component Descriptions
- 4.3 Component Interaction Diagram
- References
