Western Australian

Enterprise Architecture
Framework 1.0

WEAF 1.0
December 2017
This document, the Western Australian Enterprise Architecture Framework, Version 1
(WEAF 1.0) is licensed under a Creative Commons Attribution 4.0 International Licence.
You are free to re-use the work under that licence, on the condition that you attribute the
Government of Western Australia (Office of the Government Chief Information Officer) as
author, indicate if changes were made, and comply with the other licence terms.

The licence does not apply to any branding or images.

License URL: https://creativecommons.org/licenses/by/4.0/legalcode

Attribution: © Government of Western Australia (Office of the Government Chief

Information Officer) 2017

Notice Identifying Other Material and/or Rights in this Publication:

The Creative Commons licence does not apply to the Government of Western Australia Coat
of Arms. Permission to reuse the Coat of Arms can be obtained from the Department of
Premier and Cabinet.

Produced and published by: Office of the Government Chief Information Officer (Western
Australia) 2017.

Acknowledgements This framework was developed in collaboration with Western

Australian public sector agencies.

Enquiries:

Office of the Government Chief Information Officer

Dumas House, 2 Havelock Street, West Perth 6005
Locked Bag 11 Cloister Square, Perth WA 6850
Telephone: (08) 6551 3900
Email: [email protected] | Website: www.gcio.wa.gov.au
 Table of Contents

Context .........................................................................................................................................................1
Introduction .................................................................................................................................................2
Key Drivers ...............................................................................................................................................2

Composition ................................................................................................................................................3
1. Defining Enterprise Architecture Framework ..................................................................................5
1.1 Enterprise Architecture Definition .......................................................................................................5

1.2 Enterprise Architecture Framework Attributes ....................................................................................5

2. Overview..............................................................................................................................................7
3. Architecture Domains .............................................................................................................................8
4. Deliverables .............................................................................................................................................9
4.1 Future State Architecture Views ...................................................................................................... 10

4.2 Current State Architecture Views .................................................................................................... 12

4.3 Enterprise Roadmap ........................................................................................................................ 13

4.4 Content Metamodel ......................................................................................................................... 15

4.5 Architecture Repository ................................................................................................................... 16

5. Elements ............................................................................................................................................... 17
5.1 Metrics ............................................................................................................................................. 17

5.2 Governance ..................................................................................................................................... 18

5.2.1 Architecture Review Board ................................................................................................... 18

5.2.2 Architecture Compliance .......................................................................................................... 19

5.2.3 EA Governance Structure for WA Agency ............................................................................... 20

5.3 Principles ......................................................................................................................................... 21

5.4 Method ............................................................................................................................................. 21

5.5 Tools ................................................................................................................................................ 24

5.6 Reference Models ............................................................................................................................ 25

5.7 Standards......................................................................................................................................... 26

5.7.1 Reference Architectures ........................................................................................................... 26

5.8 Reporting ......................................................................................................................................... 27

6. Enterprise Architecture Services ....................................................................................................... 29
6.1 Problem............................................................................................................................................ 29

6.2 Benefit .............................................................................................................................................. 29

6.3 Enterprise Architecture Services Overview for WA Public Sector ................................................... 30

6.3.1 Assist with Business Strategy and ICT Strategy .................................................................. 31

6.3.2 Application Portfolio Rationalisation ..................................................................................... 32

6.3.3 Enterprise Architecture Planning and Actionable Enterprise Roadmap Development ............ 34

6.3.4 Project Prioritisation Advice to Help Driving Business Forward and Improve Program
Outcomes .......................................................................................................................................... 34

6.3.5 Business and ICT Initiatives Development ........................................................................... 35

6.3.6 Standards Establishment and Architecture Governance ..................................................... 35

6.3.7 Solution Architecture Guidance and Oversight .................................................................... 36

6.3.8 Architecture Patterns and Reusability .................................................................................. 36

7. Enterprise Architecture Skills ............................................................................................................. 38

7.1 Skills Development Maturity Roadmap ............................................................................................ 38

7.2 Reason for Defining an Enterprise Architecture Skillset .................................................................. 39

7.3 Identified Skillset .............................................................................................................................. 40

7.3.1 Communication skills ............................................................................................................ 40

7.3.2 Presentation and public speaking skills ............................................................................... 40

7.3.3 Rapport building and networking .......................................................................................... 40

7.3.4 Innovation and creativity ....................................................................................................... 41

7.3.5 Art of influencing – the Trusted Advisor ............................................................................... 41

7.3.6 Leadership skills ................................................................................................................... 41

7.3.7 Decision-making ................................................................................................................... 41

7.3.8 Negotiating Skills .................................................................................................................. 42

7.3.10 Managing Time and Competing Deadlines ...................................................................... 42

7.3.11 Assertiveness ................................................................................................................... 42

7.4 Comparative Analysis against Industry Skill Frameworks ............................................................... 43

7.4.1 Mapping of Desired Skillset against TOGAF Matrix ............................................................. 43

7.4.2 Mapping of the desired skillset to SFIA Skills Category ....................................................... 44

7.5 A Recommended Minimum Sector Wide Skill Requirement ........................................................... 45

 7.5.1 Occupational/Profession Specific Capability ........................................................................ 45

7.5.2 Occupational/Profession Specific Capability - Detailed Description .................................... 46

Appendix A – Government Enterprise Architecture Workgroup (GEAW) .......................................... 49

Members ................................................................................................................................................ 49

Consultative Process ............................................................................................................................. 49

Appendix B – Digital WA Strategic Principles ...................................................................................... 50

Appendix C – TOGAF Proficiency Level ................................................................................................ 52
Appendix D - Acronyms .......................................................................................................................... 54
Context
The Digital WA: Western Australian Government ICT Strategy 2016-2020 (the Digital WA
Strategy) is the result of consultation across the public sector and Information and
Communications Technology (ICT) industry. It positions the public sector as a whole to
leverage the opportunities presented by current and emerging technologies to deliver efficient,
reliable ICT services that support exceptional public services.

An important part of the Digital WA Strategy is the development of an Enterprise Architecture

(EA) framework for use across the public sector with the purpose of leveraging the combined
ICT capability of all agencies. An EA framework will support the Digital WA Strategy by
informing, guiding and supporting agencies in the delivery of government services.

A tailored EA framework will promote policies and practices that will assist agencies to:

 Inform and be informed: on what ICT capabilities (people, processes, information

and technologies) are available across the entire public sector by contributing to and
building on cross sector capabilities.

 Guide and be guided: by contributing to and utilising principles, policies, processes

and standards that promote agencies working together to achieve whole-of-
government- goals as well as leverage agency capabilities across the sector to more
efficiently deliver services.

 Support and be supported: assist and advise agencies on tools, techniques and
information on how to best deliver services more efficiently at a lower cost and higher
quality to the citizens of Western Australia and deliver strategic public sector outcomes.

Figure 1 – Strategic Context

Figure 1 has been sourced directly from the Digital WA Strategy. Its purpose is to provide a
whole-of-government strategic context on where the Digital WA Strategy is aligned with other
government strategic plans. This document uses the diagram to depict where EA will provide
value (blue arrows) in the areas of Informing on Agency Strategy, Guiding Agency ICT
Strategy and Supporting Agency Projects and Operations.

1
In line with the approach the Digital WA Strategy has taken, the Office of the Government
Chief Information Officer (OGCIO) will continue to collaborate across the public and private
sectors throughout the life of the Digital WA Strategy to ensure that the development of the
Enterprise Architecture capability remains relevant, effective and achievable.

Introduction
In August 2016, an inter-agency workgroup was setup within the OGCIO to develop the
Western Australian Enterprise Architecture Framework (WEAF). The group was named the
Government Enterprise Architecture Workgroup (GEAW)1.

The WEAF is designed to guide the implementation of effective EA functions within the
Western Australian public sector. The resulting EA deliverables and services will assist
agencies to deliver strategic outcomes with a lower total cost of ownership, faster time to
delivery and reduced duplications within each Agency and across the sector.

Key Drivers

The key drivers for developing the WEAF were:

 Provide an EA framework to support delivery of the Digital WA Strategy.

 Involve public sector agencies early to encourage collaboration and facilitate

consultation. Continuous engagement will likely secure agency buy-in and support for
WEAF.

 Improve the maturity of Government’s EA capability. For the majority of WA public

sector agencies, the maturity level of their current EA capability is low.

 Provide a blueprint for an EA function based on widely-used industry EA frameworks,

and be mindful of providing a structure that allows agencies with established EA
functions to easily align with WEAF.

 Leverage work already performed by another state, regional, national and international
organisations regarding EA and associated policies, procedures and guidelines.

 Maintain compatibility with Australian Government Architecture (AGA) and Federal

Enterprise Architecture Framework (FEAF) reference models to leverage these well-
established frameworks and facilitate national and interstate collaboration.

 Utilise a consolidated set of principles to make fully supportable and consistent

information technology investment decisions within the WA public sector that align with
the achievement of business and government goals.

1The GEAW is comprised of EA practitioners and/or representatives from 7 WA government agencies.

Membership of the GEAW and its consultative processes are captured in Appendix A.

2
  Support the delivery of both short-term improvements that provide a quick return on
investment and longer-term strategic improvements that provide more substantial
value over time for an agency and the government.

 Focus on creating actionable deliverables that will be used in agency and whole-of-
government decision-making rather than just “shelf-ware”.

Composition
WEAF consists of the following major components, which when used together will assist in
the delivery of an effective EA function across the public sector:

 EA Framework: defines how to create and use an Enterprise Architecture. WEAF will
provide structure for the establishment and implementation of relevant and actionable
EA deliverables at whole-of-government and agency level.

 EA Services: to facilitate consistent and uniform implementation of EA functions

across and within agencies, WEAF recommends that agencies develop EA capabilities
to provide eight defined services (described in section 6 of this document) at a level of
maturity that is appropriate for the agency. This service catalogue approach to EA work
is intended to increase the focus of EA functions on agency performance while taking
the confusion out of what services Enterprise Architects (EAs) should be providing.

 EA Skills: to deliver the effective EA services, WEAF identifies eleven skills that apply
to someone undertaking the role of Enterprise Architect within the WA public sector.
These skills have been mapped against two industry standard skills frameworks
(TOGAF and SFIA). WEAF recommends that these skills are the minimum required
for an EA role to be effective. They should be incorporated into the job descriptions as
core competencies of those undertaking the EA role.

 Reference Architectures: Reference Architectures (RA) are the means through which
WEAF provides repeatable architecture designs based on industry best-practice to
build common business and technical capabilities. They will be developed as common
or shared solutions across the sector. They provide a key mechanism to prevent
unchecked acceptance of too many different (or duplicate) solutions for the same
government service; they assist in the promotion of a coordinated whole-of-
government approach to delivering agency services to the community and can reduce
potential increases in the support and maintenance costs of the public sectors ICT
investment.

WEAF will assist agencies to improve their business and ICT capabilities by promoting
interoperability, information sharing and cross-agency collaboration for reusable and multi-
tenanted platform services and the development of common business processes, services,
functions and technical components.

WEAF has leveraged several best practices of widely adopted industry Enterprise Architecture
frameworks and standards. This includes, but is not limited to the United States Federal

3
Enterprise Architecture Framework (FEAF), The Open Group Architecture Framework
(TOGAF), Australian Government Architecture (AGA) framework and publications and
standards from the National Institute of Standards and Technology (NIST), Harvard Business
Press and Gartner Inc.

Agencies that have been or are currently developing Enterprise Architecture functions, in the
majority of cases, will be able to align to WEAF. This will minimise rework and allow agencies
to build on what they have already implemented to date.

The following sections of this document describe WEAF.

 Section 1: provides EA definition in the context of the WA public sector, it defines an

EA Framework and the characteristics it should exhibit.

 Section 2: provides an overview of the EA framework as defined by WEAF.

 Section 3: provides a quick overview of architecture domains.

 Section 4: describes the actionable EA Deliverables that are the main focus of an
agency based EA function and its structure provided by WEAF by using a mature, well
understood Content Metamodel.

 Section 5: describes the eight basic elements of WEAF that guide, support and govern
the development of these actionable EA deliverables.

 Section 6: describes eight services that all agency EA functions should offer.

 Section 7: identifies eleven minimum skills required for an EA role within the WA public
sector.

4
1. Defining Enterprise Architecture Framework
1.1 Enterprise Architecture Definition

There are many definitions of Enterprise Architecture; all focus on providing a holistic
description or view of the organisation under review. All analyse the structures, activities,
goals, vision and objectives of the organisation to provide greater understanding for relevant
and divergent stakeholders by presenting multiple views and viewpoints.

The general goal of Enterprise Architecture is to improve an organisation’s performance in

reaching their goals through better investments in people, process, information and
technology. Enterprise Architecture is also a way of describing the structure, functions,
relationships and performance of an organisation.

The following has been put forward as a definition of Enterprise Architecture (EA) within the
context of Western Australian government;

“The purpose of Enterprise Architecture is to enable the Western Australian public

sector to realise its strategic goals through better service delivery of community
services, while enabling it to respond to change and increasing its effectiveness, agility,
durability, efficiency, reliability, trust and quality while reducing costs and risks

By

Strategic Planning, Collaboration, Influencing and Governance supported by a

decision support framework to allow senior decision makers across the public sector
to make more informed decisions

Using

The Principles, Models, Guidance, Processes and Tools for the WEAF”

1.2 Enterprise Architecture Framework Attributes

An EA framework defines how to create and use an Enterprise Architecture typically by

providing blueprints, structures, common language, methods, tools and templates with the
intent of achieving business objectives in alignment with an organisation’s overall strategy.

Given its importance for business sustainability, there are a lot of EA frameworks available
and in use by various organisations in both the public and private sectors. Some of those
frameworks are specifically designed to support a multitude of organisations in multiple
industries and include comprehensive methods, tools and implementation guidelines. Some
of the other frameworks are intended to simplify the initiation of an EA function, and some
other frameworks provide generic or sector specific taxonomies to provide a common
language.

Prescribing or enforcing a single type of EA framework is not the primary purpose for WEAF.
Rather, its intent is to support the Digital WA Strategy and to meet the specific needs of the

5
Western Australian Public Sector by using Enterprise Architecture best practices and sharing
the collective lessons learned by agencies.

From the WEAF point of view, the following characteristics are what an EA framework should
possess:

 Comprehensive: an EA framework should cover all aspects of an agency. It achieves

this by providing clarity on the current and future views of the agency’s performance,
business, services, data and technology. It supports incremental development through
lines of business (agency purpose and business unit functions), Segments (targeted
lines of business that slices through architecture domains) or Domains (see section 3.
Domains for more details).

 Integrated: an EA framework should provide a mechanism (e.g. content metamodel)

that documents the relationships among architecture components within the domains
of performance, business, services, data, and technology domains and their alignment
to agency and whole-of-government strategic goals.

 Scalable: an EA framework should support architecture practices at various

organisational levels and scopes (i.e. can be applied at; whole-of-government, cross
agencies, agency, line of business, segments, capability, etc.).

 Flexible: an EA framework should be adaptable to change and accommodate different

approaches to the implementation of an EA function. It should provide the flexibility to
support architecture practices using a top-down (business-driven) approach where the
focus is on the strategic planning value of EA. Or a bottom-up approach (initially driven
by the need to improve ICT efficiencies and standardisation) to enable architecture
teams to start small, demonstrate the operational value of EA in order to gain executive
support and then incrementally expand the scope and focus of EA over time.

 Standards and Reusable Assets: an EA framework should provide and identify

reusable standards including best-practice-based architectural designs (such as
Reference Architectures) to build and document common business and technical
capabilities.

6
2. Overview
The Western Australian Enterprise Architecture Framework (WEAF), illustrated in Figure 2
below, is closely aligned with the AGA. To understand WEAF, it is necessary to understand
the components that make it up. Each of these components by themselves does not add value;
it is only when they are used together to provide a complete picture or solution can meaningful
value be delivered to stakeholders

Figure 2 – WEAF overview

Discussing the components from the outside-in, we have the following:

 Architecture Elements: methods and processes that guide, support and govern the
development of EA deliverables. WEAF has eight elements; these are; Metrics,
Governance, Principles, Methods, Tools, Reference Models, Standards2 and
Reporting.

 Architecture Domains: allow agencies to view themselves in terms of their strategic

goals and the business services, processes, information, applications and the
underlying technology that supports them. There are five domains within WEAF;
Performance, Business, Services, Data and Technology.

 EA Deliverables: are outputs produced from the Architecture domains. They are used
by agency executives in their portfolio planning, decision-making and resource
planning to achieve strategic business outcomes.

2Note that “Standards” as WEAF element (refer to section 5.7 Standards) is different to “Standard”
as an example of outputs identified within Technology domain (which is based on the AGA reference
models - refer to section 5.6 Reference Models).
7
3. Architecture Domains
An architecture domain is an abstract view of an organisation that provides stakeholders of
EA with the ability to see the organisation through different lenses. Depending on the lens
being used, it allows for the use of specific analysis and modelling to be undertaken at the
required depth to provide clarity on how the organisational component is used and contributes
to the goals of the organisations.

WEAF leverages on and conforms to the AGA. It adopts the following five architecture
domains; Performance, Business, Services, Data and Technology.

Performance domain is focused on designing and implementing effective business

measurement systems and performance architectures. It identifies measurement needs,
describes the types of measurement that can support identified needs and define effective
measurement indicators.

Business domain provides a taxonomy for classifying a functional (as opposed to an

organisational) view of an agencies’ Line of Business (LoB). It articulates the capabilities
required for achieving the desired performance outcomes and business objectives and links
the capability through to the supporting business processes.

Service domain serves to identify and classify horizontal and vertical service components that
support agencies and their ICT investments and assets. Service architecture encapsulates
business services, applications, application capabilities and components.

Data domain serves to identify and classify data assets and supports information sharing and
reuse across the public sector. It promotes uniform data management practices by enabling
agencies to agree, establish and support a common language and standards for information
sharing.

Technology domain is component-driven, technical framework categorising the standards

and technologies used to support and enable the delivery of business functions and services.

Each domain can impact or influence the others. For example, the Business drives what the
Services are, but at the same time, the Business is dependent on the Services to operate and
achieve its goals.

8
4. Deliverables
There is the tendency for EA practitioners to focus heavily on producing operational EA
deliverables (‘doing EA’) that are useful to Enterprise Architects or Solution / Domain
Architects. These deliverables are required to define, communicate and run EA functions, but
they may not be perceived as valuable by senior management or do not directly respond to
specific business and ICT requirements.

WEAF attempts to strike a better balance by maintaining and expanding the focus of agency
and cross-agency EA functions to creating actionable EA deliverables. Actionable in a way
that the architecture analysis, artefacts and documentation can also be used by executives,
managers, and staff to support and improve portfolio planning, resource planning and
decision- making. Actionable deliverables have a direct relationship to strategic goals and
business requirements, and they drive change towards the desired future state of the agency.

The WEAF identifies the following actionable deliverables as the minimum set of core
artefacts;

1. Future State Architecture

A view that represents the target state architecture of an organisation, within the
context of the strategic goals of an agency and its operating model.

2. Current State Architecture

A view that represents the current state (baseline) architecture of an organisation. An
organisation cannot start transformation process without knowing its starting point.

3. Enterprise Architecture Roadmap

A guide that contains a necessary set of actions to transform the organisation from its
current state architecture to its target state architecture.

Figure 3 below illustrates the recommended minimum set of EA deliverables.

Figure 3 – Minimum Enterprise Architecture Deliverables.

9
Both the Current State Architecture and Future State Architecture can be thought of as two
views of the same organisation at different points in time. They can take the form of a set of
interconnected models that support better planning, decision-making and management both
within an agency and whole-of-government strategic initiatives. These models describe the
relationship between an organisation’s strategic goals, business functions, information and
enabling applications and technologies in an explicit and manageable way.

The Enterprise Architecture Roadmap and the two views provide a picture of the architecture
regarding what exists currently, what is planned for the future, and what programs, projects
and initiatives constitute an enterprise roadmap to transition the agency to the future state
architecture (bridge the gap) in all five architecture domains.

For most organisations, it’s very common to also include one (or more) Transition State
Architecture as an additional deliverable to show an architecturally significant state between
the Future and the Current State Architectures. A Transition State Architecture view is used
to describe possible milestones for the effective realisation of the Future State Architecture of
the organisation.

Since public sector operations and strategic goals are not static, these deliverables must be
updated, and communicated, periodically to reflect new realities (i.e. new current state) and
changing directions (i.e. new target state).

This section describes the deliverables and a framework for an organised structure of the
current and future state architectures of an organisation. It does not contain actual architecture
views of particular agencies or indeed the whole of government. It is only when the WEAF has
been successfully implemented through an agency EA function that these outputs will be
delivered.

Other common deliverables detailed in this section, include the Content Metamodel and
Architecture Repository.

4.1 Future State Architecture Views

The Future State Architecture views represent possible target states of the organisation within
the context of its strategic direction and operating model.

It defines the architecture required to meet agency and whole-of-government initiatives. It

describes what the architecture should look like. Typically, it consists of the following models:

 Future Performance Architecture – describes the future state outcome-focused

measurements of all other architecture domains.

 Future Business Architecture – describes the future state business capabilities and the
business process model.

 Future Services Architecture – describes what business services, applications, and

systems are necessary and relevant to the organisation and how those multiple

10
 applications work together to support the future state business process model and
manage the information.

 Future Data Architecture – describes the structure of an organization's logical and

physical data assets and the data management resources required to support the
future state business process model.

 Future Technology Architecture – describes what logical software and infrastructure

capabilities on an organisation are required to support the future state business
process model, information, and application services.

Future State Architecture views also identify the motivational elements pertaining to the future
state and relate them to other architecture elements described in section 5. Elements.

Creation of Future State Architectures can be based on both agency and whole-of-government
vision and strategies. Creating Future State Architecture first before creating the Current State
Architecture view will most likely provide greater freedom in considering future possibilities. It
will allow architects to think about the business strategy and its requirements and how EA can
best support them, without being constrained by the limitations of the current environment.
Doing Future State Architecture first will also assist in determining the level of detail necessary
for the Current State Architecture to be meaningful.

One of the typical activities in establishing a Future State Architecture view is to create
diagrams and models that show how the organisation should look, without redundant
applications or systems and unnecessary processes. It also involves designing or using whole-
of-government capability / reusable components that an agency can leverage throughout the
public sector.

The type and depth of documentation of the models mentioned in the previous paragraph will
be guided by the need (i.e. ‘just enough’ approach) for detail and answers to questions about
objectives, requirements, applicable standards, time frames, and resources. To ensure
interoperability and shareability of services, Future State Architecture views need to
sufficiently describe the architecture components in each domain and specify their key
attributes at a level of detail necessary to provide an authoritative reference and to
communicate the benefits of the Future State Architecture to all stakeholders.

Additionally, models should incorporate whole-of-government Enterprise Architecture

standards including the reference architectures as applicable, based on the required business
capabilities. Reference architectures are a key input into creating future state architectures
and generally will have broad applicability to most, if not all, agencies.

Development of Future State Architecture covering all Lines of Business and architecture
segments of an agency or multiple agencies could take a significant amount of time and
resource to complete. WEAF recommends that this effort is initially focused on a small number
of key business outcomes and the underlying segments to provide quick value and gain
executive support. Note that narrowing down the focus of Future State Architecture can also
be facilitated through developing the current state and gap analysis, fitness and strategic

11
alignments of systems, etc. This incremental approach allows the EA function to evolve over
a period of time.

4.2 Current State Architecture Views

The Current State Architecture views represent the current state or baseline for the
organisation. It documents the current elements of the organisation that typically consists of
the following models:

 Current Performance Architecture – describes the existing state of outcome-focused

measurements, if any, across all other architecture domains.

 Current Business Architecture – describes the current state business capabilities and
the business process model.

 Current Services Architecture – describes what business services, applications and

systems are currently in place to manage the information and support the business
processes including their key components and interactions.
 Current Data Architecture – describes the structure and content of an organisation's
existing digital and physical data assets.

 Current Technology Architecture – describes what software and infrastructure is being

used to support the organisation.

Additionally, Current State Architecture views also represent the motivational elements
pertaining to the current state as (identified) assessments, requirements, and constraints
across all architecture domains.

One of the typical activities in establishing a current state architecture view is to create
diagrams and models to show the current operation and interactions between data, function
and platform components in the context of the five architecture domains. The type and depth
of documentation of the models should be guided by the need (i.e. ‘just enough’ approach) for
detail and answers to questions about requirements, benefits, alternatives, applicable
standards, and available resources while making sure that the EA focus is on business
outcomes and is not diverted to documentation for its own sake.

The importance of getting an accurate picture of an organisation’s current state cannot be

understated because it is fundamental to producing a quality and actionable roadmap for the
organisation – in other words, we need to know where we are to devise a reliable plan to get
to where we want to be.

Apart from providing an initial baseline in the development of an Enterprise Roadmap (refer to
section 4.3. Enterprise Roadmap) to probable future states. The Current State Architecture
assists in identifying dysfunctions, duplications, complexity and dependency of existing
solutions, facilitates continual updating of infrastructure documentation.

12
4.3 Enterprise Roadmap

The Enterprise Roadmap provides a guide on how to transition from the current state
architecture to the future state architecture through a prioritised sequence of interdependent
transformation programs, projects and other initiatives. It promotes strategic long-term
(typically 3 to 5 years as a minimum) focus on business outcomes and, with an appropriate
governance process in place, facilitates continuity in the delivery of business capabilities (e.g.,
avoid loss of direction when key business or ICT leaders change). It puts high-level strategic
change into perspective and focuses on capturing and communicating the big picture.

A well-designed Enterprise Roadmap also specifies key business outcomes expected from
each program/project/initiative; when a specific business outcome will be achieved, when a
specific business and/or information technology objective will be accomplished and how those
outcomes and accomplishments will be measured. Without such measurable objectives, it
may not be possible to validate the value and progression of programs and projects (during
their execution) towards the target Enterprise Architecture and in turn this can affect the
governance of those programs and projects.

Both the Future State Architecture and the Enterprise Roadmap can be incrementally
developed through lines of business, segments or domains by focusing on a few key business
outcomes for each increment.

Figure 4 below illustrates one commonly used approach to producing a sensible, achievable
and defensible Enterprise Roadmap.

Figure 4 – A common approach in building Enterprise Roadmap.

The steps in Figure 4 above are described in more detail below:

1. Develop desired future state architecture.

2. Develop an understanding of current state architecture.

3. Perform gap analysis between future and current state architecture views.
The outcome of the gap analysis is to identify required business and technology
transformation initiatives to close the gaps. These transformation initiatives are the
core of the Enterprise Roadmap.

4. Describe and prioritise all initiatives identified during the gap analysis.
It is critical to involve, engage and consult all relevant stakeholders throughout this
step. Each initiative should be described (typically in one or two pages) with key
information such as; why the initiative is needed, drivers, business impact and

13
 expected outcomes, organisational priority, stakeholders, dependencies and
estimated duration, cost and resources.

5. Define the optimal order in which all identified activities can be completed.
Based on the information gathered for each initiative (dependencies, drivers, priorities,
etc.) and consideration of the organisation's strategic outcomes.

6. Develop the Enterprise Architecture Roadmap.

Capture and articulate the Enterprise Roadmap. Once produced, it needs to be
published and communicated in a simple yet compelling manner for the intended
audiences.

The Enterprise Roadmap is a key input to the following activities:

 Investment Management Review

Provides information to support the investment review decision process from an
organisation-wide perspective rather than in silos and thus prevents/reduces
isolated/silo investments without big picture perspective. It also supports investment
decision-making in the context of an “architect–invest–implement” approach.

 Sourcing Practices
Ensures there is alignment between Enterprise Architecture and other transformational
processes being carried out in the organisation. Sourcing does not necessarily mean
procurement activities; sourcing could mean the reuse or redeployment of existing
public sector resources. However, if a gap is identified, then a procurement activity
may be required.

 Whole-of-government Initiatives
Provides information to support opportunities for whole-of-government / multi-agency
initiatives by promoting the interoperability and shareability of systems and services.

 Program/Project Governance
Provides information to plan, execute, monitor and control programs/projects to ensure
incremental progress towards business outcomes, and business and ICT objectives.
This, in turn, will contribute to the successful execution of multi-year programs/projects.

 Architecture Governance
Provides information to coordinate the effort and ensure architectural coherence of
multi- project and multi-vendor solutions.

As an example of a Roadmap, figure 5 below depicts the roadmap of the Digital WA: ICT
Strategy 2016 – 2020.

14
 Themes 2016-17 2017-18 2018-19 2019-20
Open Data Portal Government Data Dictionary Government Analytics
Info rmatio n and
Analytics Data Management Framework Secure Data Exchange & Repository

ICT Skills F’work

Peo ple Digitally Skilled Workforce

Capability ICT Leadership Program Digital Workforce Plan

So urcing and Agile Procurement Framework Government Solutions Marketplace Collab. & Innovation Portal

Inno vation Innovation Hub ICT Resource Sharing Portal

WA Enterprise Architecture (v1) ICT Portfolio Repository

ICT Business
Management Government ICT Dashboard

Initial Portal Portal Multiagency Exchange

Online Self-
Service Portal Identity and Payments Portal Personalisation

Digital Security Framework Public Sector Digital IAM

Digital Security
Digital Identity Digital Profile Management

Gov. Svc. Broker Software Rationalisation

Techno lo gy
Platfo rms Government Cloud and Network (GovNext_ICT)

Strategy Review & Baselining

Common Standards

Government ICT Policies

Go vernance and
Strategic Po licy ICT Governance Framework Collaborative Solution Design

Technical Impact Evaluation Process Strategy Planning & Development

Strategy Review & Update Review Review Review

Preparation Initiatives Key Initiatives Integration Initiatives

Figure 5 – Digital WA Strategy Roadmap

4.4 Content Metamodel

The content metamodel defines a set of entities that allow architectural concepts to be
captured, stored, filtered, queried and represented in a way that supports consistency,
completeness and traceability. The WEAF content metamodel utilises the metamodels of both
TOGAF and ArchiMate. Both originate from the Open Group and both focus on the Open
Group’s four architectural domains (Business, Application, Data and Technology) which can
be mapped to the following WEAF domains; Business, Services, Data and Technology.

It is acknowledged in the industry that ArchiMate diagrammatic tools promote easier use and
understanding. However, the TOGAF Architecture Content Framework (ACF) adds more
structure and breath, specifically in the context of TOGAF Architecture Development Model
(ADM) where it supports activities in “Phase E: Opportunities and Solutions” which ArchiMate
does not address (refer to figure 7 on page 25 for TOGAF ADM phases illustration). When
mapping agency deliverables to whole-of-government deliverables, agencies are free to use
the metamodels of either TOGAF or ArchiMate - or the combination of both.

Within the Performance domain (in a whole-of-government context), the ArchiMate metamodel
is used to facilitate accelerated adoption by agencies. Using this content metamodel to
develop current and future views of Enterprise Architecture allows agencies (those currently
using other frameworks such as FEAF, TOGAF and Gartner) to maintain compatibility with
those frameworks while enabling them to visually represent their Enterprise Architectures for
faster modelling and better communication. Additionally, adoption of the content metamodel
promotes consistent views within and between architectures and promotes interoperability
within and between agencies.

15
The content metamodel is intended to be flexible rather than prescriptive in order to adjust to
the different contexts found within public sector agencies. It should enable agencies to model
their architectures with a few components initially and then expand over time based on the
need for additional detail. For example, in the technology architecture domain, the
infrastructure service, infrastructure function and infrastructure interface can be ignored during
initial architecture development efforts (thus mapping an application component or artefact
directly to a node) but these elements can be added later when that level of detail is required
for communication and decision-making.

4.5 Architecture Repository

There needs to be an EA repository to support planning and decision-making using EA

information/artefacts. The EA repository is used to store, reference (link to), manage and
access architecture artefacts created by the EA function. The repository can be as simple as
logically structured hierarchy of folders and files using typical desktop tools or implemented
with an EA tool that can make it easier to manage, maintain and publish EA products. The EA
repository is a knowledge base that should be accessible by all relevant stakeholders and
supports EA governance processes.

When choosing an EA repository tool, it should be easy to access and use, support integration
with other existing EA tools and allow custom-built artefacts to be imported and stored.

Additionally, it should provide configuration management functionality that can store details
about architecture entities, their relationships and supports version control of all EA artefacts.
Any repository used within the context of the whole-of-government Digital WA Strategy should
meet the required characteristics detailed in section 5.5 Tools.

The OGCIO undertook a review of EA tools with the aim of selecting one that will undertake
the role of a whole-of-government EA Repository. After four months of review, Abacus from
Avolution Software has been selected. Agencies who do not currently own or utilise a
repository should consider leveraging the work being done by the OGCIO and leverage of a
whole-of- government capability3.

Agencies who have already invested in their repositories should continue utilising and gaining
benefit from it. To ensure consistency between the whole-of-government and agency
repositories, agencies will be asked periodically to map their repository to the whole-of-
government repository as appropriate.

3If your agency is interested to find more information on how to subscribe to this cloud-based EA tool,
please contact OGCIO on (08) 6551 3900 or via email to [email protected].

16
5. Elements
There are eight basic elements of WEAF. These elements guide, support, and govern the
development of the framework’s actionable EA deliverables.

The elements are:

 Metrics
 Governance
 Principles
 Methods
 Tools
 Reference Models
 Standards
 Reporting

5.1 Metrics

Metrics allow EA practitioners to validate the effectiveness of an EA function. They need to be

standardised to facilitate reliable comparisons to measure progress over time. To be useful,
EA metrics need to be meaningful, measurable, consistent and repeatable. Useful metrics
provide an insight into EA practices and outcomes, which can then be used to improve the EA
function.

One of the top challenges for EA practitioners is demonstrating the business value of
Enterprise Architecture. Enterprise Architecture is still an emerging practice, where 47% of
organisations have no EA metrics in place4.

Most EA practitioners focus metrics on EA operational activities that measure business value
in terms of EA activities or “doing EA”. Some of these metrics include the following:

 EA maturity assessments.
 Stakeholder surveys.
 Measuring project timelines and the quality of deliverables.
 Number of streamlined application portfolio.
 Number of business processes mapped, etc.

It is important for EA practitioners to track and measure their activities to ensure that they are
progressing EA in the right direction. However, these metrics may mean little too senior
executives. Effective EA functions should communicate and demonstrate the value of EA at
the strategic level for this audience group, by focusing how EA enables the organisation to
meet business outcomes. The challenge lies in measuring the direct contribution of EA

4Taken from Gartner’s EA Business Value Metrics You Must Have Today (ID: G00303296, published
on 3 May 2016). More information available on this link: http://bit.ly/WEAF-link11.

17
regarding the delivery of business outcomes that align with strategic goals, noting the fact that
these outcomes are often the result of transformation projects.

To demonstrate and communicate EA to senior executives, Enterprise Architects need to

frame the benefit of EA in a way that it increases IT-to-Business alignment agility and quality
and how EA influences on which transformation projects are identified, initiated, prioritised and
directed in alignment with the future state EA and the Enterprise Roadmap.

EA metrics should include key operational (EA activities, EA compliance and EA adoption)
metrics for internal use within the EA function as well as business value metrics to demonstrate
the value of EA as business outcomes enabler to senior executives.

The OGCIO will work on the delivery of whole-of-government measures in the second quarter
of 2018. Once developed and approved, agencies can adopt these measures for use within
their own EA function.

5.2 Governance

Governance is an essential function of Enterprise Architecture. Governance is not about

making ‘the right’ decision, but instead, it is about making sure that the best possible
processes are in place for making and implementing those decisions while enforcing
accountability and maintaining transparency. Good governance reduces chaos, avoids
friction, and encourages consistent and predictable results.

Good Governace should have the following characteristics (Naidoo, 2002);

- Discipline: commitment to adhere to procedures, processes and an authority

structure.
- Transparency: actions and their decision support will be available for inspection.
- Independence: establish processes, decision-making and mechanism to minimise or
avoid a potential conflict of interest.
- Accountability: individuals with certain roles within the organisation are authorised
and accountable for their actions.
- Responsibility: all parties will act responsibly
- Fairness: no unfair advantage is given to any particular party for all decisions taken,
processes used and their implementation.

When being used to support the Digital WA Strategy initiatives, WEAF will work within the
existing governance structure as described on page 13 of the Digital WA Strategy.

It is expected that EA activities will inform the work being carried out across the ICT advisory
boards and committees of agencies.

5.2.1 Architecture Review Board

18
The Architecture Review Board (ARB) serves as an Architecture Governance body that
performs the primary function of the establishment, maintenance and enforcement of Business
and ICT architecture throughout an agency.

The ARB is comprised of individuals who are experts in their field; typically, this will be the
architect practitioners (across all architecture domains) as well as other technical and non-
technical leaders from different areas of ICT.

The ARB acts as the approving and controlling authority for the following responsibilities;

 Establish, own and maintain the Agency’s EA Capability and its elements (principles,
processes, resources, standards, guidelines, reference models, etc.).
 Enforce and monitor compliance of ICT designs and components with the Enterprise
Architecture – i.e. alignment of ICT investments and project designs to organisational
goals.
 Achieving consistency between architecture domains.
 Maintaining and improving the maturity level of the architecture capability within the
agency.
 Communicate the Agency’s EA blueprint throughout the organisation.
 Provide the basis for decision-making in regards to architecture reviews and changes.
 Escalate decisions beyond the mandated authority to the appropriate (higher) body.

At a whole-of-government level, the OGCIO will create an ARB working group that will have
responsibility for the continued development and upkeep of the WEAF as well as assisting
agencies in complying with the requirements of the WEAF. Agencies are encouraged to create
their ARB to assist with the management of the agency’s architecture in a way that best-fit the
agency especially in terms of existing resource constraints.

5.2.2 Architecture Compliance

Architecture Compliance is a review of the compliance of a specific project against established

architectural criteria (i.e. elements such as principles, standards, policies, etc.) and ultimately
business objectives.

The review process involves identifying key roles, determining review scope, establishing or
tailoring checklists of the review, executing the checklists (interviewing appropriate roles and
assessing relevant documents), analysing completed checklists and preparing the
Architecture Compliance report.

Architecture Compliance review will identify the level of conformance or relationship between
the architecture model and the implementation of the product. The conformance levels are;
Irrelevant, Consistent, Compliant, Conformant, Fully Compliant and Non-conformant.

Figure 6 below illustrates the architecture conformance levels.

19
 Figure 6 – Architecture conformance levels

5.2.3 EA Governance Structure for WA Agency

To fully implement EA practice will require significant investment of time, effort and resources.
Agencies should take pragmatic approach in developing their EA practice. Two examples of
potential EA governance structures are illustrated in Figure 7 below; for a large agency (left
hand side of the diagram) and for small/medium agency (right hand side of the diagrams).

Figure 7 – Example of EA governance structure

20
5.3 Principles

The State Government endorsed the Digital WA Strategy in May 2016. The strategy contains
fifteen principles that agencies must adopt and use in their ICT decision-making processes.

WEAF promotes and heavily relies on these principles to ensure consistency in the way
business and ICT leaders consider options and make decisions. A set of clear, strategic
principles allows decisions to be delegated to the operational and project levels, by ensuring
that decisions that comply with those principles align with the approved strategic direction and
intent.

To be effective, ICT principles should support delegated ICT decision-making:

 All agencies and projects should have clear, documented principles to guide staff in
operational decisions that are in line with agreed strategic, agency and project
directions and outcomes.

 Principles should be specific and provide direction in deciding between realistic and
viable alternatives, and should not be simple missional statements of common sense.

 Principles should provide clear guidance in areas with the greatest potential to result
in scope variation or misalignment with sector, agency or project strategy.

 Project principles must align with and support agency principles, which should support
and align with whole-of-government principles, for consistent sector-wide decisions.

 Principles should regularly be reviewed at key milestones to ensure consistency at all

levels and to monitor compliance, use and understanding by relevant staff.

The Cabinet of Western Australia endorsed the mandatory use of the Digital WA Strategy in
the Premiers Circular 2016/03. The principles5 within the Digital WA Strategy have primacy
over all agency specific principles.

Individual agency ICT principles should be aligned with and support these principles, while
extending delegation to cover areas specific to an agency’s or project’s scope.

5.4 Method

A mature EA practice seeks to translate the strategic vision of the organisation into an effective
enterprise transformation plan. It enables consistent planning across the organisation and

5 The principles are listed in Appendix B of this document and in Appendix 4 - Strategic Principles of
the Digital WA Strategy available on the following link: http://bit.ly/WEAF-link2.

21
supports a risk-aware decision-making process to improve business outcomes through
collaboration.

Enterprise Architects have an important role to play in the planning, implementation and
performance measurement activities of identified investments/transformation projects. It is
crucial that the EA methods are fully aligned and integrated with the overall planning method
of the agency.

One EA method that is widely used globally, both in private and public sectors, is TOGAF’s
Architecture Development Method (ADM)6. The ADM is a reliable, proven method for
developing and managing the lifecycle of an Enterprise Architecture to meet the business and
ICT needs of an organisation. The ADM process is at the core of TOGAF.

Figure 8 below illustrates the stages of TOGAF’s ADM cycle.

Figure 8 – Architecture Development Model

The ADM is designed to be iterative over the whole process, between phases and within
phases. The ADM provides simplified steps of developing an architecture which works well for

6 Architecture Development Model (ADM) is explained in TOGAF 9.1 PART II – ADM available in the
following link: http://bit.ly/WEAF-link3.

22
non-technical stakeholders. Most of WA agencies with existing EA function should be aware
of the ADM – if not already adopting the ADM process.

Both ADM and WEAF can be tailored to suit the needs of agencies and whole-of-government
initiatives. For example, WEAF architecture domains can be mapped to phase B. Business
Architecture, phase C. Information Systems Architectures and phase D Technology
Architecture of the ADM process.

Another method that can be adopted for agency or whole-of-government collaboration

initiatives is FEAF’s Collaborative Planning Methodology (CPM)7. The CPM is a simple,
repeatable process that consists of multidisciplinary analysis designed to support integrated
planning, implementation and measurement activities. It is intended as a full planning and
implementation lifecycle for use at all levels of scope (i.e. application, system, segment,
agency, sector, state, federal, and international for some agencies).

The CPM is illustrated in figure 9 below.

Figure 9 – Collaborative Planning Method

WEAF recommends that agencies involved in multi-agency or whole-of-government initiatives

adopt an EA method that best fits the needs and maturity of their organisation. In the case of
a whole-of-government initiative, it makes sense to adopt a method that is already being used
by the majority of agencies.

7Collaborative Planning Methodology (CPM) is explained in detail on Appendix A: Collaborative

Planning Methodology Guidance Document of FEAF v.2 available on the following link:
http://bit.ly/WEAF-link4.
23
5.5 Tools

Enterprise Architects can begin EA work successfully using commonly used office productivity
software such as Microsoft PowerPoint, Microsoft Visio, Lucid Charts, SmartHost, Trello, etc.
However, due to the limitations on the capability of these tools, at a certain point, these
standard tools will no longer be sufficient. At that point, it’s inevitable that more comprehensive
professional-grade EA tools will be required and become a necessity.

Without specialised EA tools, Enterprise Architects are faced with the following challenges:

 Managing a high volume of EA artefacts and maintaining overall consistency (no

automated propagation when making changes to one).
 Capturing complex relationships between all elements that make up EA artefacts.
 Performing gap analysis, impact analysis, scenario planning and modelling.
 Presenting appropriate information for different group of stakeholders to support
planning and decision-making.
 Support for the tracking of architecture standards.
 No easy ways to collaborate with peers or when working in teams.

EA tools capture, store, structure and analyse EA artefacts and present them to the
stakeholders as appropriate. When used properly, EA tools can effectively provide support for
strategic decision-making by capturing important organisational context, along with content
development and analysis capabilities across architecture domains.

EA tools don’t solve problems on their own, but they assist Enterprise Architects in doing so.
It’s important to find a tool that suits the maturity of agency’s EA practice, which offers flexibility
to grow/adjust to your specific agency needs and is built to support common industry EA
frameworks. EA tools that an agency selects for use within an EA function should provide the
following features:

 Support for standard architecture domains view (visual representation) and their
relationships and ability to decompose the overall architecture and specific
architectures into these views.
 Modelling capabilities, which support all views.
 Support for ArchiMate (especially for EA collaboration across multiple agencies) and
TOGAF modelling concepts and notions, at a minimum.
 Support data import and export, and interface with other tools.
 Configurable capabilities that are extensive, simple and straightforward while providing
flexibility to modify the content metamodel.
 Ability to extend to link to strategic goals and transformation projects.
 Decision analysis capabilities and presentation capabilities.
 Intuitive and easy to use interfaces.
 Built-in or easily integrated architecture repository, configuration management
(including version control) and quality standard.
 Provide ability to generate reports and publish artefacts (maps, diagrams, etc.).

24
Additionally, the following characteristics have been identified to be the requirement for EA
tools used within the WA public sector:

 Must be cloud ready (Software as a Service - SaaS) and capable of securing

Unclassified data with DLM in an IRAP certified Data Centre.
 Must have the ability to store structured/unstructured information from multiple file
formats.
 Must be accessible from a browser (web-based).
 Must provide administration capability such as to enable Role Based Security, user
management.
 Must provide for Pay-As-You-Go licensing. This will allow agencies to only pay for what
they need when updating the architecture repository.
 Must meet any standards and requirements applicable to WA public sector.

5.6 Reference Models

Reference models are the taxonomies that provide standardised categorization to describe
government agencies public sector architecture elements across various viewpoints; strategic,
business, and technology models and information.

Reference models allow architects within an agency and across the public sector to
communicate using a common language. They support consistent analysis and reporting
across agency and whole-of-government EA functions. Through the use of common reference
models and their vocabularies, ICT portfolios can be better managed and leveraged across
the public sector, facilitating collaboration and ultimately achieving Government ICT strategic
goals documented in the Digital WA Strategy.

WEAF leverages the Australian Government Architecture (AGA) reference models8 created
by the Australian Government Information Management Office. The AGA reference models
are specifically designed to provide common taxonomies and categories to describe
Australian Government Agency architecture and the elements contained within it.

There are five reference models in AGA:

1. Performance Reference Model (PRM)

An outcome-focused measurement framework that can assist in the design and
implementation of effective measurements across AGA domains.

2. Business Reference Model (BRM)

Provides a framework facilitating a whole-of-government functional view of the
public sectors Line of Business, independent of the agency performing them.

3. Service Reference Model (SRM)

8AGA reference models is available on this link; http://bit.ly/WEAF-link5. How to use AGA reference
models is available on this link; http://bit.ly/WEAF-link6.

25
 Business-driven, functional framework classifying services according to how they
support business capabilities and performance objectives.

4. Data Reference Model (DRM)

Flexible, standards-based framework that supports information sharing and reuse
across the public sector.

5. Technology Reference Model (TRM)

Component-driven, technical framework categorising standards and technologies
to support and enable the delivery of services and capabilities.

5.7 Standards

Standards are agreed ways of performing something, such as making a product or managing
a process or delivering a service, that is based on collective knowledge of subject matter
experts in the relevant fields and lessons learned from previous experiences. Standards are
often voluntary; they serve as a reliable guide in approaching common problems in a
consistent and efficient manner.

In EA, standards are especially essential to achieving interoperability, increase consistency

and efficiency in terms of resource optimisation through proven common methods and shared
language for analysis, design, documentation and reporting. Standards typically contain
sufficient level of details built on repeatable patterns to encourage consistent and predictable
outcomes, but at the same time it’s also built to be agnostic and vendor neutral to facilitate
reuse, replication and implementation. Without standards, EA models, analysis and
products/deliverables will be done differently and an “apples to apples” comparison will not be
possible between applications, systems, services, lines of business and organisations.

WEAF recommends the adoption of existing applicable standards from leading bodies,
including International Organisation for Standardisation (ISO), Institute of Electrical and
Electronics Engineers (IEEE) and National Institute of Standards and Technology (NIST). In
addition to these proprietary standards, WEAF also includes other standards such AGA
reference models, Reference Architectures (described in section 5.7.1 Reference
Architectures), and Content Metamodel (described in section 4.4 Content Metamodel).

5.7.1 Reference Architectures

Learning from past experiences is not a new concept. It is common sense to leverage on
existing knowledge rather than allocating resources to reinvent the wheel each time. The issue
of how or where to learn the experience from others can be addressed by collecting relevant
information in one centrally managed location. Professions, such as civil engineers have
established engineering handbooks which document patterns of best practices and solutions
(or standards) for reuse. In EA the concept of reuse is supported through the use of Reference
Architectures.

26
Reference Architecture (RA) is what Enterprise Architects should proactively use to capture
and retain relevant architectural information potential future reuse. It is template architecture,
reusable pattern, for a specific architectural subject area. It is an abstraction of multiple
solution architectures designed and successfully deployed to solve the same (recurring)
business or technical problem in each problem space. An RA incorporates knowledge,
patterns, and best practices gained from multiple successful deployments.

RA provides detailed architectural information in a common format so that solutions can

repeatedly be designed and subsequently deployed in a manner that is consistent, high quality
and supportable. It also explains the context, goals, purpose, the problem being solved and
major foundational components (e.g., architecture building blocks) of the architecture at
multiple levels of abstraction (conceptual, logical and physical) and provides guidance on
when and how RA should be used. It also provides concepts, elements and their relationships
that are used to guide and constrain the instantiation of repeated concrete solutions and
architectures. Thus RAs serve as a reference foundation for architectures and solutions and
may also be used for comparison (benchmarking) and alignment purposes. This alignment
will facilitate repeatable solutions across state agencies that will lead to shared solutions.

RAs also provide a key mechanism to prevent unchecked acceptance of disparate solutions.
For architects, they serve as a key input when creating their agency’s future state Enterprise
Architecture. It provides a standard blueprint on how a future state should be developed.

Additional benefits of RAs include risk reduction, knowledge transfer, simplified decision-
making, improved deployment speed, integrated regulatory compliance and cost reduction.

Reference Architecture is different to Reference Model. While RA is the collection of

experiences as an architectural template, reference model provides architecture categories
and taxonomy to enable architects to communicate using common language which mitigates
the risk of learning from the wrong experience. Enterprise Architects find the right RA using
the reference model as the reference point to communicate and learn the right experience in
the right context.

5.8 Reporting

To be useful for the organisation, architecture artefacts that are created, collected and stored
in an EA repository system need to be easily accessible by and published to relevant
stakeholders. These artefacts support the creation of various EA reports.

EA reporting is about using relevant metrics (refer to section 5.1 Metrics), assemble and
present them in a manner that is meaningful for the intended stakeholders. Like any other
programs/initiatives/projects, we need to be able to report on the EA function activities and
measure the benefits to maintain visibility of current organisational capabilities and future
opportunities.

Reporting is also a powerful tool to communicate EA performance and market the relevance,
value and importance of the EA function within the organisation - in a standardised way using
established metrics and a documented method. EA should be produced in the context of
alignment with organisation goals and outcomes, especially those that are intended for senior

27
executives. Executive leadership is often attributed to being the key to address management
challenges identified by EA function, such as overcoming limited executive
understanding/support and inadequate funding. As such, benefits and outcome of EA function
should be periodically reported to senior executives, who are the decision makers and have
the authority to invest additional resources or make changes and improvement to the EA
function.

WEAF recommends that an EA function should consider producing the following reports;

- Annual EA Plan, include sufficient details of how the overall EA is planned to be

developed in segments, EA function current status and progress to date.
- Enterprise Roadmap
- ICT / Business Strategic Alignment
- Application Portfolio Rationalisation Results
- EA Maturity Scorecard
- Business Process Maturity Scorecard
- Catalogue of Reusable Services and Assets
- Reference Architecture Technology Standard Matrix

28
6. Enterprise Architecture Services
The purpose of this section is to establish a set of minimal EA responsibilities; specific services
that agencies should deliver to facilitate consistency and regularity in the implementation of
an Enterprise Architecture function across the public sector.

This section also aims to provide WA government agencies with an understanding of how EA
services can help guide and inform their business and ICT decision-making processes to
deliver fit for purpose solutions that empower business in achieving their strategic goals
effectively.

Furthermore, this section provides an understanding of how to leverage EA services to extract

the maximum value for each agency.

6.1 Problem

Agencies need to make informed strategic decisions. Decisions made without the necessary
and relevant information can deliver suboptimal outcomes to the organisations. The most
common problems are that business units develop siloed solutions with increasing
unsustainable support costs, causing agencies to abandon an integrated, cost effective and
corporate wide approach to delivering solutions. A lot of unnecessary work may take place
before the results of an uninformed or misinformed strategic decision finally surface.

6.2 Benefit

Enterprise Architecture, through its services, can support a common understanding of needs
across different areas of the business. EA facilitates collaboration in the planning of solutions
to address specific business needs with a holistic view rather than simply addressing it only
from technology planning perspective. EA especially plays a pivotal role in ensuring the
alignment of solution investments to the agency’s strategic goals.

A mature EA practice seeks to translate the strategic vision of an agency into an effective
enterprise transformation plan. It will ensure decisions are made with full understanding of the
strategic objectives and their implications for the agency and across the public sector. It will
also ensure decision makers have a clear understanding of cost, risk and benefit associated
with each decision to assist them in finding the optimal solution.

A consistent and well-defined EA function can help change the perception that may currently
exist within an agency that views ICT as an inhibitor instead of seeing it as the key enabler for
core business transformation.

An EA function can be implemented to deliver benefits to agencies of all sizes and whole-of-
government initiatives. The services offered by an EA team should be tailored and adjusted to
match the size and specific circumstances of an agency. Just enough and no more
architecture should be applied so an agency can be confident that well considered and risk-
aware decisions can be made and governed. Similarly, it is important that an EA capability is

29
implemented pragmatically in order not to introduce too many overheads or deliver
architecture products that are difficult to deliver and maintain which eventually become “shelf-
ware”.

6.3 Enterprise Architecture Services Overview for WA Public Sector

The GEAW process researched, identified and discussed a range of activities where
Enterprise Architecture can provide value to agencies.

What follows is a minimal list of eight services that an EA function within an Agency should
provide to support an effective EA function. The eight EA services are:

1. Assist with Business Strategy and ICT Strategy.

2. Application portfolio rationalisation.
3. Enterprise Architecture planning and actionable Enterprise Roadmap development.
4. Project prioritisation advice to help drive the business forward and improve program
outcomes.
5. Business and ICT initiatives development.
6. Standards establishment and architecture governance.
7. Solution architecture guidance and oversight.
8. Architecture patterns and reusability.

Figure 10 below illustrates the context of the EA services.

Figure 10 – WA Enterprise Architecture service context

To order to develop a level of effectiveness of EA capability across the public sector, it is

envisaged that agencies will charter their EA teams to provide the services listed in this
section.

30
6.3.1 Assist with Business Strategy and ICT Strategy

A Business Strategy can be defined as a set of guiding directions/principles that when adopted
by the business, provides the mechanism to generate desired decision-making. It sets the
strategic direction and what needs to be done to achieve/accomplish key objectives. It should
also include a clear and focused roadmap that guides the prioritisation of initiatives. Typically,
a business strategy spans across a number of years (e.g. 5 to 10 years).

An ICT Strategy is focused on how technology will enable the business to achieve its strategic
goals. It specifies the contribution required of ICT to support and deliver strategic business
outcomes successfully. The ICT strategy primarily focuses on the applications, data and
technologies required to deliver business services, along with the people or organisations
whom directly interact with (or manage) them.

To deliver value, the ICT strategy needs to be aligned with the business strategy. ICT
investment must be made in a way that it demonstrates support for the achievement of
business strategic goals. The development of the aspirational and achievable business
strategies depends on a good understanding of the capabilities of the existing and available
ICT services that can enable them.

EA aims to clearly show how ICT investments are linked to strategic goals and how these
investments will help achieve measurable business outcomes. It is because of this strategic
perspective and future thinking that the EA role is well suited to assist in the development of
Business and ICT strategies.

Figure 11 below describes the role of Enterprise Architecture in assisting with the alignment
of ICT Strategy with Business Strategy.

Figure 11 – EA role in the context of business and ICT strategies

To assist with the development of business and ICT strategies, EA can provide:

 An understanding of how emerging and innovative ICT solutions can drive business
efficiencies.

31
  Shape strategic vision and goals to ensure they are achievable and viable with the
technology available now and into the future.

 An understanding of the synergies available from the strategic paths of, different
business units within the agency, similar industry segments outside the agency and
across the whole-of-government.

 Understanding what existing ICT capabilities are available, assessing their business
and ICT fitness and identifying capabilities that can be reused or leveraged to support
the strategic vision.

 Facilitate the alignment of ICT strategy with business strategy.

6.3.2 Application Portfolio Rationalisation

“Application rationalisation often occurs after an IT organisation accumulates an unmanaged

collection of applications through shifting business strategies or mergers and acquisitions. The
clean-up can include replacing, retiring, modernising or consolidating applications.” Gartner9.

Based on the above definition, Application rationalisation is part of an Application Strategy that
looks at whether an agency needs to replace, retire, remediate or consolidate legacy
applications. As part of this exercise, the agency should assess whether the chosen ‘clean-
up’ decision assists in streamlining existing business processes. To increase overall
efficiency, reduce complexity, free up a budget for more business-critical initiatives and ensure
that ongoing costs and resources are value for money.

Figure 12 below shows the overview of application rationalisation processes.

Figure 12 – Portfolio rationalisation overview (based on Gartner, July 2013)

9Taken from Gartner’s Application Rationalisation Key Initiative Overview (ID: G00252063, published:
25 July 2013, refreshed: 11 February 2015), more information on this link: http://bit.ly/WEAF-link7.

32
Significant savings can potentially be made through a sound understanding and management
of an organisation’s application portfolio. EAs can assist the agency in developing a well
maintained and appropriately structured application portfolio strategy; agencies will have the
ability to identify duplication of application functionality across the agency technology
landscape.

Application rationalisation plans can be developed and built into future planning as
applications reach end-of-life or as ICT and business plans progress.

To support the applications rationalisation exercise, EA can assist in guiding how the business
can initiate and implement the following activities:

 Retiring applications with low business value and low level of strategic alignment.
 Modernising applications with high business value and low level of strategic alignment.
 Consolidating or reprioritising applications with low business value and high level of
strategic alignment.
 Eliminating applications that are identified as being redundant or duplicate.
 Standardising common technology/infrastructure platforms.

Figure 13 below shows how the mapping of applications in relation to their business value and
their strategic alignment can assist with rationalising the application portfolio, using Gartner’s
TIME (Tolerate, Invest, Migrate and Eliminate) analysis10.

Figure 13 – Mapping of applications using Gartner’s TIME analysis

10Based on Gartner’s Application Portfolio Triage: TIME for APM (ID: G00169227), published on 5
August 2009), more information on this link: http://bit.ly/WEAF-link12.

33
Agencies should understand their strategic initiatives, potential and in-flight projects to prevent
new initiatives delivering duplicate solutions. It is imperative that what already exists is defined
within the agency and what is required to support other future initiatives (current vs. future
state). It is envisaged by taking this approach, an agency will reduce its costs and minimise
system complexity.

6.3.3 Enterprise Architecture Planning and Actionable Enterprise Roadmap

Development

An effective EA practice can provide the skills and methods to translate business and ICT
strategy into an achievable and actionable roadmap, helping lead an organisation through
business transition.

Transitioning an organisation to meet a significant change agenda requires a big picture

approach to ensure all impacts, opportunities and constraints are well understood and
considered. It requires an understanding of the business’ desired future state and how to best
transition towards it, in a manner that ensures risk is appropriately managed while maintaining
minimal disruption to business activities throughout the process.

Taking an organisation-wide perspective ensures that all interrelationships and

interdependencies are understood and built into a roadmap that seeks to deliver both tangible
business benefits continuously and progressively, and to sequence technical dependencies
to minimise future work effort.

Section 4.3 Roadmap provides a guideline of EA roadmap development.

6.3.4 Project Prioritisation Advice to Help Driving Business Forward and Improve
Program Outcomes

EAs’ understanding of Business and ICT strategies and priorities combined with their
understanding of how to best sequence and group ICT activities enable them to provide well-
considered advice on project prioritisation. Project prioritisation helps to drive business
forward efficiently which in turn improves overall business outcomes.

EAs understand what activities are required to transition a program of work that needs to be
broken up into projects, that include the following:

 Grouping activities that deliver discrete pieces that are immediately useful and valuable
to the business with the minimum amount of effort.
 Grouping change to minimise business disruption by avoiding multiple instances of
business process change.
 Grouping closely related technology change together.
 Grouping activities that will deliver key foundation ICT pieces.

Project prioritisation and sequencing are typically driven by a reconciliation of:

34
  Business priorities and progressive delivery of items that provide business value.
 Project complexities and Interdependencies through ICT components, business
components and their interdependence on separate business activities.
 ICT constraints and cost avoidance from items such as license agreement renewals,
end of vendor supports, etc.
 Risk value of the project vs projected organisational benefit.
 Alignment of the project to the approved agency’s future state architecture.

6.3.5 Business and ICT Initiatives Development

To get project approval, an organisation typically requires a clear description of the project
concept and its business case to justify the undertaking of the project. The business case also
documents the requirement, the desired benefits as well as common agreements on how the
outcomes will be measured.

EAs are uniquely positioned to assist business and technology leaders with the development
of project concept and business case documents. EAs can proactively assist by providing the
following capabilities:

 Brings the experience to understand how the big pieces of the solution can be
assembled to meet the objectives of the business case and assist the development of
cost estimates for solution options.
 Brings a thorough knowledge of an agency’s ICT landscape to recognise what can be
reused, leveraged or interfaced to, and what pieces of other projects will deliver and
what is planned for the future. All of these bring opportunities or constraints to the
business case.
 Through a knowledge of emerging technologies, EA understands what can be
leveraged to provide solution options.
 Brings a knowledge of the business and ICT strategies to ensure the proposal will be
fit for purpose and can deliver the required strategic benefits.

6.3.6 Standards Establishment and Architecture Governance

EAs are skilled in establishing standards, guidelines and principles that guide ICT systems
development including the establishment of appropriate governance and assurance
processes to manage how they are applied.

Standards and principles guide the development of solutions in a systematic way leading to
predictable outcomes that are the key to successful delivery of projects. Governance
processes ensure the agreed approach is followed and any exceptions are considered at the
appropriate level of decision-making.

Exceptions to the standards are at times necessary to exploit new opportunities or to avoid
constraints. An EA role is best positioned to understand if the benefits of the exception will
outweigh the introduction of non-standard aspects into the environment.

35
Ideally, standards, guidelines and principles should be highly accessible to projects from a
single location and managed in a controlled way. Making these available to projects alongside
other architecture information provides projects with a one stop shop for their project planning
requirements.

6.3.7 Solution Architecture Guidance and Oversight

Solution and technical architects engaged by ICT project teams can be overly focused on the
delivery of specific requirements for an isolated business area and may overlook or forget the
“big picture” or holistic view and its benefits.

On top of delivering fit-for-purpose solutions, the project also needs to make sure that they
are durable, fit well into the environment and aligned to the future state EA.

To do this, the project needs to:

 Provide solutions that align to agency and whole-of-government wide business

strategies.
 Be developed according to agreed principles and standards that instil good practice.
 Complement and integrate well into an existing environment.
 Use technologies and hosting arrangements that will bring down the long term total
cost of ownership, for instance by leveraging existing whole-of-government solutions.

EAs project involvement will provide valuable direction, guidance and oversight for solution
architecture in designing solutions and producing deliverables that align with the
organisation’s strategic direction.

Acting as a central governance function for the organisation’s architecture, EAs can apply the
governance and assurance processes to ensure that project teams deliver designs and
implement their solutions that align with the agreed architectural outcomes.

For it to be successful and consistent, this needs to be embedded in the Project Lifecycle or
the organisation’s Project Management Framework.

6.3.8 Architecture Patterns and Reusability

A Reference Architecture is an example of a reusable pattern or asset that provides a template

solution, prescriptive guidance or a defined set of architectural guidelines and constraints
about a specific subject to be shared across an agency’s business process, systems,
information and technology. It reflects lessons learned from previous change programs, offers
standardised terminology, provides a common language and encourages adherence to
common standards and best practices.

Utilising existing reference architecture eliminates the need to reinvent the wheel. More
importantly, creating and using a reference architecture will support consistency across

36
solutions and streamlining or reducing potential solutions duplication in addressing the same
problems while increasing the chance of delivering successful solutions at the same time.

Other types of reusable assets include shared services and infrastructures, best practices &
guidelines for different activities (system design, software specification and constructions,
testing, etc.), solution documents, code fragments, scripts and so on.

Sector-wide focus on creating, maintaining, identifying and utilising reusable assets can make
a notable contribution to reduced ICT project and operational costs, increased stability and
efficiency throughout the project life cycle and reducing risks.

EAs can promote the concept of asset reuse, assist with leading and coordinating the
collection of reusable assets at the agency level and make them available for use across the
public sector to benefit other agencies.

37
7. Enterprise Architecture Skills
The purpose of this section is to define the minimum required Enterprise Architecture skillset
for the Western Australian public sector. The skills identified in this section are necessary to
ensure that EA practitioners are equipped to deliver the services and responsibilities described
in section 6. Enterprise Architecture Services.

This section also provides a comparative analysis of the identified skill sets and two industry
standard skill frameworks; namely TOGAF skills matrix and SFIA skills category. All skills
identified in this section are recommended to be the minimum required skillset that should be
incorporated into job descriptions as compulsory core competencies for the position(s)
performing the EA function within an agency.

7.1 Skills Development Maturity Roadmap

There are two mainstream views of Enterprise Architecture. The first one is the ICT view that
an EA role undertakes the planning responsibilities of the Chief Information Officer (CIO). The
second and more contemporary definition is that the EA role focuses on assisting agencies to
identify business opportunities, provide clarity on possible internal and external issues which
may affect business execution and aligning the organisation's structural capabilities and
performance to reach its desired goals.

To successfully contribute to the Digital WA Strategy, the EA role needs to be business

focused, staff undertaking the role need to be able to quickly relate to and understand internal
and external influences within their agency. They must have the capability to seek out and
leverage the capabilities of the public sector. This thinking is in line with the definition of EA
as it is described within TOGAF.

Currently, within the WA public sector, there is a need for strong performance, business and
data architecture skills. Technology architecture skills are in greater supply due to a stronger
correlation with existing ICT roles.

Figure 14 below demonstrates the focus of a staff member undertaking the EA role.

Figure 14 – EA Domain Focus.

38
The skills required to operate within each domain are similar. The main differentiator is in the
depth and proficiency of the skills required to be effective within the requirements of specific
agency. An agency’s maturity in the adoption of EA as a defined role will go a long way in
determining how proficient certain skills need to be; for example, if EA is restricted to
supporting the CIO planning function there is less of a requirement to be proficient in
understanding structural agency requirements.

7.2 Reason for Defining an Enterprise Architecture Skillset

The OGCIO has conducted multiple workshops and surveys across the public sector regarding
the use and future adoption of EA within agencies and the skills required by the people to
undertake the task.

It was found that there were small pockets of agencies who understood what Enterprise
Architecture was and had integrated it into their business and operating models. However, in
most cases, agencies thought that EA was purely ICT related and focused purely on managing
Technology, as opposed to taking a more holistic, strategic approach to managing their ICT
investments.

Figure 15 places the WA public sector EA’s focus towards strategic organisation issues. For
most of those surveyed, it was believed that EA was undertaken within projects and that most
of these projects had the objective of delivering operational ICT architecture outcomes.

Figure 15 – Architecture Focus

39
7.3 Identified Skillset

Enterprise Architect is the glue, not the guru; the glue that bridges the gap between business
strategy and execution through facilitating enterprise collaboration, not the guru with a broad
knowledge to architect enterprise systems or complex integrated solutions.

With this in mind, the GEAW identified the following skill sets as being required as a minimum
skillset for the Enterprise Architecture role within the Western Australian public sector.

For convenience, staff carrying out the Enterprise Architecture role can be called Enterprise
Architects (EAs). Within the public sector, these people sometimes can carry titles such as
Chief Information Officer, Chief Technical Officer or Corporate Services Director.

It is important to emphasise that this section focuses on roles, not positions. A role can be part
of a position or spread over multiple positions. A role can be generic for example “Strategic
Planning”, or more specific such as a “Business Architect with Health Experience”.

7.3.1 Communication skills

To be effective, staff undertaking the EA role must confidently present messages in a clear,
concise and articulate manner to senior executives, business management, ICT management,
solution architects, technical architects, Subject Matter Experts (SME), partners and
customers.

EAs need to adapt their vocabulary and style for each situation and target audience to
effectively communicate the message they’re trying to convey.

They must sell the business value of the structured approach that Enterprise Architecture
promotes to an agency by developing compelling and memorable value propositions and
promoting them effectively.

7.3.2 Presentation and public speaking skills

Enterprise Architects are expected to give presentations on a fairly regular basis. As such they
need to be comfortable speaking to large audiences, senior executives, business and
technical leaders.

They must operate as an effective representative of the agency in public and internal forums.
They must have the ability to translate information for others, focusing on key points and using
appropriate, unambiguous language at a level and in a way suitable to the target audiences.

They should be adept at representing complex ideas using suitable tools and techniques to
promote a better understanding of the value of the message being conveyed.

7.3.3 Rapport building and networking

40
EAs must have the ability to build, sustain and influence relationships with key internal and
external stakeholders.

A key principle of EA is to break down silos and find common solutions across an organisation.
To have any chance of succeeding at this, EAs must network and build rapport with business
and technology leaders, SMEs and other influencers.

Ideally, Enterprise Architects should be amongst the most connected individuals in an

organisation.

7.3.4 Innovation and creativity

Enterprise Architects are commonly required to find solutions to a wide range of business and
technology problems. A good architect has no interest in reinventing the wheel but instead will
seek standardised solutions for problems. In cases where no standard solution exists, EAs
are expected to determine a simple and sensible solution quickly.

Enterprise Architects may be called upon to find solutions across a wide range of technologies
and business domains. Often solutions have budget, time or operational constraints. It takes
a considerable amount of creativity and innovation to provide Enterprise Architecture services.

7.3.5 Art of influencing – the Trusted Advisor

Enterprise Architects must be able to build credibility, gain support, inspire others, create
relationships and engage people's imaginations to influence their behaviour.

The mandate of EA is ambitious; to bridge the gap between the business and ICT, to break
down silos and agree on common solutions. EAs will not be effective in achieving those
objectives if they cannot influence others to enact change.

7.3.6 Leadership skills

EAs may be asked to lead business and technology programs, projects, workshops and
initiatives. They must inspire confidence, garner respect from business and technology
stakeholders and encourage others to work collaboratively towards a common goal.

Leadership also requires planning, supervision, coaching and delegation skills.

7.3.7 Decision-making

Enterprise Architects are frequently asked to make decisions about technical approaches. The
ability to make clear, consistent decisions is key to an EAs success. Decision-making requires

41
skills such as fact finding, big picture thinking, creativity, analytical ability, emotional
intelligence and assertiveness.

7.3.8 Negotiating Skills

Enterprise architecture involves building common solutions across organisational, business

and technological silos. Implementation and governance of Enterprise Architecture involves
constant negotiation. Differences of opinion are the rule, not the exception.

Enterprise Architects must find common ground between stakeholders and determine
approaches that have a good chance of gaining stakeholder support necessary to achieve
results. Choosing the ideal architectural path needs to be balanced with practical concerns
such as budget and time to market.

7.3.9 Research Skills

Enterprise Architecture spans business, system, data and technical architecture. To be

effective across diverse and constantly changing domains, EAs need to be able to quickly
locate, gather, investigate and process information quickly from variety of sources.

EAs need to explore new be proactively researching emerging business and technology trends
and applying them within the context of their agency.

7.3.10 Managing Time and Competing Deadlines

Enterprise Architecture involves long term strategic planning. EAs should not be purely
reactive; they need to balance daily pressures with the need to focus on achieving long term
priorities and goals.

7.3.11 Assertiveness

Avoiding conflict at any cost might be perfectly all right for some professions - an Enterprise
Architect is not one of those professions. EAs need to take the initiative, proactively step in
and do what is required, question approaches, point out mistakes and ask for help when
necessary.

They must challenge important issues constructively and sand stand by their position when
challenged. Effective EAs know it is not possible to please all the people all the time, they are
seldom reluctant to speak their mind.

42
7.4 Comparative Analysis against Industry Skill Frameworks

To ensure that the GEAW’s findings were in line with industry thinking, a comparative analysis
of the selected skill sets was carried out against two prominent industry skills frameworks.

These were TOGAF and the Skills for an Information Age (SFIA) framework. Many public
sector agencies should already be familiar with both standards.

7.4.1 Mapping of Desired Skillset against TOGAF Matrix

TOGAF is considered an industry standard for Enterprise Architecture. The GEAW undertook
a mapping exercise of the 11 skills identified in this document and mapped them against the
level of proficiency suggested by TOGAF for generic skills for EA role. See figure 16 below for
the result of the skills mapping exercise.

Figure 16 – Mapping of minimum EA skill sets to TOGAF proficiency level

An analysis of the required EA skill sets against TOGAF proficiency level identified that an EA
role needs to have a comprehensive knowledge of the technical skills identified and be seen
as an expert communicator.

Refer to Appendix C for more information in relation to each of the proficiency levels.

43
7.4.2 Mapping of the desired skillset to SFIA Skills Category

The Skills Framework for the Information Age (SFIA)11 is a competency framework that
describes the skills needed to fulfil roles within the ICT field.

It has been adopted in over 200 countries and has become the globally accepted language
for skills and capabilities of ICT professionals. SFIA is administered by the SFIA Foundation
and is supported by government and industry in the United Kingdom.

The current published SFIA model (SFIA 6) has identified 97 separate skills which are grouped
into six work areas;

- Strategy and architecture

- Change and transformation
- Development and implementation
- Delivery and operation
- Skills and quality
- Relationships and engagement.

Each skill entry has an overall description and descriptions of each of up to seven levels of
responsibility and accountability at which the skill might be exercised by ICT professionals.

The seven levels are;

1. Follow
2. Assist
3. Apply
4. Enable
5. Ensure, advise
6. Initiate, influence
7. Set strategy, inspire, mobilise

The WA Public Sector has adopted SFIA as a standard to enable consistency in defining ICT
skills and abilities within Western Australian government. This is reflected on the ICT
Capability Framework12.

As part of WEAF development, the GEAW undertook a mapping exercise to understand how
the base Enterprise Architecture role requirements would map to the SFIA framework.

The result is provided in figure 17 below.

11 More information on SFIA available on the following link: http://bit.ly/WEAF-link8.

12ICT Capability Framework is a guideline for ICT and HR practitioners to assist in developing greater
consistency in defining ICT practitioner capability within WA public sector. This framework was
created by the OGCIO in partnership with the Public Sector Commission. The ICT Capability
Framework is available on the following link: http://bit.ly/WEAF-link9. 44
 Figure 17 – Mapping of minimum EA skillsets against SFIA framework

In the above diagram, the “Compulsory” section within “SFIA Skills” lists the skills that are
recommended by SFIA for an Enterprise Architect to possess. The GEAW also identified
additional skills, the “Optional” section within “SFIA Skills”, that are applicable for an Enterprise
Architect that works within the WA public sector.

7.5 A Recommended Minimum Sector Wide Skill Requirement

The GEAW process researched, identified, consulted and undertook comparative analysis
against industry skills frameworks. What follows is a minimum skillset that should be
incorporated into all job descriptions that undertake the Enterprise Architecture role within the
public sector as compulsory core competencies. Agencies may add to these required skill sets
but should not remove them.

In alignment with the ICT Capability Framework, the recommended skillset for EA roles has
been specified in SFIA format below to allow for transcription into Job Description Form (JDF).

7.5.1 Occupational/Profession Specific Capability

The content shown below can be used in Enterprise Architecture JDF to help ensure
applicants meet common competencies across the sector.

45
 SFIA Skills Category SFIA Level - PSGOGA
Code Equivalent

Strategy & Architecture Business Strategy and Planning Level 6 - STPL Level 7 - 9
Enterprise and business architecture

Strategy & Architecture Advice & Guidance Level 6 - CNSL Level 7 – 9

Consultancy

Strategy & Architecture Information Strategy Level 6 - ISCO Level 7 – 9

Information systems coordination

Strategy & Architecture Technical Strategy & Planning Level 6 - EMRG Level 7 – 9
Emerging technology monitoring

^Strategy & Architecture Information Strategy Level 6 - GOVN Level 7 – 9

IT governance

^Strategy & Architecture Business Strategy and Planning Level 6 - INOV Level 7 - 9
Innovation

^ Optional

7.5.2 Occupational/Profession Specific Capability - Detailed Description

Category and Level and Level Description

Sub-category Code
Strategy & Level 6 Enterprise and business architecture (STPL)
Architecture STPL
Business Captures and prioritises market and environmental trends,
Strategy and business strategies and objectives, and identifies the business
Planning benefits of alternative strategies.

Establishes the contribution that technology can make to

business objectives, conduct feasibility studies, produce high-
level business models, and prepare business cases.

Leads the creation and review of a system's capability strategy

that meets the strategic requirement of the business.

Develops enterprise-wide architecture and processes that

ensure that the strategic application of change is embedded in
the management of the organisation, ensuring the buy-in of all
stakeholders.

Develops and presents business cases, for high-level

initiatives, for approval, funding and prioritisation.

46
Category and Level and Level Description
Sub-category Code
Ensures compliance with business strategies, enterprise
transformation activities and technology directions, setting
strategies, policies, standards and practices.

Strategy & Level 6 Consultancy (CNSL)

Architecture CNSL
Advice & Manages provision of consultancy services, and/or
Guidance management of a team of consultants. In own areas of
expertise, provides advice and guidance to consultants and/or
the client through involvement in the delivery of consultancy
services.

Engages with clients and maintains client relationships.

Establishes agreements/contracts and manages completion
and disengagement.

Strategy & Level 6 Information systems coordination (ISCO)

Architecture ISCO
Information Maintains an awareness of the global needs of the
Strategy organisation, and promotes the benefits that a common
approach to IT deployment will bring to the business as a
whole, among information systems and business
management.

Coordinates the promotion, development, acquisition and

implementation of information systems and services in close
liaison with those responsible for management and strategy.

Strategy & Level 6 Emerging technology monitoring (EMRG)

Architecture EMRG
Technical Coordinates the identification and assessment of new and
Strategy & emerging hardware, software and communication
Planning technologies, products, methods and techniques.

Evaluates likely relevance of these for the organisation.

Provides regular briefings to staff and management.

^Strategy & Level 6 IT governance (GOVN)

Architecture GOVN
Information Puts in place, or confirms, staffing structures to support the
Strategy work of the governing authority (board, trustees, etc.) and
proper relationships between the organisation and external
parties.

Takes responsibility for review of management processes (and

decisions) and confirms that they are compliant with the
organisation's strategy for corporate governance of

47
 Category and Level and Level Description
Sub-category Code
information. Is familiar with relevant standards and the
principles embedded within them.

Reviews new business proposals and provides specialist

advice on compliance issues. Acts as the organisation's
contact for relevant regulatory authorities. Establishes policy
and standards for compliance with relevant legislation.

^Strategy & Level 6 Innovation (INOV)

Architecture INOV
Business Recognises potential strategic application of information
Strategy and technology capabilities. Initiates and manages investigation
Planning and development of innovative methods, practices and
technology, to the benefit of organisations and the community.

Plays an active and dynamic role in improving the interface

between all interested parties, facilitating knowledge flow to
enable sharing and development of creative ideas.

^ Optional

48
Appendix A – Government Enterprise Architecture Workgroup
(GEAW)

Members

# Name Agency

1 Alex Kay Western Australia Police Force

2 Angelo Giaros Department of Premier and Cabinet

3 Bill Bell (Chair) Office of the Government Chief Information Officer

4 Clive Williams Department of Justice

5 Envy Crosby Department of Health

6 Gery Elrahweise (Coordinator) Office of the Government Chief Information Officer

7 Mel Trifiletti Department of Mines, Industry Regulation and Safety

8 Michael Clover Department of Finance

9 Patrick Brosnan Insurance Commission of Western Australia

Consultative Process

In developing this document, the GEAW consulted with the following stakeholder groups.

# Consultative Method Stakeholder Group

1 Undertook public sector wide surveys and workshops to gauge Public Service ICT &
the current maturity of Enterprise Architecture across the sector. Business.

2 Research on the capabilities of other government jurisdictions Peers.

was undertaken at state, federal and international levels.

3 Consulted with Tier 1 advisory services providers. International Subject

Matter Expert.

4 Make document available for review on the public sector CIO Public sector ICT
collaboration portal Leadership Group.

5 Presented at Government CIO and Business Impact forums. Public sector

Executive Group.

49
Appendix B – Digital WA Strategic Principles
1. Align to deliver and leverage whole-of-government technology, commercial and
service benefits.
Agencies must balance priorities between delivering whole-of-government benefits and
agency-specific benefits. Agencies must actively collaborate to deliver solutions that
provide benefits for many agencies, rather than only for a few.

2. Comply with whole-of-government standards, methods and frameworks.

Agencies must comply with all policies, standards and frameworks approved and
communicated under the Strategy. Agency standards or frameworks must align with and
support whole-of-government standards and frameworks.

3. Reinvest to drive digital transformation; invest to drive business sustainability.

A significant portion of any funds saved through ICT reform within an agency should be
retained and reinvested to fund digital transformation initiatives aligned to this Strategy,
with sufficient ongoing funding to ensure sustainability.

4. Treat information as one of the State’s most important assets.

Information is to be recognised and managed as an asset. All systems must ensure data
is entered with integrity, stored and transmitted with appropriate security, and is easily
accessible and discoverable to suitable search and analysis tools.

5. Design government services to be digital by default.

All systems and services must support easy access and use over the most appropriate
and relevant digital channels.

6. Make decisions driven by business needs and informed by ICT capabilities.

ICT decisions must prioritise meeting business needs, while business decisions must
prioritise practical ICT considerations. All significant agency plans should include
appropriate business and ICT representation and consultation in the process.

7. Source solutions using good PRACTICE.

The following prioritised sequence of options should be used when sourcing, stopping at
the first option where sufficient business value can be realised:
Proof of concept – using existing solutions, open source, freeware, pilot purchase, etc.
Reuse – an existing solution in government that delivers good enough value
Adapt – an existing solution that can be slightly modified to deliver good enough value
Consume – new “as-a-Service” offering without significant ongoing commitment
Test – the market, taking into account the next two requirements:
(Improve – change business processes first before customising a procured solution; and
Commercial – buy a commercially supported solution that delivers good enough value)
Engage – suppliers to customise or develop a new solution.

8. Actively seek to leverage expertise from professional, peer and social communities.

50
 Projects must actively seek to identify and leverage skills and expertise available in internal
and external peer communities to improve outcomes, reduce costs, or improve
communication during the design, development, testing, implementation or use of new or
improved services and systems. This can include online communities of practice,
crowdsourcing, consulting with professional industry associations, etc.

9. Seek, develop and maintain appropriate internal expertise.

Agencies must attract and retain appropriate ICT expertise so that business decisions can
be made and informed by suitably qualified, skilled, knowledgeable and experienced staff.
Agencies should seek to access and leverage this expertise within the broader public
sector before seeking external expertise.

10. Use human-centric design, and machine-centric automation.

All systems and processes must be designed to prioritise the user experience of the
targeted user base. Human involvement in an ICT-enabled system or process should be
targeted at decision and analysis points, with automation targeting the capture and
exchange of data between machines or systems.

11. Keep things we control simple; coordinate complexity we don’t control to interface
simply.
ICT systems or processes under the direct management of government must be made as
simple as possible through the elimination of duplication, removal of unnecessary
redundancy, and the avoidance of unnecessary change complexity. Systems or processes
that are not directly managed by government will have potential complexity to government
minimised through the appropriate use of standards, controlled interfaces and managed
gateways.

12. Seek solutions that are fit for purpose, not fit for everything.
ICT systems and processes must be designed or selected to meet the known purposes
for which they are intended (which includes interoperability across the sector and
compliance with standards), and must not be designed to include, or selected due to,
additional functionality or capabilities that are not required or desired within the immediate
context.

13. If it can be shared, make it available to be shared.

All ICT resources, including staff expertise and underutilised assets, that can legitimately
be shared for use by other agencies or the public must be made easily discoverable and
accessible.

14. Balance the consequential risks and benefits of all decisions.

The objective of ICT risk-benefit analysis must not be to reduce or minimise all risks, but
to optimise the overall risk-benefit combination, in line with an agency’s reasonable risk
appetite and tolerance.

15. Make decisions that are environmentally aware and socially responsible for Western
Australia.

51
 Project and operational ICT governance decisions must take into consideration any likely
impact on the environment, community, or state economy, with an objective of maximising
benefits to the community.

Appendix C – TOGAF Proficiency Level

TOGAF proficiency level description:

Level Description

Level 1, Background - Not a required skill, though should be able to define and
manage skill if required.
Level 2, Awareness - Understands the background, issues, and implications
sufficiently to be able to understand how to proceed
further and advise the client accordingly.
Level 3, Knowledge - Detailed knowledge of subject area and capable of
providing professional advice and guidance. Ability to
integrate capability into architectural design.
Level 4, Expert - Extensive and substantial practical experience and
applied knowledge.

A detailed description of the TOGAF proficiency levels can be found in TOGAF section 52.5
Enterprise Role and Skills Definitions, accessible on the following link: http://bit.ly/WEAF-
link10.

52
53
Appendix D - Acronyms
ACF Architecture Content Framework

ADM Architecture Development Model

AGA Australian Government Architecture

CEAF California Enterprise Architecture Framework

CIO Chief Information Officer

CPM Collaborative Planning Methodology

DLM Dissemination Limiting Marker

EA / EAs Enterprise Architecture / Enterprise Architects

FEAF Federal Enterprise Architecture Framework

GEAW Government Enterprise Architecture Workgroup

ICT Information & Communication Technology

IEEE Institute of Electrical and Electronics Engineers

IRAP Information Security Registered Assessors Program

ISO International Organisation for Standardisation

JDF Job Description Form

NIST National Institute of Standards and Technology

OGCIO Office of the Government Chief Information Officer

RA Reference Architecture

SFIA Skills Framework for the Information Age

SME Subject Matter Experts

SOA Service Oriented Architecture

TOGAF The Open Group Architecture Framework

WEAF Western Australian Enterprise Architecture Framework

54