InDEA 2 - 0 Report Draft V6 24 Jan 22 - Rev

InDEA 2.
Draft for consultation (Ver 1.0 Jan 22) 0

InDEA 2.0 Framework
InDEA 2.0
India Digital Ecosystem Architecture 2.0
January 2022
Ministry of Electronics & IT

Government of India
Draft for consultation (Ver 1.0 Jan 22)

InDEA 2.0 Framework
PREFACE
From systems to ecosystems. That is the new order. Blurring of organizational and system
boundaries is happening continuously. Agile is the new watchword – agile governance, agile
development, and agile architecture! We see the beginning of the era of digital ecosystems, which
are constellations of several large, autonomous systems - interdependent and interoperable, and
which can collectively deliver a swathe of innovative services at population scale.
India Enterprise Architecture (IndEA) was designed in 2017 with a view to enable alignment of the IT
developments with the business vision of government organizations. It provides a set of architecture
reference models aimed at a holistic and integrated approach to e-Governance. As a sequel to it,
Agile IndEA Framework was developed in 2019 to make the architecture development to be taken
up in shorter cycles. The MeitY white paper on National Open Digital Ecosystems or NODEs
published in 2020 is a set of principles, which emphasizes that governance frameworks and
community-engagement are essential components of a digital ecosystem. It defines NODEs as “open
and secure delivery platforms, anchored by transparent governance mechanisms, which enable a
community of partners to unlock innovative solutions, to transform societal outcomes.”
Reviewing IndEA framework was expedient considering the paradigm shift proposed by NODE,
coupled with the emerging demand in several Ministries and State Governments for a holistic but
simple architectural approach. InDEA 2.0 seeks to address this felt need.
InDEA 2.0 harmonizes and builds upon the architectural frameworks developed during the last few
years. While codifying their principles, it provides a pragmatic approach to realize the concept of
open digital ecosystems in an integrated and collaborative manner. It recommends a value-driven
approach, a focus on capability building and above all, a preference to ‘enabling’ rather than
‘building’. It is an evolving and dynamic framework with continuous improvement as its mantra.
An architectural framework cannot be prescriptive or overly descriptive. InDEA 2.0, therefore, leaves
enough degrees of freedom for those taking up transformational digital initiatives at the national or
state levels to build innovative, agile, and efficient architectures and solutions that best suit their
specific needs.
Knowledge without power is ineffective. Power without knowledge is wasteful. It is the right
combination of knowledge and power that can create innovative, holistic, and sustainable solutions
and outcomes. It is fervently hoped that the InDEA 2.0 framework enables establishing such a right
balance in all the ongoing architectural initiatives and accelerates the realization of the vision of
Digital India.
J Satyanarayana Ajay P Sawhney
Chairman Co-chairman

InDEA 2.0 Framework
EXECUTIVE SUMMARY
InDEA 2.0 Framework
EXECUTIVE SUMMARY
Executive Summary
What is InDEA 2.0 ?

India Digital Ecosystem Architecture 2.0 or InDEA 2.0 is a framework that enables Governments and
private sector enterprises to design IT architectures that can span beyond their organizational
boundaries and enable delivery of holistic and integrated services to the customers. While InDEA
2.0 builds upon the principles and models recommended in India Enterprise Architecture (IndEA 1.0
- 2018), it adopts a radically different approach to architecture development. It addresses the
architectural needs of an ecosystem rather than of an enterprise which was the focus of its
predecessor.
InDEA 2.0 is a framework that promotes the evolution of digital ecosystems. It consists of a set of
principles and architectural patterns that inform, guide, and enable the development of large digital
systems, with a focus on the public sector. The following statements define the characteristics of
InDEA:
· InDEA is applicable more to ecosystems than to systems.

· InDEA offers a set of architectural patterns but not an architecture.
· InDEA prefers enabling to building.
· InDEA is agile and evolving, and not rigid and inflexible.
· InDEA is unifying and does not force uniformity.
EXECUTIVE SUMMARY
Why InDEA 2.0 ?
The boundaries between functions, jurisdictions and public-private organizations are getting
blurred due to increasing interdependencies and the need for citizen-centric approaches to
designing digital services, as opposed to organization-centric approaches. The need to provide end-
to-end services, adopting the methods of digital transformation, agile development methods,
disruptive business models, and above all, the as-yet unfathomable opportunities offered by the
emerging technologies like AI, ML, IoT and DLT are strong forces pushing the limits towards the
evolution of digital ecosystems.
The core value proposition of InDEA 2.0 to the Governments is in terms of a more rational planning
of IT investments, cost savings due to reusable and interoperable systems, and better architectures
designed faster. To the citizens, it means a more holistic and seamless experience across
organizations. And to the industry, it holds out immense promise of innovation.
The InDEA 2.0 framework is useful to the policy makers in the government, and architects and
system designers in the public and private sector.

InDEA 2.0 Framework
InDEA 2.0 Principles

A large national framework should be based on a set of generic principles, but not
prescriptions. InDEA 2.0 propounds a set of 27 principles in 5 categories, namely, ecosystem,
architecture, business, technology, and architecture governance. The ‘principle of these
principles’ relates to enabling rather than building. Federated architecture, openness in
designs, modularity and interoperability are core among the set. Security- and privacy-by-
design, and agile governance are among the other key principles.
Upholding the primacy of the principles and adoption by all organizations would produce a
multiplier effect and thereby pave the way to realizing the goals of InDEA 2.0.
Building Blocks, the essence of InDEA 2.0

In line with the basic philosophy of enabling, InDEA 2.0 envisages development of architecture
by the ecosystem players by using a set of Building Blocks. A building block is a package of
business or technical functionality, which is reusable, stable, and scalable. Every building block
has a business owner and a technology owner. A building block is interoperable with other
building blocks through well-defined and stable APIs. Building blocks are like Lego blocks using
which we can build different structures.
InDEA 2.0 defines 3 types of building blocks, namely, core, common and reference building
blocks. Core building blocks play a pivotal and central role and occupy an extremely important
position in the architecture. Because of their extremely useful functionality they are accessed
by most of the other building blocks. Common building blocks are reusable across multiple
organizations. Reference building blocks are most often functional and technical specifications
but not working applications. The actual architecture of the digital ecosystem of any sector,
ministry or State can be derived through an appropriate combination of the core, common
and reference building blocks identified by InDEA 2.0 and supplemented by other context-
specific applications.
The InDEA 2.0 report recommends a highly selective approach to the design and development
of the building blocks. Only the core building blocks are proposed to be designed, developed,
EXECUTIVE SUMMARY
and managed centrally by the central or state governments. From a governance perspective,
the government plays an enabling role in respect of the remaining building blocks.
InDEA 2.0 Master Plan and Architecture Patterns

InDEA 2.0 Master Plan is like the master plan of a city. InDEA 2.0 Architecture Patterns are like
the type designs of housing colonies and public infrastructure in a city. The master plan plays a
triple role. It hosts the core and common building blocks. It acts as a repository of all
architectural artefacts of InDEA 2.0. Above all, it acts as the model for development of
ecosystem architectures, through its 3-layer federated structure. In view of its pivotal
importance, the master plan is reproduced below.
The pivotal role of the master plan arises out of the core building blocks, the most important of
which are the registries and directories which are sector-agnostic and pan-India. The
architectural portal also plays a very important role in making available the building blocks,
artefacts, standards, and specifications in a dynamically up-to-date fashion.

InDEA 2.0 Framework
The master plan is constituted by a set of 45 building blocks organized into 10 groups or
‘zones’ of the master plan. 5 of them are core, 12 are common and 11 are reference building
blocks. The rest are building blocks at the domain or state level.
InDEA 2.0 makes architecting simple by adopting the ‘pattern approach’. InDEA 2.0 comprises
of three architectural patterns suited to different administrative environments, and the Master
Plan binds them together.
The Domain Architecture Pattern is most suitable to be adopted by the line ministries of GOI
that deal with concurrent subjects or state subjects that have substantial funding and/ or
involvement of GoI. The State Architecture Pattern, as the name indicates, is to be adopted by
the States and UTs. While this pattern encompasses all the subjects administered by the State
governments, the States can implement it in a phased manner depending upon their own
priorities and resources. The InDEA Lite Architecture Pattern is recommended for adoption by
small departments which intend to produce quick wins ‘on their own’.
A significant amount of systematic effort is required for any ministry, department, or State
EXECUTIVE SUMMARY
Government in converting the patterns into implementable solution architectures. This
requires specialized capacities and competencies.
Federated Digital Identities

Digital Identity is fundamental to enabling the citizen to answer the first question
asked in any interaction with public or private organization – ‘who I am’. While Aadhaar
seems to have answered this question at population scale in respect of all publicly-funded
schemes, the ministries and States are required to create several identities for the same
citizen acting in different capacities like student, teacher, farmer, land owner,
entrepreneur, customer of a bank, driver, owner of a vehicle, pensioner and so on. InDEA
2.0 proposes a model of Federated Digital Identities that seeks to optimize the number of
digital identities that a citizen needs to have. The model empowers the citizen by putting
her in control of these identities and providing her the option of choosing which one to use
for what purpose. It gives the agency to the citizen and protects privacy-by-design. The
same logic holds for entities. And the model is generic enough to establish identity
ecosystem for entities as well.
Emerging trends in Open Digital Architecture

InDEA 2.0 is about empowering the individuals and entities. While the ecosystem of digital
identities forms the foundational layer, at least two more layers are required to ensure that the
ecosystem functions and delivers. These are the ‘assets layer’ and ‘transactions/interactions
layer’. Several initiatives have been successfully implemented to demonstrate the power of one
or more constituents of these 3 layers – identities, assets and transactions. InDEA 2.0
introduces these emerging trends in the form of verifiable credentials, open networks and
protocols. The list consists of Aadhaar, UPI, GSTN, Account Aggregator and the upcoming
frameworks of UHI, NDEAR and ONDC.
InDEA 2.0 Implementation Framework

InDEA 2.0 is an ambitious framework in so far as digital ecosystems are themselves complex to
visualize. For this very reason, Governments are well advised not to try to implement it by
themselves. They should enable the ecosystem players to implement different parts. The
InDEA 2.0 Framework
enablers are of two types (i) policy enablers like PPP Framework, special procurement policy
(e.g outcome-based procurement), data sharing policies and rules of engagement of ecosystem
players (ii) technology enablers like, sandbox(es) and data exchange(s).
The key steps in implementation include developing a vision for the domain/ State/
Organization, developing a Digital Ecosystem Blueprint consultatively and adopting agile
methods for developing architecture and applications. Ultimately, an architectural effort
inspired by InDEA 2.0 will succeed in producing the desired impact if the sponsor can
‘reimagine’ the sector/ domain and conceptualize at least one gamechanger which has the
potential to make a huge difference. The role of the leadership at political, administrative and
technology levels is critical to create such impact.
From capacity building to competency building

InDEA 2.0 requires the coordinated efforts of multiple stakeholders over the medium and long
term to produce widespread impact and achieve the goals of interoperability, citizen-centricity,
EXECUTIVE SUMMARY
and innovation. Governments need to go an extra mile in creating in building not capacities but
competencies. While capacity indicates the potential to perform, competency indicates the
existence of empowered multi-disciplinary teams that have the fitness to execute large
programs. Braodly, it is the difference between ‘thinking’ and ‘doing’. These competencies are
required to be built in both the public and private sectors at the policy, administrative and
technology layers of organizational hierarchies. A blended model containing F2F and online
programs with appropriate curriculum for various programs has been recommended in the
report.
To conclude, InDEA 2.0 is one of the critical enablers in the evolution of a digital economy. India
will do well to adopt InDEA!

InDEA 2.0 Framework
Messages

InDEA 2.0 Framework
COMMITTEE MEMBERS AND WORKING GROUP
STEERING COMMITTEE
Chairman & Co-Chairman
Shri J. Satyanarayana, Former Secretary, MeitY
Shri Ajay P Sawhney, Secretary, MeitY
Members
Shri Arvind Kumar, DG, STQC
Smt. Neeta Verma, DG, NIC
JS (Program Division), MeitY
Representative of DARPG
Representative of concerned Ministry/State
Shri Pramod Verma, Chief Architect , UIDAI
and CEO of Ek Step
Sh. Kiran Anandampillai, Architect of PMJAY
and CEO of DRISTI
Prof. V. Kamakoti, IIT Madras
Shri Sachin Puniyani, AWS
President & CEO, NeGD (Convener
WORKING GROUP
Chairman
Shri J. Satyanarayana, Former Secretary, MeitY
Members
Shri Prakash Kumar, Former CEO, GSTN
Dr. Rajendra Kumar, AS, MeitY
Shri Abhishek Singh, P&CEO, NeGD, MeitY
Dr. Jaideep Kumar Mishra, JS, MeitY
Shri Arvind Kumar, DG, STQC
Shri D C Misra, DDG, NIC,
Prof. V. Kamakoti, IIT Madras
Shri Pramod Verma, Chief Architect , UIDAI and CEO of Ek Step
Sh. Kiran Anandampillai, Architect of PMJAY and CEO of DRISTI
Shri Sachin Puniyani, AWS
Shri Shantanu Godbole, IBM
Shri Ravi Goyal, Redhat
Representative of Independent ICT Standards Assurance and Consultancy (IISAC) Pvt. Ltd.
Program Director, CDAC (Convener)
TABLE OF CONTENT
CONTENTS
Contents
InDEA 2.0 .......................................................................................................................................... 1
PREFACE............................................................................................................................................ 2
Executive Summary .......................................................................................................................... 4
Messages .............................................................................................. Error! Bookmark not defined.
Shri Ashwini Vaishnaw........................................................................... Error! Bookmark not defined.
Shri Rajeev Chandrasekhar .................................................................... Error! Bookmark not defined.
Shri Ajay Sawhney ................................................................................. Error! Bookmark not defined.
Shri Abhishek Singh ............................................................................... Error! Bookmark not defined.
STEERING COMMITTEE ..................................................................................................................... 9
Chairman & Co-Chairman.......................................................................................................... 9
Members9
WORKING GROUP .............................................................................................................................. 9
Chairman................................................................................................................................... 9
Members9
COMMITTEE MEMBERS AND WORKING GROUP............................................................................... 9
CONTENTS ........................................................................................................................................ 1
TABLE OF CONTENT .......................................................................................................................... 1
InDEA 2.0 – The WHAT & WHY ......................................................................................................... 5
1. InDEA 2.0 – WHAT and WHY ..................................................................................................... 6
1.1. Context of InDEA 2.0 .................................................................................................. 6
1.2. WHAT is InDEA ? ........................................................................................................ 6
1.3. WHY InDEA 2.0? ......................................................................................................... 7
1.4. Intended Audience..................................................................................................... 8
1.5. Structure of InDEA 2.0 ............................................................................................... 8
InDEA 2.0 Principles ........................................................................................................................ 10
2. InDEA 2.0 Principles ................................................................................................................... 11
2.1 Ecosystem Principles ......................................................................................................... 11
2.1.1 Ecosystem Thinking: ................................................................................................ 11
2.1.2 Building Block approach: ......................................................................................... 11
2.1.3 Open API-based: ...................................................................................................... 12
Draft for consultation (Ver 1.0 Jan 22) 1

InDEA 2.0 Framework
2.1.4 Open, Open and Open: ............................................................................................ 12

2.1.5 National Portability: ................................................................................................ 12
2.1.6 Participatory Design:................................................................................................ 12
2.1.7 Innovation: .............................................................................................................. 12
2.2. Architecture Principles ...................................................................................................... 14
2.2.1. Federated Architecture: ........................................................................................... 14
2.2.2. Agile Architecture: ................................................................................................... 14
2.2.3. Technology Independence: ...................................................................................... 14
2.3. Business Principles (or Domain Principles) – ....................................................................... 14
2.3.1. Value-driven: ........................................................................................................... 14
2.3.2. Integrated Services: ................................................................................................. 14
2.3.3. Outcome-driven: ...................................................................................................... 15
2.3.4. Choice: ..................................................................................................................... 15
2.3.5. Universal Access: ..................................................................................................... 15
2.4. Technology Principles........................................................................................................ 15
2.4.1. Cloud First: ............................................................................................................... 15
2.4.2. Mobile First:............................................................................................................. 15
2.4.3. Data is an asset: ....................................................................................................... 15
2.4.4. Data sharing:............................................................................................................ 16
2.4.5. Standards: ................................................................................................................ 16
2.4.6. Privacy-by-Design: ................................................................................................... 16
2.4.7. Security-by-Design: .................................................................................................. 16
2.5. Governance Principles ....................................................................................................... 17
2.5.1. Governance Systems: ............................................................................................... 17
2.5.2. Capabilities: ............................................................................................................. 17
2.5.3 Business Model: ....................................................................................................... 17
2.5.4 Leverage the legacy: ................................................................................................ 18
2.5.5 Implementation Strategy: ........................................................................................ 18
2.5.6 Enable rather than build: ......................................................................................... 18
InDEA 2.0 Architecture Patterns ..................................................................................................... 19
3. InDEA 2.0 Architecture Patterns.............................................................................................. 20
3.1 InDEA 2.0 Master Plan ............................................................................................. 21
3.2 InDEA Domain Architecture Pattern ........................................................................ 23
3.3 InDEA State Architecture Pattern ............................................................................ 24
3.4 InDEA Lite Architecture Pattern ............................................................................... 25
2
InDEA 2.0 Framework
Federated Digital Identities ............................................................................................................ 27

4. Federated Digital Identities..................................................................................................... 28
4.1 The Big Picture of Digital India ........................................................................................... 28
4.1.1 Digital Transformation in India ................................................................................ 28
4.1.2 Aadhaar & India Stack.............................................................................................. 28
4.1.3 Empowering Citizens and Businesses ....................................................................... 28
4.2 Digital IDs and Electronic Registries ................................................................................... 30
4.2.1 Context .................................................................................................................... 30
4.2.2 Understanding Uniqueness ...................................................................................... 30
4.2.3 The Need for Registries ............................................................................................ 31
4.2.4 Digital ID as a key to a Registry ................................................................................ 31
4.2.5 Federated Registries ................................................................................................ 32
4.2.6 Authentication and eKYC ......................................................................................... 33
4.3 Recommendations on Federated Digital Identity Ecosystem ............................................... 33
Emerging Trends in Ecosystem Architecture ................................................................................... 36
5. Emerging Trends in Ecosystem Architecture ........................................................................... 37
5.1 Citizen Impact on Digitization ............................................................................................ 37
5.2 Credentialing and Data Empowerment .............................................................................. 37
5.3 Platforms to Protocols ....................................................................................................... 41
5.4 Recommendations on protocol approach ........................................................................... 43
Implementation Framework ........................................................................................................... 44
6. InDEA 2.0 – Implementation Framework ................................................................................ 45
6.1 Enable Vs Build ........................................................................................................ 45
6.2 Guidelines for architecting InDEA Digital Ecosystem for a sector/ State .................. 47
6.3 Testing and Certification .......................................................................................... 49
6.4 Leveraging Emerging Technologies .......................................................................... 49
6.5 Architecture Governance ......................................................................................... 49
6.6 Way Forward ........................................................................................................... 49
Building capacities for InDEA 2.0 .................................................................................................... 50
7. InDEA 2.0 - Building capacities and promoting adoption ........................................................ 51
7.1 From Capacity Building to Competency Building ..................................................... 51
7.2 Target Groups .......................................................................................................... 52
7.3 Themes for Capacity Building................................................................................... 52
7.4 Delivery Channels .................................................................................................... 55
7.5 Content creation and dissemination ........................................................................ 55
3
InDEA 2.0 Framework
7.6 Competency Maturity Model ................................................................................... 56

7.7 Recommendations on institutional arrangements ................................................... 57
GLOSSARY ....................................................................................................................................... 58
ANNEXURES .................................................................................................................................... 59
Annexure 1: Executive Summary of InDEA 1.0, within the Reference Models .................................. 60
Annexure 2 : Indicative set of principles of governance of Federated Architecture .......................... 67
Annexure 3 : Case studies of GSTN, DIKSHA, NDHB ........................................................................ 68
Annexure 4: Indicative list of Common and Reference Building Blocks at National / Sate Level ........ 81
Annexure 5 : Suggested curriculum for InDEA CB Courses and InDEA Certificate Course................... 82
4
InDEA 2.0 Framework
InDEA 2.0 – The WHAT & WHY

InDEA 2.0 Framework
1. InDEA 2.0 – WHAT and WHY
1.1. Context of InDEA 2.0

The only thing constant in Information Technology is the radical and disruptive change that
occurs regularly. The domain is continuously impacted by new technologies, new
architectures, new delivery models and above all, a new user experience. We are currently
at the peak of the transition of systems from electronic to digital. Among other such things
we are witnessing the beginning of a big change in the concept and practice of Enterprise
Architecture, which held its ground for about two decades. Ideas like agile manifesto,
DevOps and Open Digital Ecosystems are disrupting the principles and practice of Enterprise
Architecture.
India Enterprise Architecture or IndEA was notified as a standard framework of enterprise

architecture by the Ministry of Electronics and IT (MeitY), Government of India in 2018.
IndEA 1.0 is a set of business and architectural principles, and 8 reference models that
encapsulate these principles. The uptake of IndEA had not been significant in two years,
despite the efforts to create awareness among the Ministries and the States. MeitY realized
the need to modify, enhance and simplify IndEA framework for some other reasons like
being resource-intensive, and prescriptive. The strongest reason however is, the emergence
of new concepts alluded to in the previous paragraph.
MeitY constituted a Steering Committee to design an architectural framework for digital

government that is agile, user-friendly, and lightweight. The constitution of the Steering
Committee is in Annexure IA. The Committee met 8 times during the period Aug 2020 to
January 2022 and designed a new framework termed as India Digital Ecosystem Architecture
or InDEA. The Committee constituted a Working Group to examine the issues in depth. The
constitution of the Working Group is given in Annexure 1B. The principles and structure of
InDEA framework are presented in this report.
1.2. WHAT is InDEA ?

InDEA is a framework that promotes the evolution of digital ecosystems. It consists of a set
of principles and architectural patterns that inform, guide, and enable the development of
large digital systems, with a focus on public sector. The following statements define the
characteristics of InDEA:
· InDEA is applicable more to ecosystems than to systems.
· InDEA offers a set of architectural patterns but not an architecture.
· InDEA prefers enabling to building.
· InDEA is agile and evolving, and not rigid and inflexible.
· InDEA is unifying and does not force uniformity.
Since the central theme of InDEA is digital ecosystem, it is necessary to explain the term and
to delineate its boundaries in the current context to set the expectations right.
A digital ecosystem is a distributed, adaptive, and open socio-technical system with

properties of self-organization, scalability, and sustainability.
6
InDEA 2.0 Framework
A digital ecosystem can be large and nebulous. In the context of InDEA, the digital ecosystem
is visualized to extend to various sectors of the economy, with substantial emphasis on the
services provided by the public sector, while providing enabling environment for the private
sector and innovation. In other words, the primary goals of InDEA relate to G2C, G2B and
G2G space and the secondary goals include playing a facilitatory role in the B2C and B2B
space. In sum, InDEA is substantially about digital government.
1.3. WHY InDEA 2.0?

Before addressing the question ‘Why InDEA 2.0?’, it is necessary to address the preceding
question ‘Why digital ecosystem approach?’. The need for thinking beyond digital systems
and paying attention to digital ecosystems at this stage of evolution is arising now due to the
following reasons:
a. Blurring boundaries: The boundaries between functions, jurisdictions, public-private
organizations are getting blurred due to increasing interdependencies and the need for
citizen-centric approaches to designing digital services.
b. End-to-end services: Citizens are increasingly expecting fulfilment of their needs on an
integrated and end-to-end basis. This calls for seamless and automated collaboration
between multiple organizations and their systems.
c. Digital Transformation: The transition from e-Governance to digital governance calls for
raising above the traditional systems approach.
d. Leveraging innovation: The potential of explosive and disruptive innovations happening
via emerging technologies like AI/ML, IoT, DLT, AR/VR can be leveraged only if cross-
cutting and pervasive digital environment is established.
e. Disruptive Business Models: An ecosystem approach provides the flexibility and
complementarity required for the growth of disruptive business models that can
enhance efficiency and effectiveness at a lower cost.
InDEA 2.0 Value Proposition
While the basic justification for InDEA 2.0 derives from the foregoing discussion on digital
ecosystem approach, the case for InDEA 2.0 stands on its own feet due to the specific value it
proposes to various stakeholder groups as described in the Table 1.1.
Stakeholder Group Specific value proposition Basis of value

Citizens, businesses, end · Integrated services · Interoperability across
users ecosystem
· SSO
· Innovative, value-added · Open standards,
services specifications, and Open APIs
Government · More effective planning · Holistic view of ecosystem
· Data-driven decision making
· Cost savings · Avoidance of duplicative
development efforts
· Optimal utilization of IT assets
· Minimization of data
collection and management
costs (‘once only’ principle)
7
InDEA 2.0 Framework
· Better architectures · Adoption of the principles

designed faster and patterns of InDEA 2.0
Industry · More active · Clarity of goals
participation in digital · Outcome-based
government initiatives procurements
· Reduced costs in · Open Standards and
providing services to specifications
public sector
Innovators/ startups · Ease-of-Doing- · Innovation policy
Innovation (EoDI) · Ecosystem sandboxes
· Transparency and cost- · Ease of access to test,
effectiveness in data validation, and production
discovery and exchange data of the public sector
with public and private through open data platforms
sectors · Data Exchanges
Table 1.1: Value proposition of InDEA 2.0
Project level value proposition: InDEA 2.0 is not a digital transformation project by itself. It
informs, guides, and inspires many digital transformation projects in the public and private
sectors to realize the value propositions stated above. Each such initiative - ongoing or future -
must define the need for and purpose of adopting InDEA 2.0 in non-technology terms to enable
the governance authorities to take appropriate investment decisions, and / or to modify goals
suitably. Each project should aim to define the significant problems or issues of the sector that it
intends to solve and establish how InDEA 2.0 could be one of the key instruments in such an
endeavor. Collectively such initiatives in each sector should demonstrate unity in diversity by
conformance to a shared vision.
1.4. Intended Audience

InDEA 2.0 framework defined in this report is principally meant to benefit the following
categories of stakeholders.
· Policy makers: can benefit from aligning the IT investments in ways that are outcome-
oriented, provide benefits across the ecosystem, and are open and transparent.
· Architects: can design business and technology architectures faster and in a more
holistic way by adopting the principles and patterns recommended here.
· Industry: can contribute to the growth of InDEA 2.0 by co-creating processes for sharing
data, designing protocols and defining APIs.
InDEA 2.0 is a concept that applies across several ecosystems. It is not feasible nor
appropriate for the public sector to develop all the building blocks. It can happen only
through the active involvement of the community. The Central and State Governments can
do well by promoting ‘InDEA 2.0 Community’ through an initiative that can be called JoinUp
InDEA. The InDEA 2.0 community can crowdsource, curate and publish the specifications of
the various building blocks of InDEA 2.0, and the interfaces.
1.5. Structure of InDEA 2.0

InDEA 2.0 is a set of principles and architecture patterns, along with guidelines for its
adoption /implementation and capacity building. Chapter 2 deals with the principles on
8
InDEA 2.0 Framework
which InDEA 2.0 is founded. Chapter 3 defines the InDEA architecture patterns. Chapter 4
gives an overview of the federated digital identities as an approach to overcome the
problem of proliferation of identities. Chapter 5 touches upon the emerging trends in digital
ecosystem architecture. Chapter 6 provides guidance on adoption/ implementation. .
Chapter 7 emphasizes the need to build capacities at scale on digital transformation and
digital ecosystems. Illustrative examples of digital ecosystems are provided in the
Annexures.
9
InDEA 2.0 Framework
InDEA 2.0 Principles

InDEA 2.0 Framework
2. InDEA 2.0 Principles

InDEA is not prescriptive. It seeks to establish an environment of co-creation by the
community that shares a common understanding on the way the digital ecosystem should
evolve. Such a common understanding can be conveniently articulated in the form of set of
common principles all the actors in the ecosystem agree to adopt voluntarily.
InDEA 2.0 provides a superset of 27 principles organized into 5 categories listed below:
A. Ecosystem Principles
B. Architecture Principles
C. Business Principles
D. Technology Principles and
E. Architecture Governance Principles.
i. This superset is built upon the principles laid down in IndEA 1.0 and those adopted by
large digital ecosystems like Aadhaar, GSTN and NDHB.
ii. Any organization or enterprise intending to adopt InDEA 2.0 can select a subset of these
principles depending upon the requirements of the system/ ecosystem being
architected.
iii. Once adopted, the principles will have to be held as sacrosanct by all the actors of the
related digital ecosystem.
The InDEA 2.0 principles are listed and briefly explained below.
2.1 Ecosystem Principles

-that strengthen the ecosystem concept and enable interoperability and innovation.
2.1.1 Ecosystem Thinking:

Design all digital initiatives as ecosystems, and NOT as systems.
· Ecosystems span across Centre and States, public and private, and are composed of
several autonomous, interoperable and federated systems.
2.1.2 Building Block approach:

Architect and design systems and ecosystems in terms of minimal and reusable
Building Blocks.
· InDEA 2.0 categorizes the Building Blocks as Core, Common or Reference Building
Blocks basing on the degree to which they are to be decentralized. (elaborated at
the end of this sub-section)
· All the building blocks shall evolve orthogonally. Any change in any building block
shall not require consequential changes to be made to the other building blocks.
· The building blocks shall interoperate via standardized, open, and stable interfaces.
· Building Blocks infuse reusability and interoperability into InDEA 2.0.
· Building Blocks designed and developed by the community and placed in the public
domain reduce the effort and cost of development of common software
components.
11
InDEA 2.0 Framework
2.1.3 Open API-based:

Adopt the principle of ‘Open-API by default’. Exceptions shall be justified.
· The Open API Policy (https://apisetu.gov.in) and the guidelines issued by the
Government of India shall be followed.
· Appropriate communities shall be promoted in various sectors of governance/
economy for developing Open APIs
· The specifications on Open APIs published by global organizations like OAS
Foundation (Open API Specification) may be adopted as needed.
2.1.4 Open, Open and Open:

Design the digital systems to be built on open source, to be published as open
source, and to conform to open standards. Exceptions shall be justified.
· The Policy of GoI on Open-Source Software shall be followed in all developments

and procurements for e-Governance/ digital transformation projects.
2.1.5 National Portability:

Design national digital systems and platforms for portability across India.
· Factor the requirements of localization and diversity, inclusion, and special needs.
2.1.6 Participatory Design:

Drive participatory design and end-user engagement at all stages of the digital
initiative.
· Establish a set of robust rules of engagement for the ecosystem players.

· Promote open communities on all major themes and major initiatives of e-
Government and digital transformation.
2.1.7 Innovation:
Enable and promote innovation, and ‘responsible’ deployment of emerging
technologies.
· Establishing an ‘ecosystem sandbox’ can be good enabler of innovation.

· Data is the oxygen for innovation. Data sharing policies appropriate to various
sectors shall be notified by the central and state governments, ensuring data
protection requirements at the same time.
12
InDEA 2.0 Framework
------------------------------------------------------------------------------------------------------------------------------------------
Building Blocks – the essence of InDEA 2.0

A building block is a package of business or technical functionality, which is reusable, stable and scalable.
The concept of building blocks is central to InDEA 2.0. A building block has
· a business owner and a technology owner
· generic applicability
· stand-alone capability
· cross-functional usage
A building block is interoperable with other building blocks through well-defined and stable APIs.
InDEA 2.0 recognizes the following 3 categories of building blocks depending upon the combination of its
attributes and the degree to which it is centrally positioned.
1. Core building blocks: which play a pivotal and central role in the enterprise system and hence occupy
an extremely important position in the architecture. Because of their extremely useful functionality they
are accessed by most of the other building blocks.
2. Common building blocks: which are most often shared assets play the role of optimizing the effort in
design, development, and maintenance. They have the common minimum horizontal functionality to
facilitate their use in a wide range of organizations.
3. Reference building blocks: which are most often in the form of tools that enhance efficiency and
effectiveness. While they provide important functionality, they are not show-stoppers.
Table 2.1 compares the 3 categories of building blocks.
Sl Attribute Core building block Common building Reference building

No block block
1 Qualifying criteria
2 Pan-government Yes Yes No
usage
3 Pan-India usage Yes Yes Yes
4 Domain-neutrality Maybe Maybe Maybe
2 Object type Data or Middleware Application or Tool

infrastructure
3 Flexibility to user Rigid Configurable Configurable and
customizable
4 Unique benefits/ value · Supports · Saves duplicative · Enables specific
proposition interoperability effort value addition critical
· Enables integrated · Provides uniform required by some
services user experience organizations
· Forms Single source of · Incentivizes one- · Supports policy and
truth/SoR time process M&E functions.
· Saves duplicative effort optimization, usage · Enhances
· Promotes innovation across enterprise. accountability
· Ensures consistency
across the enterprise
5 Ownership Public Sector Public sector Public/ pvt sector
6 Design Public sector Co-design Public/pvt sector
7 Development Public sector Outsourced Private sector
8 Maintenance Public sector Outsourced Private sector
13
InDEA 2.0 Framework
------------------------------------------------------------------------------------------------------------------------
2.2. Architecture Principles

- that advocate and promote decentralization, choice and technology
independence.
2.2.1. Federated Architecture:
Adopt a Federated Architecture model for designing digital ecosystems – especially data
and applications.
· Build around the constructs of Single-Source-of-Truth and System-of-Records, both

of which should be created and maintained by the entity legally responsible to do
the same. All other entities shall be required to access it from such a source/ record.
· The principles of Federation, outlined in Annexure 2, shall be adopted.
· These principles apply to databases, applications, identities and reference data; and
to architectural and IT governance.
· A consultative approach shall be adopted in designing the architecture, involving all

the stakeholders related to the initiative. These include the States, industry,
academia, and the civil society organizations.
2.2.2. Agile Architecture:

Permit the architecture to evolve in an agile and iterative manner.
· Do not restrict or constrain the potential for innovation by being prescriptive when
not necessary. Adopt the principles and methods suggested in Agile IndEA
Framework.
· All artefacts are hosted online and evolved continuously
2.2.3. Technology Independence:

Architect systems to be technology-independent.
2.3. Business Principles (or Domain Principles) –

- that enjoin a value-driven, citizen/business-centric approach to architecture,
design, and development.
2.3.1. Value-driven:
Focus on providing additional or new value to the user. Plan to Define, Design and
Deliver value.
· Measure service levels (planned and achieved), impact and outcomes.
· Adopt the methods suggested in Digital Service Standard.
2.3.2. Integrated Services:

Identify, design, and deliver integrated services that cut-across agency boundaries,
to realize the goal of Connected Government.
14
InDEA 2.0 Framework
2.3.3. Outcome-driven:
Define service levels and outcomes benchmarking with the best, and then build
services around such outcomes. Work backwards to re-engineer the processes -
where necessary.
2.3.4. Choice:
Provide choice, by design, to the citizen.
2.3.5. Universal Access:

Ensure that the digital services are accessible to all the target groups, including those
residing in remote areas and to disadvantaged groups.
2.4. Technology Principles

- that emphasize adoption of standards, optimal exploitation of digital assets and
above all, user experience.
2.4.1. Cloud First:

Cloud shall be the first choice in taking ICT infrastructure decisions.
· In respect of applications, systems or data classified as confidential or sensitive

and confidential, explore the option of going in for Government Community
Cloud (GCC).
· In respect of applications, systems or data classified as sensitive, explore the
option of going in for GCC or Virtual Private Cloud (VPC).
· In all other cases, go for public, private or hybrid cloud depending on the
requirements of the domain.
· The Meghraj Policy of GoI (https://www.meity.gov.in/content/gi-cloud-meghraj)
may be followed.
2.4.2. Mobile First:

Design the delivery of all digital services through mobile by default.
· Citizen-facing services shall have ‘offline option’ to include network-challenged

geographies and should have versions compatible with feature phones.
2.4.3. Data is an asset:

Design data systems in a manner that creates, supports, maintains, and
enhances value to the enterprise specifically, and to the ecosystem in general.
· Promote establishment of Data Exchange(s) that enable regulated exchange of

data for public purposes, innovation, and research, and for permitted
commercial purposes.
· Establish / promote robust data governance systems in conformity with the best
practices
15
InDEA 2.0 Framework
2.4.4. Data sharing:

Lay down clear data sharing policies specific to the relevant domain(s), that enable
and regulate the sharing of data, in conformance with the applicable data protection
regulations.
· Data sharing policies apply to public sector data

· Private sector may adopt the data sharing policies on a voluntary basis.
2.4.5. Standards:
Specify the existing technology and data standards applicable to the ecosystem and
define methods to ensure compliance with the same.
· It is necessary to
o Update the standards listed in IndEA 1.0 and establish a process for an
annual updation.
o Establish a framework for government-industry-academia collaboration
for development of standards, protocols and specifications required for
InDEA 2.0.
2.4.6. Privacy-by-Design:
Design and publish a privacy policy that conforms to the principles of Privacy-by-
Design.
· Privacy-by-design implies adopting the nine principles listed below

o Notice
o Choice and consent
o Purpose limitation
o Collection limitation
o Access and correction
o Security
o Openness, transparency and
o Accountability
2.4.7. Security-by-Design:
Design and enforce a cybersecurity policy that conforms to the principles of Security-
by-Design, and an ISMS (Information Security Management System) that conforms to
the ISOs relating to information security.
· Security-by-design implies adopting the principles listed below

o Minimize attack surface area
o Establish secure defaults
o Follow the principle of least privileges
o Follow the principle of defence-in-depth
16
InDEA 2.0 Framework
o Fail securely
o Don’t trust 3rd party services
o Observe principle of separation of duties
o Avoid security-by-obscurity
o Keep security simple
2.5. Governance Principles

- that enhance trust, efficiency, and transparency of/ in the digital ecosystem.
2.5.1. Governance Systems:

Establish accountable, transparent, and effective institutional structures for
· Architecture Governance
· IT Governance
· Data Governance and
· Security Governance.
2.5.2. Capabilities:
Build requisite capacities and capabilities in individuals and organizations of the
ecosystem.
· Capacity building programs should focus on ecosystem architecture, enterprise

architecture, design thinking, agility, co-creation and outcome orientation.
· Capacities on InDEA 2.0 should be built at multiple levels in public and private
sectors.
· Environment for co-design and co-creation should be actively promoted.
2.5.3 Business Model:

Design, develop or promote a policy environment that supports financially viable and
sustainable business models based on value-for-money.
§ Primarily in the sectors where government is the key driver of actual usage and
the underlying standards, a policy environment may be created to enable the
industry and innovator ecosystem to develop new business models based on
additional value like convenience, personalization, cost-saving, faster/ time-
bound/ instant service. The business models in the other sectors may be kept
outside the purview of InDEA 2.0 and allow the market dynamics to work.
· Subject to the above, the model RFPs on public sector procurement and PPP
should make specific provisions for enabling self-financing models of delivery
of digital services.
17
InDEA 2.0 Framework
2.5.4 Leverage the legacy:

Leverage the existing systems after assessing the degree of their conformance to
these principles and enhancing them appropriately for strict conformance.
2.5.5 Implementation Strategy:

Think Big, Start Small, Scale Fast.
· An hourglass model of implementation is recommended. Details are in

Annexure 3.
2.5.6 Enable rather than build:

Enable the ecosystem to design, develop and deliver digital services. Build only in
exceptional cases.
18
InDEA 2.0 Framework
InDEA 2.0 Architecture Patterns

InDEA 2.0 Framework
3. InDEA 2.0 Architecture Patterns

The key drivers of InDEA 2.0 include re-usability of architectural components (termed as building
blocks) across the digital ecosystem and ease of developing an architecture out of the
‘architecture templates. The architecture templates are called Architecture Patterns in InDEA
parlance.
A pattern is defined as: "an idea that has been useful in one practical context and will
probably be useful in others" (Source: Analysis Patterns - Re-usable Object Models, by M.
Fowler).
Pattern is a way of putting building blocks into context; for example, to describe a re-usable
solution to a problem. Building blocks are what we use to architect. Patterns tell us how to use
them, when and why.
InDEA 2.0 makes architecting simple by adopting the ‘pattern approach’.
InDEA 2.0 comprises of three architectural patterns suited to different administrative

environments, and a Master Plan that binds them together. These are explained in Table 3.1.
Sl Name of the Capabilities, characteristics of the Organizations which can

No Architecture Pattern Pattern adapt the pattern
1 InDEA Master Plan · Hosts and maintains · MeitY, GoI (develops and
o core building blocks, maintains the key components
o core data of the Plan)
o common building blocks · GoI Ministries dealing with a
· Enables inter-domain interoperability central subject (with adaptation)
· Acts as the fountainhead of all · State government departments
architectural models through dealing with a state subject
adaptation · CPSUs
Acts as a repository of · Private organizations with pan-
o all artefacts of InDEA 2.0 India presence and uniform
o specifications and application code processes
of reference building blocks
2 InDEA Domain · Acts as the template for designing of · GoI Ministries dealing with a
Architecture Pattern architecture of the digital ecosystem of concurrent subject
a domain (sector) · Private organizations with pan-
· Enables interoperability within the India presence and localized
domain, processes
o between centre and States
o between public and private sector
and with other related domains
· Catalyzes the evolution of a building
block that can become gamechanger for
that domain
· Promotes innovation through
ecosystem sandbox
3 InDEA State · Acts as the template for designing of · State Governments planning
Architecture Pattern architecture of the multi-sectoral digital pan-Government systems,
ecosystem of a state. integrated services
· Enables interoperability · Private organizations dealing
o across all the domains within the with LoBs in multiple sectors
State
o between the State and the Centre
o between public and private
sectors
20
InDEA 2.0 Framework
· Supports development of integrated/

joined-up services
4 InDEA Lite Architecture · Minimum architectural effort · Small ministries and

Pattern · Focus on outcomes, interoperability departments of GoI
· Quick results · Small departments of State
Government
Table 3.1 InDEA Architecture Patterns
Figure 3.1 provides a synoptic view of InDEA 2.0 ( * AP = Architecture Pattern)
Domain State IndEA Lite

AP* AP* AP*
IndEA 2.0 Master Plan
Capacity Building & Adoption Strategy
Figure 3.1 Overview of InDEA 2.0
A description of the Master Plan and the 3 architectural patterns with their salient features is given
in what follows.
3.1 InDEA 2.0 Master Plan

Figure 3.2 provides an overview of the InDEA 2.0 Master Plan.
The rationale for the InDEA 2.0 Master Plan, and its features are given below:
a. InDEA 2.0 Master Plan is NOT an architecture or an architectural pattern. It is a plan (akin
to the master plan of a city) that provides a direction to all initiatives for digital
transformation – largely in the public sector, and in the private sector to the extent that
their initiatives interface with the government.
b. Items 1 to 4 in Figure 3.2 are best designed, developed, and managed by MeitY, Govt of
India. This would bring consistency and interoperability across the whole of Government
– central, state, and local governments included. This would also result in saving of cost
currently incurred in duplicative efforts by Governments all over the country, on these
building blocks and applications.
InDEA 2.0 Framework
c. Items 5 to 10 in Figure 3.2 are to be designed, developed, and managed by the rest of the
ecosystem, consisting of GoI Ministries, State Governments, academia, and the private
sector (including innovators).
Figure 3.2 InDEA 2.0 Master Plan
d. Figure 3.3 represents a detailed view of the items 1 to 7 of the Master Plan. There are
altogether 10 Groups and 45 building blocks in the Master Plan.
e. Annexure 4 provides a cryptic description of the capability of each of the building blocks.
Significant effort is required to undertake the detailed design of these building blocks,
requiring the establishment of a specialized institution to guide the designs and oversee
the implementations.
f. The following conditions apply to the Master Plan.
i. The list of Groups (10) and building blocks (45) is non-exhaustive.
ii. An organization / enterprise is not required to deploy all the building blocks but
can choose what the domain needs.
g. Though the plan is represented in two dimensions, it is multi-dimensional because we
have multiple domains (sectors) and multiple States. The set of domains and set of States
is each represented by a single element of the set. When designed fully over a period,
the Master Plan can be huge in size and complexity.
h. Can InDEA 2.0 be a gamechanger? The answer depends on how effectively the InDEA
principles are assimilated by the domain experts and put into practice. InDEA framework
itself is agnostic to any domain. Its inherent game changing potential is technical in
nature and is limited to that achievable through interoperability and consistency across
the government. However, the true gamechangers are born in the different domains /
sectors by the efforts of experts who are passionate to address the fundamental issues
and challenged faced by the sector by thinking laterally and by promoting innovation.
InDEA 2.0 Framework
Figure 3.3 Overview of the building blocks of InDEA
3.2 InDEA Domain Architecture Pattern

The justification for the Domain Architecture Pattern arises from the fact that the basic
architectural requirements of most organizations in the public sector are significantly
similar. This pattern therefore abstracts the common and comparable requirements into
a stereotype which can be adopted straightway as a starting point for any architectural
effort. Quality time and effort can be devoted to innovation on the domain side.
Customization, supplementation, and improvisation of the template provided by the
pattern are necessary but may consume only incremental efforts.
Figure 3.4 represents the Domain Architecture Pattern (DAP). The salient features of the
pattern and guidance on its use are explained below.
a. DAP applies to all the Ministries of Govt of India that deal with a concurrent subject i.e a
sector in which both the central and state governments can legislate, govern and
administer. DAP can also be used by the private sector organizations (i) that operate in a
sector covered by the concurrent list or (ii) that have pan-India operations - possibly with
some local variations.
b. Every domain (sector – like health, education, agriculture) shall have its own ‘domain
core’, common building blocks and reference building blocks. The essential items of the
domain core, common and reference building blocks are shown in Figure 3.4 on a non-
exhaustive basis. The respective domains need to validate and supplement these building
blocks.
c. A 3-layer architecture is suggested in DAP – core, national and state layers. This pattern
enables interoperability across the country where needed, and leaves flexibility in the
design and development of digital systems autonomously by the ecosystem players –
public and private.
InDEA 2.0 Framework
d. DAP is truly representative of the principle of federated architecture. The core registries
and directories shall be designed in a truly federated manner whereby the data is created
and maintained by the organization legally empowered to do so, and can be shared in
accordance with the applicable data protection regime. Likewise, the common
applications are codesigned or designed in consultation with the States to be closer to
the ground realities.
e. Widespread adoption of DAP by multiple states enables dissemination and replication of
best practices across the country.
f. DAP in conjunction with the principles such as open API and building blocks like data
exchange would give a great fillip to innovation catalyzed by the access to data. Value-
added services also get a boost through DAP.
g. Above all, DAP provides a fertile ground for new ideas, and can catalyze gamechangers to
evolve anywhere and benefit the whole country. The incentive for innovation would be
that the solution developed can scale rapidly and seamlessly in multiple states due to the
interoperable environment within the same sector/ ecosystem.
h. NDHB (National Digital Health Blueprint), IDEA (India Digital Ecosystem of Agriculture),
NDEAR (National Digital Education Architecture) and AG (Ayush Grid) are all founded on
InDEA principles and are good examples of how a protype or pattern can help speed up
the architecture development method.
Figure 3.4 The Domain Architecture Pattern
3.3 InDEA State Architecture Pattern

The justification for the State InDEA Architecture Pattern (ISAP) arises from the fact that
most of the citizen-facing services are delivered by the States and delivering the services
in a consistent, efficient and integrated manner will result in substantial enhancement in
citizen satisfaction. A State which has a well-designed, standards-based and open
architecture in place shall be the focal point for convergence of digital transformation
initiatives of several Ministries of GoI.
InDEA 2.0 Framework
The ISAP pattern is represented in Figure 3.5. The salient features of ISAP are mentioned
below:
a. ZA VAmong the 3 Architecture Patterns, ISAP offers the maximum challenge and
potential for architectural effort because of the large number of domains (over 30) to be
catered to, and the need for integration and interoperability o several fronts.
b. ISAP has been conceptualized as a 3-layer ecosystem consisting of a Core, Common
Applications, and domain/ sectoral ecosystems.
c. The State Core acts as the focal point for integrating the applications at the State level
but also of the central level.
d. One of the critical success factors of adoption of ISAP is to prioritize the Common and
domain applications to be implemented at first. Ideally 2 to 3 common applications
(preferably including HR and Finance) and 2 to 3 domain systems are taken up in the first
tranche. This would enable reaping quick benefits of ecosystem architecture and propel
further phases.
e. The State Core can leverage the common and reference building blocks developed at the
national level.
f. Given the pivotal importance of the State Core, it is desirable that GoI promotes the
development of State Cores in a few states as it can lead to significant architectural
learnings and proliferation of the adoption of ISAP as well.
Figure 3.5 State Architecture Pattern
3.4 InDEA Lite Architecture Pattern

As the name indicates, InDEA Lite Architecture Pattern (ILAP) makes it possible to derive benefits
of architecture in a speedier manner. It is the minimum viable architecture that can be taken up in
a limited jurisdiction with limited functionality. The concept of gamechanger building blocks can
also be attempted as a part of the adoption of Lite Pattern.
Figure 3.6 shows one of the possible models of the ILAP. The following are the salient features of ILAP:
InDEA 2.0 Framework
a. InDEA Lite is meant for departments of Central or State Governments intending to adopt a holistic
approach to their portfolio of functions, and to unify their legacy systems
· They can go on a stand-alone basis at their own pace, without any dependencies
b. InDEA Lite provides a quick route to produce holistic results. (6-9 months!)
c. InDEA Lite pattern guides the dept though its layered approach
· 3 layers for GoI Depts (National- State- District levels)
· 2 layers for State Departments (State-District)
d. The application architecture adopts 2 architectural concepts:
· Common Applications & Domain-specific applications
e. InDEA Lite does not mandate Building Blocks model
· However, the department can pick and choose the relevant building blocks available at
National/ State levels.
f. InDEA Lite provides flexibility to develop/ integrate applications at any of the 3 levels,
independently of the other layers.
g. The only mandate of InDEA Lite is to follow the InDEA Principles to the extent applicable (the
‘Reduced Set’)
Figure 3.6 InDEA Lite Architecture Pattern

InDEA 2.0 Framework
Federated Digital Identities

InDEA 2.0 Framework
4. Federated Digital Identities
4.1 The Big Picture of Digital India
4.1.1 Digital Transformation in India

Through 2000 to 2010, India’s mobile operators with the support of the Government and
regulator, transformed the access reaching a billion mobile connections within a decade.
With the advent of affordable smartphones and high bandwidth mobile networks, India has
one of the largest Internet and smartphone user bases.
4.1.2 Aadhaar & India Stack

Although India’s mobile access was booming, By 2009, India was spending around Rs.3
trillion in benefits and entitlements. At the same time, in 2009, India’s banking access was
still below 20% and a low percentage of people had access to a nationally portable ID. In
2009, India began the Aadhaar project, now covering over 1.32 billion Indian residents,
doing 1 billion plus authentications every month, providing a true foundation for
Government Direct Benefits Transfer (DBT) and Jan Dhan financial inclusion programs.
Subsequently, India built a set of federated digital building blocks as public infrastructure,
collectively known as India Stack, which included APB, AEPS, eSign, Digilocker, UPI, and DEPA
(a decentralized consented data sharing protocol) based on which new data networks such
as Account Aggregator and Personal Health Records are being activated.
4.1.3 Empowering Citizens and Businesses

When systems/platforms - both public and private - are in the middle enabling people and
small enterprises, it is essential to ensure people and especially small businesses are
empowered to have meaningful choice and opportunities.
Figure 4.1: Three core aspects of a Person’s/Entity’s Digital Life

InDEA 2.0 Framework
Figure 4.1 depicts the three core interlinked aspects of a person’s/entity’s digital life, explained
below:
1. DIGITAL IDENTITIES (Who I am): This provides the ability for people and businesses to
ascertain their identity, authenticate themselves, do KYC (share profile), and manage the
lifecycle of those IDs. It is important to note that there will be multiple digital IDs co-existing
each having different purposes and levels of assurances. For example, people may have a
strongly verified unique ID like Aadhaar, mobile/email,and other online digital IDs that are
used in social media etc. Which ID can be used for what service depending on the provider
of that service, for example, opening a bank account may necessitate a strongly verified
Government issued ID, while booking a hotel may only need an email or phone number
verification.
2. DIGITAL ASSETS (What I Have): As a person (or an entity) participates in various transactions
in their life, they earn/accrue various assets such as money, property, other physical assets,
digital assets, etc. But two additional assets that must be taken into account are data and
credentials. In India, with the new data protection bill, every person will have the right to
own their data and credentials. Not only that they can own, they can use data as asset, share
with consent, and leverage to access various services such as jobs, loans, etc. Credentials
(various certificates in digitally verifiable form) enable people and entities to make claims
about them (e.g., claims about academic degree or work experience) for availing services
and the service provider having the ability to verify those claims in a paperless and trusted
manner.
3. DIGITAL TRANSACTIONS (What I Do): Once the person can digitally authenticate and
leverage their assets in their control, they participate/engage in various
interactions/transactions throughout their life, in turn, trading/earning assets. In the digital
realm, these transactions are conducted via various platforms, be it a public or private
platform. These platforms enable consumers (who are seeking the service) to connect with
the providers (who are providing services). But, as transactions increase, these platform
providers become, in one sense, the gatekeepers of it, thus reducing the choice and
portability. It also creates “winner take all” and anti-competitive behaviour. Notice that
irrespective of whether a platform is provided by Government or a private player,
concentration risk and reduced innovation sets in. Also given the scale and diversity of India,
no single platform can solve for all. A new way to think about this is to allow multiple
platforms to co-exist, but ensuring that these platforms form a 'unified interoperable
network’ through the use of “open protocols”. India with its highly successful payment
networks such as Unified Payment Interface (UPI) and Account Aggregator (AA) networks,
upcoming Open Network for Digital Commerce (ONDC), Unified Health Interface (UHI), and
other similar efforts across domains is leading the world by showing how a vibrant
ecosystem can thrive, interoperate, and still provide choice for participants and level playing
field for the innovators.
This chapter specifically covers architecture and recommendations for digital IDs and linked
federated registries. It may be recalled that Federated registries of ID constitute one of the core
building blocks of InDEA 2.0. Further aspects of digital empowerment with respect to data &
credentialing and open ecosystem networks along with architecture and recommendations are
discussed in the Chapter 5.
29
InDEA 2.0 Framework
4.2 Digital IDs and Electronic Registries

4.2.1 Context
In India, digitization of various Government and market systems is happening at a fast pace
across all domains such as healthcare, agriculture, education, commerce, etc. With a large
number of people having Aadhaar, mobile, Internet connection, citizen
interaction/transaction data are stored digitally across all these systems. When
interactions/transactions are conducted, some form of digitally verifiable ID of the
"participants" of those transactions are captured along with the transaction record. Typically
these are in the form of Aadhaar or mobile or email or PAN or other verifiable digital
identifiers.
To ensure inclusive development, any system (especially Government platforms) must be

designed to include people from all walks of life including people with no access to phones,
Internet, etc. Given India's large diversity and widely varying education levels, it is also
essential that architecture of Government systems must support diversity and be inclusive.
As various Government platforms across domains are being digitized, there is a tendency to
create more IDs each with its own ID card, ID management, and effort to make it unique,
etc. Having a multitude IDs, especially to interact with the Government, makes it harder for
common man for whom these are created! Especially given the diversity in education,
awareness, and capabilities, this also has a potential to further create exclusion scenarios.
While the intent of the State is to care for the vulnerable and poor, systems must still be
designed to provide agency and choice to people. At the same time, architecture must make
it easy and convenient for people to participate and access their documents, data,
entitlements, etc.
4.2.2 Understanding Uniqueness

It is common to make sure ID is unique to a user and also common to issue a “unique ID
card” for specific purposes.
There are fundamentally two different lenses through which the concept of uniqueness can
be seen - from user perspective and from state perspective, as differentiated below:
User Controlled Uniqueness State Controlled Uniqueness
1. I have an ID that is unique TO ME and ONLY 1. You can have one and only Unique ID
TO ME (mobile, email ID, bank account No, (Aadhaar using biometric to de-duplicate)
etc are all unique to the user) 2. You cannot have two IDs even if you wish to
2. I can choose to create two IDs both of do
which are unique to me 3. Your records will be linked to only one
3. I can link my records to any of the unique unique ID
IDs I have easily 4. You cannot remain anonymous from the
4. I can keep my records private state point of view
It is important to note that, in India, the only universally covered unique ID (that is globally
unique) is Aadhaar due to its use of multi-modal biometrics and universal coverage. Under
the Aadhaar Act and regulations, Aadhaar can be used for the Government programs where
30
InDEA 2.0 Framework
Government is spending money to provide such services in addition to using for tax/AML
compliance.
While domain specific platforms are popular, it is important to leverage the JAM identities as
the universal IDs that are already used by almost everyone in India. It is thus recommended
that other Government systems trying to create a “state controlled'' unique ID are
encouraged to achieve it through Aadhaar authentication and eKYC. But, if that system is
creating a “user controlled” ID, then, typically the user is allowed to use mobile
number/email etc as a means to sign in.
Either way, such linkages allow citizens to onboard themselves and manage their account
using common IDs such as mobile numbers or Aadhaar numbers that they are already using
every day.
4.2.3 The Need for Registries

All digital platforms require master data and actor (person/entity/thing) data related to that
system to be maintained for identification, validation, etc. For example, a property tax
system needs to maintain master data about properties, the PDS system needs to maintain
master data about the beneficiaries and so on.
As the world becomes data rich, it is essential that various data about people, entities,
geographies, resources, assets, etc. are made available in electronic registries with Open
APIs for other applications to seamlessly validate and use attested and authenticated data.
This is even more critical when it comes to people and entities where various claims can be
electronically validated against such registries via open APIs avoiding paper-based
validations, thus increasing trust while decreasing cost of validation.
In this document, the word “Electronic Registry” is used to depict a trusted system
that enables consented subjects (people, entities, things) to enrol, manage their
record with necessary levels of verification, and avail 3rd party services built on it
using its authentication and KYC services.
Aadhaar is a registry of “usual residents of India”, PAN system is a registry of “persons

(people/entity) who are direct taxpayers”, PDS database is a registry of “people (and
families) who receive food subsidy”, and so on.
4.2.4 Digital ID as a key to a Registry

A Digital ID by itself does not independently exist nor has any stand-alone benefit unless
accompanied by appropriate trust levels and used by other systems using authentication
and consented profile sharing (KYC) service.
A digital identifier, therefore, is the “key” to a registry where the subject (ID holder) is
present who, in turn, is empowered to control her ID, manage the registry record (her
profile in that registry), choose to use it for availing other 3rd party services through
authentication and consented eKYC (digitally signed profile sharing).
In every registry it is necessary that the subjects in that registry are “identified” in a unique
and trusted fashion. These identifiers may be purely numeric (e.g. Aadhaar number, mobile
number, health ID within ABDM, etc.) or alpha-numeric (e.g. PAN number, Vehicle number,
31
InDEA 2.0 Framework
email address, UPI Address, etc.) with or without any logic attached in generating the
identifier itself (random vs logic based identifier).
Depending on the policy, uniqueness can be either “user controlled” (user may have more
than one ID within the same registry, say, using two different mobile numbers) or “state
controlled” (by linking the ID to a globally unique ID like Aadhaar, and hence making sure a
user has one and only one entry within the registry).
Custodians of such registries should ensure appropriate policy is applied to either allow user
controlled uniqueness or state controlled uniqueness. In addition, the fields in the record of
that subject are to be verified/attested or marked as self-declared. When registering, people
must be given an option to use their existing digital IDs such as Aadhaar, mobile, etc as
appropriately to fit the purpose of that registry and also allow people to control, update,
manage their record using the common IDs such as Aadhaar, mobile, etc.
4.2.5 Federated Registries

Many registries stand alone while some get interlinked via registry IDs depending on the
policies that allow such linking. But, when it comes to delivery of benefits, in addition to
usage of Aadhaar, interlinked registries within a state may be required to provide a unified
view of benefits delivery.
Word “linking” is used in the technology context. It can mean
(i) one registry adding another registry’s ID to its records after appropriate user
authentication.
(ii) One registry or system trying to validate the end-user by using the entry of the
end-user in another registry through an API
Any such linking in both the scenarios should be compliant to appropriate
p
o
l
i
c
i
e
s
/
l
a
w
s
.
Figure 4.2: Illustrative example of federated registries

InDEA 2.0 Framework
Technically, electronic registries can be linked via the IDs to allow easy, paperless on-
boarding of citizens and also avoid repeated data verification needs. For example, when a
beneficiary is registered for, say, PDS scheme, that record will be linked to Aadhaar by the
PDS system storing the Aadhaar number (or a tokenized version of it). Similarly, when
someone obtains a PAN, that record gets linked to Aadhaar where the Aadhaar number
becomes the linking ID. Then when that person obtains a mutual fund account, PAN number,
in turn, gets linked to the mutual fund record.
Ability to reuse an existing registry (under appropriate policy/law) of pre-verified

attributes is critical to eliminate this repeated verification process that is costly, error
prone, and most importantly inconvenient to citizens.
When a registry allows users to use “existing IDs from other registries” to be used as an
authentication mechanism, it not only creates an “auto verified/attested” set of fields in the
new registry (registry provider does not have to re-verify those fields again), but also gives
convenience to the people to reuse and leverage commonly used IDs. This fundamental
design pattern is what allowed Aadhaar to become a “building block” for other systems
allowing banks to open accounts with eKYC (attested common fields coming from Aadhaar in
digitally signed manner) and allow transactions with authentication.
To achieve this, it is essential that all registries are built to allow single sign-on (SSO) using
existing IDs in other registries as well as expose itself as a SSO provider for the next set of
systems.
4.2.6 Authentication and eKYC

To allow registries to be “reused” as “sources of truth” in a paperless and trusted
manner for the sake of simplifying citizen service delivery process and reducing costs,
it is critical that all registries provide the choice to the subject (person)
authentication/Single-Sign-On and eKYC (consented digitally signed profile sharing)
capabilities using the primary ID of that registry.
4.3 Recommendations on Federated Digital Identity Ecosystem

The approach suggested in this chapter for creation of federated registries eventually results in
an “optimaly set of federated digital IDs” . The design is privacy -respecting, provides choice,
and still allows citizens to use a few of their preferred IDs for various purposes.
Following are a set of recommendations for establishing federated digital ID and registries:
1. Under the federated architecture approach of InDEA 2.0, it is important to create a “federated
set of registries”, each of which is meant for a “specific purpose” rather than a universal, all-
inclusive registry.
a. Given the federated nature of service delivery and Government systems, it is essential
that each registry be maintained in an autonomous way with its own workflows,
purposes, rules of participation, etc.
b. Any registry provider/custodian must design the registry with the subject (person) in the
centre and ensure convenience, inclusion, data empowerment, and meaningful choice for
them to control and manage their own record within the registry.
33
InDEA 2.0 Framework
c. All registry providers/custodians must ensure personal data protection and consented
access fully and ensure appropriate security and privacy measures to protect the data
within the registry.
2. All such registries should have their own “digital ID” internally to uniquely identify a record.
a. These internal IDs should ideally be “user managed” (like a “user ID”) making it easier for
them to remember and reuse.
b. If not, a random number may be used with an option to attach a user ID.
3. Handling uniqueness:
a. When global state-controlled uniqueness is necessary, allow users to link their Aadhaar or
other Aadhaar linked or Aadhaar derived or Aadhaar based digital IDs to achieve it.
b. If not (if it is user-controlled uniqueness), then allow common identifiers such as mobile
numbers or other acceptable Digital IDs to be used and still allow users to voluntarily use
their Aadhaar.
c. This allows minimizing the need to remember and use many IDs by the citizens and
provides convenience of managing their account using either Aadhaar or mobile or other
acceptable digital IDs.
4. Authentication, eKYC, and SSO:
a. All registries should be built as a “building block” to be “reused” as “sources of truth”
in a paperless and trusted manner for the sake of simplifying citizen service delivery
process and reducing costs
b. All registries should offer authentication/Single-Sign-On along with eKYC (consented
digitally signed profile sharing) capabilities using the primary ID of that registry
c. The SSO should cater to cross-domain and should facilitate identity management among
multiple SSO providers. SSO mechanism should be resilient enough to handle multiple
point of failures. Also, it should identify and address security breach in SSO in proactive
and reactive manner systematically.
d. All registries should accept and allow citizens to enrol and sign-in with other available
digital IDs (white listed as per their policies) to provide 1-click enrolment and sign-in for
citizens.
e. Items b & c above ensure that the registries are not siloed and stand-alone systems, but a
true digital building block for other systems, providing citizen convenience and
eliminating repeated data capture and verification complying with appropriate
policies/laws.
In addition to the above, the following are also recommended to be explored by ID providers:
● Explore and leverage international open API specifications such as OpenID, oAuth, etc.,
when possible, to make it easy for interoperability of multiple -registries.
● Encourage use of e-Pramaan, Digilocker IDs as “authentication and SSO” mechanisms for
others to leverage and provide convenience for citizens.
● All Government ID providers are highly recommended to explore the feasibility of creating
an ID alliance to bring coherence, interoperability, and reuse among those keeping citizen
choice, convenience, and control at the centre
34
InDEA 2.0 Framework
● ID providers should evaluate and adopt NIST Guidelines on Digital ID1 for establishing
standardized trust levels across verification, authentication, and federation.
● The principles of federated architecture set out in Annexure 2 for governance of the digital
ID ecosystem.
35
InDEA 2.0 Framework
Emerging Trends in Ecosystem

Architecture
InDEA 2.0 Framework
5. Emerging Trends in Ecosystem Architecture
5.1 Citizen Impact on Digitization

When systems/platforms - both public and private - intend to be ceitizen- business-centric, in, it is
essential to ensure that people (and small businesses) are empowered to have choice and
opportunities.
Attention is invited to Figure 4.1 depicted in the previous chapter on Digital Identities, where the
idea of using IDs to earn / accrue / control / leverage digital assets, and ability to participate in open
transaction networks are discussed.
InDEA 2.0 implementers must necessarily be cognizant of all the three aspects of Digital
Empowerment and therefore not only implement federated digital IDs, but also address the aspects
of data & credential, and when possible facilitate and enable an open interoperable network within
their domain.
Rest of the sections below deal with the architecture and recommendations for (i) data
empowerment (ii) credentialing and (iii) open ecosystem networks.
5.2 Credentialing and Data Empowerment

5.2.1 Context
Every person (or an entity) participates in various transactions in across many platforms,
leaving digital footprints across such platforms. They also earn many certificates, badges and
other credentials. Unfortunately, in most cases, neither these credentials are available to
them in digitally verifiable fashion nor the related data is available to them in a unified and
trusted manner. It is necessary that both data and credentials are made available to its
owner in a digitally verifiable form and in their control for subsequent use.
5.2.2 Personal Data Empowerment
In India, under the new data protection bill, every person will have the right to own
their data and credentials. Not only that they can own, they can use data as asset,
share with consent, and leverage to access various services such as jobs, loans, etc.
It is essential that all platforms adopting InDEA acknowledge this and design to provide
machine readable personal data access back to individuals.
5.2.3 Principles & Architecture

Global conversation around individual privacy and data ownership has been happening in
the last decade due to rapid growth in digitization. Legislations such as the General Data
Protection Regulation (GDPR) in the EU, Open Banking in the UK, and the California
Consumer Privacy Bill in the USA are all designed to give the individual agency and control
over their personal data. Data Empowerment and Protection Architecture, or in short, DEPA2
2
NITI Aayog page on DEPA - https://www.niti.gov.in/node/1299
37
InDEA 2.0 Framework
is the technology foundation for India for creating “a secure consent-based data sharing
framework”.
NITI Aayog paper3 articulates the need, value, and the necessity for having a technology
infrastructure like DEPA to implement the data access and sharing part of the data
protection bill.
Architecture of DEPA is shown below:
Figure 5.1: DEPA High Level Architecture illustration for financial data (from NITI Aayog Paper)
5.2.4 Verifiable Credentials (VC)

The government, academic, industry, and other ecosystems today issue many certificates
(government and non-government issued), licenses, authorization letters, etc. Unfortunately
having all these in paper form creates issues of low trust, information asymmetry, costly
verification procedures, and non-portability amongst many others. In addition, authenticity
of such documents is not easily verifiable giving rise to fake certificates and fraud.
Establishing a system of standardized VC documents enables an individual to easily

share credentials in a trusted manner anywhere and thereby open up possibilities to
access various opportunities and services.
Given India’s successful Digilocker implementation, it is time for other ecosystems like skill
development to ensure all certificates/credentials are issued digitally still allowing
printability and inclusive usage.
Credentials (various certificates in digitally verifiable form) empower people and entities to
make claims about them (e.g., claims about academic degree or work experience) for
availing services and the service provider having the ability to verify those claims in a
paperless and trusted manner.
India’s Co-WIN platform is a great example of population scale implementation of W3C and
WHO:DD compliant vaccine credentialing.
3
NITI Aayog paper on DEPA - https://www.niti.gov.in/sites/default/files/2020-09/DEPA-Book.pdf
InDEA 2.0 Framework
5.2.5 Principles & Architecture
The architecture and principles described below are adapted from recent efforts in the
skilling and education sector under NDEAR and NDEAR-H and from the efforts of Co-WIN
(vaccination credentials).
Figure 5.2: Credential Issuance & Verification - High Level Architecture
In order to achieve its objectives, the electronic credential should enable the following:
1. Verifiability: Authenticity of the credential should be digitally verifiable by any application to

which it is presented in a paperless and presence-less manner. This verification should not
require the physical presence of the credential holder or be contingent on any human action
of the issuer.
2. Portability: To ensure empowerment and choice for the credential holder, the credentials
should be digitally portable across systems participating in the ecosystem. As in the case of
physical certificates, unrestricted usage by the holder should be enabled. This includes easy
digital storage of choice of the holder and easy consented sharing for various purposes that
holder deem fit.
3. Permanence: The credentials should continue to exist and be valid beyond the lifetime of
the institution where it was awarded. That is, if a training agency which has awarded a
credential subsequently ceases to exist, the credentials still remain verifiable and portable
across the ecosystem.
4. Self-Describing: The credential model should be self-describing in a manner that the verifier
of the credential does not require private sources of information to validate or understand
it. In practice, this means that all metadata, common identifiers, taxonomies, etc should be
publicly accessible in various registries.
5. Consent-based: Design must ensure privacy preservation across the system including taking
holder’s consent for collection and use.
InDEA 2.0 Framework
6. Inclusive: Design of credentials must ensure inclusion in terms of digital and physical usage
(through printed modes with signed QR codes etc.), multi-lingual support, online and offline
usage, and work seamlessly with inclusive and accessible technologies.
5.2.6 Recommendations on verifiable credentials

Credential Standards: InDEA 2.0 proposes to adopt a common electronic, machine-readable
specification to represent various
credentials/certificates across the ecosystem.
For verifiable credential, InDEA 2.0 will leverage

internationally acceptable specification W3C VC4
for all digital verifiable credentialing.
On top of W3C VC, to ensure domain

interoperability, it is highly recommended that
various domains create standardized schemas by
aligning and adopting existing open source
schema efforts. Diagram depicts the 2-layer
standards approach.
Credential Issuance: Various systems implementing VCs as per InDEA 2.0 should set up
credential issuance platforms (ideally by using existing open source implementations - see
DPGA registry5 for globally available implementations - which is recommended for
Government systems or using commercially available implementations) to issue standard
schema based W3C VC complaint credentials, give choice to users to download it, access via
Digilocker, and also via any additional channels such as emails, instant messaging platforms,
blockchain based systems, etc. Such issuance platforms should provide both natively digital
formats along with a printable format which contains a digitally signed QR code. In addition, a
process for issuance through revocation (as necessary) be implemented in such platforms.
Data Empowerment: Platforms implementing InDEA 2.0 should also implement DEPA
architecture for all personal data access (including transactions, audit data, etc.) so that the
individual/subject can access their data in a machine readable and digitally signed manner.
Such consented access should be based on MeitY personal data sharing and consent
principles. While implementing InDEA 2.0, systems should build core personal data APIs
(Information Provider APIs) internally and start allowing users access it via a user interface
built into those platforms. That allows InDEA 2.0 implementers to empower users with data
even when an external consent manager and a data network is not yet in place. And when an
open data network and consent manager falls in place, these same APIs can be then used to
allow users to access their personal data through other applications as well.
4
W3C Verifiable Credentials - https://www.w3.org/TR/vc-data-model/
5
Digital Public Goods Global registry - https://digitalpublicgoods.net/registry/
InDEA 2.0 Framework
5.3 Platforms to Protocols

In any organized society, the need to connect consumers and providers for conducting various
transactions existed. This is especially true when the system is fragmented and disconnected. This
discovery and connection asymmetry was typically solved by a “middle man” connecting both sides.
Brokers in the physical world, yellow pages in the print world, etc are classic examples of a 2-sided
“platform”! In the digital world, “a market/transaction platform” connecting consumers and
providers on the same platform took charge.
5.3.1 The Need

Such a platform becomes a “store of value” and when they grow large, they become a
concentration/monopoly risk. This is true even when the Government is running a monopolistic
platform. In addition, such dominance created anti-competitive behaviour where the platform
intermediary starts charging higher fees/tax for transacting on their platform. This fundamentally
reduces the choice especially for providers, be it an individual or a small business.
But, if we look at the World Wide Web or Email, we see a different picture. We see multiple
platforms connected co-existing and interoperating allowing any browser to view any website or
someone to send email through one service provider to a recipient on another email service. This
is because of the underlying “open protocols” (such as HTTP or SMTP) that enable such “networks
of platforms” to interconnect and interoperate. These networks enable “flow of value” using
these open protocols and bring out a much more decentralized ecosystem architecture. India’s
mobile phone network is another classic example of this where many providers can interconnect
seamlessly due to underlying open protocol (GSM).
The following figure depicts the difference between a “platform approach” and “protocol approach”.
Figure 5.3: Platforms to Protocols
InDEA 2.0 fundamentally is an ecosystem architecture that is federated. When it comes to

transaction systems, many times, Government departments or ministries wanting to induce
innovation and interoperability across the ecosystem, can achieve that merely by adopting
“open protocol specifications” and “facilitating an ecosystem open network” instead of
setting out to build yet another platform.
5.3.2 Open Ecosystem Networks

Solving a problem at such a population scale obviates a paradigm shift from ‘central platforms
storing and exchanging value’ to a ‘decentralised network of interconnected ecosystem actors
orchestrating flow of value’. Instead of an operator-driven monolithic platform-centric model,
InDEA 2.0 Framework
there is a need to initiate a facilitator-driven, interoperable decentralised network using open

protocols.
Given India’s federal structure, growing startup ecosystem, and diverse usage scenarios, it
is essential that Government departments and ministries look at facilitating open
ecosystem networks via open protocols that allow many applications and many platforms
to co-exist, give choice to consumers and providers, and drive innovation and growth
while preserving interoperability.
5.3.3 Open Networks in India
India has already started reaping the benefits of creation of such open ecosystem networks that
allow many applications and platforms to interconnect and interoperate seamlessly using open
protocols. Following table gives the current and upcoming networks.
Network Network Open Facilitator

Name Description Protocol Organization
eSign Instant digital signature service for a billion people built on eSign cca.gov.in
an open protocol (APIs)I approach allowing any application
to connect to any eSign provider in an open and
interoperable way.
UPI Unified Payment Interface - enabling interoperable instant UPI npci.org.in

payment across banks, wallets, merchants, apps, and other
systems in a seamless way.
AA Account Aggregator network is a financial consented data DEPA sahamati.org.i

access and sharing network. It was created through an n
inter-regulatory decision by RBI, SEBI, IRDA and PFRDA
through Financial Stability and Development Council (FSDC).
RBI licenses the AAs.
PHR Personal Health Records network is an open network using DEPA nha.gov.in
(upcoming) a consent manager framework to enable individuals obtain
their health records and provide consented access.
KOMN Kochi Open Mobility Network – an open mobility network Beckn for KMTA –
connecting various modes and providers (taxis, auto Mobility openkochi.net
rickshaws, metro, buses, etc.) through an open protocol to
many consumer apps.
ONDC Open Network for Digital Commerce - an effort launched Beckn for ondc.org
(Upcoming) under the leadership of the commerce ministry to create a Commerce
decentralized commerce network for various types of
commerce in India. Currently in early pilot mode.
UHI Universal Health Interface - an open network to unify health DHP nha.gov.in
(Upcoming) and wellness services and enable interoperable discovery (Beckn for
through fulfillment of various health and wellness services. Health)
42
InDEA 2.0 Framework
5.3.4 Implementing an Open Network

As described above, open protocols and specifications are critical to drive such networks. But,
definition of protocols and specifications require deep technical understanding, domain
knowledge, as well as understanding of how abstracted layers work in such protocols.
It is thus important for Government agencies adopting these to adopt existing open source
protocols or work with the relevant communities to adapt and enhance as needed. By adopting
open protocol specifications ideally built by an open-source community, these networks are
driven by openness and interoperability as key principles.
While technology implementation of such open networks is possible by adopting the open
protocol as digital commons, it also requires a mechanism to manage, co-ordinate, incentivize,
and evolve the nationwide adoption and long-term sustenance of such open networks. It is
therefore important to define a governance framework that is formed and informed by the
purpose of the network. The approach of the RBI in this area may be examined in this context.
5.4 Recommendations on protocol approach

Open Network: When there is a need to connect a large ecosystem of providers and consumers to
enable transactions, facilitate and create an open protocol based decentralized, but, interoperable
network instead of a central platform.
Adopting Protocol: To explore working with the communities to adopt existing open source
protocols to ensure a sustainable development and rapid adoption.
Network Facilitation: Enable creation of a participant driven, co-opted, not-for-profit entity to

facilitate and run the network to ensure network adoption, growth, trust, health, and overall
sustainability.
43
InDEA 2.0 Framework
Implementation Framework
InDEA 2.0 Framework
6. InDEA 2.0 – Implementation Framework

InDEA is about digital ecosystems – a concept which is still evolving. There are no standard
methods and frameworks for implementation. Some of the current trends which are promising
have been discussed in the previous chapter. This chapter provides guidelines on
implementation, based on the experiences of practitioners who implemented comparable
projects in this space in the last few years.
6.1 Enable Vs Build
InDEA tries to address the needs of large and complex digital ecosystems as they evolve. These
needs may not be precisely articulated in the early stages but are discovered or evolve over a
period. Hence the traditional way of systems development by the government either by
themselves or through outsourcing may not work perfectly or efficiently. Digital ecosystems
require implementation frameworks that are non-traditional and provide substantial degrees of
freedom to the private sector to ‘build’ the ecosystem organically over a period. However, for this
to happen, the Government needs to establish two types of enablers, namely, policy enablers
and technological enablers. Establishing these enablers calls for special efforts, which can be
made in a phased manner after this framework is formally notified after due process of
consultation and approval.
Policy enablers include the following:
a. Procurement Policy for digital ecosystems: which should, inter alia, enable the
following:
i. Outcome-based procurement process
ii. Outcome and SLA-linked terms of payment
The procurement policy should be used sparingly in cases where Government must
necessarily build certain core infrastructure or building blocks.
b. PPP Framework: a framework for public sector agencies to collaborate with the
private sector to create innovative and scalable digital ecosystems that provide
customer-centric services. The role of the public sector would be that of an enabler
or facilitator and private sector plays the major role in the design and
implementation. Public sector, for instance, can enable access to relevant data, use
of its field machinery, and delivery systems, besides fast-tracking/ simplifying the
licensing / statutory processes. The framework would enable selection of PPP
projects and partners in a transparent ad accountable manner. It would ensure that
the public and private sectors take up responsibilities which they are best positioned
to perform.
c. Data management and sharing policy: Data is the oxygen of digital innovation.
Providing access to the data available with the public sector to the private sector
would spur innovation and value-added services in the G2C, G2B and B2C space.
Organizations, both public and private alike, are reluctant to share the data collected
by them with other organizations for several reasons. This would impede the
evolution of digital ecosystem. To overcome this barrier, central and state
45
InDEA 2.0 Framework
governments should come out with appropriate policies for managing data in public
sector and sharing the same, with requisite safeguards, with those requiring the
same for beneficial purposes. The governments can provide guidelines on what
types / categories of data – historic data, master data, and transactional data - can
be open, what kind of data needs specific permission/ privilege to access and how
the departments can share data with other departments and the private sector.
MeitY can develop model policies and guidelines in this regard to ensure uniformity
and speed in adoption.
d. Rules of Engagement
A digital ecosystem comprises of several types of players both on the demand side
and supply side, across the entire value chain. The pace of growth would not only be
slow but also haphazard in the absence of a set of rules. It is like the condition of
traffic, including traffic jams in the absence of the rules of the road and the traffic
signals. The rules of engagement could be generic with some special provisions for
each sector. The rules specify (i) how to get engaged with the public sector agencies
for access to data (ii) the compliance requirements to be met (iii) the minimum
required IT Infrastructure and safeguards on security, privacy (iv) trust (v) standards
and protocols to be adopted and (vi) mechanisms for grievance redressal.
MeitY can develop model rules of engagement to ensure uniformity and speed in
adoption.
Technology enablers include the following:
a. Ecosystem sandbox: The concept of Sandbox had its origins in relation to developing
solutions in a highly regulated sector, like the financial sector. We have a few
examples of Sandboxes in India set up by RBI, IRDA and NHA. It is desirable that
every large digital ecosystem sets up its own ‘ecosystem sandbox’ to validate
compliance of a solution with regulatory requirements but also technological
requirements like interoperability, security and privacy besides commercial viability
and scalability. A reference architecture for ecosystem sandbox may be designed to
cut short the gestation period in establishing the sandbox in any sector.
b. Data Exchange: The basic concept on which the visionary idea of data economy is
founded is the establishment of a data exchange(s) that enables the providers and
consumes of data to discover each other and the data (available/ required), and to
exchange the data with ease, transparency, and compliance. A high-level reference
model of the Data Exchange is provided in Annexure 4. Ministries, States and the
other ecosystem players can explore setting up data exchanges needed in various
sector to accelerate the development of data economy, which is estimated to be of
the order of US$ 500 billion in 2025. The DEPA framework designed by NITI Aayog
may be leveraged in this regard.
c. Gamechangers: The example set by UPI gives credence to the belief that most of the
sectors of the economy have the potential for discovery of technology
gamechangers that are innovative, disruptive, impactful and pan-India. It is
necessary for each sector to create appropriate incentives for the discovery of the
46
InDEA 2.0 Framework
gamechangers. This can be an exciting opportunity that unfolds as a part of the

development of architecture of a digital ecosystem in line with the principles of
InDEA 2.0
d. Operational guidelines that ‘enable’:
i. Open the development and staging environments for collaborative

development by other members of the ecosystem
ii. Expose application services through APIs so that ecosystem players may
develop value-added services
iii. Avoid re-inventing the wheel and try to reuse the applications/ components
already operational.
6.2 Guidelines for architecting InDEA Digital Ecosystem for a sector/ State
Strictly speaking, digital ecosystems can’t be architected. They evolve. However, it is desirable
that the proponents create an aspirational picture of what the digital ecosystem should achieve
and could visualize the same in the form of an architecture. The following is a possible path for
such a visualization.
6.2.1 Developing Vision

Developing a vision of the digital ecosystem for the sector is a necessary first step. The
stakeholders should be clear on what is the major challenge that is being addressed and the
overarching benefit it would bring. The vision statement should be precise and picturize the
state of the sector after 5 years. The sector policies of the Central/ State government
together with the related SDGs shall be the basis of developing the vision of the digital
ecosystem. The vision should reflect the future of the sector with widespread use of
technologies emerging currently and be realistic at the same time, factoring the availability
of resources.
6.2.2 Designing Blueprint

Creating a ‘blueprint’ should be the first major milestone in the InDEA journey. ‘A business
blueprint in all its essence is the genuine, realistic and conclusive detailing of our
understanding of the scope, the specifications and the completeness of the solution design
to be fulfilled to the business objectives, desired project outcomes and envisioned benefits’.
For the purposes of InDEA, the term blueprint connotes a high-level document that deals
with the following topics:
a. Scope of the architecture initiative

This includes defining the objectives, principles, functional scope, stakeholder value
proposition and measures of success. Unless the scope is reasonably bounded, such
exercises can go on for a longtime and become infeasible. Prioritization of the
components of the scope is an important step.
b. Architecture of the Digital Ecosystem
One of the architecture patterns recommended by InDEA (in section 3 of this report)
may be selected and suitably customized to fulfil the vision and achieve the objectives.
The Architecture may be defined as a multi-layer structure and comprise of core,
common and reference building blocks. The functionality of each building block may be
defined at a high-level.
47
InDEA 2.0 Framework
c. Standards
Standards are of two broad categories – domain standards and technical standards.
While the digital architecture is basically concerned with the technical standards, it is
necessary to consider the domain standards as well since an ecosystem can not evolve
speedily in the absence of the domain standards that flow across the value chains of the
sector.
An extensive list of technology standards has been provided in IndEA 1.0. These
standards may be updated by MeitY annually and made available in inDEA Portal for the
benefit of all the stakeholders.
d. Implementation Framework
An architecture can be as good as it is implemented. As alluded to earlier, Government
can play the initial catalyzing role in the evolution of digital ecosystems. This involves
essentially, setting up a Program Management Unit (PMU), establishing Architectural
Governance structure, creating a core group drawn from the community for setting the
vision and identifying the priorities and core building blocks, defining the specifications
of the building blocks, selection of an implementing agency or consortium that creates
all the enabling environment for the ecosystem to evolve.
An important aspect of the implementation framework is establishing an institutional
mechanism for the implementation and sustenance of the initiative. The two obvious
choices are to entrust the responsibility to one of the organizations of the ministry or
the State that has all the required capabilities to handle the multiple tasks or to establish
an SPV to undertake the program. These capabilities include technical, domain, legal,
commercial and program management. In either case, the organization (a wing in an
existing organization in the first option and the SPV in the second option) shall be
autonomous in taking all architectural decisions, agile and have the necessary authority
over the jurisdictions in which the initiative is to be implemented. The successful
examples of SPVs are UIDAI (Aadhaar), NPCI (UPI) and GSTN (GST).
6.2.3 Consulting Stakeholders

The essence of the digital ecosystem is to allow it to be developed in a collaborative and
consultative manner such that the outcomes are user-centric and need-based. The
consultation can be done at multiple stages through methods such as publication of draft
papers and designs inviting comments, conducting a series of workshops with the
stakeholders like the States, industry, academia, and civil society organizations. Working
Groups constituted for defining/ detailing the building blocks and for developing the
specifications can all be represented significantly by experts drawn from these stakeholder
groups. The vision itself should be developed consultatively by conducting a Vision
Workshop involving key stakeholder groups. Involving the civil society organizations would
not only bring in citizen-centric perspective but also ensure that the data protection and
privacy aspects are adequately taken care of in the designs.
6.2.4 Adopting Agile Principles for Architecture Development

There is a perceptible debate on the merits of developing architecture in a structured way.
Concepts such as Agile Manifesto and DevOps have questioned the need for architecture. To
reconcile these apparently conflicting perspectives, MeitY has developed the Agile IndEA
framework which recommends developing the architecture in multiple sprints. The
principles and methods recommended in Agile IndEA framework are quite relevant to the
implementation of InDEA 2.0 and may be read as part of this report.
48
InDEA 2.0 Framework
6.2.5 Leveraging IndEA 1.0

Does InDEA 2.0 supersede IndEA (1.0)? No. Are the principles and methods suggested in the
latter still relevant? Yes. The Agile IndEA framework addresses these issues. Stated briefly, (i)
the principles of IndEA 1.0 have been adopted in the set of InDEA 2.0 principles. (ii) the
technology standards recommended in IndEA 1.0 are relevant for firming up specifications,
with the caveat that IndEA 1.0 needs to be updated with the latest standards and (iii) the
reference models developed by IndEA 1.0 may be referred to while undertaking detailed
design of system architectures.
6.3 Testing and Certification

It is necessary to introduce a degree of rigour in implementation/ adoption of InDEA 2.0 for all
major IT initiatives in future. To this effect, Meity, GoI may formulate an appropriate scheme of
testing and certification of projects for compliance with InDEA 2.0 principles, patterns, and other
recommendations. An organization such as STQC may be entrusted with this responsibility.
Multiple private firms may be empaneled for testing and certification to expedite the process of
testing and certification.
The list of organizations complying with the InDEA 2.0 requirements may be publicized to
incentivize adoption by others.
6.4 Leveraging Emerging Technologies

Emerging technologies like AI, ML, IoT and DLT are making inroads into several sectors of the
economy in most of the IT-savvy countries, including India. Significant degree of innovation is
happening basing on the emerging technologies. It is necessary to formulate a set of enabling
policies to promote the growth of these technologies. The data policies should be designed with
adequate enabling provisions so that innovators can access data with relative ease and in
compliance with the applicable regulations.
From an architectural perspective, like that of InDEA 2.0, it is necessary that architectures should
be so designed to ensure that the emerging technologies are mainstreamed into the architecture
by design rather than being retro-fitted. Organizations embarking on greenfield IT projects should
explore the feasibility and desirability of deploying emerging technologies for enhancing the
value to stakeholders and to innovate.
6.5 Architecture Governance

Adoption of InDEA is a medium and long term initiative. Sustainability over such a period is an
important consideration. Besides this quality of InDEA implementations is a requisite for the
program to proliferate and produce impact. All these requirements can be met only by
establishing a robust governance structure for guiding the adoption of InDEA 2.0. The
recommendations of IndEA 1.0 and Agile IndEA framework on Architecture Governance may be
adopted in toto to achieve success.
6.6 Way Forward

Considering the medium and long-term benefits of widespread adoption of InDEA 2.0 across the
country, both in the central government ministries and State Governments, it is recommended
that Govt of India may formulae an appropriate central sector scheme of providing technical and
financial assistance to the organizations adopting InDEA 2.0.
49
InDEA 2.0 Framework
Building capacities for InDEA 2.0

InDEA 2.0 Framework
7. InDEA 2.0 - Building capacities and promoting adoption

World over, when governments aim to introduce digital governance, the crucial factor is to build
the capacity and competency of the key stakeholders of the change viz. the employees of the
government sectors and the professionals from the public and private sector. The former group
is responsible for conceptualizing the business value and the policy changes required to enable
realization of such value. The latter would be responsible to design, develop and implement the
program in a scalable way by adopting the right architectures, technologies, solutions and
methods.
Capacity building assumes a special significant in the context of InDEA 2.0 for the following
reasons:
· The concept of digital ecosystem is nascent and not much knowledge exists on it, even
among management and technology professionals.
· InDEA 2.0 is a high-level framework, requiring significant detailing to be done in the
context of any Ministry or State to create the right architecture and building blocks.
· Realizing interoperability across multiple layers of the ecosystem could be quite
challenging, requiring significant change management in multiple organizations, public
and private.
· Concepts like co-design and co-development, enablement rather than building are
easier said than done.
7.1 From Capacity Building to Competency Building
InDEA2.0 relies crucially on a wide understanding and adoption of the principles of

“Ecosystem Architecture” and “Federation” in architectural, infrastructural and
implementation aspects of digital transformation. As a run up to IndEA2.0 program while we
continue work on capacity building, we must raise the bar to competency building to realize
the vision of InDEA 2.0 program.
Figure 6.1 shows the different levels of maturity of HR for implementing programs.
Figure 7.1: Capacities and competencies

As Figure 7.1 indicates, ability and capability are attributes of individuals while capacity and
competency are attributes of organizations. While capacity indicates the potential to
InDEA 2.0 Framework
perform, competency indicates the existence of empowered multi-disciplinary teams that

have the fitness to execute large programs.
Executing the InDEA program is a gigantic and complex task especially given the organizational
dynamics, complexity of the government sector and the diversities across the country. This
requires a series of carefully designed plans to be undertaken widely amongst the target
groups for graduating from “capacity building to competency building”.
7.2 Target Groups

The proposed program aims to create capacities and competencies in organizations, both in
public and private sectors, to understand, design, implement and proliferate InDEA 2.0.
among broadly two target groups.
· Government staff.
· Professionals.
The following gives a rationale and composition for this categorization.
· The government staff are categorized under either Administrative or Policy streams.
Typically, the targeted group from the government sector would be a hybrid group with
the following functional profiles.
o Top policy makers and administrators at Central and State Governments-
Secretaries/Addl/Joint Secretaries to GOI;
o Principal Secretaries to State Governments, Commissioners
o Heads of Department of Central and State Governments.
· The professionals are categorized under either Architectural or Development streams.

Typically, the targeted group from the public and private sector domains with the
following functional profiles will be the targets.
o CTO, COO, Architects, System Analysts, CISOs, Privacy Officers.
7.3 Themes for Capacity Building

The brief of the program with an abstract of the objectives of each of the training modules
targeting capacity building are given below keeping the objectives and principles in focus and
the pre-existing expertise of the targeted groups. The detailed program structure and syllabi
are given in the Annexure 6 titled “Training modules”.
· The program would focus on administrative, techno-policy, infrastructural, design,

development, architectural components and details of InDEA 2.0 program. This includes
principles of digital governance, policy aspects of technology in digital/e-governance, skills
in developing artifacts relating to digital governance projects falling under InDEA 2.0
program.
· The central theme of this program would be around the principles of Ecosystem
Architecture in a Federated hierarchy with security/privacy principles in focus.
7.3.1 Government Officials

The following program structure is suggested for the senior government officials.
a. Foundation - Common Module for both Administrative and Policy streams
52
InDEA 2.0 Framework
• Abstract
The goal of this module is to provide an overview of digital governance, the overarching
vision of Digital India Program and the principles of InDEA 2.0. Digital governance is often
defined as the adoption and use of Information and Communication Technologies (ICT),
in particular the internet, to transform the relationship between government and society
in a positive manner. The major reform paradigm of digital governance is moving towards
an entrepreneurial approach synchronizing with the functional hierarchy of the
government. In case of IndEA2.0 this transforms to architectural approaches in a
federated system with privacy and citizen-control in focus. The topics couls include the
basics of (i) enterprise architecture and ecosystem architecture (ii) Data Governance (iii)
Data Management (iv) Data Protection (v) Interoperability (vi) Principles of Federated
Architecture (vii) Procurement and PPP for InDEA (viii) Capacity & Competency Building
(ix) Business Vision and Business Architecture (x) Role of emerging technologies (xi)
Concepts of Building Blocks and (xii) Architecture Governance.
b. Stream 1 – Administrative
• Abstract
The goal of this module is to provide concepts that are crucial for IndEA2.0 laying the
foundation for the importance of administrative aspects of EA in governance. The
advanced concepts of technology are introduced in a gentle way. The module wraps up
with focus on significance of factors like partnerships, co-design, stakeholder
engagement, enablement as the preferred option compared to building, outcome-focus
of InDEA2.0, basics of IndEA 1.0 and Agile IndEA framework.
c. Stream 2 – Policy
· Abstract
The goal of this module is to provide deeper insights of InDEA2.0 laying the foundation
for the importance of policies related to technology, especially data policies and PPP
frameworks. They are crucial enablers to the success of InDEA 2.0. The advanced aspects
of technology are introduced in a gentle way. The module wraps us with focus on
significance of factors like privacy, AAA, security, provenance, performance, quality,
capability, usability and availability for the success of InDEA 2.0
d. Case study and Discussion (Optional)

· Abstract
The goal of this module is to discuss approaches towards adoption of InDEA 2.0 by
comparing and contrasting the advances in India and in other countries. Real-life
problems involving the concepts and principles of EA and digital ecosystems would be
provided to all members to work upon. Both the groups (administrative and policy)
would be divided into small teams and required to come up with ideas and solutions to
the problems. Each group would present their learnings followed by a debate and QA.
7.3.2 Professional Stream

The following is program structure is suggested for the professionals.
53
InDEA 2.0 Framework
a. Foundation – Common module 1 (For both architectural and technological streams)

· Abstract
The goal of this module is to provide an overview of digital governance and InDEA 2.0-
the overarching vision of Digital India Program. This module gives a heads up to both
Architectural and Technology streams from the view point of digital governance. The
following topics are suggested at an advanced level: (i) Detailed exposure to Enterprise
Architecture Models (ii) Reference Models of IndEA 1.0 (iii) Principles of InDEA 2.0 (iv)
Detailed exposure to federated architecture, federated data (v) Federated Digital ID (vi)
Security & Privacy- by-design (vii) IndEA Architecture Development Methodology (viii)
Case Studies of Aadhaar, GSTN, DIKSHA and NDHB (xi) Case studies of Emerging
Technologies (x) Program Management.
b. Stream 1 – Architectural
• Abstract
The goal of this module is to provide complete deep insights in to EA models (both
generic and in governance), technology tools and trends. Crucial aspects of security and
privacy by design are dealt in detail. The module wraps up with focus on components of
EA, components that enable Federated models with a case study on IndEA and digital
ecosystem.
• Stream 2 – Systems
• Abstract
The goal of this module is to provide deep insights into technology and trends for EA
from the point of view of a systems professional with focus on Data and Information, the
framework for implementing programs with colossal cross sectorial, high velocity near
real time data. The module wraps up with focus on infrastructure provisioning for
Enterprise Federated Architecture in governance with crucial aspects like security,
privacy, availability and performance in infrastructural provisioning.
7.3.3 IndEA2.0 Certificate Course

An appropriate 6-week online InDEA 2.0 Certificate Course is proposed to address the
requirements of mid-level and operational level professionals in both public and private
sectors.
This program would be open to any person/professional to attend and earn a certificate.
Typically, the program will run on lines of popular MOOCs programs. It is also proposed
that this program can be accredited to one of the popular MOOCS programs, after it gets
stabilized in due course of time.
The detailed course contents will be based on targeted outcome of the InDEA 2.0
Certificate course.
The following broad framework is envisaged.
• Purpose and process-oriented approach

• Subject matter and Domain Experts to be leveraged as faculty
· Multiple delivery channels for imparting training leading to certification.
54
InDEA 2.0 Framework
The certification will be broadly based on knowledge, skills and abilities in

· Concepts of Digital governance
· Enterprise /Federated Architectures
· Technology and Adoption
· Devising implementation and adoption plans
· Regulatory aspects
· Standards compliance
· Data Analytics
· Quality and Performance Metrics
· Security, Privacy, Provenance
· Emerging technologies like AI, Block Chain
· Program management
· India-specific Digital governance programs and frameworks.
· A mini project with a specific practical problem statement.
7.4 Delivery Channels

Technology-enhanced training is preferred by organizations since all records and training
material can be digitized and stored at a central location preferably on cloud-based storage
systems. This allows delivery of relevant training and development material to reach a wider
audience and accessible from the device of choice. Such training scenarios and approaches
through proper delivery channels ensure getting optimum utilization of human resources
yielding better Return on investment (ROI).
Learning is always augmented with new methods to deliver training material personalized to
the scenarios of the domain in which the trainees are working.
The need for hybrid delivery mechanisms is emphasized. An appropriate mix of F2F mode,
virtual CB, self-paced learning and workshop mode is proposed.
· Face to Face
o On-site : one faculty per 15 candidates.
o 2 days for basic and 5 days for advanced programs.
· Virtual CB
o Online programs with fixed program schedule followed by standard
certification in IndEAD2.0 as defined before.
· Self-paced learning
o Online and offline programs followed by standard certification in IndEA2.0
based on adopted pace of the candidate.
· Workshop mode
o On-site : one faculty per 15 candidates
o Group discussions on topics related to InDEA 2.0
o Simple rapid evaluation methods and metrics
o Certification of participation in InDEA 2.0 workshop.
7.5 Content creation and dissemination

Current methodologies include content that can be in the form of video, documents,
multimedia enriched slides or mobile apps.
55
InDEA 2.0 Framework
Choosing proper methods for creation of content enhances its value. This includes crowd
sourcing and curation, commissioning development of case studies by academic and research
institutions.
Considering the broad nature of the process of content creation and dissemination the
following methods are proposed
· Detailed documentation, case studies and instruction/training creation based on India
specific Digital governance programs – Academic institutes, Government and Service
providers can be pooled in to create the contents
· Subject Matter Experts (SME) to create rich contents on SOA (State of Art), Trends and
Standards.
· Academic and research institutes on Emerging technologies and Indigenous adoption –
to give inputs for creating course contents and lecture materials.
· Interviews of successful practitioners / administrators of large enterprise digital
transformation projects
· All lectures and training to be created and handled by either Subject Matter Experts
(SMEs) or certified professionals.
7.6 Competency Maturity Model

The Capability Maturity Model (CMM) is widely adopted development model based on
defined “maturity” levels of the capability of an organization or institution. The Software
Engineering Institute (SEI) adopted the CMM model to procedures and framework used to
develop and refine an organization's software development process. This defines a five-level
evolutionary stage of increasingly organized and consistently more mature processes. A
similar but highly abridged approach is envisaged for measuring maturity in InDEA 2.0 capacity
and competency building.
The above model can be widely and efficiently adopted based on a robust institutional
framework. This plan should include procedures, formal/informal conventions, customs and
norms to evaluate the maturity level and the typical candidates for the same.
This framework can be in the form of exhibited proficiency and role played in adoption,
proliferation and knowledge imparting on/of InDEA 2.0.
The same is presented in the Table 6.1.
Maturity Levels Scope and Indicators of Maturity Typical Candidates

level
Visionaries Forward Integration, State Actors, Non-State actors and
(Level 5) GOI advisory Academia matured from Level 3 or
Legislation and Governance Level 4.
GOI Task force participation
Adapters and Of Processes and policies across State Actors as adapters and
Managerial multiple sectoral and cross sectoral
implementers matured from Level
expertise adoption of IndEA2.0 1
(Level 4) Non state actors as consultants
matured from Level 2 or Level 3
Sectorial IndEA2.0 Processes, policies State Actors as adaptors and
Expertise adaption implementation and implementers matured from Level
(Level 3) knowledge imparting in specific 1 and Non State Actors as
56
InDEA 2.0 Framework
public sectors. consultants matured from Level 2

or Level 1
Domain Exhibited and professional expertise State Actors matured from Level 1 ,
Expertise in adapting and/or knowledge Non State Actors as Consultants
(Level 2) imparting of IndEA2.0 framework, matured from either Level 1 or
Administrative Policy, Architectural expertise from experience and
and technology components working knowledge
Fundamental IndEA2.0 certification (6 weeks State Actors, Non State Actors,
(Level 1) course) or Corporate, Public Academia
The targeted group program for
IndEA2.0
7.7 Recommendations on institutional arrangements

Following are guidelines on the institutional arrangements to impart InDEA2.0 skills through
training and certification programs on a viable and sustained basis.
· Identified Academic institutes may act as nodes for InDEA 2.0 certification program.
· InDEA 2.0 (theory + practical) optional course at BSC / MSC/ BE IT streams with a mini
project.
· Candidates selected for AIS and Central Services to undergo a mandatory InDEA 2.0
training program at Fundamental level (Level 1)
· Training Institutes (with InDEA 2.0 certified experts) may provide institutional
collaboration for imparting training to private sector professionals.
· Public sector employees working at mid-management level and above to a mandatory
fundamental level InDEA2.0 training (by any delivery channel) and get certified
57
InDEA 2.0 Framework
GLOSSARY
GLOSSARY
Building A package of self-contained functionalities defined to meet business needs

Blocks through a set of services made available via APIs and optionally via
reference solutions. Building blocks have to interoperate with other
building blocks within the same system or across systems.
Directories Directories are public listing of various master data and codes in machine
representable and API accessible way. Since data listed in directories have
no link to any person, entity, or things (controlled in person/entity),
directories are considered part of open data (master data) and do not
require any consent mechanisms and access restrictions.
Digital A digital ecosystem is a distributed, open socio-technical system with
Ecosystem properties of self-organisation, evolution, scalability and sustainability
inspired from natural ecosystems connected by a shared Vision and a set
of shared digital platforms. An ecosystem may comprise organizations,
developers, service providers, people, data, processes and things.
Federated Distributed and decentralised systems to preserve autonomy and agency
of States, departments organisations and institutions. These systems must
be interoperable through common standards and specifications, while
maintaining their independence.
Registries An entity data sets belonging to ecosystem stakeholders and actors which
must be designed for consent-based access and reusability by other
building blocks. These registries can be maintained in a single source at
appropriate level (National or State) in digital form (machine-readable)
and made available via APIs for other blocks and applications to use.
Master Code A pre-assigned codes to data elements, so that the data entered into a
system can be reliably read, sorted, indexed, retrieved, communicated and
shared between systems. These master codes must be maintained in a
single source at the central level in digital form (machine-readable) and
made available via APIs for other blocks and applications to use.
Interoperable For systems to be able to connect with each other on a need-basis through
open specifications and APIs. This includes interoperability (based on
appropriate rules, administrative and legal frameworks) across systems
and domains such as health, child development, social justice, juvenile
welfare, tribal welfare and others.
58
InDEA 2.0 Framework
ANNEXURES
InDEA 2.0 Framework
Annexure 1: Executive Summary of InDEA 1.0, within the Reference

Models
IndEA Overview
The Context of IndEA

The e-Governance initiatives in India have acquired a new momentum with the launch of the Digital
India program by the Central Government. The thrust given to Aadhaar and the emphasis on its
adoption in the various welfare schemes have created the expediency for painting the big picture of
e-Governance so as to derive the maximum out of this soft infrastructure. The need for adopting a
holistic approach in the domain of e-Governance has become evident from the interoperability
issues within and across the multiple clusters of stand-alone applications developed by the States
and Central Ministries over the last decade. Against this background, the Working Group constituted
by the Central Government came up with a holistic framework, named IndEA, for streamlining,
standardizing, and optimizing the e-Governance efforts across the country so as to address the
much-needed interoperability and integration.
IndEA defined
IndEA, a catchy acronym for the India Enterprise Architecture, is a framework for developing a
holistic architecture treating the Government as a single enterprise or more realistically, as an
Enterprise of Enterprises, which are functionally inter-related. IndEA is a structured combination of
several Reference Models that, together, enable a boundary-less flow of information across the
length and breadth of the government and facilitate the delivery of integrated services to the
stakeholders, namely, the citizens, businesses and employees. Strictly speaking, IndEA is not an
Enterprise Architecture as its name seems to connote. It is a comprehensive and convenient
framework for developing Enterprise Architecture to support ICT enabled transformation across
governments. It is an authoritative reference providing an integrated, consistent and cohesive view
of strategic goals, business services and enabling technologies across the entire organization. IndEA
can be adopted and used successfully, by the Central, State and Local Governments alike,
irrespective of their size and current status of technology implementation. It can also be used by
PSUs, large departments and agencies of the Government to derive the envisaged benefits.
Simply stated, IndEA is a way to establish Unity in Diversity in the domain of e-Governance. It is a
framework that enables the development and implementation of Enterprise Architectures
independently and in parallel by all governments and their agencies across India, conforming to the
same models and standards.
Vision & Value Proposition of IndEA

The Vision of IndEA is “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”.
60
InDEA 2.0 Framework
IndEA brings to the table the entire value proposition of adopting Enterprise Architecture plus more.
It derives its approach from the globally known architectural frameworks like the TOGAF, Zachman
and the Federal Enterprise Architecture. The models and concepts contained in these global
frameworks have been substantially simplified and suitably contextualized to the Indian conditions.
The principles of ‘Just-in-Time’ and ‘Just Enough’ have been advocated in the design and
implementation of Enterprise Architecture.
The major benefits envisaged by the adoption of IndEA framework are:
1. Provide a ONE Government Experience to the citizens and businesses, by offering

integrated services through multiple channels, in a contactless, frictionless manner.
2. Enhance the efficiency of delivery of services, by defining and enforcing service levels of a
very high order
3. Improve the effectiveness of implementation of the developmental and welfare schemes
through a holistic performance management.
4. Enhance the productivity of employees and agencies through easy access to information.
5. Provide integrated and cross-cutting services through seamless interoperability across
the Whole-of Government.
6. Bring in flexibility and agility in making changes to the systems to align with the best
practices and to leverage the latest technologies.
7. Realize cost-effectiveness through use of shared infrastructure and services.
8. Enable establishing a Connected Government that works for inclusive development.
9. Maintain the right balance between security of data and privacy of personal information.
Architectural Patterns Adopted by the Working Group

It is significant to mention the following major strategies adopted by the Working Group:
1. IndEA Framework is basically designed keeping the architectural needs of the State
Governments. However, the Models are developed in a sufficiently generic manner,
adopting standard notations, such that the Framework can be adopted by the Ministries of
the Central Government and the CPSU’s in the upper tier and the Local Governments in the
lower tier.
2. Federated Architectural Pattern is chosen for IndEA framework for better administrative
feasibility, need for decentralization of implementations, on-boarding of legacy/ ongoing
efforts of e-Governance and above all, the need for state governments to have the flexibility
to build state specific ICT services. The Core Platform is the backbone to provide ONE
Government Experience and interoperability. Any Government or agency delivering ICT
services should centrally deploy the Core Platform. In this sense, IndEA Framework adopts a
hybrid architectural pattern – a combination of centralization of core and common assets
and decentralization of domain platforms.
Structure of IndEA
In line with other globally known architectural frameworks, the structure of IndEA consists of a
number of Reference Models, each dealing with a specific domain of the Enterprise Architecture. 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.
The representation is both graphical - adopting standard notation like the UML, and descriptive -
61
InDEA 2.0 Framework
specifying the capabilities of each of the components (entities) comprising the Reference Model.
Each Reference Model also contains the list of standards that should govern the entities, their
relationships and the manner of communications between them. All the Reference Models
comprising IndEA are technology-agnostic. These Reference Models are, by definition, devoid of the
details specific to their implementation. The Performance, Business, Data, Application and
Technology Reference Models using UML notations are depicted in the Annexure (X) – Reference
Models in UML Notation.
Through a combination of the above-stated 3 basic attributes of all the Reference Models, namely,
abstraction, standards-base and technology-neutrality, the IndEA framework is sufficiently generic
for its widespread adoption by various entities of Government from national to state to local
authorities and organizations.
IndEA framework comprises of 8 Reference Models, represented graphically below, viz., Business,
Application, Data, Technology, Performance, Security, Integration and Architecture Governance.
Principles of IndEA
An Enterprise Architecture is to be founded on a set of Principles that inform and guide the
Architecture Development process. A good set of Principles should satisfy five criteria, namely,
Understandable, Robust, Complete, Consistent and Stable.
Citizen-centricity, Outcome-focus, Standardization, Reusability and Integration are the key mantras
followed while designing IndEA. While individual sets of principles have been stated and explained in
the respective Chapters relating to the 8 Reference Models, the most important of these principles
are given below.
InDEA 2.0 Framework
1. SDG Linkage: Performance Measurement Systems and associated metrics are aligned to
Sustainable Development Goals prioritized by the Government.
2. Integrated Services: Integrated Services that cut across agency-silos are identified, designed
and delivered through multiple delivery channels, to realize the vision of ONE Government.
3. Sharing & Reusability: All commonly required Applications are abstracted to be built once
and deployed across the Whole-of-Government through reuse and sharing. Sharing &
Reusability shall be subject to conformance with the principles of Security & Privacy.
4. Technology Independence: Application Design is open standards-based and technology-
independent.
5. Data-sharing: Data is shared across the Government, subject to rights and privileges, so as to
prevent development and use of duplicative sets of data by different agencies. Data Sharing
shall be subject to conformance with the principles of Security & Privacy.
6. Cloud First: Cloud infrastructure is chosen by default for deployment of applications and on-
site option is resorted to only with strong justification.
7. Mobile First: Mobile channels are mandatory for delivery of all services, among all delivery
channels.
8. Federated Orchestration: Integration services, capabilities and orchestration processes are
federated.
9. Primacy of Principles: The principles specified in this framework govern all reference models
and their implementations.
Eight Reference Models of IndEA

An overview of the 8 Reference Models of IndEA is given below:
Performance Reference Model (PRM)
The key objective of PRM is to provide a uniform and consistent mechanism to measure the
efficiency and effectiveness of the different sectors or domains in achieving the overall goals of the
Government. The principal instrument of the PRM is a set of KPIs designed rationally to measure the
outputs and outcomes of the various programs, schemes, projects and activities. A prioritized and
phased approach for implementation of PRM is recommended so as to avoid the situation of
creating a plethora of KPIs, which hide the actual performance and outcomes.
Business Reference Model (BRM)
The BRM is pivotal for the design of a good Enterprise Architecture, in so far as it looks at purely the
business vision and the functions/ services required to fulfil that vision but not the technologies
required to be used. The key entity in BRM is Service, be it customer-facing or internal. The
watchwords of BRM are – Service Portfolio, Citizen/Business-centricity, Service Prioritization and
Integration. A successful implementation of BRM requires a fundamental re-engineering of the
Business Processes, elimination of non-value-adds and above all, identification of services that are
common across the Government or across groups of departments and abstracting them to a
combination of uniform processes and workflows.
With a view to give a concrete shape to the BRM, the Group attempted an identification of the 16
vertical domains and 12 horizontal functions, which, together, represent most of what a
Government does.
63
InDEA 2.0 Framework
An aspirational goal of IndEA is to support the concept of ‘ONE Government’ with a single interface
offered to the citizens, hiding the boundaries of government agencies. It necessarily involves the
breaking of the departmental silos. Since it is not practically feasible to break the silos physically, this
laudable objective is sought to be achieved by breaking them virtually, through the new concept of
Virtualization of Departments.
Application Reference Model (ARM)
The Application Reference Model provides the foundation to automate Services, identified as a part
of the Business Reference Model. It enables government to achieve its objective through
collaboration and data-sharing between & within departments thereby providing effective business
services to its stakeholders.
ARM provides a framework for grouping similar applications to maximize re-use. To this end, a
concentric set of layers represent the ARM Meta-model within IndEA. The inner-most layer of ARM
is the Core Platform, which provides the most generic services in a domain-agnostic, application-
agnostic and technology-agnostic manner. The three layers around the IndEA Core relate to
Common Applications, Group Applications and Domain-specific Applications.
ARM also captures guidelines and recommendations on Application Architecture Standards, use of
Open APIs, Microservices Architecture and Open Source Software. It also specifies the Secure
Coding Standards for Application Development.
Data Reference Model (DRM)
DRM provides the structure and description of the department’s data (metadata), the logical data
model (depicting the relationship between various data elements), taxonomy, the security
associated with each data element and its sharing. It provides the framework to design the 3
components of Data Architecture, namely, Data Description, Data Context and Data Sharing. These
3 areas deal with Discovery, Creation, Management and Exchange of enterprise data. Database
Schema, Data Steward and Exchange Package are the key concepts/ components in the 3 areas
respectively. Defining Metadata and Data Standards are key activities in the design of Enterprise
Data Architecture.
Technology Reference Model (TRM)
TRM depicts the layout of the technology foundation of ICT-based systems to be designed for
delivery of identified business services. TRM lists all the components of the technology system on
an end-to-end basis, including IT Infrastructure, Applications, Access Devices, Communication
Systems and Service Delivery modes. TRM also defines the currently applicable open standards for
all the solution building blocks and components and identifies the Open Source Products for each
technology component.
TRM also deals with the various considerations for designing the solution architecture besides the
options for application deployment and service delivery. Important among these are insourcing or
outsourcing strategy, cloud strategy, and the mobile strategy.
Integration Reference Model (IRM)
Integration of Governmental Business processes and services across the breadth of the enterprise is
needed for delivering the services conveniently to the citizens on a sustainable basis. Government
entities need to organize, secure, prioritize, classify, and publish the information needed by other
64
InDEA 2.0 Framework
entities for seamless interoperability. IRM consists of 6-layers of integration, namely, Performance,
Process, Service, Application, Data and Infrastructure.
The objective of the IRM is to identify all the technology options for integration and provide
guidelines and recommendations for integrating business applications, services, information systems
and platforms for a boundary-less information flow.
Given the accent of IndEA on providing ONE Government experience to the users, the Integration
Architecture assumes special importance.
Security Reference Model (SRM)
The SRM delineates the overall framework for providing information security to the entire gamut of
IT systems in the enterprise. Integrity, privacy, confidentiality, and availability of information / IT
systems are the key concerns addressed by SRM.
SRM adopts a layered approach to identifying and meeting the information security needs of the
enterprise. The model identifies the security controls to be applied at 6 layers, namely, the Business
Layer, Data Layer, Application Layer, Perimeter Layer, Network Layer and the End Point Layer. SRM
also touches upon the manner of designing Security Policies and Standard Operating Procedures.
Enterprise Architecture Governance Reference Model (GRM)
The objective of GRM is to manage and maintain architecture requirements and artefacts. It
comprises of enterprise structure, processes and standards to ensure that the architecture is
consistent with the business vision and objectives of the enterprise. Effective and efficient EA
Governance ensures that priorities are based on broad consensus across the enterprise. EA is a
continuous activity and governance is an integral part for its successful implementation and
maintenance.
IndEA framework recommends a 3-tier governance structure, namely, at the political, executive
and technology levels.
The framework further recommends the establishing of 2 entities with distinct roles and
responsibilities namely, Architecture Governance Board and IT Governance Board. Blurring or
overlap of these two roles is likely to create conflicts and delays.
EA Program has to be governed keeping in view the triple constraints, namely, Scope, Time and Cost,
which represent the 3 sides of a Project (Program) Management triangle. One side can’t be changed
without affecting the other. A brief treatment of the implications of Scope, Time and Cost has been
given as a part of GRM.
Needless to say, an effective EA Governance system is critical to the success of IndEA.
Implementation Framework
IndEA is a framework for developing full-scale Enterprise Architecture for Governments. The 8
Reference Models comprising it need to be converted into respective sets of Architecture Artefacts
so as to derive the maximum benefits out of IndEA. Such a conversion of RMs into Enterprise
Architecture Artefacts involves Government-specific and/ or domain specific details to be worked
on. IndEA Adoption Guide describes the methodology to be adopted for using IndEA to develop
Enterprise Architectures.
65
InDEA 2.0 Framework
At the whole-of-government level, an Architecture team shall maintain the IndEA framework by
continuously evolving reference models through the transformation journey. Thereby, IndEA is kept
relevant and as a means of identifying new common capabilities.
It is to be emphasized that developing and implementing the Enterprise Architecture is a medium-

term exercise that can spread typically over 3 to 5 years, depending upon the size of the enterprise
and the availability of resources.
66
InDEA 2.0 Framework
Annexure 2 :
Indicative set of principles of governance of Federated Architecture
1. Federated Architecture
(FA) operates collaboratively, where governance is divided between a central authority
and constituent units, balancing organizational autonomy with enterprise needs
2. The Central Authority's architecture can focus on the dynamics of economies of scale,
standards, interoperability and the common requirements, while the constituent units'
(States and organizations) architectures have the flexibility to pursue autonomous
strategies and independent processes
3. Participating members can jointly agree upon the common goals and governance of the
federation which is expressed by the policies governing the roles and responsibilities of
membership, resource discovery, and resource access.
4. There is an administration role whereby federation membership, resource discovery, and
resesource access can be granted or revoked according to governance policy
5. States and organizations can participate in a federation by selectively making some of
their resources discoverable and accessible by other federation members
6. While the purpose of a federation is to collaborate and share resources, resource owners
retain ultimate control over their own resources
7. The design of all the systems in the federation shall conform to the prevalent laws and
regulations relating to security, privacy and data‐sharing.
67
InDEA 2.0 Framework
Annexure 3 : Case studies of GSTN, DIKSHA, NDHB
Case Study- GSTN
1. Executive Summary
The GST System Project is a unique and complex IT initiative as it established for the first time a
uniform interface for the taxpayer under indirect taxes through a common and shared IT infrastructure
between the Centre and States. The Centre and State indirect tax administrations which used to work
under different laws, regulations, procedures and formats and consequently the IT systems worked as
independent sites, were integrated into one system with uniform formats and interfaces for taxpayers
and other external stakeholders.
A centralized approach to bringing a complex tax system to a single point interface with stakeholders,
has resulted in optimum utilization of system and human resources as well. The availability of granular
data on invoice and HSN has proved to be a big tool for improving compliance. This data for the whole
country available at one place is also being used for policy purposes apart from increasing compliance.
As organization of information and digitization of applications bought suitable amount of transparency

in business processes, it automatically resulted in increased efficiency in transactions between
stakeholders. The introduction of GST has effectively reduced the information asymmetry which in turn
resulted in significant reduction in transaction cost across eco-system. With advent of new technology,
GSTN fosters a strong IT Infrastructure and Service back bone which further enables capture,
processing and exchange of information amongst the stakeholders (including taxpayers, States and
Central Governments, Accounting Offices, Banks and RBI.
2. Project Overview / history of project/ need
The matter relating to putting in place a strong IT Infrastructure and Service back bone which enabled
capture, processing and exchange of information amongst the stakeholders (including tax payers,
States and Central Governments, Accounting Offices, Banks and RBI) was discussed in the 4th meeting
of 2010 of the Empowered Committee of State Finance Ministers (EC) held on 21/7/2010. In the said
meeting the EC approved creation of an ‘Empowered Group on IT Infrastructure for GST’ (EG) under
the chairmanship of Dr Nandan Nilekani along with five state commissioners of Trade Taxes.
The Group was mandated to suggest, inter alia, the modalities for setting up a National Information
Utility (NIU/ SPV) for implementing the Common Portal to be called GST Network (GSTN) and
recommend the structure and terms of reference for the NIU/ SPV, detailed implementation strategy
and the road map for its creation in addition to other items like training, outreach, etc. Prior to this, the
Union Ministry of Finance had set up the Technical Advisory Group for Unique Projects (TAGUP) in
March 2010 to make recommendations on the roadmap to roll out five major financial projects
including GST.
The EG held seven meetings between 2nd august 2010 and 8th August 2011 to discuss the modalities.
68
InDEA 2.0 Framework
After due deliberations, the EG recommended creation of a Special Purpose Vehicle for implementing
the GST System Project. To enable efficient and reliable provision of services in a demanding
environment, the EG recommended a non- Government structure for the GSTN SPV with Government
equity of 49% (Centre – 24.5% and States – 24.5%) after considering key parameters such as
independence of management, strategic control of Government, flexibility in organizational structure,
agility in decision making and ability to hire and retain competent human resources. The shareholding
pattern would ensure that the Centre individually and States collectively are the largest stakeholders at
24.5% each. In combination, the Government shareholding at 49% would far exceed that of any single
private institution.
The Government of India approved the proposal for setting up a Special Purpose Vehicle to be called
Goods and Services Tax Network on the lines mentioned above on 12th April 2012. Following
decisions were taken in this context:
1. Suitable and willing non-government institutions would be identified and firmed up by the
Ministry of Finance to invest in GSTN-SPV prior to its incorporation.
2. The strategic control of the Government over the SPV would be ensured through measures
such as composition of the Board, mechanisms of Special Resolution and Shareholders
Agreement, induction of Government officers on deputation, and agreements between GSTN
SPV and Governments.
3. The Board of Directors of GSTN SPV would comprise 14 Directors with 3 Directors from the
Centre, 3 from the States, a Chairman of the Board of Directors appointed through a joint
approval mechanism of Centre and States, 3 Directors from private equity stake holders, 3
independent Directors who would be persons of eminence and a CEO of the GSTN SPV selected
through an open selection process.
4. Relaxation in relevant rules would be granted to enable deputation of Government officers to
the GSTN SPV for exercise of strategic control and for bringing in necessary domain expertise.
5. GSTN SPV would have a self- sustaining revenue model, where it would be able to levy user
charges on the taxpayers and the tax authorities availing services.
6. GSTN SPV would be the exclusive national agency responsible for delivering integrated indirect
Tax related services involving multiple tax authorities. Accordingly, any other service provider
seeking to deliver similar integrated services would be required to enter into a formal
arrangement with GSTN SPV for the services.
7. GSTN would be funded through a one- time non- recurring Grant- in aid of Rs. 315 crore from
the Central Government towards expenditure for the initial setting up and functioning of the
SPV for a three year period after incorporation.
Objective-
On 1st of July, 2017, GST brought together multiple tax regimes administered by various tax
authorities, including central and 36 states and union territories and to supplement this revolutionary
reform, Goods and Services Tax Network (GSTN) has built Indirect Taxation platform to help taxpayers
in India to prepare, file returns, make payments of indirect tax liabilities and do other compliances.
GSTN operates primarily with the following objectives-
69
InDEA 2.0 Framework
● Provide common and shared IT infrastructure and services to the Central and State
Governments, Tax Payers and other stakeholders for implementation of the Goods & Services
Tax (GST).
● Provide common Registration, Return and Payment services to the Tax payers.
● Partner with other agencies for creating an efficient and user-friendly GST Eco-system.
● Encourage and collaborate with GST Suvidha Providers (GSPs) to roll out GST Applications for
providing simplified services to the stakeholders.
● Carry out research, study best practises and provide Training and Consultancy to the Tax
authorities and other stakeholders.
● Provide efficient Backend Services to the Tax Departments of the Central and State
Governments on request.
● Develop Tax Payer Profiling Utility (TPU) for Central and State Tax Administration.
● Assist Tax authorities in improving Tax compliance and transparency of Tax Administration
system.
● Deliver any other services of relevance to the Central and State Governments and other
stakeholders on request.
●
3. Implementation Methodology
Principles
GSTN was setup to ameliorate Efficiency, Transparency, Commitment, Collaboration, Excellence,
Accountability & Innovation in the finance sector of our nation. Its vision is to become a trusted
National Information Utility (NIU) which provides reliable, efficient and robust IT Backbone for the
smooth functioning of the Goods & Services Tax regimen enabling economic agents to leverage the
entire nation as One Market with minimal Indirect Tax compliance cost.
Infrastructure
GST Network was registered as a non-government, not-for-profit, private limited company under
section 25 of the Companies Act 1956 with the following equity structure-
The decision to structure GSTN in its current form was taken after approval of the Empowered
Committee of State Finance Ministers and the Union Government after due deliberations over a long
period of time.
InDEA 2.0 Framework
As per decision of GST Council, the shares held by non-Government Financial Institutions are being
transferred to Central and State Governments so that both hold 50% shares each of GSTN and it
becomes a 100% government owned company.
Capabilities-
The complexity of indirect tax reform, that is GST, required a dependable, scalable and highly secure
system to serve all stakeholders involved in administering and enforcing GST law and applicable rules.
GST System is a single face to all taxpayers for all statutory activities, such as payment of taxes,
registering for new businesses, filing of returns etc.
The use of open source technologies and platform design philosophy, enabled GST System to merge
tax systems of 36 states/UTs and CBIC into a single system, handle traffic of 1.3 Cr taxpayers, & operate
without tight integration within GST modules, external entities, technology verticals and platform. The
choice of technology principles, tools and architecture also provide for highly available fault tolerant
(HAFT) system ensuring failure proofing. Projects of GSTN are-
1. Goods and Service Tax (GST) is the largest indirect tax reform in the history of India. The
reform mandated integration of entire nation’s diverse tax portfolio into a single taxation
system. This brought upon a massive complexity in developing an IT platform, to handle not
InDEA 2.0 Framework
only the diverse tax systems of 36 States/Union Territories & Union Government, but also
needed providing a single interface for more than a crore taxpayers’ for their GST compliance
functions. GSTN has already enabled Tax Payment of 30.42 Lakh Crores by 1.25cr Taxpayers in
India.
2. EWay Bill is an Electronic Way bill for movement of goods to be generated on the eWay Bill
Portal. A GST registered person cannot transport goods in a vehicle whose value exceeds Rs.
50,000 (Single Invoice/bill/delivery challan) without an e-way bill that is generated on
ewaybillgst.gov.in. GSTN has already enabled creation of over 165 Cr. E-Way Bills so far.
3. E-Invoice known as ‘Electronic invoicing’ is a system in which all B2B invoices are electronically
uploaded and authenticated by the designated portal. Post successful authentication, a
unique Invoice Reference Number (IRN) is generated for each invoice by IRP. Along with IRN,
each invoice is digitally signed and added with QR code. This process is collectively called as e-
invoicing under GST. Over 1129 Cr. B2B Invoices have already been generated over GSTN up till
Dec,2020.
4. TINXSYS is a centralized system facilitating information exchange among CTDs of all

States/Union Territories for better administration of inter-state trade of non-GST Goods.
TINXSYS is the repository of information pertaining to dealers in various States registered
under the Central Sales Tax Act. There have been 17.33 Cr. Payment Transactions & 60.78 Cr.
Returns over the platform so far.
Future roadmap/sustainability-
As of now, GSTN is continuously improving taxpayer interaction with GST Portal with focus to ensure
availability of all GST Services to Indian taxpayers and authorities in a seamless manner. Currently
emphasis is on making the system more robust in terms of handling load beyond 1.5 Cr taxpayers,
ensuring application durability and improving in-site navigation to ensure better user experience.
GSTN is also enhancing its offline tools to provide more freedom at hands of taxpayers to work on
compliance related activities offline. This will also involve a tool that will enable taxpayers to do their
business accounting in digital way. An effort is being done to enhance the GSP eco-system to onboard
more service compliance activities for taxpayers.
GSTN is also engaged in creating many other value adding services like a mobile app for taxpayer
facilitation, Business Intelligence using cutting edge AI/ML techniques, improved return filing
procedure helping taxpayers have a prefilled return forms for filing and payment.
72
InDEA 2.0 Framework
Case Study- Diksha
The National Education Policy 2020 (NEP) lays down a high-level road map and goals for the country in
the next 20 years - “to achieve universal access to quality education”. This requires the development of
digital infrastructure, use of technology for aiding learning and access to learning. India is committed to
attain Sustainable Development Goals by 2030 - United Nations Sustainable Development Goal (SDG) 4
for Education, requires countries to ensure “inclusive and equitable quality education and promote
lifelong learning opportunities for all”.
In the context of COVID-19 related disruption of schooling, DIKSHA made it possible for all states/UT’s
to ensure and accelerate learning/education at home through innovative programs & has been one of
the top rated Free Education App on Google Play Store in India since May 2020. DIKSHA immensely
helped in leapfrogging the use of technology for the benefit of teachers and learners across India.
DIKSHA policies and tools make it possible for the education ecosystem (educationist, experts,
organisations, institutions - government, autonomous institutions, non-govt and private organisations)
to participate, contribute and leverage a common platform to achieve learning goals at scale for the
country

DIKSHA (Digital Infrastructure for Knowledge Sharing) is the national platform for school education
available for all states and the central government for grades 1 to 12 and was launched in September
2017. DIKSHA can be accessed through a web-portal and mobile application. DIKSHA provides access to
a large number of curriculums linked e-content through several use cases and solutions such as QR
coded Energized Textbooks (ETBs), courses for teachers, quizzes and others. As of July 2020, it is
estimated that over 60 crore ETBs are being printed this year in India by 35 states and Union
Territories, with more than 30 crore content plays and 200 crore page hits already on DIKSHA. It has
1,40,000+ e-content resources available across 30+ languages along with 500+ micro courses for
teacher training for easy access and consumption during as well as post lockdown.
As part of PM eVidya announced under the Atma Nirbhar Bharat programme, DIKSHA is the ‘one
nation; one digital platform’ for school education in India. DIKSHA is being transformed into a platform
for diverse and rich curriculum linked e-content requirements of learners and teachers for all
states/UTs accessible across digital devices (laptop/mobile/desktop/tablets, TV and radio) in order to
have coherence of access and learning experience.
At the same time, DIKSHA is designed to inherently support states/UTs to exercise autonomy,
independence and choice to craft and run learning programs to suit their needs and achieve their
goals, by using solutions, tools and data on the platform.
Objective-
Education is now increasingly resourced and conducted through digital devices to ensure continuous
learning during the Covid-19 pandemic. Schools across the country have moved towards adopting
various modes to facilitate teaching and learning at home. While digital or online education cannot
replace classroom learning, it has some advantages. It allows flexible and personalized learning at the
73
InDEA 2.0 Framework
speed of the learner and one can continuously augment and expand content through digital means.
Principles
DIKSHA platform embodies, is designed and implemented on the basis of ten design principles and they
are Shared infrastructure, Enable extensibility via platform, Create transparency and accountability,
Enable extensibility via platform, Allow configurable design with plug ‘n’ play capabilities, Offer diverse
solutions, interoperable via open standards, Distributed access via multiple delivery channels, Designed
to scale via commodity computing, & Data security and privacy by design.
Building Blocks
DIKSHA is built on open source technology, made in India and made for India, which incorporates
internet scale technologies and enables several use-cases and solutions for teaching and learning.
DIKSHA is built using MIT licensed open-source technology called Sunbird, (initially upgraded by EkStep
Foundation), which is a digital infrastructure for learning and is designed to support multiple languages
and solutions and offers over a 100 micro services as building blocks for the development of platforms
and solutions.
Building blocks of DIKSHA are-
1. Teacher & Leadership Training

2. Lesson Plans & Teacher Tools
3. Explanation Content
4. Practice & Homework
5. Question Banks & Exam Prep
6. Assessments
7. Quiz
Capabilities-
The vastness and diversity of India is reflected in the scale at which school education operates in the
country - with about 95 lakh schoolteachers and 25 crore students, characterized by geographical,
socio-cultural and linguistic diversity. Therefore, decentralised education platform like DISHA is best
suited for the digital education system to work in India, keeping in view the ground realities of each
State and Union Territory.
DIKSHA is a flexible and evolving platform, with the below-mentioned diverse capabilities, that will
continue to evolve, based on the aggregated needs of the various states/UTs.
1. The Energised textbook solution allows educational boards to achieve that by enabling just-in-time
access to digital content through QR codes printed in textbooks. This solution enables 18 crore+
students and 70 lakh+ teachers to leverage technology in the same way as a select few have been
able to do so far.
2. Digital Teacher Training (DTT) courses allow roll out of structured learning programs targeted to
build or enhance specific knowledge and skills for learners. Over 30 lakh teachers have been
74
InDEA 2.0 Framework
digitally trained with the help of such courses on DIKSHA.
3. Periodic rollout of quizzes to provide an interactive format for joyful learning and promote healthy
competition
4. Federated and multi-tenanted feature lets tenants like 35+ states/UTs, NCERT, CBSE are create and
manage their programs on DIKSHA and help in further expanding its ever-evolving horizons.
5. Diverse content in over 20 languages propagated via various mediums like TV, radio, mobile apps,
websites helps in educating diverse set of students in every part of India.
6. Features like ‘Vidya Daan’ help in sourcing, curating, and organizing content at scale and
encourages community collaboration across the country.
7. Target user based curriculum for students ranging from early childhood to higher classes, helps in
personalised & self-paced learning.
8. Compatibility with advanced technologies like Artificial Intelligence, Augmented Reality,& Virtual
Reality, and its Integrability with Digi Locker makes it one stop solution every student of India in
K12 Spectrum.
DIKSHA has witnessed more than 170 Crores learning sessions till date which showcases the relevance
of the available e-resources as well as the integration of digital learning in the daily lives of teachers
and students across the nation. It is truly an education platform for modern & digital India.
Standards
Standards used within DIKSHA include Codification standards - language, master data, etc., Content
standards (SCROM and enhanced Content Markup Language), Question Markup Language (QuML)
Specifications, Electronic Credential Specifications and other open standards for consent, security, etc.
InDEA 2.0 Framework
Case Study- National Digital Health Blueprint (NDHB)
The National Health Policy (NHP) 2017 defined the vision of ‘health and wellbeing for all at all ages’. The
policy strongly advocated the concept of Continuum of Care. These lofty ideals are sought to be achieved
by refactoring the existing schemes and introducing several new schemes including some digital
initiatives. Citizen-centricity, quality of care, better access, universal health coverage, and inclusiveness
are some of the key principles on which the Policy is founded. This mammoth task requires that a holistic,
comprehensive and interoperable digital architecture is crafted and adopted by all the stakeholders. In
the absence of such architecture, the use of technology in the health sector continues to grow in an
uneven manner and in silos.
In the above context the need for creating a framework for the evolution of a National Digital Health Eco-
system was recognized. This has been realized by creating the National Digital Health Blueprint (NDHB),
which is more than an architectural document, as it provides specific guidance on its implementation as
well.
The Blueprint keeps the overall vision of NHP 2017 in perspective and recommends a pragmatic agenda to
start with, adopting the principle of ‘Think Big, Start Small, Scale Fast’. To this end, it has been designed
as a layered framework, with the Vision and a set of Principles at the core, surrounded by the other layers
relating to Digital Health Infrastructure, Digital Health Data Hubs, Building Blocks, Standards &
Regulations, and an Institutional Framework for its implementation. The document also contains a high-
level action plan.
Healthcare has always been central to all development efforts be it a national or global agenda.
Government of India envisages as its goal the attainment of the highest possible level of health and well-
being for all at all ages and intends to provide universal access to good quality health care services
without anyone having to face financial hardship as is enunciated in National Health Policy, 2017.
The most promising approach adopted by National Health Policy towards this goal is extensive
deployment of Digital Tools/Technology to enhance health system performance. Government is
committed to Universal Health Coverage for all citizens; to make healthcare affordable, accessible, and
equitable, and Digital Health technology has a huge potential for supporting Universal Health Coverage
(UHC).
Ministry of Health and Family Welfare (MoHFW) prioritized the utilization of Digital Health to ensure
effective “service delivery” and "citizen empowerment" so as to bring significant improvements in the
public healthcare delivery.
To improve efficiency in healthcare delivery, extend healthcare to rural areas and provide better quality
services at low cost, certain eHealth initiatives using ICT (Information and Communication Technologies)
were undertaken by MOHFW across the country with the following objectives.
76
InDEA 2.0 Framework
● To ensure availability of services on wider scale

● To address the human resource gap by efficient & optimum utilization of the human resources
existing in the health sector
● To provide healthcare services in remote & inaccessible areas through telemedicine
● To improve patient safety by access to medical records and help reduce healthcare cost
● To monitor geographically dispersed tasks for meaningful field level interactions through effective
use of MIS
● To help in evidence-based planning and decision making, and
● To improve efficiency in imparting training and in capacity building
The Objectives of NDHB are aligned to the Vision of NHP 2017 and the SDG’s relating to the health sector.
These include:
a. Establishing and managing the core digital health data and the infrastructure required for its
seamless exchange;
b. Promoting the adoption of open standards by all the actors in the National Digital Health Eco-
system, for developing several digital health systems that span across the sector from wellness to
disease management;
c. Creating a system of Personal Health Records, based on international standards, and easily
accessible to the citizens and to the service providers, based on citizen-consent;
d. Patient is the owner of his/her EHR and the health facilities and government entities maintain the
data under trust on behalf of patient. The collection as well as the end use of the data shall be
through a consent framework. The anonymized data can however be used for the research
purposes duly following the principles so defined. It is the responsibility of the health facility to
ensure privacy, security and confidentiality of the data.
e. Following the best principles of cooperative federalism while working with the States and Union
Territories for the realization of the Vision;
f. Promoting Health Data Analytics and Medical Research;
g. Enhancing the efficiency and effectiveness of Governance at all levels;
h. Ensuring Quality of Healthcare.
i. Leveraging the Information Systems already existing in the health sector.
Principles
An eco-system cannot be built – it must evolve. Given this, a set of Principles - rather than specifications -
were recommended to enable the evolution of National Digital Health Ecosystem. The key principles of
the Blueprint include, from the domain perspective, Universal Health Coverage, Inclusiveness, Security
and Privacy by Design, Education and Empowerment of the citizens, and from the technology perspective,
Building Blocks, Interoperability, a set of Registries as Single Sources of Truth, Open Standards, Open APIs
and above all, a minimalistic approach.
77
InDEA 2.0 Framework
Building Blocks
Building blocks are reusable frameworks or artefacts that most stakeholder groups need to rely upon for
designing, developing and delivering their services. The Blueprint identifies the Minimum Viable Set of
Building Blocks required for the health ecosystem to evolve and describes their capabilities at a high-
level. It is for the implementing organization, to arrange for the design, development and establishment
of the Building Blocks. Conformance to the NDHB Principles on one side and to the NDHB Standards &
Regulations on the other side, are critical for an efficient design and development of the Building Blocks.
Based on the study of the existing health systems, discussions with stakeholders and analysis, 35 key
Building Blocks have been identified across the 3-Level/4-layered architecture of NDHB. These have been
represented in the above Figure.
A few of the critical capabilities of heath ecosystem, addressed by appropriate combinations of the
Building Blocks, are explained briefly along with a schematic of the Blueprint:
1. Identification: Unique identification of Persons, Facilities, Diseases and Devices is a key

requirement and challenge as well. The Blueprint handles this requirement through 2 Building
Blocks, namely, Unique Health Identifier (UHID) in tandem with Health Locker. This is envisaged to
create and maintain Electronic Health Records and Personal Health Records.
InDEA 2.0 Framework
2. Citizen to be in Control: The need for maintaining the confidentiality, security and privacy of the
health records cannot be over-emphasized. These regulatory requirements are built into the
design, rather than being retrofitted. The Blueprint achieved these complex and mandatory
requirements through a combination of a few Building Blocks, namely, Consent Manager,
Anonymizer and Privacy Operations Centre. Besides these Building Blocks, application-specific
features and relevant International standards defined in the Blueprint fortify the privacy regime.
3. Service Access/ Delivery: Omni-channel access/ delivery are an important capability required in
NDHE. This is achieved by a combination of Web (India Health Portal), Mobile (MyHealth App)
and Call Centres besides Social Media Platforms. The Unified Communication Centre enables
real-time monitoring and real-time interventions needed in the health ecosystem.
4. Interoperability: The most important contribution of the Blueprint is its advocacy of

Interoperability, which is a pre-requisite for development of integrated digital health services and
continuum of care but also for the autonomous development of innovative value-added services
by entrepreneurs. Two Building Blocks, namely, the Health Information Exchange and the
National Health Informatics Standards enable and promote the interoperability of various
building blocks.
These building blocks are allocated under a high-level federated model with three levels of roles
delineated between Centre, State and Health Facilities. Except for the minimum data set needed at
Centre and State level the data shall primarily reside at health facility level.
The Application Layer of the Blueprint is merely a placeholder in so far as it identifies the thematic areas
for development and deployment of applications but refrains from listing them exhaustively. Such an
approach is adopted not only because of the large number and variety, but also because the applications
must evolve in an innovative way that cannot be defined upfront. Taking the legacy applications on board
to the NDHE requires that each application is rigorously assessed w.r.t it’s conformance to the standards,
using a set of criteria like that defined by the Digital Service Standard, notified by Ministry of Electronics
and Information Technology, GoI.
The value of the Blueprint can be realized mainly in terms of the impact the Digital Health Services make
on the various stakeholder groups. The Blueprint provides an illustrative, but by no means exhaustive list
of Digital Health Services, to indicate the nature of qualitative difference its implementation can make.
Needless to say that the portfolio of services must be validated and updated through a series of
consultations with the stakeholder groups.
Standards
The health sector must adopt the international standards in a large number of areas. However, The
Blueprint has adopted a pragmatic approach and recommended only the minimum viable set of
standards, to make it easier for the eco-system players to adopt the same. FHIR Release 4 (in a highly
condensed form), SNOMED CT and LOINC are among the standards recommended.
4. Future Roadmap/ Sustainability
A Blueprint is only as good as its implementation. An appropriate Implementation Framework is

suggested in the table below. The role and functions of the implementing organization have been
79
InDEA 2.0 Framework
recommended.
Year 1 Year 2 Year 3 Year 4 Year 5
(Planning & (Pre-requisite (Execution) (Analytics & (Sustenance &

stabilizing NDHM) infrastructure) Innovation) Research )
● Design and ● Designing and ● Establishing ● Implementation ● Ensuring

Development of establishing Health of Artificial Continuum of
Federated Unique Health Information Intelligence Care
Enterprise Identifier (UHID), Exchange enabled Clinical
Architecture, directories of (HIE) Decision
● Continued
adopting MeitY's health Support systems
Research
Agile IndEA professionals &
● Design,
Framework. health institutions
develop and ● Designing and
● Sustenance of
launch developing
Operations
● Design of Core ● Design and Common Health Analytics
Building Blocks implement Applications platform
and defining their federated health
standard cloud & secure
● Establish ● Design and
interfaces network
Health App develop
infrastructure.
Store Anonymization
● Assessment of methodology for
legacy systems for ● Enhancing of health data
● Design and
conformity with Legacy systems to analytics
implement
NDHB. conform to NDHB
Capacity
Principles, and
Building Plan ● Establish SOC,
interoperable
● Design and NOC and Privacy
notification of Operations
● Establish the
Health Security & ● Implementation of Centre (POC)
Repository of
Privacy Policies a plan for
Standards,
adoption of Health
API’s, ● Design and
Informatics
● Design and Metadata and notification of
Standards
development of Data Framework for
including
Consent Dictionaries Value-Added
Electronic Health
Management Services
Record (EHR) for
Framework
citizen with family
folders
80
InDEA 2.0 Framework
Annexure 4: Indicative list of Common and Reference Building Blocks at National /

Sate Level
# Service Description Available Software

1. Services Directory Directory of all G2C and G2B services India Portal
2. Collaborative Governance Collaborative engagement with the citizens MyGov
3. Grievance Management Central System for taking citizen grievances CGRAMS
related to citizens
4. Integrated ServiceHand-held access to all G2C services of the Umang
Management Government and citizen feedback
5. Single Sign On OAuth 2.0 DigiLocker
6. Integrated Call Center Emergency response center 112 Call Center
7. Document Management Electronic document management for DigiLocker
System (External) citizens with nomination facility
8. Email Gateway (External) Mass email messaging to citizens eSampark
9. SMS Gateway SMS to citizens mSeva
10. Payment Gateway Electronic payment address UPI, BHIM
11. eSign Electronic signature eSign
12. Messenger System Real time messaging Sandes
13. Linguistic Support Real time electronic translation and eBhaasha, NLTM
transliteration
14. API Gateway Electronic data exchange API Setu
15. Document Management Government document management eOffice
System (Internal)
16. Email Gateway (Internal) Government eMail @gov.in
17. Video Conference Audio and Video conferencing services VidyoConnect
18. SSO Access Management Electronic access for government officials eParichay
(Internal) (Authorization)
19. Service Delivery Real Time Tracking of G2C service delivery eTaal
Monitoring to citizens
20. Financial Management Public Financial Management System PFMS
21. Government Procurement Government eMarketplace for products GeM
and services
22. Court Management Manage all cases where Government is eCourts
System directly involved as one of the parties
23. Website Development Easy website development Swayam
24. Land Records Electronic Land Records Management BharatMaps, NCoG

25. Programming for Services Easy programming for service delivery ServicePlus
26. Collaborative SW Versioning management Open Forge
Development
27. Appstore Store-house of electronic applications eGov Appstore
28. Cloud Services Provide cloud services IAAS, PAAS MeghRaj
81
InDEA 2.0 Framework
Annexure 5 : Suggested curriculum for InDEA CB Courses and InDEA

Certificate Course
InDEA 2.0 Training Modules
For the GOVT Staff

a. Foundation Modules / Common Modules List of Topics and Relevance to
the Preferred Themes (Suggested 3 X 1 Hour Session + 2 X 1-hour Session Q & A/
Interactive) (For Administrative and Policy Strems)
Abstract: - The goal of this course module is to provide an overview and a general idea of digital
governance in the form of InDEA 2.0 - the overarching vision of Digital India Program. Digital
governance is often defined as the adoption and use of Information and Communication
Technologies (ICT), in particular the internet, to transform the relationship between government
and society in a positive manner. The major reform paradigm of digital governance is moving
towards an entrepreneurial approach synchronizing with the functional hierarchy of the
government. In case of InDEA 2.0, this transforms to entrepreneurial architectural approaches in
a Federated Hierarchy with Privacy in focus.
Learning Objectives
· Governance, People and technology
o The realm of Public Services
o People and Process
o Administration Management Governance and Services
o Digital Divide and closing the gap
o The Entrepreneurial approach
· Digital Governance – The fundamentals
o The scope and relevance of Digitization
o Sample Digitization – A practical example
o The scope and relevance of Technology
o Sample elements of Technology - A Practical example
o The concept of “Enterprise” and relevance to Governance
o Digital ID
· The road so-far and road ahead

· Success factors
· Precursors to InDEA 2.0 with a live example
· InDEA 2.0 and a sample scenario
b. Administrative Module (Suggested 3 X 1 Hour + 2 X 1 hour of Q&A/ Interactive)
82
InDEA 2.0 Framework
Abstract: - The goal of this course module is to provide background of generic thought process
and concepts that are crucial for InDEA2.0 laying the foundation for the importance of
administrative aspects of EA in hierarchical governance. The advanced aspects of technology are
introduced in a gentle way. The module wraps us with focus on significance of factors like
privacy performance etc. in InDEA2.0.
Learning Objectives
· Governance Services and Technology
o Digital Government Projects as Multidimensional Initiatives
o The idea of Federation in administration and governance
o The idea of autonomy and centralization
o Technology as an indispensable tool and an enabler
o The idea of Federation in technology adoption
o Functional and conceptual components of technology
o Administrative aspects of technology
o Ease of use and User experience
o Adoption and proliferation of technology
o SOE and Digitization
o Architectural aspects of a Digitalization SOE
o EA in other countries
· Fundamental Components
o Functional components
o Infrastructure components
o Gentle introduction to Data, information, UI, Dashboards
o Gentle Introduction to design architecture and components
o Gentle introduction to Backend and Front end and Middleware
o Gentle introduction to IT hardware and communication infrastructure
· Some success Factors

o Performance, quality, capability, usability and availability
· Privacy, AAA, security, provenance
c. Policy Module (Suggested 3 X 1 Hour Session + 2 X 1 Hour Session [Q&A/ Interactive])

Abstract: - The goal of this course module is to provide deeper insights of thought process and
concepts that are crucial for InDEA 2.0 laying the foundation for the importance of policies
related to technology. They are crucial enablers to the success of InDEA 2.0. The advanced
aspects of technology are introduced in a gentle way. The module wraps us with focus on
significance of factors like privacy, AAA, security, provenance performance, quality, capability,
usability and availability for the success of InDEA 2.0
Learning Objectives
· E-Governance, Digital governance and Enterprises
o Defining E-processes, E-administration, E-management and E-governance, E-Services
o Defining, managing Data and Information and their flows
o Defining E-Services, Autonomy
o Defining E-boundaries of sectors and interfaces
o Defining Functional, Technical architectures
o Architectural and Design Patterns of EA
83
InDEA 2.0 Framework
· Building Blocks of EA
o Definitions, Functions and Specifications
o Re-usable components
o Standards and SOA (State of Art)
o Approaches towards building “blocks”
o Types of Building Blocks
o Tools for EA.
· Policy and technology
o Technology aligned Policies of Vision, Capacity, Competency
o Technology aligned Policies for adoption and proliferation
o Technology aligned capability and performance model
o Scalability and Migration
o Federated architecture for technology proliferation in governance
o Infrastructure provisioning
o Sectorial interfaces and interoperability
o Business policies (purchase, service, contracts, development, maintenance etc.)
o IT Services/Resources as Commodities
o Technology and Vendor neutralism
o Services, Performance and Availability
o Open source approaches
o Emerging technologies and ease of their adoption
o PPP – GOI Policies
· Accommodating the Data Legislation/Laws
o Preserving privacy, AAA, non repudiation, security, provenance etc.
d. Technology Stream
(Two days [Suggested 3 X 1 Hour Session + 2 X 1.5-hour Session [Q & A/ Interactive] for
each day])
Abstract: - The goal of this course module is to provide complete heads up and deep insights in
to technology and trends for EA. The module wraps us with focus on infrastructure provisioning
for Enterprise Federated Architecture.
Learning Objectives
· Data and Technology Primer
o Introduction to Big Data
o Query Engines
o Storage Engines
o Analytics
o Ingestion and Orchestration
o Platforms (OS)
o DR DC
o Virtualization
· Big Data Frame works
o Hadoop, Apache Spark
o Infrastructure
o Clusters and Clouds
84
InDEA 2.0 Framework
o Compute and Storage

o Networking
· Security, Privacy, Availability, Performance (in Infrastructure Provisioning)
· Emerging Technologies
o AI IOT Block chain and Trends.
e. Case study and Discussion (3 X 1 Hours + Oral presentation QA and debate for each
group, wrap-up for each of the above modules) – Optional/Place Holder
Abstract: -The goal of this course module is to discuss significant roadmaps towards InDEA 2.0 by
comparing and contrasting with digital governance adoption in India and in other countries. A short
write up on EA, digitization experience would be provided to all members to work upon. Each of the
group (administrative / policy/technology) would be divided in to small teams and come up with
ideas and framework as they see. Each group would present their learnings followed by a debate
and QA.
For the Professionals

a. Foundation 1 – Common Module (1) List of Topics and Relevance to the
Preferred Themes
(One day (Suggested 3 X 1 Hour Session + 2 X 1.5-hour Session [Q & A/ Interactive])
Abstract: -The goal of this course module is to provide an overview and a general idea of digital
governance in the form of InDEA 2.0- the overarching vision of Digital India Program. This
module gives a heads up to both Architectural and Technology streams from the view point of
governance.
Learning objective
· Digital Governance
o The role of private enterprises and professionals
o Products and Services
o Participatory growth
o Digital ID, E-processes, E-administration, E-management and E-governance, E-
Services
o Data, information, UI, Dashboards
o The Backend and Front end and Middleware
o IT hardware and communication infrastructure
o IT Services/Resources as Commodities
o Technology and Vendor neutralism
o Open source approaches
o PPP – GOI Policies
· Building Blocks of EA
o Functions and Specifications
o Re-usable components
o Standards and SOA (State of Art)
o Approaches towards building “blocks”
85
InDEA 2.0 Framework
o Types of Building Blocks

o Design/Architecture and technology/infrastructure components
o Tools for EA.
· Program Management
o Design, deployment, Service, Performance and Availability Guarantees
· Data Legislation/Laws
o Privacy, AAA, non repudiation, security, provenance etc.
b. Architectural Stream
each day])
to EA models, tools and trends. The module wraps us with focus on components of EA
Learning Objectives
· Enterprise Architecture and Technology Trends
o Views, tools and languages
o Ontologies in EA
o Adopting the Technology layer
o Data, Information and Interfaces
· Security and Privacy by design
· Federated Approach
o Architecture, Data and Digital IDS
· Detailed exposure to India specific Models (and Development methodology)
o IndEA1, IndEA2
c. Technology Stream
each day])
to technology and trends for EA. The module wraps us with focus on infrastructure provisioning
for Enterprise Federated Architecture.
Learning Objectives
· Data and Technology Primer
o Introduction to Big Data
o Query Engines
o Storage Engines
o Analytics
o Ingestion and Orchestration
o Platforms (OS)
o DR DC
o Virtualization
· Big Data Frame works
o Hadoop, Apache Spark
86
InDEA 2.0 Framework
o Infrastructure
o Clusters and Clouds
o Compute and Storage
o Networking
· Security, Privacy, Availability, Performance (in Infrastructure Provisioning)
d. Foundation 2 – Common Module (2)

(Two days (Suggested 3 X 1 Hour Session + 2 X 1.5-hour Session [Q & A/ Interactive] for
each day)
to Case Studies of Aadhaar, GSTN, DIKSHA and NDHB implementation Case studies of Emerging
Technologies and their Program Management.
Learning Objectives
· Case studies of
o AADHAR, GSTN, DIKSHA, NDHB
§ Design, Architecture, Infrastructure
§ Early Challenges
§ Implementation and Adoption Success.
· Emerging Technologies
o AI IOT Block chain and Trends.
87
InDEA 2.0 Framework
88

InDEA 2 - 0 Report Draft V6 24 Jan 22 - Rev

Uploaded by

Copyright:

Available Formats

InDEA 2 - 0 Report Draft V6 24 Jan 22 - Rev

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

InDEA 2 - 0 Report Draft V6 24 Jan 22 - Rev

Uploaded by

Copyright:

Available Formats

InDEA 2.

Draft for consultation (Ver 1.0 Jan 22) 0

Ministry of Electronics & IT

Draft for consultation (Ver 1.0 Jan 22)

J Satyanarayana Ajay P Sawhney

Draft for consultation (Ver 1.0 Jan 22)

What is InDEA 2.0 ?

· InDEA is applicable more to ecosystems than to systems.

Draft for consultation (Ver 1.0 Jan 22)

InDEA 2.0 Principles

Building Blocks, the essence of InDEA 2.0

InDEA 2.0 Master Plan and Architecture Patterns

Draft for consultation (Ver 1.0 Jan 22)

Federated Digital Identities

Emerging trends in Open Digital Architecture

InDEA 2.0 Implementation Framework

From capacity building to competency building

Draft for consultation (Ver 1.0 Jan 22)

Draft for consultation (Ver 1.0 Jan 22)

COMMITTEE MEMBERS AND WORKING GROUP

Draft for consultation (Ver 1.0 Jan 22) 1

2.1.4 Open, Open and Open: ............................................................................................ 12

Federated Digital Identities ............................................................................................................ 27

7.6 Competency Maturity Model ................................................................................... 56

InDEA 2.0 – The WHAT & WHY

1. InDEA 2.0 – WHAT and WHY

1.1. Context of InDEA 2.0

India Enterprise Architecture or IndEA was notified as a standard framework of enterprise

MeitY constituted a Steering Committee to design an architectural framework for digital

1.2. WHAT is InDEA ?

A digital ecosystem is a distributed, adaptive, and open socio-technical system with

1.3. WHY InDEA 2.0?

InDEA 2.0 Value Proposition

Stakeholder Group Specific value proposition Basis of value

· Better architectures · Adoption of the principles

1.4. Intended Audience

1.5. Structure of InDEA 2.0

InDEA 2.0 Principles

2. InDEA 2.0 Principles

2.1 Ecosystem Principles

2.1.1 Ecosystem Thinking:

2.1.2 Building Block approach:

2.1.3 Open API-based:

2.1.4 Open, Open and Open:

· The Policy of GoI on Open-Source Software shall be followed in all developments

2.1.5 National Portability:

2.1.6 Participatory Design:

· Establish a set of robust rules of engagement for the ecosystem players.

· Establishing an ‘ecosystem sandbox’ can be good enabler of innovation.

Building Blocks – the essence of InDEA 2.0

Table 2.1 compares the 3 categories of building blocks.

Sl Attribute Core building block Common building Reference building

2 Object type Data or Middleware Application or Tool

2.2. Architecture Principles

· Build around the constructs of Single-Source-of-Truth and System-of-Records, both

· The principles of Federation, outlined in Annexure 2, shall be adopted.

· A consultative approach shall be adopted in designing the architecture, involving all

2.2.2. Agile Architecture: