NSW GEA Toolkit R1
April 2015
Contact ea@finance.gov.nsw
Strategic Policy
Department of Finance, Services & Innovation

1 Table of Contents
2
2.1
2.2
2.3
Document control
Document approval
Document version control
Review date
3
3.1
3.2
3.3
3.4
Introduction
Purpose
Scope
Audience
Background
5
4
4.1
4.2
Reference Process
Why use the reference process?
Process Description
4.2.1
Overview
4.2.2
Identify Proposals
4.2.3
Develop Proposals
4.2.4
Manage Enterprise Architecture Information
References
ii
8
10
6
7
5
5
6
3
4
4
4
4
13
ii
3
3
3
3

Name & Position
Emily Morgan,
Principal Manager ICT Services
Signature Date
07/09/2015
Version
0.1
1.0
1.1
Status Date Prepared by
Consultation Draft March 2015 Trent Brown
Released
Released
April 2015
Sept 2015
Trent Brown
Trent Brown
Comments
Initial draft
OFS Approved
DFSI Approved
NSW GEA Toolkit content is developed in time boxed ‘sprints’ and packaged into a Toolkit
Release. It is expected that documents will be revised based on feedback and as required to meet agreed agency needs. Feedback will be accumulated with documents generally updated and published in an agreed future Toolkit release.
3

Enterprise Architecture is a valuable dimension of ICT Planning. It identifies how the ICT environment is to change in response to business strategies and initiatives, innovations and technology driven risk. Further, it informs the timing of initiatives in the business change roadmap and provides the basis for program/project time and cost estimates, as well as sourcing and procurement strategies.
This document provides a reference process intended to help agencies integrate the essential EA elements into their business and guide their EA effort in support of ICT planning and implementation of the NSW Government ICT Strategy, Investment Policy and
Enterprise Architecture goals.
The document has an Enterprise Architecture focus and does not provide a comprehensive view of other dimensions of ICT Planning.
Similarly, much of the information produced and consumed by this process will be parts of other processes such as business strategy, business planning, business improvement, ICT service delivery management, project delivery and software asset management. While the perspective is EA, the content is framed using commonly accepted terms for the various domains.
Related NSW GEA documents provide detailed guidance on the EA information and artefacts that are produced and consumed by the EA processes described in this document. These can be found in the NSW GEA Govdex site.
The primary audience for this document are the roles of CIO, IT Managers, EA practitioners, Business Planners, Business Improvement Managers.
The NSW GEA Strategy, Sprint 1 Plan and Toolkit Overview provide the background context for this document. These are available in the NSW GEA site on Govdex.gov.au.
4

Key features of the reference process are:

Recognition that ICT consolidation, leverage, reuse and the delivery of quality key service capabilities requires planning and design work (EA) in the ‘Plan’ stage of the
‘Plan/Build/Run’ IT value chain.

Identifies keys steps to be reflected in cluster / agency processes.

Describes alternate pathways for EA work through the Proposal Development stage so that architecture effort is appropriate to the magnitude of risk, complexity and benefits of the proposed initiative.

Is supported by a common language and set of models to describe architectures and support collaboration across agencies and clusters.
NSW Government Enterprise Architecture Goals
Support the planning, design and delivery of improved Key Service Capabilities

Services Anytime, Anywhere

Community and Industry Collaboration

Citizen focused service

Better Information Sharing

Financial and Performance Management
Support opportunities for consolidation and re-use

Identification of duplicate or fragmented services and assets (business functions, information, applications, technology infrastructure)
Support alignment of investment with strategy & goals

Architecture supporting the alignment of ICT investment to strategy
Support the effective management of ICT related business change

Informing the business change roadmap

Reducing Project Delivery risk

Improved communications
Agencies will have differing approaches and various processes for strategic planning, governance, financial management, procurement etc. This initial release of the reference process is intended to help agencies integrate the essential EA elements into their business and guide their EA effort in support of ICT planning and implementation of the
NSW Government ICT Strategy, Investment Policy and Enterprise Architecture goals.
5

4.2.1 Overview
The process identifies enterprise architecture activities and outputs that integrate with the broader process for ICT Strategic planning.
It comprises three major activity areas that exist within the ‘Plan’ stage of the
‘Plan/Build/Run’ IT value chain;

Identify Proposals

Develop Proposals

Manage Enterprise Architecture Information
Identify Proposals Develop Proposals
Path 1: Low Architectural Impact (known solution pattern)
Business
Strategic
Planning
Innovation
Ideation
Legislative /
Regulatory
Change
IT Asset &
IT Service
Planning
Develop Conceptual
Architecture
Prepare Business Case
Business Case
Initiative Brief
§
Business Vision
§
Value
§ Cost
§ Impact
§
Risk
§ Architecture Concept
§
Dependencies
§
Constraints
§ Assumptions
§ Unresolved concerns
Initiative Assessment & Prioritisation
§ Validate
§ Assign Priority
§
Assess alignment with strategy
§
Determine planning path
§ Endorse/Revert/Decline
Forward Work Plan
Conceptual
Solution
Analysis
Architecture
Impact
Analysis
Path 2: Medium Complexity (say up to $10M, 18 mths)
Architecture Vision
Architecture and
Requirements
Definition Documents
Elaborate Architecture by
Layer
Scanning Agency/Cluster/
Sector/Market
Planning and Final
Estimation
Business Case
Development
Candidate Solution Options
Initiation Business Case Business Case
Manage EA Information
Manage EA Information
§
Define and capture the information base
§
Publish and support EA information
§ Maintain EA information
EA Information Base
§ EA Vision, Principles, EA Requirements
§ Business Architecture
§
Information Architecture
§
Application / Technology / ICT Services Architecture
§ Roadmaps / Plans
§ Architecture Work Packages
§
Architecture Governance
§
Architecture Contracts
§ Guidelines
Path 3: High Complexity (say >$10m, Multi-Year)
Architecture Vision
Architecture and Requirements
Definition Documents (Interative)
First pass architectural analysis
Elaborate
Architecture by
Layer Baseline and
Target
Transformation and
Transition Plan
Schedule and Delivery
Estimate
Scanning Agency/
Cluster/Sector/
Market
Candidate Solution
Options
(Short List)
Business Case and
Project Plans
Development
Business Case to
Fund Design and
Plan
Business Case to complete Plan
Business Case
Figure 1 - Process Overview
6

4.2.2 Identify Proposals
This activity is concerned with capturing and triaging proposals that will drive changes to the ICT environment. The possible outcomes being that proposal are:

agreed to proceed to the Proposal Development stage on a designated process pathway, or

sent back for suggested revision and potential resubmission, or

declined.
There are four input activity areas;

Business Strategic Planning - encompassing IT strategy this activity typically produces a vison and goals for the business and a list of initiatives required to realise these. This strategy development typically includes an iteration of enterprise architecture work to produce the high level architecture vision, views and principles.
It should also include setting direction for the organisational capability that will deliver the on-going Enterprise Architecture Service.

Innovation Ideation - this is concerned with generating good ideas for improving the business.

Legislative or Regulatory Changes - directives which require business and IT change.

IT Asset & IT Service Planning - which is the process of identifying the value, cost, risks and known lifecycle events (for example version changes, contract expiry) to produce health assessment and management plans for IT Assets and IT
Services
1
.
Business
Strategic
Planning
Innovation
Ideation
Legislative /
Regulatory
Change
IT Asset &
IT Service
Planning
§ Business Vision
§
Value
§ Cost
§ Impact
§ Risk
Initiative Brief
§
Architecture Concept
§ Dependencies
§ Constraints
§ Assumptions
§
Unresolved concerns
Conceptual
Solution
Analysis
Architecture
Impact
Analysis
Initiative Assessment & Prioritisation
§ Validate
§ Assign Priority
§
Assess alignment with strategy
§ Determine planning path
§ Endorse/Revert/Decline
Forward Work Plan
Figure 2 - Identify Proposals
1
Release 1 of the toolkit contains some tools for this process.
7

Developing an initiative brief
The outputs of these four related activities are typically developed into an initiative brief, usually in a standard format, that is shaped with input from Enterprise Architecture.
Enterprise Architecture will work with the stakeholders to

Assess the impact of implementing the solution into the Business and ICT environment, including its relationship with established roadmaps and standards

Outline a high level conceptual solution approach to support the change/proposal

Provide a recommendation on the appropriate pathway to handle the proposal
The amount of effort here should be just enough to support the identification of the key information required in the initiative brief to enable assessment and prioritisation including determination of the most suitable pathway through the proposal development stage.
From an EA perspective, this amounts to an evaluation of the architectural impact (the degree, complexity and nature of the proposed change) and business readiness. Other
(non EA) considerations for determining the best planning pathway include the degree of business change, sourcing complexity, environmental impact etc.
The selection of the pathway through the Proposal Development stage also determines the engagement requirements with architecture boards and other assurance mechanisms.
Agencies will usually have a process for approval of proposals and subsequent business cases which provides for progressive approval and checkpoints.
These checkpoints may need to be calibrated with requirements for the accuracy of solution estimations. For example, NSW Treasury Guidelines for Capital Business Cases, indicating that cost estimates for a preliminary business case should be within 25% accuracy, and 10% for the final business case.
2
Also note that initiatives with low impact and modest funding requirements may be recommended for routing to some form of “BAU change” process outside this flow.
Assessment and Prioritisation
The next step, Assessment and Prioritisation involves;

Validating the information in the brief.

Confirming the proposal is aligned to strategy.

Prioritising the proposal.

Agreeing the path the proposal should take through the subsequent Proposal
Development stage.
This activity usually results in providing a recommendation to a governance body that reviews the brief, assigns priority and approves the proposal to proceed to the proposal development stage.
Proposals approved at the end of the Proposal Identification stage are then reflected in forward work plans with a status indicating the stage they are at within the planning process and the agreed pathway.
4.2.3 Develop Proposals
This phase of activity is concerned with sufficiently elaborating the architecture, developing the proposal plans and business cases.
The workflow provides three alternate pathways so the amount of architecture effort is appropriate to risks and benefits of the proposed initiative. This workflow is shown in
Figure 3 - Develop Proposals .
2
NSW Treasury Guidelines for Capital Business Cases TPP 08-5
8

Path 1: Low Architectural Impact (known solution pattern)
Develop Conceptual
Architecture
Prepare Business Case
Business Case
Path 2: Medium Complexity (say up to $10M, 18 mths)
Architecture Vision
Architecture and
Requirements
Definition Documents
Elaborate Architecture by
Layer
Scanning Agency/Cluster/
Sector/Market
Planning and Final
Estimation
Business Case
Development
Candidate Solution Options
Initiation Business Case Business Case
Path 3: High Complexity (say >$10m, Multi-Year)
Architecture Vision
Architecture and Requirements
Definition Documents (Interative)
First pass architectural analysis
Elaborate
Architecture by
Layer Baseline and
Target
Transformation and
Transition Plan
Schedule and Delivery
Estimate
Scanning Agency/
Cluster/Sector/
Market
Candidate Solution
Options
(Short List)
Business Case and
Project Plans
Development
Business Case to
Fund Design and
Plan
Business Case to complete Plan
Business Case
Figure 3 - Develop Proposals
As with the previous stage the principle here is to do just enough work to sufficiently elaborate the architecture definition to meet the desired level of acceptable risk. The workflow can also appear deceptively linear when in practise iteration should be expected within and across steps. The workflow for proposals with medium and high complexity
9

architecture includes a specific step to scan for building blocks that can be used to enable quicker, cheaper, faster solution delivery.
Architectural risk can be substantially reduced by using proven standards, components and well-defined architectural patterns.
The concept of building blocks here is used broadly and includes;

An existing system or architectural component such as the Service New South
Wales customer digital channels or payments solution.

An ‘As a service’ solution used by other agencies within the cluster or whole of government.

Intellectual property such as reference models, standard business requirement resources and architecture materials that can accelerate the proposal development and subsequent project delivery. The Human Capital Management and Corporate
Shared Services programs are sources of these types of building blocks in the corporate space.
The EA analysis done at this point should also seek to identify opportunities for re-use or sharing of data that is captured by another business area or agency.
Proposals with high architecture complexity have a workflow structured across three phases, reflecting the value of using checkpoints to ensure the work is tracking to objectives within the time and cost parameters and will deliver the business value documented in the initial proposal.
These checkpoints may also recommend choices between architectural options to contain the amount of work involved in analysing alternatives; and propose a set of transitions that deliver incremental value while managing complexity risk.
The program risk management technique of using business case checkpoints within the stage is useful when considering that 5%-10% of the total project cost may be required to complete the Development Proposal for projects with a total cost in the tens or hundreds of millions of dollars.
4.2.4 Manage Enterprise Architecture Information
Maintaining an enterprise architecture information base is required to inform and respond to change proposals as well as the broader strategy formulation, asset/service management and ideation processes.
The types of information required to support the Enterprise Architecture activities is
illustrated by Figure 4 Repository Model . The information in the repository will be a mix of
structured data records as well as unstructured content in the form of documents and models.
Where information from agency repositories is designed to be shared, a common metamodel is very useful. The taxonomy suggested in the RI toolkit is a step towards commonality.
10

Figure 4 Repository Model
Enterprise Architecture information appears in the common types of artefacts shown below. Further information about these artefacts and their use is provided separately in the
NSW GEA Toolkit or in industry sources such as TOGAF.
Common Enterprise Architecture Information Artefacts
Business

Business Service/Capability model

Business Process Model

Value Chain model

Organisation model

Channel model

Business Motivation model

Customer Experience model

High Level Business Use Case
Information

Enterprise Information Model

Enterprise Information Inventory

Information Standards
Application

Application / SaaS Portfolio Architecture model

ICT Application Asset / ICT Services Plan

Interface catalogue

Application Interaction model
Technology

Technology / IaaS/Paas Portfolio Architecture model

ICT Technology Asset / IaaS/Paas Services Plan

Technology Standards

Environments Diagram
11

Enterprise Architecture information is typically created and maintained through a mix of project and BAU work. Creating an initial set of foundation artefacts/ information usually requires a project style effort, however once created the maintenance of this information can be done in BAU as long as the BAU effort is linked to related processes that change the data.
IT projects are the main related process as they produce new or changed architecture information that needs to be reflected in the EA information base. In fact, it is good practise for projects to ‘check-out’ relevant information from the EA repository and then ‘check-in’ the information that reflects the changes they have delivered into the ICT environment.
Another related process that can drive changes to the EA information base is the management of ICT supply contracts including software licencing and ‘as a service’ agreements. These contracts will reset the life of software components or ICT services and potentially also the scope of what is provided via the contract including support levels which need to be considered in determining the lifecycle strategy for enterprise ICT components.
12

NSW Treasury Guidelines for Capital Business Cases TPP 08-5 http://www.treasury.nsw.gov.au/__data/assets/pdf_file/0020/12953/tpp08-5.pdf
The Open Group http://www.opengroup.org/subjectareas/enterprise/togaf
13