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