Implementation of GWEA: Case study of KZN Provincial Government. By Irshad Abdulla (Senior Specialist: Architecture, SITA)

Transcription

1 Implementation of GWEA: Case study of KZN Provincial Government By Irshad Abdulla (Senior Specialist: Architecture, SITA)

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

4 Government Public Service 156 National & Provincial Depts 275 Municipalities 270 Public entities, components, agencies and State owned Enterprises National Public Service Correction Governance Treasury & Administration (+ SARS) Home Affairs Justice, Crime, Security Justice Intl. International Relations State Cooperation, Security Trade & Security Police Planning Monitor & Evaluation Human Settlements Water & Environ. Transport Infrastructure Energy Development Public Enterprises Coop Gov & Tradition. Communi -cation Economic Dev. Public Works Agriculture, Forestry & Fishery Rural Dev & Land Economic Trade & Sector & Industry Labour Employment Minerals Sport & Recreation Tourism Science & Technology Human Education Development (x 2) Health Local Provincial Defence Social Protection Social & Community Arts & Culture 4

5 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 6

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

8 GWEA Guidance 8

9 GWEA Process (TOGAF)* EA FRAMEWORK & CONTRACT EA PRINCIPLES, SCOPE, VISION Keep Architecture up to date BUSINESS ARCHITECTURE IMPLEMENTATION GOVERNANCE DATA & APPLICATION ARCHITECTURE TECHNOLOGY ARCHITECTURE IMPLEMENTATION ROADMAP PROJECT INITIATIVES * Accepted by the GITOC SCARC in Nov 2007, GITOC in Apr 2008 AS-IS, TO-BE & GAPS 9

10 Coherency (Line of sight) Consistency 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?????????????? 10

11 GWEA 1.2 Deliverables Preliminary (P) & Vision (A) Views EA Org Model EA FW EA Request EA SOW EA Principles EA Vision Comm Plan Business Architecture Views (B) Data Architecture Views (C1) Application Architecture Views (C2) Technology Architecture Views (D) Business Performance Model Data Reference & Standards Model Application Reference & Standards Model Technology Reference & Standards Model Organisation Structure Model Data Security Model Application Distribution Model Technology/Network Distribution Model Business Function/Service Model Data-Application Model Application Stakeholder Model Technology Platform Model Business Information Model Business Process Model Business Gap Data Gap Application Gap Technology Gap Business Roadmap Data Roadmap Application Roadmap Technology Roadmap Opportunities & Solution (E) and Implementation Plan (F) Views (Programmatic Views) Consolidated Roadmap & Transition Architecture Implementation and Migration Plan Implementation Governance Model 11

12 GWEA Model Relationships Ref Models Driver Objective B1 Business Performance Model B2 Organisation Structure Model B3 Business Function/Service Model B4 Business Information Model B5 Business Process Model o C1.1 Data Reference Model C1.2 Data Security Model C1.3 Data-Application Model C2.1 Application Reference Model C2.2 Application Distribution Model C2.3 Application Stakeholder Model D1 Technology Reference Model D2 Technology Distribrution Model D3 Technology Platform Model Mandatory content o Optional content From GWEA Implementation Guide V1.2. Measure Organisation Unit Content (Artefacts) Function / Service Actor (Role, Person) Process (Event, Activity, Rule) Location Application (System, Function) Data (Class, Definition) Data (Standard) Technology Technology Standard 12

13 GWEA Meta-model Driver From GWEA Implementation Guide V1.2. is determined by Objective is measured by Measure is accountable for Organisation Unit contributes is located at comprises comprises Actor (Person, Role) is responsible for Function/Service is rendered at Location has access to Data performs Process / Activity uses interacts with manipulates realises is automated by Application (System) is deployed at is deployed at Technology is enabled by is hosted on is governed by is governed by is governed by Standard 13

14 KZNPG: Vision Phase 14

15 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

16 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

17 Vision Phase. Model examples 17

18 KZNPG: Business Architecture 18

19 Business Architecture Business Function/Service Model 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 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

20 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

21 Extract Service Catalogue example STRATEGIC OPERATIONAL CORE: SOCIAL WELFARE Service Type/Capability Service Strategic Planning and Analysis Strategic Planning and Analysis Service Provision Services Strategy and Policy Development Strategy and Policy Development Service Provision Service Provision Strategy and Policy Co-ordination and Strategy and Policy Co-ordination monitoring Service Provision and monitoring Services Provide Professional Support Services Provide Substance Abuse, Prevention and Rehabilitation Services Provide Care and Service to Older Persons Provide Crime Prevention and Support Services Provide Services to Persons with Disabilities Provide Child Care and Protection Services Provide Victim Empowerment Services Provide HIV/AIDS Services Professional Compliance Services Quality Assurance Services Provide Substance Abuse, Prevention and Rehabilitation Services Provide Care and Service to Older Persons Provide Crime Prevention and Support Services Provide Services to Persons with Disabilities Alternate Care Services Protection Services ECD and Partial Care Services Provide 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 Provide Services for Care and to Families Support to Families 21

22 Extract Business Function/Service Model example Service Type/Capability Service Producer* Consumer Information System STRATEGIC Strategic Planning and Analysis Service Provision Strategic Planning and Analysis Services Directorate: Strategic Planning and Analysis HoD; Executive Management; Management; National DSD; & Collaboration IMS; Office Suite; Business Intelligence / Reporting IMS; Electronic Content Management IMS; Workflow Management IMS; Events / Calendar Management IMS; OPERATIONAL CORE: SOCIAL WELFARE Provide Professional Support Services Professional Compliance Services Quality Assurance Services Directorate: Professional Compliance Directorate: Quality Assurance; District Executive Management; Management; District Offices; Service Offices; Professional bodies; Executive Management; Management; District Offices; Service Offices; & 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; & 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; 22

23 Relating services to Business Information 23

24 KZNPG: Data Architecture 24

25 Data Architecture Data Security Model 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 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

26 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

27 Data Security Model example 27

28 KZNPG: Application Architecture 28

29 Application Architecture Application Reference Model 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 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

30 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

31 Application Architecture. Application Reference Model examples 31

32 Example ARM extract Application Class What application is currently in use? Definition Financial IMS BAS Used for Financial Accounting and reporting in the department. How is the application Functions/service currently being used? ADMINISTRATION SYSTEMS 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. Human Resource IMS PERSAL Used as the HR system in the department. See Annex C for a detailed description of the BAS functions/services. a) HR Personnel Management; b) Salary Management; c) Payroll Reporting; and 32 d) Employment Equity Information.

33 KZNPG: Technology Architecture 33

34 Technology Architecture Technology Reference Model 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 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

35 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

36 Technology Architecture. Technology Reference Model examples 36

37 Example TRM extract Technology Domain Application Delivery Infrastructure Technology Class Web Server Application Server User Interface Definition How is the technology envisaged to be used in the To-Be TRM? 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. 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 multitiered application architecture; and b) Promote application portability and re-use of application components. In addition to current utilisation, the following changes/enhancements are required in future: 37

38 KZNPG: Opportunities and Solutions 38

39 Opportunities & Solutions Consolidated Architecture Roadmap 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 Business value derived Shows logic in how target architectures are derived workings Provides motivation for target architectures 39

40 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

41 Example Prioritisation Matrix PRIORITY Compliance/ Service delivery contribution Strategic alignment Overall priority contribution to principles PROJECT AA12 : Workflow Application Project AA2: e-gov Project BA2: ITSM Governance Project

42 Example Interoperability Matrix 42

43 KZNPG: Migration Planning 43

44 Migration Planning Implementation and Migration Plan 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 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

45 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

46 Example Architecture Roadmap TIME PROGRAMME Business Systems Alignment ICT Infrastructure Alignment IT Service Delivery Optimisation Organisational Transformation P1 P2 P8 P9 P10 P19 P20 P21 P22 P27 YEAR 1 YEAR 2 YEAR 3 Beyond YEAR 3 P3 P4 P5 P6 P7 P11 P12 P13 P14 P15 P16 P17 P18 P23 P24 P25 P26 P28 P29 P30 P31 P32 P33 P34 KEY: Technology Architecture Application Architecture Business Architecture Data Architecture 46

47 Summary Project Charter 47

48 Summary Project Plan 48

49 Conclusion 49

50 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 51