Embed Size (px)
Citation preview
Contact
Strategic Policy
Department of Finance, Services & Innovation
Reference Process for Enterprise Architecture enabled ICT Planning
NSW GEA Toolkit R1
April 2015
ii
1 Table of Contents
1 Table of Contents ii
2 Document control 3
2.1 Document approval 3
2.2 Document version control 3
2.3 Review date 3
3 Introduction 3
3.1 Purpose 4
3.2 Scope 4
3.3 Audience 4
3.4 Background 4
4 Reference Process 5
4.1 Why use the reference process? 5
4.2 Process Description 6
4.2.1 Overview 6
4.2.2 Identify Proposals 7
4.2.3 Develop Proposals 8
4.2.4 Manage Enterprise Architecture Information 10
5 References 13
3
2 Document control
2.1 Document approval
Name & Position Signature Date
Emily Morgan,
Principal Manager ICT Services
07/09/2015
2.2 Document version control
Version Status Date Prepared by Comments
0.1 Consultation Draft March 2015 Trent Brown Initial draft
1.0 Released April 2015 Trent Brown OFS Approved
1.1 Released Sept 2015 Trent Brown DFSI Approved
2.3 Review date
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.
4
3 Introduction
3.1 Purpose
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.
3.2 Scope
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.
3.3 Audience
The primary audience for this document are the roles of CIO, IT Managers, EA practitioners, Business Planners, Business Improvement Managers.
3.4 Background
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.
5
4 Reference Process
4.1 Why use the reference process?
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.
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
6
4.2 Process Description
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
Path 2: Medium Complexity (say up to $10M, 18 mths)
Architecture Vision
Candidate Solution Options
Elaborate Architecture by
Layer
Architecture and
Requirements
Definition Documents
Business Case
Development
Business CaseInitiation Business Case
Planning and Final
Estimation
Path 1: Low Architectural Impact (known solution pattern)
Develop Conceptual
Architecture
Business CasePrepare Business Case
Path 3: High Complexity (say >$10m, Multi-Year)
Architecture Vision
Candidate Solution
Options
(Short List)
Elaborate
Architecture by
Layer Baseline and
Target
Architecture and Requirements
Definition Documents (Interative)
Business Case and
Project Plans
Development
Business CaseBusiness Case to
Fund Design and
Plan
Transformation and
Transition Plan
Schedule and Delivery
Estimate
Scanning Agency/
Cluster/Sector/
Market
Business Case to
complete Plan
First pass
architectural
analysis
Scanning Agency/Cluster/
Sector/Market
Identify Proposals Develop Proposals
Manage 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
Manage EA Information
§ Define and capture the information base
§ Publish and support EA information
§ Maintain EA information
Business
Strategic
Planning
Innovation
Ideation
Legislative /
Regulatory
Change
Initiative Assessment & Prioritisation
Initiative Brief
§ Validate
§ Assign Priority
§ Assess alignment with strategy
§ Determine planning path
§ Endorse/Revert/Decline
Forward Work Plan
§ Business Vision
§ Value
§ Cost
§ Impact
§ Risk
§ Architecture Concept
§ Dependencies
§ Constraints
§ Assumptions
§ Unresolved concerns
Conceptual
Solution
Analysis
Architecture
Impact
Analysis
IT Asset &
IT Service
Planning
Figure 1 - Process Overview
7
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 Services1.
Business
Strategic
Planning
Innovation
Ideation
Legislative /
Regulatory
Change
Initiative Assessment & Prioritisation
Initiative Brief
§ Validate
§ Assign Priority
§ Assess alignment with strategy
§ Determine planning path
§ Endorse/Revert/Decline
Forward Work Plan
§ Business Vision
§ Value
§ Cost
§ Impact
§ Risk
§ Architecture Concept
§ Dependencies
§ Constraints
§ Assumptions
§ Unresolved concerns
Conceptual
Solution
Analysis
Architecture
Impact
Analysis
IT Asset &
IT Service
Planning
Figure 2 - Identify Proposals
1 Release 1 of the toolkit contains some tools for this process.
8
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
9
Path 2: Medium Complexity (say up to $10M, 18 mths)
Architecture Vision
Candidate Solution Options
Elaborate Architecture by
Layer
Architecture and
Requirements
Definition Documents
Business Case
Development
Business CaseInitiation Business Case
Planning and Final
Estimation
Path 1: Low Architectural Impact (known solution pattern)
Develop Conceptual
Architecture
Business CasePrepare Business Case
Path 3: High Complexity (say >$10m, Multi-Year)
Architecture Vision
Candidate Solution
Options
(Short List)
Elaborate
Architecture by
Layer Baseline and
Target
Architecture and Requirements
Definition Documents (Interative)
Business Case and
Project Plans
Development
Business CaseBusiness Case to
Fund Design and
Plan
Transformation and
Transition Plan
Schedule and Delivery
Estimate
Scanning Agency/
Cluster/Sector/
Market
Business Case to
complete Plan
First pass
architectural
analysis
Scanning Agency/Cluster/
Sector/Market
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
10
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.
11
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
12
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.
13
5 References
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
