Download presentation
Presentation is loading. Please wait.
1
India Enterprise Architecture
Framework An enterprise 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. Holistic approach in the context of e-Governance in India Need for IndEA EA Resource Group NIC P.Gayatri Sr.Technical Director NIC, Andhra Pradesh
2
… paved way to develop a ONE GOVERNMENT Framework – IndEA
SDG 9: Industry Innovation and Infrastructure Key initiatives under Digital India 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 Broadband highways Universal access to mobile connectivity National Rural Internet mission E-Kranti E-Governance Information for All Electronic Manufacturing Training and Jobs creation Early Harvest Program … paved way to develop a ONE GOVERNMENT Framework – IndEA
3
Methodology: Adopted TOGAF ADM to develop Reference Models
IndEA 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
4
Primary Objectives of IndEA
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.
5
As-Is To-Be Architect
6
IndEA Reference Models – Overview
7
A Reference Model is an abstract representation of the entities relevant to a domain of the Enterprise Architecture, the inter-relationships among those and the standards to be followed.
8
IndEA - Reference Models
Defines KPIs for outcome assessment PRM Guides Design & Implementation of EA GRM Provides Portfolio of Services BRM IndEA Specifies Standards and Best Practices for Security Assets SRM Provides Application Portfolio and SW Development Methods ARM Interoperability & Integration AIRM Life cycle management of Enterprise Data DRM Specifies Technology Landscape & Standards TRM
9
IndEA Reference Models – Overview
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 PRM 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.
10
IndEA Reference Models – Overview
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 Provides guidelines for interoperability of Applications Technology RM 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. EA Governance RM Provides guidelines for maintaining and enhancing Enterprise Architecture
11
Performance Reference Model – PRM
PRM Provides framework to measure Effectiveness and Efficiency of Business Processes
12
Performance Layer The Performance Reference Model provides a mechanism to measure the efficiency and effectiveness of the different domains in achieving the overall goals and objectives of the government. These Goals and Objectives are established at Government Level and then percolated to each Reference Model of the Enterprise Architecture. The successful implementation of these goals and objectives is measured by Key Performance Indicators (KPIs).
13
PRM provides framework to measure effectiveness and Efficiency of Business Processes
The Performance Reference Model provides a mechanism to measure the efficiency and effectiveness of the different domains in achieving the overall goals and objectives of the government. These Goals and Objectives are established at Government Level and then percolated to each Reference Model of the Enterprise Architecture. The successful implementation of these goals and objectives is measured by Key Performance Indicators (KPIs).
14
Relationship of PRM and BRM
PRM measures the impact in terms of the outcome (effectiveness), output (efficiency) and economy of the service. It also aids in providing inputs to further enhance the service to meet the target expectations.
15
Defining KPIs for a service – PRM (Illustrative)
Gain in Process turn-around time Failed transactions due to technical outage Percentage increase in citizens benefitted Percentage increase in transactions Vision People Process Technology The Performance Reference Model provides a mechanism to measure the efficiency and effectiveness of the different domains in achieving the overall goals and objectives of the government. These Goals and Objectives are established at Government Level and then percolated to each Reference Model of the Enterprise Architecture. The successful implementation of these goals and objectives is measured by Key Performance Indicators (KPIs).
16
Business Reference Model – BRM
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
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. The Business Reference Model (BRM) is a mechanism to describe the administrative structure of the State’s Departments, its Functions and Services that it delivers to various stake-holders. BRM describes the structure that government has adopted to fulfill its goals and objectives.
18
As-Is Study Methodology - Illustrative
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 7 Mar 2018
19
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
20
To-Be Modelling - Illustrative
Scope and Vision of the Service Service deliverance through BhuSeva High-Level diagram for the To-Be system List of Comprehensive Use Cases Identification of Key Performance Indicators Prepare To-Be Document in a structured format Get Department Approval Becomes input to SRS 7 Mar 2018
21
Nodal officer for the Project Business functions of HoD
Stakeholders Matrix– Illustrative Department Departmental HOD Nodal officer for the Project Business functions of HoD Revenue CCLA (Chief Commissioner of Land Administration) Additional secretary and Project Director (CMRO Project) Maintenance of land records Issue of PPB, title deeds Assignment of land for agri and house sites Protection of Government lands IGRS Commissioner &Inspector General Asst Inspector General, CARD Project Registration of documents related to movable and immovable assets Issuance of encumbrance certificate Collection of stamp duty Registrations of societies formed for charitable, educational and religious purposes Registration of marriages under various ACTs Registration of chit funds
22
Relationship Between BRM and ARM
23
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.
24
Data Reference Model DRM envisions the single source of truth, data privacy and protection. It also emphasizes on data trusteeship and data governance for data sharing and data availability on demand. Data Description: This area focuses on the semantics and syntactic structure of the identified data assets. Un-ambiguous description of data in terms of its semantics and structure will ensure appropriate usage of the data by the department as well as its external stakeholders such as other departments, citizens and businesses. Data Context: In this area, the concerned department should answer the following questions about the various data assets it manages as part of its governance activity: What data assets does the department need? Who is the steward for the various data assets identified by the department? The steward for a data asset could be the department itself or it may be vested with some other department. How does the data relate to the Business Architecture? (Which business process/service will manage/use the data?) Under what category (of Government taxonomy) will the data asset be categorized? Data Sharing: The Data Sharing area provides a framework for defining how the data can be accessed and exchanged. Data access refers to queries and data exchange refers to exchange of data between different departments/businesses etc.
25
IndEA 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. DRM envisions the single source of truth, data privacy and protection. It also emphasizes on data trusteeship and data governance for data sharing and data availability on demand.
26
Data Context - Data Steward, Data Source, Data Assets - Illustrative
Name of the Data Asset State Master Data Asset Identifier BS-DA-001 Name of the business service(s) / process which generates / manages the data asset 1. Service - A 2. Process 1 Periodicity of data updation As per Government policy Versioned (Y/N) Source: LG Directory Trustworthiness of the Data Asset Highly trustworthy. Validity of Data Asset (from the date of its creation) Always valid subject to changes in government policy Precision of Data Asset Name of the Data Asset District Master Data Asset Identifier BS-DA-002 Name of the business service(s) / process which generates / manages the data asset 1. Service - C 2. Process 1 Periodicity of data updation As per Government policy Versioned (Y/N) Source: LG Directory Trustworthiness of the Data Asset Highly trustworthy. Validity of Data Asset (from the date of its creation) Always valid subject to changes in government policy Precision of Data Asset
27
Data Description- Data Entities, Relations - Illustrative
28
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.
29
Application Reference Model
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
30
ARM – Indicative Portfolio
31
Application Reference Model - Illustrative
Core, Common & Group Applications Departmental Applications Third Party Developers Community Development API Facade Information Services Transactional Services CRUD Services Master Data Management Service A Service B Service C Service D Service E Service F Service N
32
Technology Reference Model - TRM
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.
33
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
34
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
35
Technology Layer Stack – Illustrative
36
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.
37
Security Reference Model
38
Layers of Security Reference Model
39
Controls at Business Layer - Illustrative
Objective: To limit the access to the information, data and facilities providing it. 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. 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. Professional/ company id It should be mandated that for all the official work only the company / department ID should be used. No government information is to be shared on personal 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. Incident reporting and handling A mechanism should be defined and made available to detect any security related incidence. A procedure should be well defined and documented giving steps to be taken for handling any incidence. SIEM A software information and event management system should be defined and documented for handling security related incidences. Learning from the security incidences Knowledge gained through analysis of the earlier incidences should reflect in the security policy document. Continuous Monitoring 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. OTTP or Open Trusted Technology Provider Standards
40
Controls at Business Layer - Illustrative
Objective: To ensure proper and effective use of cryptography to protect confidentiality, authenticity and/or integrity. Policy for cryptographic control usage and key management A security policy should include the use of cryptographic controls to ensure confidentiality and authenticity of the user as well as systems. 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 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. OTTP or Open Trusted Technology Provider Standards
41
Application Integration Reference Model – AIRM
Provides guidelines for interoperability of Applications
42
Application Integration Reference Model
Co-Existence: Integration solution to be designed in such a way that it enables disparate Application and Architectures to co-exist to maximize flexibility in the product and solution selection. Reusability: It is another useful principle which needs to be taken care while designing the Application Integration. One needs to design the solution which can be more reusable. Loose coupling: It is highly recommended to design the solution which is loosely coupled. Federated Orchestration: Composition of services, capabilities, and processes to be federated in appropriate logical business units, Departments etc. Security: This is very important principle which has to be taken care as Integration is required not only within same department as well as from other department, which could be from external network. So, there is high probability of leakage of data/information.
43
IndEA Reference Model – AIRM
Consumer Layer/Provider Layer: This is the entry point for all external consumers/providers. This can be any On-Premise Applications, Mobile Applications, IoT Devices, Partners/Suppliers’ Applications or social platforms. API Layer: This layer comprises of API Gateway, API Manager, API Designer and API Analytics. This layer take care of API creation, API Management, Authentication & Authorization, API Analytics etc. SOA/ESB Layer: This layer is comprises of Business Process Layer, Service Layer and Messaging Layer. The Business Process Layer covers process representation and composition, and provides building blocks for aggregating loosely-coupled services as a sequencing process aligned with business goals. Business processes represent the backbone of the flow of a business. The Services Layer consists of all the services defined within the SOA. Service clustering, Policy Management, Orchestration and Choreography will be done at this layer. Messaging Layer takes care of transformation, routing, validation etc. Data Layer: This layer provide data level integration as well as access to all kind of data stores like Data warehouse, Big Data, Transactional databases, Operational data stores etc.
44
Layers at which integration is done Guidelines for integration
AIRM – Guidelines and integration methods Layers at which integration is done Guidelines for integration Integration methods Business Study Business processes Conduct Gap analysis and recommend suggestions Identify new Business methods Fixing broken lines in the process Business Process reengineering Data Data Sharing – ETL (legacy) Data Sharing – through real time integration (Transactional) Data Sharing Application Identity Application Plug points across inter-operating legacy and green-field applications Re-vamp / Re-do legacy application Develop new applications where required Application programming interfaces and Web Services Consumer Layer/Provider Layer: This is the entry point for all external consumers/providers. This can be any On-Premise Applications, Mobile Applications, IoT Devices, Partners/Suppliers’ Applications or social platforms. API Layer: This layer comprises of API Gateway, API Manager, API Designer and API Analytics. This layer take care of API creation, API Management, Authentication & Authorization, API Analytics etc. SOA/ESB Layer: This layer is comprises of Business Process Layer, Service Layer and Messaging Layer. The Business Process Layer covers process representation and composition, and provides building blocks for aggregating loosely-coupled services as a sequencing process aligned with business goals. Business processes represent the backbone of the flow of a business. The Services Layer consists of all the services defined within the SOA. Service clustering, Policy Management, Orchestration and Choreography will be done at this layer. Messaging Layer takes care of transformation, routing, validation etc. Data Layer: This layer provide data level integration as well as access to all kind of data stores like Data warehouse, Big Data, Transactional databases, Operational data stores etc.
45
Layers at which integration is done Guidelines for integration
AIRM – Guidelines and integration methods Layers at which integration is done Guidelines for integration Integration methods Technology Understand the existing technology infrastructure of the legacy and green field applications Establishing networks and infrastructure to connect all the 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 Consumer Layer/Provider Layer: This is the entry point for all external consumers/providers. This can be any On-Premise Applications, Mobile Applications, IoT Devices, Partners/Suppliers’ Applications or social platforms. API Layer: This layer comprises of API Gateway, API Manager, API Designer and API Analytics. This layer take care of API creation, API Management, Authentication & Authorization, API Analytics etc. SOA/ESB Layer: This layer is comprises of Business Process Layer, Service Layer and Messaging Layer. The Business Process Layer covers process representation and composition, and provides building blocks for aggregating loosely-coupled services as a sequencing process aligned with business goals. Business processes represent the backbone of the flow of a business. The Services Layer consists of all the services defined within the SOA. Service clustering, Policy Management, Orchestration and Choreography will be done at this layer. Messaging Layer takes care of transformation, routing, validation etc. Data Layer: This layer provide data level integration as well as access to all kind of data stores like Data warehouse, Big Data, Transactional databases, Operational data stores etc.
46
Architecture Governance Reference Model – GRM
Provides guidelines for maintaining and enhancing Enterprise Architecture
47
Governance Reference Model
EA Governance Structure
48
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
49
EA Communication Plan Matrix– GRM
50
Governance Model – Illustrative
Structure, Roles & Responsibilities Architecture Capabilities Architecture Development Review Architecture Compliance Legacy to Target IT system Architecture Green Field Applications Architecture System Integrators Architecture Governance Board Structure, Roles & Responsibilities IT Governance Board EA Governance Structure Architecture Contract PMU Set up
51
IndEA Implementation – Where do I start?
1 Defines KPIs for outcome assessment PRM Guides Design & Implementation GRM Provides Portfolio of Services BRM IndEA Specifies Standards and Best Practices for Security Assets SRM Provides Application Portfolio and SW Development Methods ARM Interoperability & Integration AIRM Life cycle management of Enterprise Data DRM Specifies Technology Landscape & Standards TRM 51
52
Thank You !!! IP: 20021
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.