Reference Process for Enterprise Architecture enabled ICT Planning

Reference Process for Enterprise Architecture enabled ICT Planning NSW GEA Toolkit R1 April 2015 Contact ea@finance.gov.nsw Strategic Policy Department of Finance, Services & Innovation

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 ii

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. 3

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. 4

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 5

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 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 Vision Value Cost Impact Risk Initiative Brief Architecture Concept Dependencies Constraints Assumptions Unresolved concerns Initiative Assessment & Prioritisation Conceptual Solution Analysis Architecture Impact Analysis Path 2: Medium Complexity (say up to $10M, 18 mths) Architecture Vision Elaborate Architecture by Layer Architecture and Requirements Definition Documents Planning and Final Estimation Validate Assign Priority Assess alignment with strategy Determine planning path Endorse/Revert/Decline Scanning Agency/Cluster/ Sector/Market Candidate Solution Options Development Forward Work Plan Initiation Path 3: High Complexity (say >$10m, Multi-Year) Manage EA Information Architecture Vision Architecture and Requirements Definition Documents (Interative) Manage EA Information Define and capture the information base Publish and support EA information Maintain EA information First pass architectural analysis Elaborate Architecture by Layer Baseline and Target Transformation and Transition Plan Schedule and Delivery Estimate 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 Scanning Agency/ Cluster/Sector/ Market to Fund Design and Plan Candidate Solution Options (Short List) to complete Plan and Project Plans Development 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 s, 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 s TPP 08-5 8

Path 1: Low Architectural Impact (known solution pattern) Develop Conceptual Architecture Prepare Path 2: Medium Complexity (say up to $10M, 18 mths) Architecture Vision Architecture and Requirements Definition Documents Elaborate Architecture by Layer Planning and Final Estimation Scanning Agency/Cluster/ Sector/Market Candidate Solution Options Development Initiation 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) and Project Plans Development to Fund Design and Plan to complete Plan 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

5 References NSW Treasury Guidelines for Capital s 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