Implementation of GWEA: Case study of KZN Provincial Government By Irshad Abdulla (Senior Specialist: Architecture, SITA)
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Implementation of GWEA:
Case study of KZN
Provincial Government
By
Irshad Abdulla
(Senior Specialist: Architecture, SITA)
Objectives
Define problem statement
High level overview of GWEA
Overview of practitioner experience with GWEA
implementation
Based on experience of 9 KZNPG departments, 1
public entity and 1 municipality in KZN
Scope
Sample model from each phase of the ADM
How was business value derived in practice
Key lessons learnt
Example models
Highlight some techniques applied 2
3
Problem Statement
156 National &
Provincial Depts
275 Municipalities
270 Public entities,
components,
agencies and State
owned Enterprises
Government
“Public Service”
Local
Provincial
National
Infrastructure Development
Economic Sector &
Employment
Human Development
Social Protection & Community
International Cooperation,
Trade & Security
Governance & Administration
Justice, Crime,
Security
4
Social
Health
Home
Affairs
Education
(x 2)
Justice
Labour
Correction
Treasury
(+ SARS)
Transport
Defence
Police
Human Settlements
Agriculture, Forestry &
Fishery
Science & Technology
Trade &
Industry
Energy
Public
Works
State
Security
Economic
Dev.
Intl.
Relations
Water &
Environ.
Public
Service
Communi
-cation
Arts &
Culture
Sport &
Recreation
Rural Dev
& Land
Minerals
Tourism Coop Gov & Tradition.
Planning
Monitor &
Evaluation
Public Enterprises
Challenges … some of them
Disconnect between Business Planning/Architecture and ICT Planning/Architecture.
Diverse and Fragmented Enterprise Architecture Methods (Frameworks and Processes) Inconsistent EA Plans and reporting.
Limited funding
Fragmented Public Service Catalogues
Fragmented Information System and Technology inventories
Too many duplicated systems
Departmental EA [and BPM] Capability Maturity at various levels
Poor ICT Governance (responsibilities and guidance)
Interoperability is “techno-centric” systems can connect, but not exchange data effectively; and Business processes not shared
Poor Collaboration & Cooperation on Transversal programmes / Provincial programmes.
5
6
GWEA Overview
7
What is GWEA
Government-Wide Enterprise Architecture
The purpose of the Government Wide Enterprise
Architecture (GWEA) Framework is to set the minimum
standard by which to use an Enterprise Architecture
approach as means to develop and construct ICT Plans
and Blueprints for an organ of state of the Government of
South Africa.
GWEA Guidance
8
9
GWEA Process (TOGAF)*
PROJECT INITIATIVES
IMPLEMENTATION
ROADMAP
BUSINESS
ARCHITECTURE
DATA & APPLICATION
ARCHITECTURE
TECHNOLOGY
ARCHITECTURE
AS-IS,
TO-BE &
GAPS
IMPLEMENTATION
GOVERNANCE
Keep
Architecture up to date
EA FRAMEWORK &
CONTRACT
EA PRINCIPLES,
SCOPE, VISION
* Accepted by the GITOC SCARC in Nov 2007, GITOC in Apr 2008
10
EA Deliverable definition & notations
TOGAF ADM Process Deliverable Definition Deliverable Notation
Prelim
FW & Contract ? ?
A: Architecture
Principles, Vision & Scope ? ?
B: Business
Architecture ? ?
C: Information
System Architecture ? ?
D: Technology
Architecture ? ?
E: Opportunities &
Solutions ? ?
F: Migration
Planning ? ?
Coh
eren
cy (
Line
of s
ight
)
Con
sist
ency
11
GWEA 1.2 Deliverables
Technology Architecture Views
(D)
Application Architecture Views
(C2)
Business Architecture Views
(B)
Data Architecture
Views (C1)
Organisation Structure Model
Application Reference & Standards Model
Business Process Model
Business Function/Service Model
Business Performance Model
Business Information Model
Application Distribution Model
Technology/Network Distribution Model
Technology Platform Model
Technology Reference & Standards Model
Data Reference & Standards Model
Data Security Model
Data Gap Application Gap Technology Gap
Data-Application Model Application Stakeholder
Model
Opportunities & Solution (E) and Implementation Plan (F) Views (Programmatic Views)
Business Gap
Preliminary (P) & Vision (A) Views
EA Org Model EA FW EA Request EA Principles EA Vision EA SOW Comm Plan
Business Roadmap Data Roadmap Application Roadmap Technology Roadmap
Consolidated Roadmap &
Transition Architecture
Implementation and Migration
Plan
Implementation Governance
Model
12
GWEA Model Relationships Ref Models
Dri
ver
Ob
ject
ive
Mea
sure
Org
anis
atio
n U
nit
Fun
ctio
n /
Se
rvic
e
Act
or
(Ro
le, P
ers
on
)
Pro
cess
(Ev
ent,
Act
ivit
y, R
ule
)
Loca
tio
n
Ap
plic
atio
n (
Syst
em, F
un
ctio
n)
Dat
a (C
lass
, Def
init
ion
)
Dat
a (S
tan
dar
d)
Tech
no
logy
Tech
no
logy
Sta
nd
ard
B1 Business Performance Model n n n n
B2 Organisation Structure Model n n n n
B3 Business Function/Service Model n n n
B4 Business Information Model n n
B5 Business Process Model o n n
C1.1 Data Reference Model n n
C1.2 Data Security Model n n
C1.3 Data-Application Model n n
C2.1 Application Reference Model n
C2.2 Application Distribution Model n n
C2.3 Application Stakeholder Model n n
D1 Technology Reference Model n n
D2 Technology Distribrution Model n n
D3 Technology Platform Model n n
n Mandatory content
o Optional content
Content (Artefacts)
From GWEA Implementation Guide V1.2.
13
GWEA Meta-model
Objective
Organisation Unit
Measure
Driver
Function/Service LocationActor (Person, Role)
Application (System)Data
Process / Activity
Technology
is measured by
is accountable for
comprisescomprises
is automated byinteracts with
realises
is responsible for
uses
is rendered at
manipulates
is deployed at
is enabled by
is hosted on
is deployed at
Standard
has access to
is governed byis governed by
is determined by
is located at
performs
contributes
is governed by
From GWEA Implementation Guide V1.2.
14
KZNPG: Vision Phase
Vision Phase
Architecture Principles
General rules and guidelines
Used to govern and guide enterprise architecture
development and trade-off decisions (i.e. strategic
planning, alignment, investment and macro design) of
Information and ICT
Business value derived
Structured basis for decision making
Common view of ICT vision
Easily understood by business and external service
providers
Facilitates line of sight between strategy and vision
15
Vision Phase….
Key lessons learnt
Formally adopt GWEA principles
Include department-specific principles i.e. apply
hierarchy of principles
Department-specific principles must be easily
understood in the department’s context
Useful to create a one-page view summarising EA
principles
16
Vision Phase….
Model examples
17
18
KZNPG: Business Architecture
Business Architecture Business Function/Service Model
Business value derived
Means to succinctly defined what the business is about
Relate org units to business functions/services
Relate business information to business
functions/services
Process architecture – packaged in terms processes
used to deliver business functions/services
19
Purpose To inform stakeholders regarding the Service Catalogue of an enterprise, the degree of automation of each function/service, and the roles (people) required to perform the function/service.
Definition A model that defines the Core and Support Functions/Services of the Enterprise, the Information Systems that enable the function/service, and the roles of the actors that participate.
Content Function/Service (Business)
Information System (Enabler Application) Actor (role)
Notation Format: Catalogue, Nested Box Diagram or UML Use Case
Business Architecture….
Lessons learnt Develop service catalogue first
Use existing documents to develop first draft of service catalogue – org
structures, strategic plans, existing service definition documents,
departmental websites etc.
Involve business to expand on and confirm service catalogue
Apply architecture principles and good practice
Attempt to apply consistent levels of abstraction across services – package
appropriately
Make use of service types/capabilities where applicable
Ensure that services have a service definition
First draft should not be too radical, unlikely that first draft will be 100%
accurate
Evolve the catalogue, and take business along with you on the evolutionary
journey
20
Extract – Service Catalogue example
21
Service Type/Capability Service
Strategic Planning and Analysis
Service Provision
Strategic Planning and Analysis
Services
Strategy and Policy Development
Service Provision
Strategy and Policy Development
Service Provision
Strategy and Policy Co-ordination and
monitoring Service Provision
Strategy and Policy Co-ordination
and monitoring Services
Professional Compliance Services
Quality Assurance Services
Provide Substance Abuse, Prevention
and Rehabilitation Services
Provide Substance Abuse,
Prevention and Rehabilitation
ServicesProvide Care and Service to Older
PersonsProvide Care and Service to Older
PersonsProvide Crime Prevention and Support
ServicesProvide Crime Prevention and
Support ServicesProvide Services to Persons with
DisabilitiesProvide Services to Persons with
Disabilities
Alternate Care Services
Protection Services
ECD and Partial Care Services
Provide Victim Empowerment ServicesProvide Victim Empowerment
Services
Community Care and Support
Services
HIV/AIDS Prevention Services
Provide Social Relief Services Provide Social Relief Services
Provide Services for Care and Support
to FamiliesProvide Services for Care and
Support to Families
STR
ATEG
IC
OP
ER
ATIO
NA
L C
OR
E:
SO
CIA
L W
ELFA
RE
Provide Professional Support Services
Provide Child Care and Protection
Services
Provide HIV/AIDS Services
Extract – Business Function/Service
Model example
22
Service Type/Capability Service Producer* Consumer Information System
STR
ATEG
IC
Strategic Planning and
Analysis Service Provision
Strategic Planning
and Analysis Services
Directorate: Strategic Planning and
Analysis
HoD;
Executive Management;
Management;
National DSD;
E-mail & Collaboration IMS;
Office Suite;
Business Intelligence / Reporting IMS;
Electronic Content Management IMS;
Workflow Management IMS;
Events / Calendar Management IMS;
Professional
Compliance ServicesDirectorate: Professional Compliance
Executive Management;
Management;
District Offices;
Service Offices;
Professional bodies;
E-mail & Collaboration IMS;
Office Suite;
e-Government (G2G, G2B) IMS;
Business Intelligence / Reporting IMS;
Electronic Content Management IMS;
Workflow Management IMS;
e-Learning IMS;
Events / Calendar Management IMS;
Quality Assurance
Services
Directorate: Quality Assurance;
District
Executive Management;
Management;
District Offices;
Service Offices;
E-mail & Collaboration IMS;
Office Suite;
e-Government (G2G, G2B) IMS;
Business Intelligence / Reporting IMS;
Electronic Content Management IMS;
Workflow Management IMS;
e-Learning IMS;
Events / Calendar Management IMS;
Provide Professional
Support Services
OP
ER
ATIO
NA
L C
OR
E:
SO
CIA
L W
ELFA
RE
Relating services to Business
Information
23
24
KZNPG: Data Architecture
Data Architecture
Data Security Model
Business value derived
Concise definition of security requirements of key data
classes – whether automated or manual
Implements basic data governance principles
Provides a foundation for understanding security
requirements for applications which implement data
classes
25
Purpose To inform stakeholders regarding the security and responsibilities of the data assets in a department in order to improve data accountability.
Description A model that defines the security classification of data classes and the roles in the organisation that need access thereto.
Content Data Class Actor Role
Notation Catalogue
Data Architecture….
Key lessons learnt
Data classes must be informed by the DRM
Actors must be informed by BARCH
Security classification scheme – made use of MISS
Data governance – consider roles such as owner,
steward, quality manager, user
New approach and requires change management. Cannot be a
once-off activity
Incorporate other frameworks e.g. DMBOK
Focus on quality rather than quantity
26
Data Security Model example
27
28
KZNPG: Application Architecture
Application Architecture
Application Reference Model
Business value derived
Consolidated view of application portfolio
Clearly identify how applications are used in current
landscape
Articulate how applications will be used in future
landscape
Easily identify duplicate functionality and opportunity for
consolidation
Standard ARM allows for analysis across departments 29
Purpose To inform stakeholders regarding the major kinds of applications (software) that are needed to automate or enable the functions/services of a department.
Description A model that defines a portfolio of applications and its service/function decomposition. Content Application Class & Definition
Function/Service (Application) Notation Catalogue, Nested Box Diagram or UML Class
Application Architecture….
Key lessons learnt
Use multiple sources to identify applications i.e. do not
only rely on end-user interviews
Conduct research to understand potential capability of
existing applications
Conduct high-level benchmarking exercise to assess
application fit (for key applications)
Map applications to the GWEA ARM/ISRM
“Application class definition” must be specific to dept.
context
Apply sound architecture principles in defining
application functions/services – consistency is key
To-be application architecture should be application
agnostic 30
Application Architecture….
Application Reference Model examples
31
Example – ARM extract
Application
Class
Definition
Functions/service What application is
currently in use? How is the
application
currently being
used?
ADMINISTRATION SYSTEMS
Financial IMS BAS Used for Financial
Accounting and
reporting in the
department.
BAS is the Basic Accounting System used
across South African National and Provincial
government. Some of the key business
functions include:
a) Budgeting;
b) Creditor Management;
c) Debt Management;
d) Receipts;
e) Travel and subsistence; and
f) Disbursements.
BAS also provides reporting, configuration
and controller services.
See Annex C for a detailed description of the
BAS functions/services. Human
Resource IMS PERSAL Used as the HR
system in the
department.
a) HR Personnel Management;
b) Salary Management;
c) Payroll Reporting; and
d) Employment Equity Information.
32
33
KZNPG: Technology Architecture
Technology Architecture
Technology Reference Model
Business value derived
Single view of technology portfolio
Easily identify duplicate/redundant technologies
Ensure alignment to MIOS promoting interoperability
Standard TRM allows for analysis across departments
34
Purpose To inform stakeholders regarding the major kinds of technologies and standards that are needed
as a common infrastructure to enable the integration, execution, distribution and management of Information management systems (data and applications) of an enterprise.
Description A model that defines the major classes of technology components/services (infrastructure software, hardware, and network) and the interoperability standards associated thereto.
Content Technology Service Class & Definition
Interoperability Standards (in accordance with MIOS) Notation Catalogue, Nested Box Diagram or UML Class
Technology Architecture….
Key lessons learnt
Use multiple sources to identify technology i.e. do not
only rely on end-user/technical interviews
Cross check against application architecture for
completeness – consider to-be AA requirements of TA
Conduct research to understand potential capability of
existing technology
Map technology to the GWEA TRM
“Tech service class definition” must be specific to dept.
context
Apply sound architecture principles in defining
technology functions/services – consistency is key
To-be technology architecture should be technology
agnostic 35
Technology Architecture….
Technology Reference Model examples
36
Example – TRM extract
Technology
Domain Technology Class
Definition How is the technology envisaged to
be used in the To-Be TRM?
Application Delivery
Infrastructure
Web Server In addition to current utilisation, the
following changes/enhancements
are required in future:
a) Use of web server technology
for enablement of web-based
business applications.
Application Server In addition to current utilisation, the
following changes/enhancements
are required in future:
a) Use of application server
technology to provide and
manage business logic in multi-
tiered application architecture;
and
b) Promote application portability
and re-use of application
components.
User Interface In addition to current utilisation, the
following changes/enhancements
are required in future:
a) Provide portal for KZN DSD
applications;
b) Used for implementation of
KZN DSD G2C e-Government
services.
37
38
KZNPG: Opportunities and Solutions
Opportunities & Solutions
Consolidated Architecture Roadmap
Business value derived
Shows logic in how target architectures are derived –
“workings”
Provides motivation for target architectures
39
Purpose To inform stakeholders regarding the major initiatives (or project) to be undertaken by the ICT
function of and enterprise to address the deficiencies and redundancies as identified during the prior gap analysis.
Description A consolidation of Business, Data, Application and Technology Architecture Roadmaps, which outlines a list
of individual increments of change over a timeline to show progression from the Baseline Architecture to the Target Architecture.
Content Opportunity Portfolio (Consolidated gaps, solutions alternative assessment, dependency assessment,
cost benefit assessment, capability increments, interoperability and co-existence requirements)
Work Packages for architecture implementation (scope, objectives, deliverables)
Milestone & Transition Architecture (transition architecture components per milestone) Implementation Factors (Risks, Issues, Assumptions, and Dependencies)
Notation Text or Catalogue
Opportunities & Solutions….
Key lessons learnt
Must be derived from gap reports in the BA, AA, DA, TA
– ensuring line of sight
Group together architectural components to form
solutions
Clearly explain how/why gaps have been grouped
together
Explain logic used for prioritization, dependency
assessments, interoperability assessments
Useful to use “programmes” as work packages
40
Example – Prioritisation Matrix
41
PRIORITY
PROJECT
Compliance/ contribution to
principles
Service
delivery
contribution
Strategic
alignment
Overall
priority
AA12 : Workflow
Application Project 2 3 3 8
AA2: e-Gov Project 3 3 1 7
BA2: ITSM Governance
Project 2 2 2 6
Example – Interoperability Matrix
42
43
KZNPG: Migration Planning
Migration Planning
Implementation and Migration Plan
Business value derived
Clear definition of how the To-Be architecture will be
defined and business benefits
Provides business with an easy-to-understand roadmap
Provides justification for investments
Holistic analysis – interactions with other F/W and
standards are considered 44
Purpose To inform the stakeholders of the optimal ways (methods) as well as the necessary resources and sequence by which to implement the projects as identified during the previous phase.
Description The Implementation and Migration Plan defines a strategy and plan to implement the architecture. Content Implementation and Migration Strategy (Strategic implementation direction, Implementation
sequencing approach)
Interactions with other management frameworks and standards (government business planning
framework, project management framework, solution development framework, IT Service
Management/Operations framework)
Project Charters and Plans (Project Scope, Outcome/Benefits, Objectives, Deliverables,
Risks/Assumptions, Dependencies, Work Breakdown Structure, Milestone schedule, Resource schedule, Cost schedule, Time schedule)
Notation Text
Migration Planning….
Key lessons learnt
Keep roadmap simple to understand
Ensure that charters and plans are complete,
comprehensive and will allow a business user to
understand the thought processes behind the project
Ensure that the charters and plans plot a definitive way
forward
Cross check project charters and plans to ensure that all
dependencies and pre-requisites are addressed – within
current project or within another project
45
Example – Architecture Roadmap
46
TIME
PROGRAMME
YEAR 1 YEAR 2 YEAR 3 Beyond YEAR 3
P1
P2
P4
P6
P8
P9
P10
P14
P15
P16
P17
P19
P20
P21
P22
P23
P24
P25
P27
P31
P32
KEY:
Technology Architecture
Application Architecture
Business Architecture
Data Architecture
Organisational
Transformation
P29
P34
P30
P28
P33
Business Systems Alignment
P13
P5
P3
P26
P18
P7
P11
IT Service Delivery
Optimisation
ICT Infrastructure Alignment
P12
Summary – Project Charter
47
Summary – Project Plan
48
49
Conclusion
Conclusion
Strategic architectures must be kept strategic,
whilst providing enough depth to guide
implementation of the architecture
Strategic architectures must be based on sound
architecture principles and practices
Segment and capability architectures can be built
on strategic architectures – iterative approach
GWEA Framework provides minimum compliance
requirements, and must be interpreted in the
context of client environment – to determine how
to maximise value delivered.
50
51
THANK YOU
Related Documents
