NZ Government End User Computing Reference Architecture

- From Vision and Direction to Deployment

GEA-NZ Viewpoint:
COE Reference Architecture

Release 1

Doug Newdick
DIA Enterprise Architect

Tim Woodill
DIA Programme Architect

Paul Headland
NZQA Infrastructure Architect

Unclassified

Document control
Crown copyright ©. This copyright work is licensed under the Creative Commons Attribution 3.0 New Zealand licence. In essence, you

are free to copy, distribute and adapt the work, as long as you attribute the work to the Department of Internal Affairs and abide by the
other licence terms. To view a copy of this licence, visit http://creativecommons.org/licenses/by/3.0/nz/. Please note that neither the Department of Internal

Affairs emblem nor the New Zealand Government logo may be used in any way which infringes any provision of the Flags, Emblems, and Names Protection

Act 1981 or would infringe such provision if the relevant use occurred within New Zealand. Attribution to the Department of Internal Affairs should be in
written form and not by reproduction of the Department of Internal Affairs‟ emblem or New Zealand Government logo.

Document information
Project ID/Name Common Operating Environment (COE) Programme
Author Doug Newdick
Title Enterprise Architect, GTS Architecture, Government Technology Services
File name GEA-NZ Viewpoint - COE Reference Architecture.doc
DMS reference GCI - 3216421DA

Revision history
Version Date Author Description of changes
0.1 13/07/2012 Doug Newdick Initial version for review
0.2 17/07/2012 Doug Newdick Updated based on initial COE Programme feedback.
0.3 18/07/2012 Doug Newdick Update including changes from Brian More, Chief
Architect. Also updated to include the addition of an
Executive Summary and formatting enhancements.
0.4 06/08/2012 Doug Newdick Updated to ensure further alignment to the
Government Enterprise Architecture (GEA-NZ).
0.5 14/08/2012 Doug Newdick Updated with Community of Practice feedback.
0.6 15/08/2012 Doug Newdick General enhancements including updated formatting
and pictures.
0.7 29/08/2012 Doug Newdick Updated based on GEAG feedback.
0.8 30/08/2012 Doug Newdick Final updates for candidate release 1.
1.0 26/09/2012 Doug Newdick Final release 1. Updates based on agency feedback.

Distribution list
Name Role Group
Brian More Chief Architect GTS, DIA
James Collier MoJ Chief Architect/GEAG MoJ
Representative
Ron Peake COE Programme Manager GTS, DIA
Sheryl Tunbridge DIA Desktop Services GTS, DIA
Manager

Department of Internal Affairs 3
DMS Library: GCI Document ID: 3216421DA

Document approval

4 Department of Internal Affairs

Glossary of abbreviations and terms

COE The Common Operating Environment (COE) is an approved set of
computing architectures, standards and technologies that provides a
framework for New Zealand government agencies to develop
common solutions to providing secure and interoperable agency
end user computing environments.
Each end user computing environment has a minimum standard
configuration that supports an agency‟s ability to quickly produce
and deploy high-quality applications, and reduce the complexities of
configuration, support and training associated with the computing
environment.
FC Functional Component – a technology/implementation neutral
description of a piece of coherent functionality that can be delivered
or implemented independently. An FC is a type of technical
capability, subordinate to a Government Enterprise Architecture
(GEA-NZ) Block.
FG Functional grouping – A higher level grouping of FCs grouped
together because of a high level of coherence, shared
characteristics and potential dependencies. An FG is a type of
technical capability within the section of GEA-NZ reserved for
reference architectures.
SOE Standard Operating Environment (SOE) – an agency‟s specific
standardised desktop or end user computing environment(s). It
includes both elements deployed to end devices and the associated
management tools.

References
No. Title Author Version Date
1 COE Business Case Belinda Hill/Ron Peake 5.0 10/08/2012

2 National Workspace Vision Sharp Elephant 1.0 23/05/2012

3 National Workspace Reference Architecture Sharp Elephant 1.0 23/05/2012

4 GEA-NZ v2.0 GTS Architecture 0.1 26/07/2012

5 Directions and Priorities for Government ICT 1.0

6 NZISM Government 1.1 June 2011
Communications Security
Bureau


Contents
Document control 3

Document approval 4

Glossary of abbreviations and terms 5

References 5

1. Executive Summary 9

2. Introduction 10
2.1 Purpose 10
2.2 Intended Audience 10
2.3 Scope 10
2.4 The Elements of the Reference Architecture 11
2.5 Document Roadmap 13
2.6 Alignment with Directions & Priorities 14
2.7 GEA-NZ Fit 14

3. How To Use the Reference Architecture 16

4. The COE Architectural Vision 18

5. COE Principles 19

6. COE Component Architecture 21
6.1 Functional Grouping 1: Devices 23
6.2 Functional Grouping 2: Operating Systems 26
6.3 Functional Grouping 3: End User Applications 27
6.4 Functional Grouping 4: Application Delivery Services 29
6.5 Functional Grouping 5: Configuration Management 33
6.6 Functional Grouping 6: User State Management 34
6.7 Functional Grouping 7: Security Management 34

7. Related and Dependent Functional Components 36
7.1 Functional Grouping 10: Networks 38
7.2 Functional Grouping 11: Utility Compute Services 38
7.3 Functional Grouping 12: Storage 39
7.4 Functional Grouping 13: Identity and Access Management 39
7.5 Functional Grouping 14: Print Services 39
7.6 Functional Grouping 15: Communication Services 40
7.7 Functional Grouping 16: Physical Services 41
7.8 Functional Grouping 17: ICT Management 41

8. Requirements 41

9. Standards 41
9.1 Operating System Standards 42
9.2 End User Application Standards 43
9.3 Security Standards 44
9.4 Network Standards 45


10. Guidelines 47
10.1 Device Guidelines 48
10.2 Operating System Guidelines 49
10.3 Application Guidelines 51
10.4 Application Delivery Guidelines 53
10.5 Configuration Management Guidelines 53
10.6 User State Management Guidelines 54
10.7 Security Management Guidelines 55
10.8 Utility Compute Guidelines 56
10.9 Storage Guidelines 56
10.10 Identity and Access Management Guidelines 57
10.11 ICT Management Guidelines 57
10.12 Miscellaneous Guidelines 58

11. Sample Solution Architectures 58

12. Sample Technology Solution Sets 58

Appendix A COE Components in GEA-NZ 59

Appendix B Mapping to HealthBase Reference Architecture 64

Table of tables
Table 1 Reference Architecture Elements 12
Table 2 Architectural Principles 19
Table 3 Summary of Standards 42
Table 4 Summary of Guidelines 47

Table of figures
Figure 1 COE Reference Architecture Elements 11
Figure 2 GEA-NZ Technical Reference Architecture Metamodel 14
Figure 3 COE Reference Architecture GEA-NZ fit 15
Figure 4 The Relationship Between COE and SOE 17
Figure 5 Architectural Vision 18
Figure 6 COE Component Architecture Overview 21
Figure 7 COE Functional Groupings and Components 22
Figure 8 Related and Dependent Components Overview 36
Figure 9 Related and Dependent Functional Components 37


1. Executive Summary
GEA-NZ Viewpoint: COE Reference Architecture describes the architectural building blocks to help
agencies enable their future end user computing environment. In particular, an environment that
meets the needs of their staff and assists them to deliver services to citizens and other
stakeholders while investing taxpayers‟ money wisely. It describes a superset of capabilities for
hardware devices and software environments intended to be operated by business users in
government agencies.

Agencies can leverage the Common Operating Environment (COE) Reference Architecture as a
common language to describe their existing or future end user computing environments. This
common language, underpinned by the Government Enterprise Architecture for New Zealand
(GEA-NZ), will enable agencies to more easily re-use common capabilities and share artefacts and
collateral.

For agencies beginning their efforts to migrate off Microsoft Windows XP and Office 2003, this
reference architecture gives them a head-start by providing a significant amount of initial
architecture work as well as access to cross-agency advice on how best to approach this problem.
For agencies that have already started or even completed such a migration, this reference
architecture provides a check-list of capabilities and standards to ensure their solutions are
comprehensive. Common capabilities in the end user device zone will use the language of the COE
Reference Architecture to classify their solutions, allowing those who have used this reference
architecture to more easily consume them.

Transitioning from Windows XP is regarded worldwide as a significant problem. The success of
Windows XP as a platform has led to its almost universal adoption across government. However,
the way most organisations have deployed and managed Windows XP means that migrating off XP
requires significant (in terms of cost and effort) replacement or remediation of applications and
management infrastructure.

It is critical to address the issue of migrating government agencies off Windows XP before the end
of extended support in April 2014. However, this migration should not be done in a way that re-
creates the problem of XP on a different operating system or that locks agencies into a high-cost
solution or a solution that is not fit for purpose. To avoid these risks, this reference architecture is
targeted at ensuring future device and platform independence that takes advantage of the rapid
pace of technological innovation in the consumer space. As a means to sever the link between the
applications and data that users need to deliver agency outcomes and the operating systems that
constrain agencies today, the COE Reference Architecture recommends that agencies:

 deliver applications using application virtualisation
 deliver web-enabled business applications
 explore desktop virtualisation.
This reference architecture gives agencies a framework and method for creating an end user
computing environment that enables public servants to become empowered ICT workers and helps
deliver smart government. At the same time, the reference architecture assists them in approaching
the migration off Windows XP. Agencies can create solution architectures based on this reference
architecture, or use the sample architectures supplied to quick-start their efforts. Requirements are
provided in a modular fashion to give agencies most of their requirements – those that are common
to desktops across the public sector – and allow them to focus their energies on agency-specific
requirements and solutions.


Future releases of the reference architecture will contain additional material of benefit to agencies.
For the latest version of this document please go to ict.govt.nz.

2. Introduction
2.1 Purpose
The purpose of this document is to outline how the different parts of the COE Reference
Architecture are inter-related, to describe in detail the different parts of the reference architecture
and to describe how the reference architecture can be used to assist an agency in creating its own
Standard Operating Environment (SOE).

2.2 Intended Audience
This document is intended to be read by architects (Chief Architects, Enterprise Architects, Solution
Architects and Infrastructure Architects), project teams, operational teams (agency or outsourced),
ICT managers and staff of systems integrators who are looking at or working on agency
approaches to migrating end user computing environments to the Common Operating Environment
(COE) framework.

2.3 Scope
This COE Reference Architecture covers the key aspects of delivering and managing applications
and data to end user devices. In particular, it includes:

1. Managing end user devices, their configurations and their operating systems.
2. Packaging and deploying applications.
3. Those elements of end user computing environments that are common to mobile and non-
mobile computing.
4. Security of end user devices.
5. Virtual desktops.
6. Environments that handle data up to and including a classification of RESTRICTED.
Its specific scope does not include the delivery of the following items, though it may reference or
describe them where the items delivered are dependent on them:

1. Mobile specific elements such as dumb mobile phones and Mobile Device Management
(MDM).
2. Servers, server operating systems or server environments.
3. Environments that handle information of a classification of CONFIDENTIAL or above.
4. Business applications (except in the sense of being able to package, deploy and manage
clients).
5. Server side applications.
6. Software asset management.
7. Identity and Access Management (I&AM).
8. Peripherals or printers.


2.4 The Elements of the Reference Architecture
The following diagram shows how the different elements of the COE Reference Architecture are
interrelated.

Vision

Principles

Process Architecture Component Architecture
Requirements Requirements

Standards Standards

Guidelines Guidelines

Solution Architectures
Solution Requirements

Technology Solution Sets
Requirements Compliance

Figure 1 COE Reference Architecture Elements

These elements are described in detail in the following table.


Table 1 Reference Architecture Elements

Element Description
Vision The vision gives us a high level view of our future state. The rest of the
elements should contribute towards achieving that vision

Principles The principles are a set of guiding statements that will help us achieve that
vision. These principles should be used to inform the development of the
rest of the architecture, to evaluate architectural outputs and to contribute to
making architectural decisions.

Component The component architecture is a set of technology and implementation
Architecture neutral components (and groupings) that describe all of the functionality that
could comprise an agency‟s SOE. The component architecture includes
more components than any particular agency would use as it must cover all
of the possible combinations. It cannot and should not be implemented as it
is.

Process Architecture The process architecture is a set of processes for delivering, managing
and maintaining an agency SOE.

At this point in time the Process Architecture is under development and is
not included in this document.

Requirements The requirements are a set of functional and non-functional requirements
that are assigned to the different groupings and components of the
component architecture. They specify the agency requirement against that
component or grouping. Requirements are taken from a range of sources
including the NZ Information Security Manual (NZISM), contributed agency
requirements and industry leading practice. Taken together, the
requirements for all of the components that an agency selects as part of its
SOE will form the bulk of the agency‟s requirements for its SOE.

At this point in time the Requirements are under development and are not
included in this document.

Standards The standards are a set of published open standards that apply to different
parts of the component and process architecture. Each standard will be
associated with a particular grouping, component or process. Components
and processes that are deployed as part of an SOE should comply with the
standards relevant to those components and processes.

Guidelines Guidelines are a set of directives, advice and recommendations around the
use or deployment of parts of the component architecture.


Solution Architectures Solution Architectures are examples of how to take the reference
architecture and select the relevant parts to create a complete (technology
neutral) SOE architecture. These samples may be used as illustrations, or
as patterns for the creation of an agency SOE.

At this point in time the Solution Architectures are under development and
are not included in this document.

Technology Solution The technology solution sets are examples of solution architectures that
Sets are implemented with particular technologies (hardware and software
products) in particular configurations incompliance with the standards and
guidelines of the reference architecture, and that meet the requirements of
the reference architecture.

At this point in time the Technology Solution Sets are under development
and are not included in this document.

2.5 Document Roadmap
This is Release 1 of the GEA-NZ Viewpoint: COE Reference Architecture. This document will be
expanded over several releases in order to complete the reference architecture elements over time
and to incorporate additional elements as required by agencies.

Release 1 incorporates:

 Completed Vision
 Completed Principles
 Completed Component Architecture
 Initial Standards
 Initial Guidelines
Release 2 is intended to additionally incorporate:

 Requirements
 Additional Standards
 Additional Guidelines
 Initial Solution Architectures
 Initial Technology Solution Sets
 Any revisions required to the component architecture.
Release 3 is intended to additionally incorporate:

 Process Architecture

 Additional Standards
 Additional Guidelines
 Additional Solution Architectures


 Additional Technology Solution Sets
 Any revisions required to the rest of the architecture.

2.6 Alignment with Directions & Priorities
This GEA-NZ Viewpoint: COE Reference Architecture directly contributes to fulfilling the Directions
and Priorities for Government ICT. Specifically it contributes to the following directions:

 Direction 4 - Strengthen cross-government business capability
 Direction 5 – Improve operational ICT management
The COE Reference Architecture will do this by:

1. Enabling cross-agency collaboration and sharing of collateral and best practices in end user
computing.
2. Standardisation of end user computing environments and associated processes through
architectures, standards and recommendations.
3. Engaging with industry to improve delivery and management of end user computing
environments.
4. Supporting the COE Programme‟s aims around standardisation consolidation.

2.7 GEA-NZ Fit
The COE Reference Architecture is a viewpoint of the Government Enterprise Architecture for New
Zealand (GEA-NZ). That is, it is a selection of elements from GEA-NZ that can be used to describe
the COE, organised in a way that is relevant to the purposes of the COE. In particular the
Component Architecture is a superset of Functional Components from GEA-NZ that describe the
potential components that could be used to deliver an end user device environment in an agency.

Figure 2 GEA-NZ Technical Reference Architecture Metamodel


Reference architectures within GEA-NZ consist of particular views that are relevant to the purposes
of the reference architecture, bringing together relevant elements of GEA-NZ in a way that suits
those purposes. The diagram above shows how Functional Groupings and Functional Components
of a reference architecture are related to the Zones and Blocks of GEA-NZ.

The following picture gives a high-level view of the GEA-NZ Blocks and GEA-NZ Zones involved in
delivering the COE. Orange diamonds represent a Zone or Block where the COE Reference
Architecture directly uses Functional Components. A yellow triangle represents a Zone or Block
where the COE Reference Architecture interfaces to, or depends upon, Functional Components in
that capability. A more detailed breakdown of the Zones, Blocks and Functional Components that
form the COE Component Architecture is given in sections 6 and 7. A more detailed breakdown of
where the COE Reference Architecture Functional Components fit within GEA-NZ is given in
Appendix A.

Figure 3 COE Reference Architecture GEA-NZ fit


3. How To Use the Reference Architecture
An individual agency should use the COE Reference Architecture in the following way:

1. Incorporate the COE Reference Architecture into their Enterprise Architecture, or align their
Enterprise Architecture with it.
2. Create a Solution Architecture by selecting the functional groupings and components from
the COE Reference Architecture that are relevant to the type of solution they are looking to
create, or by selecting one of the sample solution architecture from those in the reference
architecture and adapting it to their circumstances. Additional components outside the
scope of the COE Reference Architecture may need to be added to meet an agency‟s
specific circumstances.
3. Through the associations with the selected components the agency will have a list of
requirements, standards and guidelines for the solution architecture. This should form the
bulk of the agency‟s requirements for their SOE.
4. The agency should supplement these requirements with its own agency specific
requirements, and remove any of the COE Reference Architecture requirements that do not
apply (articulating the reason for removal). The agency will then have a more complete set
of requirements for its SOE.
5. The Solution Architecture should be revised and refined in light of the complete SOE
requirements set.
6. Look for re-use opportunities among common capabilities or collateral or solutions provided
by other agencies. This will be made easier by the use of the common language of the COE
Reference Architecture.
7. The agency should select specific technologies (i.e. hardware and/or software products) to
create a technology solution set that realises this solution architecture, or select one of the
sample technology solution sets from the reference architecture and adapting it to their
circumstances.
8. From this solution set the agency can create a design of their SOE and begin to build and
deploy it.
9. Where agencies have additional learning developed in their own agency that may further
enhance the value of the Government Enterprise Architecture (GEA-NZ), and specifically
this COE Reference Architecture, feedback is welcomed to aid in cross-agency knowledge
capture and enhancements to GEA-NZ and this document.


The following diagram gives a high-level overview of how the COE Reference Architecture is to be
used to create an agency specific SOE.

Technology Specific Solutions

Solution Solution Solution
Set 1 Set 2 Set 3
Technology Neutral COE Architecture

End User Computing
Requirements

Standards
Management

Operations and Maintenance

Transition

Agency
Tailoring Process Requirements

Agency Specific Standard
Operating Environment (SOE)

Figure 4 The Relationship Between COE and SOE


4. The COE Architectural Vision
The architectural vision gives a high level description of the future state that the programme is
trying to enable and deliver. The architectural vision that the COE Programme is supporting can be
illustrated with the following diagram.

Public Servants as Empowered ICT Workers Engaging with Citizens, Customers & Partners
COE enables  Device independent access to business Where, How and When They Want
applications and data.  Supporting more interactions over online and
 Cross-government collaboration and information social media channels.
management tools enhance productivity and  Consistency of interactions.
effectiveness.  Government portal.
COE delivers  Ability to work anywhere, anytime.  Increased use of B2B interactions and e-
COE delivers  Personalisation and choice. commerce.
COE delivers  Take advantage of advances in consumer  Increased use of partners to deliver information
COE enables
computing to rapidly deploy tools that workers and services.
understand.

Future State of Government ICT
The Standardised Government Cloud Smart Government
COE delivers  Agencies will consume standardised all-of-  ICT supporting innovation.
government services, and deploy standardised all-  Collaboration between citizens, government
of-government solution sets. workers/agencies.
COE delivers  A utility approach to commoditised ICT services  Information technology embedded in the fabric of COE enables

and resources. government - physical and social.
COE enables  Common services delivered from a “Government  Planning, management and operations based on
Cloud”. real-time analysis of real-time data.
COE delivers  Widespread use of agreed standards and common  Use of lean and agile development models.
data formats.  Information crossing silos and boundaries.

Figure 5 Architectural Vision


5. COE Principles
These architectural principles are intended to assist in delivering against the desired business
outcomes of the COE Programme. They are a set of guiding statements that will help us achieve
that vision. These principles should be used to inform the development of the rest of the
architecture, to evaluate architectural outputs and to contribute to making architectural decisions.
The principles were developed by the COE Programme Architects‟ Community of Practice (Co)
which included both agency and vendor representatives using the principles developed by Health
Alliance in their National Workspace Reference Architecture [3]. The principles are derived from the
problem statement and business drivers as described in the COE Programme Business Case [1],
and the architectural vision outlined in section 4.

Table 2 Architectural Principles

No. Name Description
1 Minimise lock-in The architecture should incorporate maximum technical and
commercial flexibility to minimise the lock in to: any particular
technology for a component; any particular solution set; and, any
particular solution vendor.

2 Platform and Client devices can be independent of specific technology choices
connectivity and therefore can operate on a variety of organisational and
independence technology platforms.

Accordingly, connectivity should not be restricted to any specific
delivery channels.

3 Lower lifecycle TCO The architecture should deliver a lower total cost of ownership
throughout the entire lifecycle for end user computing (and
particularly the desktop) for the New Zealand government.

4 Secure by design Security should not be an afterthought or add-on. Security
considerations should begin with the requirements phase of
development and be treated as an integral part of the overall system
design.

5 Interoperability The architecture should maximise the ability of components of the
solutions to work with other components of the solution, and with the
wider enterprise needs.

6 Independent of delivery The architecture should support different models for delivery of end
and service choices user computing (e.g. virtualisation, desktop as a service) and
different service models (e.g. outsourced, insourced or hybrid).

7 Supportability All of the components that make up Workspace must be supportable
individually and as a whole.


No. Name Description
8 Integrated solution The architecture will deliver solutions composed of reusable modular
components and services where possible. Where this is not
possible, integrated application and infrastructure components will be
used.

9 Maximise ROI in end The architecture should maximise the return on the NZ government‟s
user computing current investment in end user computing technologies and
commercials.

10 Mobility The ability to provide secure access to the required data and
applications regardless of location or device. Consideration should
be given to providing secure access regardless of device ownership
(i.e. Bring Your Own Device policies).

11 Reduce Diversity The architecture aims to maximise business benefits by reducing the
unnecessary diversity in end user solutions and technologies.

12 Enduring and The architecture will be enduring in that it will last and be continually
Sustainable improved over time and the cost of maintaining and improving it over
time will be sustainable.

13 Improved Usability The architecture will deliver solutions which provide improved
usability for staff and stakeholders of government agencies. End user
computing environments should enable and support people in
achieving their jobs. This will increase staff productivity and aid buy-
in for solutions.


6. COE Component Architecture
The COE Component Architecture is a technology neutral description of a superset of the
Functional Components that could make up an agency standard operating environment. Each
component is described in terms of the functionality that it delivers rather than in terms of how it will
be implemented or the technology (software or hardware) that will deliver it.

A Functional Component (FC) is a chunk of functionality that is relatively coherent and delivers
independent outcomes. Functional Components are grouped together under GEA-NZ Blocks,
which are grouped into GEA-NZ Zones. The list of Functional Components here is superset of all of
the components that could be part of complete Standard Operating Environment for an agency, but
an agency may not need a solution for every Functional Component. A particular solution set will
deliver a range of Functional Components – not all Functional Components will be present in a
particular technology solution set. As part of this reference architecture, Functional Components
are grouped together into functional groupings which are based on the coherence of the grouped
components.

This section describes all of the Functional groupings and Functional Components that form part of
the Common Operating Environment. Functional groupings and Functional Components that are
not part of the COE, but that the COE is dependent upon are covered in section 7. Where each of
these Functional Components fits within GEA-NZ is described in Appendix A.

The following picture shows the Functional groupings that make up the COE Component
Architecture. These Functional groupings are aligned to specific GEA-NZ zones. These
components are described in detail in this section of the reference architecture.

Figure 6 COE Component Architecture Overview

The following diagram shows a detailed view of the FCs that are directly delivered by the COE
Reference Architecture within their Functional groupings. The FCs are described in detail in the
following sections for their respective Functional groupings.


Figure 7 COE Functional Groupings and Components


6.1 Functional Grouping 1: Devices

Functional Grouping 1 is aligned with the GEA-NZ End User Devices Zone. Devices are hardware
platforms that support a user interface through which you can access systems, applications or
information that is provided by the computing platforms. In the past, standardisation of devices was
the only way to assure compatibility with software, but compliance with standards now makes
device selection simpler. Standardisation, however, should be considered from the buying power,
support, spares and training point of view in line with the COE principles of lower lifecycle TCO and
reducing diversity.

Traditionally the focus of end user device solutions in government agencies has been on agency-
owned devices. Today the consumerisation of IT and the growing popularity of virtual desktop
solutions means that agencies should explicitly consider the role that staff owned devices will play
in the overall architecture and solution. In particular the growing interest in Bring Your Own Device
(BYOD) approaches should be factored in to any solution as well as the use of personal home
computers as a means of accessing agency applications and data through remote access solutions
(especially the use of virtual desktops in this role).

ID Name Description
GEA: Thin Device A Thin Device boots from a lightweight operating system that loads
3.1.01.01 minimal services and allows connection to a virtual desktop
infrastructure or application presentation services. Application and
data processing is performed “in the data centre” rather than by the
device.

Thin devices could be utilised where the need for a Fat Device is not
justified. Thin devices could provide advantages in areas where staff
need to share devices, for example. Implemented correctly, the use
of thin devices and enabling technologies such as swipe card
authentication should remove the requirement for generic user
accounts.

GEA: Zero Client A Zero Client is a thin device that has the OS and a Virtual Desktop
3.1.01.02 Client running in firmware. They typically lower cost than thin clients,
but are less flexible. In general they will have lower energy
consumption, are less customisable and will have specialised central
management tools. Many zero clients come as displays with the OS
and virtualisation client built in.

Department of Internal Affairs
DMS Library: GCI Document ID: 3216421DA Page 23 of 64

ID Name Description
GEA: Fat Device - A Fat Device boots from local storage, has a full Operating System
3.1.01.03 Desktop installed and performs the majority of processing locally.

Access to fat devices will be required by some of the user profiles.
There will be systems that require local client software, local
processing or do not support Presentation Virtualisation technology.
Fat device is currently the most commonly used device. Future
methods for the deployment and management of software and
updates to these devices will change dramatically from the standard
base image approach of the past.

Technologies such as application virtualisation, presentation
virtualisation and enhancements in roaming profile technology, will
dramatically reduce the maintenance required to keep the
applications and operating systems of these devices up to date. It
will also allow for more agile delivery of applications to users rather
than devices. Because of the high number of these devices in use
today, transitional strategies may need to be developed to allow their
continued usage until replacement occurs.

Desktops are fat devices that are not portable.

GEA: Fat Device - Laptop Laptops are Fat Devices that are portable. In most respects they are
3.1.01.04 identical to Fat Device – Desktop, but care is required to consider
issues around security, offline usage and management due to their
portability. They will require different policies and configuration to
maximise the specific benefits and minimise specific risks associated
with them.

GEA: Repurposed PCs A Repurposed PC is a fat device (desktop or laptop) that has been
3.1.01.05 repurposed to be managed as a thin device. It may be an older
specification machine that is no longer suitable for running a full (up
to date) operating system. A specialised, lightweight thin client
operating system can be installed onto the device to allow it to be re-
purposed to function as a virtual desktop device (Thin Device). It is
possible that these device will be out of warranty, and can be treated
as “disposable”


ID Name Description
GEA: Virtual Desktop A virtual desktop is a virtual machine that runs a desktop operating
3.1.01.06 system and is capable of functioning as a desktop in terms of running
desktop applications. Virtual desktops are typically run in the
datacentre and accessed by virtual desktop clients (though there are
solutions where virtual desktops run on local devices). This means
that all of the processing traditionally carried out by a desktop device
(or laptop) is performed by datacentre hardware emulating desktop
hardware. This can deliver efficiencies in terms of centralised
management of these desktops and their applications and data, as
well as allowing thin, lower powered, or non-traditional devices to
access rich desktop functionality

The virtual desktop is not a device as such, but in a virtual desktop
architecture it will function as a device in a number of different ways:
bearing an operating system, containing applications and data, being
managed etc.

GEA: Smart Phone The Smart Phone mobile device is now capable of much more than
3.1.03.01 calls and SMS messages. The smart phone can be utilised as a
communication and productivity mechanism within an SOE. Smart
phones should be tiered to match the main usage scenarios that
exist, and devices should be selected based on their match to the
requirements of that tier.

Examples of the functionality that will be provided by Smart phones
are:

 Voice calls

 Video calls

 SMS (text) messaging

 Email services (inbox, calendar, contacts, tasks)

 Internet browsing

 Application access

GEA: Tablet / Slate In the near future Tablet/Slate are likely to be the key devices that will
3.1.03.04 enable mobility. Different devices may be used based on
requirements and suitability in each environment. While most tablets
are primarily aimed at the consumer market and some may not have
the level of management support expected of enterprise grade
platforms that is rapidly changing. Until that change has completed,
additional care may need to be taken when considering deploying
them as part of an SOE. In addition because of their highly portable
nature and desirability they may pose additional security risks for an
agency that will need to be taken into account.


6.2 Functional Grouping 2: Operating Systems

Functional Grouping 2 is aligned with the GEA-NZ End User Devices Zone. Operating Systems
contains the locally installed OS software that is required on all devices.

ID Name Description
GEA: Thin Device OS Thin Device OS is the Operating System that is installed onto the
3.1.01.07 device, typically in firmware. Many thin devices have thin or zero OS
options and just boot from firmware that can be refreshed from a
central repository when required. There are major advantages with
these options, as the maintenance around Operating System
patching is dramatically reduced or removed.

GEA: Fat Device OS Fat Device OS is the Operating System that is installed onto desktop
3.1.01.08 or laptop devices. Of all the devices, this Operating System could
provide the richest functionality, but conversely, is likely to be the one
that requires the most on-going maintenance.

GEA: Virtual Desktop OS The Virtual Desktop OS is the Operating System that is installed onto
3.1.01.09 the virtual desktop. It may be the same OS as is installed on Fat
Devices, but may often be based on a different image.

GEA: Repurposed PC OS The repurposed PC OS is a lightweight operating system installed on
3.1.01.10 re-purposed computers that provides the minimum functionality
required to run a thin client / virtual desktop client.

GEA: Smart Phone OS Smart Phone OS is the operating system that is installed on the
3.1.03.05 device and all of its features. There are many variations of smart
phone OS available, each with their own user interface which dictates
look and feel. The operating system is usually supplied in conjunction
with the device.

In a corporate environment there are OS features that are beneficial
for supportability reasons, such as -

 Simplicity to apply patches to the OS and software.

 Ability to support corporate based infrastructure (such as
DHCP, APNs and WPAD).

 Ability to favour wireless over data connections to save data
charges.

 The ability to remotely wipe data from the device if it is lost.

 Ability to support the “pushing” of corporate applications to
these devices.


ID Name Description
GEA: Tablet / Slate OS Tablet / Slate OS is the Operating System that is installed on the
3.1.03.06 device. The operating system is usually supplied in conjunction with
the device. Due to the emerging nature of the tablet/slate market
these operating systems often do not support the sorts of features
that are expected of enterprise grade devices.

6.3 Functional Grouping 3: End User Applications

Functional Grouping 3 is aligned with the GEA-NZ End User Devices Zone. End User Applications
consists of all of the end user applications that are available to the users of the SOE. It includes
those applications that are labelled “utilities”. There will be a variance of the utilities required
between devices. In addition, note that some operating systems deliver these capabilities as part of
the operating system‟s native capabilities (e.g. Windows 7 includes a file extraction utility natively).
Therefore care needs to be taken not to merely provide a utility because it is in this list, but instead
to ensure that these capabilities are delivered by the complete SOE while minimising the number of
utilities delivered as separate applications.

There are a range of additional capabilities to those listed here, such as media players, screen
capture tools and PDF creators that could be considered, These are, however commonly available
as built in features of major operating systems, or office productivity suites, and so are not included
here.

ID Name Description
GEA: Business Business Applications covers all applications that provide the
3.1.07.01 Applications functionality required by the business and that are not covered under
another heading below. They may include transactional systems, but
may also include specialised tools such as scientific applications, call
centre management tools etc.


ID Name Description
GEA: Web Browser Web Browser provides the interface to all web based content, be it on
3.1.07.02 the Internet or Intranet. Often the delivery of web applications is
underestimated because of a perception that it‟s simply browser
based. Web applications often require additional applets or plug-ins
for the application to work. These factors need to be considered to
ensure usability and security is not compromised.

GEA: Productivity Suite Productivity Suite is the core suite of general applications that are
3.1.07.03 designed to improve users‟ productivity at generalised tasks rather
than specialised or business specific tasks. This includes software
such as:

 Word processor

 Spread sheet

 Email client

 Presentation software

 Database application

 Drawing tools

 Publishing software

 Note taking software

GEA: PDF Reader PDF Reader is the software required to read PDF files. This is a basic
3.1.07.09 tool that does not allow editing of the PDF file. This software is subject
to regular version updates which can be problematic for users and
cause issues in locked down environments. Because of this, the
software is a perfect candidate for Application Virtualisation
technology.

GEA: File Compression File Compression is the capability to compress files for storage or
3.1.07.10 and Extraction transit and extract files that have been compressed. There are formats
that are commonly used such as ZIP, which require an additional
software component or could be supported natively in the Operating
System being run.

GEA: Power Management Power Management Tools allow changes to be made to the power
3.1.07.11 Tools scheme on the device. This can reduce the energy consumption on
the device or ensure power saving doesn‟t affect expected operation.
As an example, users would turn off hibernation if they were going to
be doing a presentation. Power settings have the potential to save an
organisation a substantial amount of money, when the savings per
device are multiplied by the number of devices installed. Third party
tools may give advanced functionality, greater control and additional
cost savings over the native operating system tools.


ID Name Description
GEA: Video Tools Video Tools are required to attach additional
3.1.07.12 monitors/projectors/cameras and to change resolution states, video
quality etc. Some video tools are resident in the OS, but advanced
functionality can be gained by using the native tools that are provided
with the display adapter or camera.

GEA: Development Development frameworks (such as a Java runtime environment or
3.1.07.13 Frameworks .NET) are required to allow applications or applets based on those
frameworks to execute. Incompatibility issues may arise when
different versions of the frameworks are required on a single device.
(Note: in general the .NET framework avoids this issue.) This can be
resolved using Application Virtualisation and its associated backend
technologies by virtualising each application with its required
framework, as each virtual bubble forms an isolation barrier. Care
should be taken with this approach however as it can lead to additional
management overhead around keeping applications synchronised with
development framework versions.

GEA: Audio Tools Audio Tools are required to adjust and tune audio components
3.1.07.14 installed in the devices. There are some tools resident in the OS, but
advanced functionality can be gained from using the native tools that
are provided with the audio components.

GEA: Web Application Web Application Frameworks are required to run web application
3.1.07.15 Frameworks components developed in that framework. Examples of these
frameworks are Adobe Flash and Air and Microsoft Silverlight.

GEA: Legacy Browser Legacy Browser Support provides the ability to display web
3.1.07.16 Support applications that require Internet Explorer 6 proprietary extensions.

GEA: Screen Saver Screen Saver includes the ability to auto-lock a device.
3.1.07.17

GEA: Additional Language Additional Language Support gives the ability to enter, display and
3.1.07.18 Support spell-check additional languages required. Māori should be installed as
a default.

6.4 Functional Grouping 4: Application Delivery Services


Functional Grouping 4 is aligned with the GEA-NZ End User Devices Zone. Application Delivery
Services contains tools required to deliver applications to users.

ID Name Description
GEA: App Deployment Tools or solutions to deploy applications (which may be packaged
3.1.06.02 or virtualised) to workstations or devices (which may be virtual or
physical).

GEA: Application Application Virtualisation will allow applications to be streamed on-
3.1.07.04 Virtualisation demand or pre-cached to a device and executed in a virtualised
bubble. The advantages of this type of technology are -

 Simplified application packaging process

 Smaller regression testing requirements

 No file or registry changes made to the device by the
streamed application

 Simplified upgrade process

 Shorter application provisioning time

 Local processing power can be utilised for application
execution

 Reduction or removal of applications conflicts

In the past, a core image was created that contained the OS,
productivity suite, utilities and other core applications. In the
future, technologies such as application virtualisation should be
used as much as possible to reduce the effort required for on-
going maintenance. It may still make sense to have OS and
productivity suite, and a few utilities in the core image, but very
little else. Additional applications could be streamed on demand
to users as required, allowing them to have the same access, no
matter which device they logon to.

Pre-staging of the application would suit mobile or laptop devices,
where connectivity for streaming could not be guaranteed. Also
pre-staging can be used to provide the quickest execution of the
application while maintaining the benefits of application
virtualisation. For example, if Adobe Acrobat Reader 9.0 was pre-
staged to all devices, it would be immediately available to users as
required. If version 9.1 was sequenced and pre-staged, the next
time the user ran the application, they would get the new version.
Because the initial application was contained in a bubble and
never altered the OS registry or files, the upgrade is seamless to
the user and extremely painless to the administrators.

The factor that is most likely to dictate whether an application is
sequenced or remains core will be the interoperability. Application
Virtualisation technology has advanced dramatically since its
invention, but original application virtualisation had limitations on
interaction between virtualised applications or virtualised


ID Name Description
applications and the OS. The other factor is speed and network
connectivity. If every user will open the email client, is there any
point not having it already pre-deployed to prevent network
congestion?

For consistency, consideration should be given to applying the
same deployment method across platforms. For example, if
Adobe Acrobat is pre-staged to desktops, it also makes sense for
this to be done on the Presentation Virtualisation (Terminal
Services) platforms. This reduces the need to duplicate effort and
maintains consistency across the board.

Note: some application virtualisation technologies are client-
based, and some are clientless.

GEA: Presentation Presentation Virtualisation will allow sessions to be run on devices
3.1.07.05 Virtualisation that contain a desktop or the publishing of an individual application
icon. The processing of the desktop session and the application
execution will be server side.

Presentation virtualisation has a major role to play in the services
such as rapid sign-on. The establishment and disconnection of
sessions on the fly allows quick and efficient roaming between
devices.

GEA: Virtual Desktop The Virtual Desktop Client will allow devices to be presented with
3.1.07.06 Client a desktop session that provides the same rich and customisable
environment as a locally installed operating system (i.e. a Fat
Client OS). This is essentially a full desktop operating system
session that runs “in the data centre”.

Virtual Desktop Infrastructure (VDI) attracts the highest cost as the
server side processing requirements are high, but it offers a
unique method of providing services. Scenarios where VDI
provides value include:

 Static environments – if one VDI image can be used to
service multiple users, and changes or customisations to
the image do not need to be retained, the solution is likely
to be cost effective. This is known as non-persistent VDI.
If each user requires their own customisations, additional
applications etc., the storage and maintenance of the
image deltas needs to be carefully considered. Static
environments may exist in areas such as wards, call
centres and other areas where shift workers, such as
telephone operators, are present. Again, the requirements
for these environments may also be met by Presentation
Virtualisation. In these situations the cost of VDI may not
be justified.

 One off specialised – an example of this scenario could be
a contractor coming in to perform a piece of work where
specific tools are required. The contractor could be given


ID Name Description
a persistent VDI session that can be fully customised to
suit the task being performed. When the contractor
leaves, the image is retained for when it is required next.
In the current environment, it is likely that these
customisations get left on the desktop that the contractor
worked on and are lost over time as the desktop is rebuilt.

 Remote workers – since the processing is done in the
data centre, application performance is not limited by the
bandwidth between the user and the data centre (as only
screen updates are sent). Performance is comparable to
the user working in the local office, and data is securely
contained within the organisation.

Another consideration for VDI is which applications should make
up the core image and which should be additional? Application
Virtualisation can, and should, be used as the application delivery
mechanism to VDI, but with persistent VDI (changes retained),
there could be duplication. For example, if 5 VDI users all use an
additional drawing package, their delta images may contain 5
copies of the same software. Some technologies are intelligent
enough to support a shared application cache for VDI, which
ensures only one copy of the software is retained. This level of
thought needs to go into the implementation of these technologies
to ensure the challenges of today‟s distributed desktop don‟t get
replicated to the server hosted desktop environment. A significant
portion of the persistence challenges can be resolved by
combining the user environment virtualisation with application
virtualisation.

GEA: Packaging Tools Tools or solution set for packaging applications for delivery to an
3.1.07.07 end user device. This tool may be for packaging applications in
the traditional sense or an application virtualisation packager

GEA: Self Service A Self-Service App Store allows users to self-select, and
3.1.07.08 Application Store automatically provision applications onto their devices. This may
include workflow functionality to allow for line-management
approval or to control expenditure, licence consumption and
financial approval. In addition it could include management of
requests for new applications not currently available through the
App store, and the workflow required to approve and make these
available.


6.5 Functional Grouping 5: Configuration Management

Functional Grouping 5 is aligned with the GEA-NZ End User Devices Zone. Configuration
Management contains all of the tools required to manage the configuration of a device and/or
operating system as well as monitoring and enforcing compliance with policy.

ID Name Description
GEA: OS Deployment The OS Deployment FC is used to deploy (patched) operating
3.1.06.01 system images.

GEA: Security Tools to manage, report on and enforce required security
3.1.06.03 Configuration configuration of client devices
Manager

GEA: Policy Manager Tools to manage deployment and enforcement of policy on the
3.1.06.04 configuration and settings of devices and their operating systems.

GEA: Policy Compliance Monitors configuration against policy for compliance and initiates
3.1.06.05 Manager action if the configuration does not comply with the relevant
policy. This includes the ability to gather configuration data from
the device or operating system. NB: Policy Compliance Manager,
Policy Manager and Security Configuration Manager are often,
though not always, implemented using the same software
technology.

GEA: Patch Manager Solution to automatically remediate, manage installation of and
3.1.06.06 report on operating system and application software patches.
The applicability of this functional component is mainly focussed
on fat device desktops and laptops.

GEA: Application Application Discovery is a tool that can be used to discover which
3.1.06.09 Discovery applications are being used within an agency. Discovery tools
may be agent-less or require agents and may use a variety of
means to discover applications.

GEA: Application Tool to automate the analysis of applications to determine
3.1.06.10 Compatibility compatibility with device operating systems.
Testing


GEA: Virtualisation Tool to automate the analysis of applications to determine
3.1.06.11 Compatibility compatibility with application virtualisation. Note: these tools are
Testing often implemented in combination with Application Compatibility
Testing.

6.6 Functional Grouping 6: User State Management

Functional Grouping 6 is aligned with the GEA-NZ End User Devices Zone. User State
Management contains all of the components to manage user state within the end user computing
environment.

ID Name Description
GEA: Persona Manager The Persona Manager maintains information relevant to a
3.1.06.07 particular user (settings, preferences, and configuration) and
determines how it is managed across devices and contexts.

GEA: User Data Manager The User Data Manager provides access to users‟ files
3.1.06.08 regardless of their environment. This FC does NOT guarantee
off-line access, but may deliver that additionally.

6.7 Functional Grouping 7: Security Management

Functional Grouping 7 is aligned with the GEA-NZ Foundation Zone. Security Management
Services contains all of the components that protect devices, applications, users and data from
threats and control user access to resources.


ID Name Description
GEA: Anti-Virus Tools Anti-virus Tools provide protection against viruses and other threats at the
3.6.02.01 device level. Common components that are included are –

 Real-time scanner
 Scheduled scan function
 Manual scan function
Traditional AV clients download full AV pattern files and engine updates
on a regular basis. The latest client software only downloads a subset of
information and relies on a locally installed server for the remaining
information as it is required. The advantage of this type of technology is
that bandwidth and processing is saved by not downloading full updates to
every client. Also as full protection requires definitions to be aware of
every threat that has ever existed; the size of these updates is only going
to get worse as time passes.

Anti-virus tools for virtual desktops may be client-less, relying on
intercepting API calls to the virtual host.

GEA: Drive Encryption Encryption of data stored on local drives or encryption of the complete
3.6.02.02 local drive for fat clients.

GEA: Removable Media Device encryption for portable storage devices – may be provided through
3.6.02.03 Encryption software or hardware.

GEA: Device (Port) Controls read & write access to external ports & portable storage devices
3.6.02.04 Manager (USB devices at a minimum)

GEA: Host Firewall Solution to securely control network access to and/or from a device.
3.6.02.05

GEA: Application Solution to only allow approved applications to run on user‟s device
3.6.02.06 Whitelisting

GEA: Secure Remote Solution providing secure access to an agency‟s services from outside the
3.6.02.07 Access agency‟s physical footprint. This includes technologies such as Virtual
Private Networks (VPN).

GEA: Network Access Solution to control access to wired and wireless networks based on
3.6.02.08 Control location and user‟s posture, what device they are on (managed or not
managed) and where they are located.


7. Related and Dependent Functional Components
The following FCs are not in the scope of the COE Programme, but are described here to make
explicit any dependencies that the COE (or an SOE) has on them, or vice versa. They include ICT
infrastructure components that form important considerations for any end user computing
deployment or implementation. Some Functional Groupings listed here do not include any lower
level Functional Components as that level of detail is not required for the purposes of the COE
programme. Individual agencies, however, may need to fill these out in order to deliver a complete
working solution.

The following picture shows the Functional Groupings that the COE is related to, or dependent on.
These Functional Groupings are aligned to specific GEA-NZ zones. These components are
described in detail in this section of the reference architecture.

Figure 8 Related and Dependent Components Overview

The following diagram shows a detailed view of the Functional Components that the COE is related
to, or dependent on, within their Functional Groupings. The Functional Components are described
in detail in the following sections for their respective Functional Groupings.


Figure 9 Related and Dependent Functional Components


7.1 Functional Grouping 10: Networks

This Functional Grouping contains components for accessing different network resources.

ID Name Description
GEA: Fixed Local Services for accessing applications, data or services over a fixed local
3.2.01.01 Network network.

GEA: Wi-Fi Services for accessing applications, data or services over a wireless (Wi-
3.2.03.01 Fi) network.

GEA: Mobile Network Services for accessing applications, data or services over a wireless
3.2.03.02 (mobile) network.

7.2 Functional Grouping 11: Utility Compute Services

This Functional Grouping includes those utility computing services that may be used to support or
run COE systems (e.g. management infrastructure or virtual desktops).

ID Name Description
GEA: Server Computing Server computing resource required to deliver server based end user
3.6.01.01 computing services such as virtual desktops or streamed applications.

GEA: Hypervisor The Hypervisor is the software that acts as the mediating layer between
3.6.01.02 the guest operating system (and applications) and the underlying
hardware.

GEA: Virtualisation The Virtualisation manager manages the virtualised environment for an
3.6.01.03 Manager agency. It manages the configuration of hypervisors and the deployment
and operation of virtual machines.


GEA: Virtual Desktop The Virtual Desktop Manager manages the allocation and configuration
3.6.01.04 Manager of virtual desktops and virtual desktop pools. This includes the
functionality required by agency staff to manage individual virtual
desktops (to rebuild or restore them for instance), or classes (pools) of
virtual desktops. It also includes functionality required to direct requests
from virtual desktop clients to particular virtual desktops (i.e. virtual
desktop broker services).

7.3 Functional Grouping 12: Storage
This Functional Grouping includes services for storing, accessing and backing-up files and data.
Storage is a key area of concern for the COE specifically when we look at virtual desktops.

7.4 Functional Grouping 13: Identity and Access Management

This Functional Grouping includes services for managing user and device identity and access
control. It includes systems which provide central management of users and their attributes, as well
as controlling user rights to applications.

ID Name Description
GEA: Directory Services Systems that store, organize and provide access to information held within
3.4.05.01 a directory, which can be considered a map between „objects‟ and
information about those objects, typically described as „attributes‟.
Attributes of objects can be made secure so that only users with the
available permissions are able to access it.

Examples of directory services include Active Directory, Open LDAP, e-
Directory and other implementations of the X.500 ISO/IEC 9594 directory
services standards.

7.5 Functional Grouping 14: Print Services

Services for performing printing, scanning, faxing and copying.


ID Name Description
GEA: Printers Devices for printing documents and files onto paper or similar materials.
3.1.02.02

GEA: Scanners Devices for taking documents and rendering them into graphical formats
3.1.02.03 (typically graphics files or PDF documents).

GEA: Multi-Function Devices that combine the functions of printers, faxes, photocopiers and
3.1.02.01 Devices (MFD) scanners.

GEA: Photocopiers Devices that copy physical documents.
3.1.02.04

GEA: Follow-me Printing A service for sending documents to a print queue that can be accessed
3.1.02.05 by any networked printer when the user authenticates with that printer.

7.6 Functional Grouping 15: Communication Services

Services for performing different types of communication such as: unified communications, voice,
video, email and instant messaging

ID Name Description
GEA: Communications This is the integration and coordination between different communication
3.2.02.01 Integration types that deliver the value of unified communications. It includes the
ability to contact people with a range of different types of
communications technology as appropriate for the situation and person,
presence across different communication types, and follow-me
functionality across different communication types.

GEA: Voice Systems for delivering voice communications to users or endpoints.
3.2.02.02

GEA: Email Systems for delivering, storing and managing email.
3.2.02.03

GEA: Voicemail Systems for storing voicemail, delivering notifications and managing
3.2.02.04 access to stored messages.


GEA: Instant Messaging Systems for sending instant messages to contacts.
3.2.02.05

GEA: Video Systems for communicating with people using video.
3.2.02.06

GEA: Electronic Meeting Systems for sharing presentations, electronic whiteboards, screens with
3.2.02.07 System other meeting participants. These may be delivered bundled as part of
video conferencing tools, or delivered separately.

7.7 Functional Grouping 16: Physical Services
Physical services required for a user to use their end user devices such as space and power.

7.8 Functional Grouping 17: ICT Management

This Functional Grouping includes components related to managing ICT services and resources.

ID Name Description
GEA: Hardware Asset The Hardware Asset Manager is responsible for discovering the computing
3.6.03.01 Manager hardware assets of an organisation, determining what they are,
maintaining a register of those assets and managing them over the
lifecycle of the asset.

GEA: Software Asset The Software Asset Manager is responsible for discovering software
3.6.03.02 Manager assets, associating software assets with the appropriate hardware or user
profile, enforcing licensing compliance and managing the lifecycle of
software assets across desktops and servers.

8. Requirements
At the time of writing there are no requirements available. Requirements will be added in
subsequent versions.

9. Standards
The following standards are a minimum set of international, technology neutral standards that apply
to different components of the architecture. If a standard is not in this list it does not mean that an
SOE should not adhere to or comply with that standard. Standards are listed here as either MUST
comply, SHOULD comply or as RECOMMENDED. The standards listed here are not intended to be
used instead of the controls and standards documented in the NZISM, but instead are intended to
show some important applications of that guidance to the area of end user devices.


At this point in time the standards contained in this section apply only to components. It is expected
that this section will be extended to cover the process architecture as well.

Additional standards may be added in subsequent versions.

The standards listed here are:

Table 3 Summary of Standards

ID Standard
STD2.1 IPv6 Operating Systems

STD3.1 HTML 5 Compatible Web Browsers

STD3.2 Open Document Formats

STD3.3 File Compression Algorithms

STD7.1 AES 128+ for Disk Encryption

STD7.2 AES 128+ for Remote Access Encryption

STD7.3 NZ Information Security Manual

STD10.1 802.11n for Wireless Communication

STD10.2 802.11ac for Wireless Communication

STD10.3 UMTS for Mobile Communication

STD10.4 LTE for Mobile Communication

9.1 Operating System Standards

ID STD2.1

Title IPv6 Operating Systems

FC/FG FG2: Operating Systems

Description COE components MUST be IPv6 capable. Operating systems must be capable of
operating using IPv6, even if that capability is not actively being used by the agency.

Rationale OGCIO Circular GCIO-2012-01 on IPv6 states that “Agencies, through the course of
technology and application refresh cycles or where funding is available, are expected
to…ensure that internal networks, applications and devices operationally use IPv6”.

Implications As there are security implications to running services such as IPv6 when an agency is
not using them it is expected that this feature may be disabled through configuration


and/or policy if an agency is not actively using IPv6.

9.2 End User Application Standards

ID STD3.1

Title HTML 5 Compatible Web Browsers

FC/FG GEA: 3.1.07.02 Web Browser

Description Web Browsers SHOULD be HTML5 compatible.

Rationale HTML5 is the standard that is emerging as being the dominant standard for web
pages from the present day forward. In addition with the pending demise of Adobe
Flash, and the rise of mobile web browsing (with all major mobile web browsers being
HTML5 compatible and most mobile websites and web apps being based on HTML5)
HTML 5 has all of the capability that is needed to deliver rich web applications to end
users. Web browsers that are not HTML5 compatible will be unable to display many of
the latest web pages, and will be unable to make use of these web apps.

Implications Browsers can be tested for HTML5 compatibility using http://html5test.com/ which
scores browsers out of a possible 500 points.

ID STD3.2

Title Open Document Formats

FC/FG GEA: 3.1.07.03 Productivity Suite

GEA: 3.1.07.09 PDF Reader

Description Office Productivity suites SHOULD support the ISO Standard ISO/IEC 26300:2006
Open Document Format for Office Applications (OpenDocument) v1.0, the ISO/IEC
29500 OOXML standard and the Open PDF file format as defined by ISO/IEC 32000-
1:2008. These standards are supported by most modern office productivity suites.

Rationale Use of an open, international, standard for document formats means that documents
will always be able to be recovered thus enhancing the ability to meet Public Records
Act requirements. In addition it enhances inter-operability between different office
productivity suites allowing documents to be viewed and edited across devices and
avoiding the vendor lock-in associated with proprietary document formats.

Implications Most of the major office productivity suites available support the Open Document
Format and/or OOXML.

ID STD3.3

Title File Compression Algorithms


FC/FG GEA: 3.1.07.10 File Compression and Extraction

Description File compression and extraction utilities SHOULD support the following file
compression standards:

ZIP (.zip)

7z (.7z)

RAR (.rar)

gzip (.gz)

Compress (.Z)

Pack (.z)

bzip2 (.bz2)

Rationale These standards are the most commonly used open standards for file compression
(with the exception of RAR which is a proprietary standard, but is one of the most
commonly used compression methods). Using a file extraction tool that does not
support these formats means that agencies are likely to encounter files that they
cannot extract.

Implications As the standard Windows 7 file extraction utility does not support all of these
standards an agency needs to decide how to allow for their use. If native file extraction
tools are the agency default then administrators or support staff will need to be
supplied with tools that support a wider range of formats. There are open source and
free tools that support all of the above formats.

9.3 Security Standards

ID STD7.1

Title AES 128+ for Disk Encryption

FC/FG GEA: 3.6.02.02 Drive Encryption

Description Disks or data that are encrypted SHOULD be encrypted with AES 128 or higher.

Rationale AES 128 (or higher) is an approved cryptographic algorithm in NZISM.

Implications Disk encryption products for use with an agency SOE should support AES 128 bit or
higher encryption.

ID STD7.2

Title AES 128+ for Remote Access Encryption

FC/FG GEA: 3.6.02.07 Secure Remote Access

Description Communication between remote access endpoints and an organisation‟s systems


SHOULD use encrypted communication of at least AES 128 (or higher).

Rationale AES 128 (or higher) is an approved cryptographic algorithm in NZISM.

Implications Remote access products for use with an agency SOE should support AES 128 bit or
higher encryption.

ID STD7.3

Title NZ Information Security Manual

FC/FG FG7: Security Management

Description The NZ Information Security Manual 1.01 (NZISM) includes a set of security controls
and a risk based approach to managing information security that applies to classified
information. Agencies that use classified information MUST comply with NZISM.

Rationale Agencies that deal with classified information are required by GCSB policy to comply
with NZISM.

Implications The controls from NZISM are included in the security requirements in the COE
Reference architecture. Agencies that use these requirements can therefore be
assured that they meet the requirements from NZISM.

9.4 Network Standards

ID STD10.1

Title 802.11n for Wireless Communication

FC/FG GEA: 3.2.03.01 Wifi

Description Wireless (Wifi) devices SHOULD support 802.11n for wireless communication.

Rationale 802.11n is the current approved wifi standard with the highest data rate. Most devices
and network equipment available today supports 802.11n.

Implications Agencies should only procure new hardware that includes support for 802.11n

ID STD10.2

Title 802.11ac for Wireless Communication

FC/FG GEA: 3.2.03.01 Wifi

Description It is RECOMMENDED that agencies consider 802.11ac when looking at new
hardware and designing wireless networks for use by end user devices.

Rationale 802.11ac provides for significantly higher data rates than 802.11n. 802.11ac is


currently in draft status and wireless equipment using this standard is currently
available in the market.

Implications When purchasing wireless equipment agencies should check whether the equipment
supports 802.11ac and/or when it is on the vendor‟s roadmap to support it. If it is not
currently supported, but is on a roadmap agencies should seek to understand what is
required to move to full 802.11ac support (i.e. does it require a firmware upgrade, or
hardware replacement).

ID STD10.3

Title UMTS for Mobile Communication

FC/FG GEA: 3.2.03.02 Mobile

Description Mobile (cellular) enabled devices SHOULD support UMTS for mobile communication.

Rationale UMTS, the 3G evolution of the GSM standard, is deployed by all of the mobile service
providers in New Zealand and is the most widely used standard for 3G mobile
communication throughout the world. Most 3G devices are backwards compatible with
2G networks. In a number of areas nationally and internationally 2G networks are no
longer available. The equivalent 3G standard CDMA2000 is not supported by any
carrier in New Zealand (or Australia).

Implications As 3G enabled handsets are the only ones currently available in the New Zealand, the
implications are negligible. If agencies still have any 2G only devices, they should
consider retiring them.

ID STD10.4

Title LTE for Mobile Communication

FC/FG GEA: 3.2.03.02 Mobile

Description It is RECOMMENDED that agencies consider LTE when looking at new mobile
devices.

Rationale LTE is the next evolution of the UMTS standard and is being investigated by carriers
in New Zealand and deployed in some areas outside New Zealand. It offers higher
data rates than are available with UMTS.

Implications When purchasing mobile enabled devices agencies should see whether the device
supports LTE. If the device supports LTE then it potentially prolongs the useful life,
though it is unclear when LTE will be introduced into New Zealand.


10. Guidelines
The following guidelines are a set of technology neutral requirements, guidelines and advice that
apply to different components of the architecture. The key guidelines that are recommended for all
agencies are:

 GL4.1 Deliver applications using application virtualisation

 GL3.1 Make legacy applications web-enabled

 GL11.1 Use of Desktop Virtualisation

These guidelines are all aimed at achieving device independence and delivering the capability for
government employees to work anywhere and anytime – a key part of the overall vision for the
COE Programme.

Guidelines are listed here as either MUST comply, SHOULD comply or as RECOMMENDED.
Guidelines are organised by the section of the component architecture that they refer to. At this
point in time the standards contained in this section apply only to components. It is expected that
this section will be extended to cover the process architecture as well. The guidelines listed here
are not intended to be used instead of the controls and standards documented in the NZISM, but
instead are intended to show some important applications of that guidance to the area of end user
devices.

Additional guidelines may be added in subsequent versions.

The Guidelines listed in this section are:

Table 4 Summary of Guidelines

ID Guideline
GL1.1 Define Tiers for Devices

GL2.1 Disable IPv6 through policy when unused

GL2.2 Use a 64 bit version of Windows as the default Windows Operating

GL2.3 Maintain Operating System

GL2.4 Create Thin Base Images

GL3.1 Make Legacy Applications Web-enabled

GL3.2 Application Lifecycle Management

GL3.3 Dual Web Browsers

GL3.4 Minimise utilities

GL3.5 Single Sign On (SSO)


ID Guideline
GL4.1 Deliver applications through application virtualisation

GL5.1 Single Management Toolset for Virtual and Traditional Desktops

GL6.1 Minimise data stored on local devices

GL7.1 Local Disk Encryption for Laptops

GL7.2 Local Disk Encryption for Desktops and Laptops

GL7.3 Use Two Factor Authentication For Remote Access

GL11.1 Use of Desktop Virtualisation

GL12.1 Profile Storage for Desktop Virtualisation Deployments

GL13.1 Keep Local Admin Accounts to a Minimum

GL17.1 Software Asset Management

GL20.1 Profile Users

10.1 Device Guidelines

ID GL1.1

Title Define Tiers for devices

FC/FG FG1: Devices

Description It is RECOMMENDED that agencies define tiers for devices based on user profiling
and usage scenarios. The establishment of tiers will allow a closer fit between user
requirements and device capabilities. For instance, multiple tiers for fat clients might
be defined by an agency based on required computing power or memory needs for
different user profiles.

Rationale As there are many devices available, but there are only a restricted set of usage
scenarios that need to be met:

 The creation of tiers will allow the right type of device to be applied to the right
usage scenario, based on requirements.

 Devices that meet the requirements for a tier would be a contender, allowing
final selection to be driven by fit, suitability, availability and cost etc.

Implications Agencies that take this approach to devices will be better able to satisfy user needs


through appropriate selection of devices.

10.2 Operating System Guidelines

ID GL2.1

Title Disable IPv6 through policy when unused


Description All operating systems must be IPv6 capable (see STD 2.1). When IPv6 is not being
used by an agency these services SHOULD be disabled through policy. If an agency
is using IPv6 then this guideline does not apply.

Rationale It is good practice to disable services that are not being used. If IPv6 is enabled on
devices while the agency is not actively using and managing IPv6 then there is
increased risk of unauthorised use of this service. In addition the NZISM states that
IPv6 must be disabled if it is not being used.

Implications If an agency is not using IPv6 then it will need to decide how to prevent unauthorised
use of IPv6, and how and when it will be re-enabled when the agency transitions to
IPv6.

ID GL2.2

Title Use a 64 bit version of Windows as the default Windows Operating System


Description The standard Windows operating system SHOULD be a 64 bit version. Windows 7 will
be the last operating system that has a 32 bit edition therefore agencies that deploy a
32 bit operating system may encounter difficulties in migrating to later operating
systems. For users who use applications that only run on 32 bit operating systems a
second desktop operating system could be made available. In addition some virtual
desktop technologies may get benefits around density if a 32 bit operating system is
used. As virtual desktop technology matures the need for this consideration may
disappear.

Rationale To take advantage of the additional memory that a 64 bit operating system enables
and to smooth transition to future operating systems.

Implications Agencies should assess whether their current application portfolio is compatible with a
64 bit operating system and look to remediate those applications that are not. If
agencies are looking at virtual desktops they will need to carefully consider whether
they use a 64 bit or 32 bit operating system as their standard.

ID GL2.3

Title Maintain Operating System



Description Operating Systems lifecycle SHOULD be maintained to ensure they do not become
legacy and unsupportable.

Rationale The latest Operating Systems are the most secure, have advanced features and are
often the version that users are running in their home environments. These OSs are
also often the easiest to maintain because they support or contain the latest
deployment technologies. Most organisations own the latest version of the software so
it makes sense to realise the value of the investment.

Implications The organisation should strive to maintain at least an N-1 status across all device
Operating Systems, unless the latest OS is less than 12 months old.

Organisations should plan to have deployment of the latest OS underway, if not
completed, by the time the latest OS has been released for 24 months. Note: Mobile
Device OS may need more regular updates as their OSs have a quicker release cycle.

ID GL2.4

Title Create Thin Base Images

FC/FG GEA: 3.1.01.07 Fat Device OS

GEA: 3.1.01.08 Virtual Desktop OS

Description To ensure on-going maintainability, base images SHOULD be thin, including a
footprint limited to the operating system and minimal additional components and tools.

Rationale Where application or management software is unnecessarily built into base images,
those base images will typically need to be regenerated when one of those
components needs to be updated - or increasingly complex un-installation and
upgrade scripting undertaken immediately after deployment of the base image.

Implications Deployed image instances are often made up of modular layers overlaid on a base
image. Such layers typically add version controlled applications, utilities and
management tools on top of the thin base image to deliver an end user environment
customised for user role, hardware / platform and organisation. Increasing use of
application virtualisation reduces the complexity of these additional layers, but does
not undermine the principle that underlying base images should remain thin


10.3 Application Guidelines

ID GL3.1

Title Make Legacy Applications Web-enabled

FC/FG GEA: 3.1.07.01 Business Applications

Description Legacy line-of-business applications that currently have deployed desktop client
software are RECOMMENDED to be remediated to use HTML5 compliant web front
ends.

Rationale One of the barriers to adoption of modernising desktops or moving to a device
independent mode of operating is that legacy applications have thick clients that are
tied to particular operating systems. Creating standards compliant web front-ends
means that any device running a modern browser can be used to access that
application.

Implications Agencies should look at the effort required to replace traditional clients with web front-
ends.

ID GL3.2

Title Application Lifecycle Management (ALM)

FC/FG FG3: End User Applications

Description It is important to manage desktop/client applications throughout their lifecycle.
Agencies SHOULD use some form of application lifecycle management (ALM)
process. Applications should be introduced into the end user environment
appropriately (that is assessed and procured through an appropriate process and then
packaged/virtualised and distributed), maintained and patched as required and
eventually retired and replaced.

Rationale Application patching/maintenance was identified by the Cyber Security review as one
of the critical interventions to prevent intrusions/incidents.

Implications Agencies should have a documented process for application lifecycle management in
place. Agencies with a significant application estate should consider an automated
toolset or process for managing their applications.

ID GL3.3

Title Dual Web Browsers

FC/FG GEA: 3.1.07.02 Web Browser

Description It is RECOMMENDED to deploy two web browsers to physical or virtual desktops or
other end user devices: in the case of Windows desktops Internet Explorer and one
other.

This reduces dependence on a single component and encourages standards


compliance.

Rationale Some sites and applications will work better – or in some cases exclusively with a
single web browser.

Security vulnerabilities may also affect one browser while others are unaffected.

Maintaining dual web browsers provides a pragmatic way of minimising the impact of
these limitations.

Given two up-to-date and well configured browsers it is less likely that an application
or site will not function correctly on either. Such an approach also provides an
alternative means of accessing web based services should an unpatched security
vulnerability be disclosed which affects the platform‟s primary browser.

Implications Where practical, agencies should consider choosing, deploying and maintaining a
second standards compliant browser. Following this recommendation, however, may
lead to an agency incurring additional costs. This should be taken into account when
an agency makes its own specific policy decision.

ID GL3.4

Title Minimise utilities


Description Utilities SHOULD only be deployed if they add required value to the user environment
and a suitable maintenance schedule can be deployed. Over time the base OSs have
rd
added more and more functionality that used to only be provided by 3 party utilities
(e.g. file extraction). Because of this history, users often want to use free or purchased
utilities that merely duplicate functionality provided in the base OS. They should
instead be steered to use the capabilities bundled with the OS.

Rationale Often the Workspace environment becomes cluttered with utilities that offer very little
additional value on top of standard functionality and they are problematic to update /
upgrade on a regular basis.

Implications • Software distribution methods should also be considered for the update /
upgrade of each utility.

• It is not assumed that all utilities would be bundled with the core OS like has
been done in the past.

• Utilities are often hardware specific (i.e. display software) increasing the
difficulty to correctly target updates to the right devices.

ID GL3.5

Title Single Sign On (SSO)


Description It is RECOMMENDED that agencies look at Single Sign On for business applications
and web browsing.


Rationale Single Sign On provides a significant improvement to usability, and reduces the risk
that staff will compromise password security and integrity through the use of unsafe
password management techniques.

Implications Agencies will need to decide on an application by application basis whether single
sign on is appropriate for use with each application that requires authentication.

10.4 Application Delivery Guidelines

ID GL4.1

Title Deliver applications through application virtualisation

FC/FG GEA: 3.1.07.04 Application Virtualisation

Description Applications SHOULD be packaged and delivered using an application virtualisation
technology.

Rationale Application virtualisation separates the application from the underlying operating
system. This means that the application is no longer dependent on the operating
system, and will not need to be redelivered if the operating system is changed.

Implications If an agency does not have an application virtualisation capability then they should
investigate acquiring one. When looking at application virtualisation technologies
agencies should take into account their existing investment in delivering, presenting,
monitoring and deploying applications as well as how they intend to do this going
forwards.

It should be noted that the technology in this area is changing rapidly and
improvements are constantly being made. Agencies should regularly check back with
vendors to understand how their chosen technology is evolving.

There are often tight integrations between applications which can create an improved
user experience. It can, however, also create challenges when attempting to virtualise
these applications as application virtualisation technologies have significant
constraints when dealing with these integrations When virtualising an application
portfolio a general approach to virtualising dependent applications should be decided
upon. Agencies may decide to virtualise applications together in “bundles”, or to break
application integrations.

Patching tools for virtualised applications are not as mature as those for non-
virtualised applications. This can impose additional costs and constraints for
applications that require regular patching. Agencies should be aware of this and
understand the implications for them.

10.5 Configuration Management Guidelines

ID GL5.1


Title Single Management Toolset for Virtual and Traditional Desktops

FC/FG FG5: Configuration Management

Description Agencies are RECOMMENDED to use a single management toolset across both
virtual and non-virtual environments (devices, OS and applications).

Rationale Using separate management toolsets for virtual as opposed traditional desktops (and
laptops) will significantly erode or remove the operational efficiencies gained from
moving to a virtual desktop.

Implications When agencies select their management toolset for virtual desktops they must take
into account how they will manage their remaining traditional desktop clients.

10.6 User State Management Guidelines

ID GL6.1

Title Minimise Data Stored on Local Devices

FC/FG GEA: 3.1.06.08 User Data Manager

Description Agencies SHOULD implement and enforce policies to minimise the amount of data
that is stored on local drives of end user devices.

Rationale This reduces the possibility of data loss and leakage due to loss, theft or disposal of a
device. Data will be more secure if placed in a managed, secured, and backed-up
location. In addition, device management and servicing is easier as devices can be
rebuilt or replaced without risking loss of data.

Implications Agencies should investigate how they wish to manage user data and how they will
meet storage requirements.

The overall approach to storing data should be considered: will the agency take a
centralised or a distributed (e.g. departmental/office storage) approach.

For scenarios where users or devices are disconnected from corporate networks
frequently or for extended periods of time (e.g. laptop use) local data storage will
probably be unavoidable. In these cases thought should be taken to how to address
the concerns outlined above.


10.7 Security Management Guidelines

ID GL7.1

Title Local Disk Encryption for Laptops


Description Agencies MUST use local disk encryption for all laptops.

Rationale A vast number of laptops are stolen or misplaced every year. While detailed figures for
the NZ government are not available, we must assume that this holds true for the
public sector as well. The only way to reduce the risk of the loss or theft of laptops
from leading to unauthorised access to government information is through the use of
local drive encryption.

Implications Agencies must acquire and use a drive encryption product for all of their laptops. A
single encryption product should be used across devices, though this is not always
achievable.

ID GL7.2

Title Local Disk Encryption for Desktops and Laptops


Description It is RECOMMENDED that agencies use local disk encryption for all fat clients
including both laptops and desktops.

Rationale The overhead of disk encryption these days is low enough that it should be considered
for all local disks, not just laptops.

Implications Agencies should acquire and use a drive encryption product for all of their laptops and
desktops.

ID GL7.3

Title Use Two Factor Authentication For Remote Access

FC/FG GEA: 3.6.02.07 Secure Remote Access

Description It is RECOMMENDED that agencies require two factor authentication for access from
remote devices to agency services.

Rationale The NZISM recommends using multiple authentication mechanisms for system
access. Given the additional risks around remote access over traditional on-premise
access to agency services two factor authentication adds an additional level of control
and risk reduction.

Implications Agencies may need to source and integrate a two factor authentication solution.


10.8 Utility Compute Guidelines

ID GL11.1

Title Use of Desktop Virtualisation

FC/FG GEA: 3.6.01.04] Virtual Desktop Manager

Description It is RECOMMENDED that agencies investigate desktop virtualisation or desktop as a
service (DaaS) to see whether it is suitable to deliver end user computing services for
them.

Rationale Desktop virtualisation has the potential to allow end user services to be delivered to
any device regardless of device operating system. This helps break the link between
the operating system and the applications and data that the end user needs access to
in order to perform their job. Desktop virtualisation may also potentially enable mobile
and remote access to applications and data.

Implications Agencies may need to understand what proportion of their devices and/or users are
candidates for use of virtual desktop technologies. In addition they may need to
investigate what particular virtual desktop technologies and solutions meet their
needs.

10.9 Storage Guidelines

ID GL12.1

Title Profile storage for desktop virtualisation deployments

FC/FG FG 12 Storage

Description It is RECOMMENDED that agencies that are actively pursuing virtual desktop
solutions profile and manage storage carefully.

Rationale Desktop virtualisation moves storage requirements and utilisation from the distributed
end user device into the centralised data centre. As such, storage profiling (initially)
and on-going management (afterwards) is critical to the delivery of a successful virtual
desktop solution.

Implications Agencies looking to deploy virtual desktop solutions should investigate the storage
requirements of their user base taking into account the amount of storage required for
the different functions and components of the solution (operating system, application
installs, user data, user state etc.) as well as the amount of throughput and
performance required to deliver a solution that meets user expectations. Particular
care should be taken in understanding time-of-day (e.g. high demand at the beginning
of the work day) and situation specific variations (e.g. variations caused by national
holidays or disaster recovery scenarios) These factors will need to be proactively
managed and capacity monitored and forecast once the solution is live.


10.10 Identity and Access Management Guidelines

ID GL13.1

Title Keep Local Admin Accounts to a Minimum

FC/FG FC13 Identity and Access Management

Description Agencies should keep the number of local administrator accounts to a minimum. Who
has a local admin account should be tracked and local admin privileges should only be
allocated if they are needed by staff to fulfil their function.

Rationale NZISM requires the minimisation of administrator accounts; this applies equally to
local administrator accounts on end user devices such as laptops and desktops. This
minimises the risk of unauthorised or malicious code executing on a local device.

Implications Agencies should:

 ensure that the use of privileged accounts is controlled and accountable

 ensure that system administrators are assigned an individual account for the
performance of their administration tasks

 keep privileged accounts to a minimum, and

 allow the use of privileged accounts for administrative work only.

Standard practice would be to provide those staff who need local administrator
accounts with a second privileged account that can be used when privileged access is
needed, but that is not used for day-to-day tasks.

10.11 ICT Management Guidelines

ID GL17.1

Title Software Asset Management

FC/FG GEA: 3.6.03.02 Software Asset Manager

Description Agencies SHOULD use asset management to keep track of deployed software assets
and manage the application lifecycle.

Rationale Keeping track of deployed software assets reduces the risk of non-compliance with
licensing commitments; supports better security.

Managing software through its lifecycle enables agencies to realise the greatest
amount of benefit from their investment in software while reducing the risk of security
issues due to un-patched software.

Implications Agencies should have a documented software asset management process in place.
Agencies with a significant application or end user device estate should investigate the


appropriateness of investing in an automated solution for software asset management.

10.12Miscellaneous Guidelines

ID GL20.1

Title Profile Users

FC/FG N/A

Description In order to most effectively allocate end user computing solutions and devices to users
in a way that maximises productivity and user satisfaction, it is RECOMMENDED that
agencies profile their users. This means that users‟ needs, ways of working and ways
of using devices and end user computing environments should be investigated. This
will allow new end user environments and solutions to be designed that deliver to
those needs and ways of working rather than forcing staff to change to suit the
solution.

Rationale If agencies do not understand staff needs for their end user computing
environment(s), then they are unlikely to gain the greatest benefits from modernising
or maintaining them.

Implications Agencies should profile users based on at least the following criteria: mobility, content
creation and consumption patterns, application use and specialisation.

11. Sample Solution Architectures
Solution Architectures take elements of the Reference Architecture (FGs and FCs) and assemble
them to suit the particular requirements and environment of an agency.

At the time of writing there are no sample solution architectures available. Solution architectures will
be added in subsequent versions.

12. Sample Technology Solution Sets
Technology solution sets take a solution architecture (a set of FCs) and realise them in particular
technologies, that is particular software and hardware products.

At the time of writing there are no sample technology solution sets available. Technology solution
sets will be added in subsequent versions.


Appendix A COE Components in GEA-NZ
This appendix shows how the Functional Components of the COE Reference Architecture sit within
the overall GEA-NZ ICT Region. Each Functional Component sits within a specific GEA-NZ Block,
which in turn sit within a GEA-NZ Zone. They form part of the lower level of detail of GEA-NZ. This
appendix reproduces the descriptions of the relevant zones and blocks from GEA-NZ v2. For
descriptions of the relevant Functional Components, please see sections 6 and 7.

GEA: 3.1 End User Devices Zone
This ICT capability zone includes devices used by State sector employees and clients to access
common services, as well as peripheral devices. The zone includes the hardware used for end user
computing, operating systems and tools for managing them.

End User Devices includes all the devices and things that people interact with and use directly, e.g.
End User Computing.

Often this is considered part of the overall infrastructure but in GEA-NZ End User Devices has been
given a specific voice.

The GEA-NZ Blocks from this zone that contain elements used by the COE Reference Architecture
are:

 GEA: 3.1.01 Personal Computing Block
 GEA: 3.1.02 Peripherals Block
 GEA: 3.1.03 Mobile Devices Block
 GEA: 3.1.06 End User Device Management Block
 GEA: 3.1.07 End User Applications Block


GEA: 3.1.01 Personal Computing Block
The Personal Computing ICT Capability Block includes Desktop, Laptop, Personal Computers
(PCs), and associated desktop devices such as monitors and keyboards as well as their operating
systems.

GEA: 3.1.02 Peripherals Block
This block contains the ICT capabilities relating to the peripheral devices that people interact
directly with - printers, scanners etc.

In particular printing, scanning, and follow-me printing etc. are of particular importance when
looking at the COE.

GEA: 3.1.03 Mobile Devices Block
This block includes devices that operate over a Mobile network and includes Tablets, Mobile
Phones, Smart Mobile phones, Mobile Data Cards as well as their operating systems.

GEA: 3.1.06 End User Device Management Block
The End User Device Management block includes all of those technologies used to manage end
user devices as well as their configuration, operating systems and applications. It also includes
tools for managing user state information and transitioning from legacy end user device
environments to more modern ones.


GEA: 3.1.07 End User Applications Block
This block includes all of the applications that an end user interacts directly with including clients for
enterprise applications and standalone apps such as desktop applications or tablet apps. It includes
common utilities as well as the application delivery software that is required to manage the user‟s
access to applications

GEA: 3.2 Communications Zone
The Communications ICT Capability Zone is about communications including internet and private
government networks, voice, video and multi-channel communications technologies.

Communications is about the networks that connect our citizens, agencies, employees and
partners, with each other and to the services we supply and aggregate e.g. one.govt.

are:

 GEA: 3.2.01 LAN / WAN Block
 GEA: 3.2.02 Unified Communications Block
 GEA: 3.2.03 Mobile / Wireless Block

GEA: 3.2.01 LAN / WAN Block
This ICT Capability block covers those Government Common ICT Capabilities and the department
specific ICT Capabilities that relate to Local Area Network (LAN) and Wide Area Network (WAN)
communications.

GEA: 3.2.02 Unified Communications Block
The Unified Communications Capability block includes technologies that significantly improve the
ways that individuals, groups and companies interact and perform and also enables multiple
communication channels to be coordinated.

GEA: 3.2.03 Mobile / Wireless Block
This ICT Capability block covers those Government Common ICT Capabilities and the department
specific ICT Capabilities that relate to Mobile and Wireless Communication ICT Capabilities.


GEA: 3.4 Business Processes and Integration Zone
The ICT capability Zone provides the capability to orchestrate and manage services offered in the
Business and Operational Functions layer, and utilises utility services such as authentication also
located in this stream. Integration services including Enterprise Applications Integration and
Enterprise Service Bus technologies, workflow, and Data Integration are also included.

Business Processes and Integration is about the core business processes execution and
automation technologies, and the integration technologies that interlink systems e.g. Enterprise
Service Bus.

The GEA-NZ Block from this zone that contains elements used by the COE Reference Architecture
are:

 GEA: 3.4.05 Authentication and Access Management Block

GEA: 3.4.05 Authentication and Access Management Block
The Authentication and Access Management Capability block includes services that provide the
authentication of users and citizens and the management of their access to Government
information systems and portals, for example the igovt logon service.

GEA: 3.6 Foundation Zone
The Foundation ICT Capability Zone contains the Blocks that support the other 5 ICT Capability
Zones. They provide the common infrastructure, security and management viewpoints.

are:

 GEA: 3.6.01 XaaS Block
 GEA: 3.6.02 Security Block
 GEA: 3.6.03 Business / ICT Management Block
 GEA: 3.6.06 Storage Block
The only part of the Foundation Zone that is directly delivered by the COE is the Security Block.
Other blocks from the Foundation Zone can be found in section 7 on related components.


GEA: 3.6.01 XaaS Block
This ICT Capability Block is about the Infrastructure, Platforms and Software as a Service
foundation that supports the business. X = I for Infrastructure as a Service, X = P for Platform as a
Service, X = S for Software as a Service. It contains the Capabilities that are the major building
blocks of existing and new business or technology capabilities. What is called Cloud Computing is
covered within this block.

GEA: 3.6.02 Security Block
This Block is about the Security foundation capabilities that support the business. The Security
block contains all of the components that protect devices, other hardware, applications, users and
data from threats as well as monitoring for incidents and mitigating damage from them.

GEA: 3.6.03 Business / ICT Management Block
This GEA-NZ block is about the Business and ICT management processes that operate within
foundation zone that support the business. It contains the ICT Capabilities that are the major
building blocks of existing and new business or technology capabilities.

GEA: 3.6.06 Storage Block
This ICT Capability Block is about the storage infrastructure that supports the business. It includes
services for storing, accessing and backing-up files and data.


Appendix B Mapping to HealthBase Reference Architecture
At the time of writing the mapping to the HealthBase National Workspace Reference Architecture is
not available. This mapping will be added in a subsequent version.


NZ Government End User Computing Reference Architecture

More Related Content

What's hot (20)

Similar to NZ Government End User Computing Reference Architecture (20)

Recently uploaded (20)

NZ Government End User Computing Reference Architecture