India Enterprise Architecture An enterprise Framework architecture EA

  • Slides: 52
Download presentation
India Enterprise Architecture An enterprise Framework architecture (EA) is a conceptual blueprint that defines

India Enterprise Architecture An enterprise Framework architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an Enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. Need for Ind. EA Holistic approach in the context of e. Governance in India EA Resource Group NIC P. Gayatri Sr. Technical Director NIC, Andhra Pradesh 1

SDG 9: Industry Innovation and Infrastructure Key initiatives under Digital India 1. Broadband highways

SDG 9: Industry Innovation and Infrastructure Key initiatives under Digital India 1. Broadband highways 2. Universal access to mobile connectivity 3. National Rural Internet mission 4. E-Kranti 5. E-Governance 6. 7. 8. 9. Information for All Electronic Manufacturing Training and Jobs creation Early Harvest Program The aim is to simplify government business processes by • Introduction of IT • Online interface and tracking across departments • Integration of services and platforms (UIDAI, Payment Gateway, Mobile Platform) • Public grievance redressal through IT so on … paved way to develop a ONE GOVERNMENT Framework – Ind. EA

Ind. EA Vision 'To establish best-in-class architectural governance, processes and practices with optimal utilization

Ind. EA Vision 'To establish best-in-class architectural governance, processes and practices with optimal utilization of ICT infrastructure and applications to offer ONE Government experience to the citizens and businesses' Methodology: Adopted TOGAF ADM to develop Reference Models 3

Primary Objectives of Ind. EA • Capture and codify current knowledge and experience in

Primary Objectives of Ind. EA • Capture and codify current knowledge and experience in a consolidated form for ready reference to anyone who is interested to understand this subject • Kick start enterprise architecture initiatives across India, covering entire state governments and other government / public sector entities; • Enrich the procurement process and provide greater leverage to government enterprises in managing their vendors; • Spell issues and concerns contextual to India, in a manner such that the finer nuances of governance are captured and factored in; • Support India’s transition towards digital governance and knowledge economy as envisaged in the Digital India initiative. 4

As-Is Architect To-Be 5

As-Is Architect To-Be 5

Ind. EA Reference Models – Overview National Centre for e-Governance Standards and Technology 6

Ind. EA Reference Models – Overview National Centre for e-Governance Standards and Technology 6

A Reference Model is an abstract representation of the entities relevant to a domain

A Reference Model is an abstract representation of the entities relevant to a domain of the Enterprise Architecture, the interrelationships among those and the standards to be followed. 7

Ind. EA - Reference Models Defines KPIs for outcome assessment PRM Guides Design &

Ind. EA - Reference Models Defines KPIs for outcome assessment PRM Guides Design & Implementation of EA GRM Specifies Standards and Best Practices for Security Assets SRM Provides Portfolio of Services BRM Ind. EA Interoperability & Integration AIRM Provides Application Portfolio and SW Development Methods ARM Life cycle management of Enterprise Data DRM Specifies Technology Landscape & Standards TRM 8

Ind. EA Reference Models – Overview Reference Model Objective Business RM BRM is a

Ind. EA Reference Models – Overview Reference Model Objective Business RM BRM is a mechanism to describe the administrative structure of the State’s Departments, its Functions and Services. It articulates Business Structure and Prioritizes Business Services. Performance RM Provides framework to measure Effectiveness and Efficiency of Business Processes. Data RM It provides a standard framework for describing the data identified by the department, its context, mode of sharing and data modeling so that a meaningful and usable Data Architecture can be derived by the consuming departments. Application RM It provides structure to automate Business Services identified in BRM. It defines the building blocks required to develop high-level Application Architecture. ARM identifies various Application Capabilities and facilitates sharing & re-use of application capabilities. It also provides building blocks to group similar applications and describes guidelines for integrating the applications. 9

Ind. EA Reference Models – Overview Reference Model Objective Security RM Provides security and

Ind. EA Reference Models – Overview Reference Model Objective Security RM Provides security and privacy requirements and standards that secure Applications and Services supported. It provides guidelines to define security controls at various levels including business, network, infrastructure, application and data. AIRM Technology RM EA Governance RM Provides guidelines for interoperability of Applications TRM applies the Common Technology Standards to Infrastructure Service Components for ensuring interoperability between Applications and Technology Platforms for multi-channel delivery of Stakeholder Services. Provides guidelines for maintaining and enhancing Enterprise Architecture 10

Performance Reference Model – PRM Provides framework to measure Effectiveness and Efficiency of Business

Performance Reference Model – PRM Provides framework to measure Effectiveness and Efficiency of Business Processes 11

Performance Layer 12

Performance Layer 12

PRM provides framework to measure effectiveness and Efficiency of Business Processes 13

PRM provides framework to measure effectiveness and Efficiency of Business Processes 13

Relationship of PRM and BRM 14

Relationship of PRM and BRM 14

Defining KPIs for a service – PRM (Illustrative) • Percentage increase in transactions •

Defining KPIs for a service – PRM (Illustrative) • Percentage increase in transactions • Failed transactions due to technical outage • Percentage increase in citizens benefitted Vision People Technology Process • Gain in Process turn-around time 15

Business Reference Model – BRM is a mechanism to describe the administrative structure of

Business Reference Model – BRM is a mechanism to describe the administrative structure of the State’s Departments, its Functions and Services. It articulates Business Structure and Prioritizes Business Services. 16

Business Reference Model Schematic BRM is a mechanism to describe the administrative structure of

Business Reference Model Schematic BRM is a mechanism to describe the administrative structure of the State’s Departments, its Functions and Services. It articulates Business Structure and Prioritizes Business Services. 17

As-Is Study Methodology - Illustrative 7 Mar 2018 Interact with Nodal Officer Prepare a

As-Is Study Methodology - Illustrative 7 Mar 2018 Interact with Nodal Officer Prepare a Skeleton Document Prepare/Communica te Questionnaire from the basic understanding Visit Field offices View Demonstrations of Existing legacy systems Interact with Users and Citizens Study Acts / Gos / Circulars / Registers Examine Filled-in Questionnaire Gap Analysis with BPR Recommendations Prepare As-Is Document in a structured format Get Department Approval 18

Gap Analysis through Heat-map preparation -Illustrative Service Citizen Friendliness SLA definition Workflow Inter-departmental interaction

Gap Analysis through Heat-map preparation -Illustrative Service Citizen Friendliness SLA definition Workflow Inter-departmental interaction Notifications MIS /Audit Security KPIs Service A Service B Service C Legend Description Low Gap Medium Gap High Gap 7 Mar 2018 19

To-Be Modelling - Illustrative Service deliverance through Bhu. Seva High-Level diagram for the To-Be

To-Be Modelling - Illustrative Service deliverance through Bhu. Seva High-Level diagram for the To-Be system Scope and Vision of the Service Get Department Approval Prepare To-Be Document in a structured format Becomes input to SRS 7 Mar 2018 List of Comprehensive Use Cases Identification of Key Performance Indicators 20

Stakeholders Matrix– Illustrative Department Revenue IGRS Departmental HOD CCLA (Chief Commissioner of Land Administration)

Stakeholders Matrix– Illustrative Department Revenue IGRS Departmental HOD CCLA (Chief Commissioner of Land Administration) Commissioner &Inspector General Nodal officer for the Project Business functions of Ho. D Additional secretary and Project Director (CMRO Project) 1. Maintenance of land records 2. Issue of PPB, title deeds 3. Assignment of land for agri and house sites 4. Protection of Government lands Asst Inspector General, CARD Project 1. Registration of documents related to movable and immovable assets 2. Issuance of encumbrance certificate 3. Collection of stamp duty 4. Registrations of societies formed for charitable, educational and religious purposes 5. Registration of marriages under various ACTs 6. Registration of chit funds 21

Relationship Between BRM and ARM 22

Relationship Between BRM and ARM 22

Data Reference Model – DRM It provides a standard framework for describing the data

Data Reference Model – DRM It provides a standard framework for describing the data identified by the department, its context, mode of sharing and data modeling so that a meaningful and usable Data Architecture can be derived by the consuming departments. 23

Data Reference Model 24

Data Reference Model 24

Ind. EA Reference Model - DRM It provides a standard framework for describing the

Ind. EA Reference Model - DRM It provides a standard framework for describing the data identified by the department, its context, mode of sharing and data modeling so that a meaningful and usable Data Architecture can be derived by the consuming departments. 25

Data Context - Data Steward, Data Source, Data Assets - Illustrative Name of the

Data Context - Data Steward, Data Source, Data Assets - Illustrative Name of the Data Asset State Master Name of the Data Asset District Master Data Asset Identifier BS-DA-001 Data Asset Identifier BS-DA-002 Name of the business service(s) / process which generates / manages the data asset 1. 2. Periodicity of data updation As per Government policy Versioned (Y/N) Source: LG Directory Trustworthiness of the Data Asset Highly trustworthy. Source: LG Directory Name of the business 1. service(s) / 2. process which generates / manages the data asset Service - A Process 1 Service - C Process 1 Periodicity of data updation As per Government policy Versioned (Y/N) Source: LG Directory Trustworthiness of the Data Asset Highly trustworthy. Source: LG Directory Validity of Data Asset (from the date of its creation) Always valid subject to changes in government policy Precision of Data Asset Source: LG Directory 26

Data Description- Data Entities, Relations - Illustrative 27

Data Description- Data Entities, Relations - Illustrative 27

Application Reference Model – ARM It provides structure to automate Business Services identified in

Application Reference Model – ARM It provides structure to automate Business Services identified in BRM. It defines the building blocks required to develop high-level Application Architecture. ARM identifies various Application Capabilities and facilitates sharing & re-use of application capabilities. It also provides building blocks to group similar applications and describes guidelines for integrating the applications. 28

 • • Provides structure to automate Business Services identified in BRM. Defines the

• • Provides structure to automate Business Services identified in BRM. Defines the building blocks required to develop high-level Application Architecture. Identifies various Application Capabilities and facilitates sharing & re-use of application capabilities. Provides building blocks to group similar applications and describes guidelines for integrating the applications. Application Reference Model 29

ARM – Indicative Portfolio 30

ARM – Indicative Portfolio 30

Application Reference Model - Illustrative Core, Common & Group Applications Information Services Service A

Application Reference Model - Illustrative Core, Common & Group Applications Information Services Service A Departmental Applications Transactional Services Service B API Facade Service C Service D Third Party Developers CRUD Services Service E Service F Community Development Master Data Management Service N 31

Technology Reference Model - TRM applies the Common Technology Standards to Infrastructure Service Components

Technology Reference Model - TRM applies the Common Technology Standards to Infrastructure Service Components for ensuring interoperability between Applications and Technology Platforms for multi-channel delivery of Stakeholder Services. 32

Technology Reference Model TRM provides a holistic view of the e-Governance technology landscape The

Technology Reference Model TRM provides a holistic view of the e-Governance technology landscape The Technology Reference Model (TRM) t aims to develop an interoperable and cost effective framework which could be referenced and used by Central government, States and agencies for inter-departmental discovery and digital collaboration 33

Technology Reference Model TRM establishes a common vocabulary for describing the technology used to

Technology Reference Model TRM establishes a common vocabulary for describing the technology used to develop, operate and maintain applications and infrastructure Facilitates communication, cooperation and collaboration by providing a coherent description of the technologies in a hierarchical manner Acts as the foundation for planning and standardizing the use of technologies across the organization Promotes Open Standards, Open Formats, and Open Sources to avoid vendor lock-in and being cost effective Provides Cloud based On. Demand delivery of Services to stakeholders Gives the design criteria for an Open API based Microservices / SOA based architecture 34

Technology Layer Stack – Illustrative 35

Technology Layer Stack – Illustrative 35

Security Reference Model – SRM Provides security and privacy requirements and standards that secure

Security Reference Model – SRM Provides security and privacy requirements and standards that secure Applications and Services supported. It provides guidelines to define security controls at various levels including business, network, infrastructure, application and data. 36

Security Reference Model 37

Security Reference Model 37

Layers of Security Reference Model 38

Layers of Security Reference Model 38

Controls at Business Layer - Illustrative Objective: To limit the access to the information,

Controls at Business Layer - Illustrative Objective: To limit the access to the information, data and facilities providing it. 1. Access Control Policy A policy should be established, documented and reviewed as per the business information security policy to provide access to information or assets available at the state/ organization/ department level. The policy should define who can access what resources and what authentication mechanism should be used to provide the access. Different multi-factor authentication mechanisms should be defined for accessing different information and information facilitating resources based on the sensitivity. 1. Strong password Policy should be defined about what is acceptable password. A strong password is recommended with minimum 8 characters, with at least one capital character, at least one numeric and at least one punctuation mark. 1. Professional/ company email id It should be mandated that for all the official work only the company / department email ID should be used. No government information is to be shared on personal email IDs. The policy related to the same is already issued by the government. Objective: To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses. 1. Incident reporting and A mechanism should be defined and made available to detect any security related incidence. handling A procedure should be well defined and documented giving steps to be taken for handling any incidence. 1. SIEM 1. Learning from the security incidences 1. Continuous Monitoring A software information and event management system should be defined and documented for handling security related incidences. Knowledge gained through analysis of the earlier incidences should reflect in the security policy document. A mechanism along with skilled resources should be developed for continuous monitoring that can help in detecting any security related incident. The monitoring also includes the analysis and identification if the integrity is getting compromised. 39

Controls at Business Layer - Illustrative Objective: To ensure proper and effective use of

Controls at Business Layer - Illustrative Objective: To ensure proper and effective use of cryptography to protect confidentiality, authenticity and/or integrity. 1. Policy for cryptographic A security policy should include the use of cryptographic controls to ensure confidentiality control usage and key and authenticity of the user as well as systems. management A security policy also should document the secured use and storage of cryptographic keys. It is essential that the cryptographic keys should be changed at regular interval. The security policy should define the interval at which the keys are changed. The policy also should document the key generation mechanism to be used. Objective: To ensure the integrity of the systems 1. Installation of software A secured procedure should be defined for installing software. Rules governing installation of software should be defined and implemented. VAPT should be mandated before installing any software in the production environment. Many of CERT-IN empanelled agencies do VAPT testing of applications. Separate development, testing, staging and production environments should be recommended. 40

Application Integration Reference Model – AIRM Provides guidelines for interoperability of Applications 41

Application Integration Reference Model – AIRM Provides guidelines for interoperability of Applications 41

Application Integration Reference Model 42

Application Integration Reference Model 42

Ind. EA Reference Model – AIRM 43

Ind. EA Reference Model – AIRM 43

AIRM – Guidelines and integration methods Layers at which integration is done Guidelines for

AIRM – Guidelines and integration methods Layers at which integration is done Guidelines for integration Integration methods Business 1. Study Business processes 2. Conduct Gap analysis and recommend suggestions 3. Identify new Business methods 1. Fixing broken lines in the process 2. Business Process reengineering Data 1. Data Sharing – ETL (legacy) • Data Sharing 2. Data Sharing – through real time integration (Transactional) Application 1. Identity Application Plug points 1. Application programming across inter-operating legacy and interfaces and Web Services green-field applications 2. Re-vamp / Re-do legacy application 3. Develop new applications where required 44

AIRM – Guidelines and integration methods Layers at which integration is done Guidelines for

AIRM – Guidelines and integration methods Layers at which integration is done Guidelines for integration Integration methods Technology Understand the existing technology Establishing networks and infrastructure of the legacy and infrastructure to connect all the green field applications greenfield and legacy applications with a high end standard security protocols Performance Monitor the performance of the services inclusive of the Vision, stakeholders, services and technology Detailed Key performance indicators for every service Governance Comprehensive Study of the departmental services Performing an extensive Gap analysis Identifying key areas for continuous monitoring for every service • Setting up internal committees for • Business decisions • Application and technology monitoring • Performance monitoring 45

Architecture Governance Reference Model – GRM Provides guidelines for maintaining and enhancing Enterprise Architecture

Architecture Governance Reference Model – GRM Provides guidelines for maintaining and enhancing Enterprise Architecture 46

Governance Reference Model 47

Governance Reference Model 47

Critical Success Factors – GRM • • Engagement of senior management Continuous EA program

Critical Success Factors – GRM • • Engagement of senior management Continuous EA program as against a one-time project Involvement of Different important Government Agencies Skillful EA team Good knowledge management practices Staff and other stakeholder support Clear definition of roles, responsibilities, and procedure in the governance team. Use automation tools to control governance and architecture board Work flow 48

EA Communication Plan Matrix– GRM 49

EA Communication Plan Matrix– GRM 49

Governance Model – Illustrative Architecture Governance Board Legacy to Target IT system Architecture Green

Governance Model – Illustrative Architecture Governance Board Legacy to Target IT system Architecture Green Field Applications Architecture Structure, Roles & Responsibi lities IT Governance Board Architecture Contract PMU Set up Architecture Capabilities Architecture Development Review Architecture Compliance Structure, Roles & Responsibi lities System Integrators 50

Ind. EA Implementation – Where do I start? Defines KPIs for outcome assessment PRM

Ind. EA Implementation – Where do I start? Defines KPIs for outcome assessment PRM Guides Design & Implementation GRM Specifies Standards and Best Practices for Security Assets SRM 1 Provides Portfolio of Services BRM Ind. EA Interoperability & Integration AIRM Provides Application Portfolio and SW Development Methods ARM Life cycle management of Enterprise Data DRM Specifies Technology Landscape & Standards TRM 51

Thank You !!! gayatri. ap@nic. in IP: 20021 52

Thank You !!! gayatri. ap@nic. in IP: 20021 52