Overview
Last updated
Last updated
DRISIT Architecture has been influenced by thinking of Digital Public Infrastructure (DPI) and Digital Public Good (DPG). In simple terms, think DPI as a digital infrastructure which can provide the required building blocks to create a digital good that will solve socio-enonomic problems of the public, at national scale. At the core of it a DPI is crafted keeping in mind a few core principles - interoperability, minimalist core building blocks, ecosystem innovation, decentralized and secure by design.
A DPG is open software, open standards, open data and helps build DPI. A DPI should have open specifications and should allow for both public and private participation to build innovative solutions on top of it.
Another concept that this architecture uses extensively is that of registries. While a detailed architectural discussion can be found here, in simple terms think of registry as
A data storage which stored verified data
Which has Open APIs for others to access signed data
Which has security and consent based access provisions to secure the data access
The DRISTI architecture imbibes these principles and has the following at its foundation.
At the very base are the foundational or core services that include
Core Platform Services: The underlying core platform and its services that provide the foundation for DRISTI. We have selected the Digital Infrastructure for Governance and Inclusive Transformation (DIGIT) platform as the base platform on which to build DRISTI as DIGIT is a proven open-source, scalable, interoperable platform for responsive public service delivery and good governance. Some examples of core services are - authentication, authorization, audit, ID generation, encryption, storage etc.
Core/National Registries: These are registries as required for a dispute resolution system. These will be responsible to hold the key data and also provide the required data exchange using standard formats and also consent based architecture. Because data in a registry is expected to be verified and no random data makes its way to the registry, each registry will have ownership, who will be responsible for maintaining the correctness of data within the registry and relevant access rights. Some examples of such registries are - Individual, Advocate, Case/Dispute, Judge etc.
Core/National Master Data: Any platform/application always has a need for some master data, a data that is core, persistent data entities that are essential for its operations and are generally shared across various processes or modules within the application. Some examples of such data will be - state list, case types, application types, order types etc.
Next in the architecture is the platform specific services and registries etc. These call into the core services or registries and create the relevant domain layer on top of the core platform. This layer is very specific to the domain, in this case it being a legal system dealing with a case management system.
Platform Services: Similar to the core services, these are services that are specific to the application/portal being developed and bring in the relevant domain flavor. Some examples of platform services are - case, applications, e-filing, scheduling, transcript, order etc.
Regional Registries: These are platform or regional registries that can be very specific to each tenant/region. A tenant/region is a security boundary, where direct data access/sharing across tenants is typically prohibited. Some examples of such registries are - case, order, hearing, application, workflows etc.
Regional Master Data: Similar to the common master data, there will be master data that will be region/tenant specific and may change as one moves from one region to another. One can think of localized data (language specific) as part of this, along with any other data. Some examples are - statutes and sections specific to region, district details, court details etc.
Integration Services: Any platform/application also has a need to integrate with third party applications to fulfill the required functionality. These integrations help reuse features/functionality already built and tested and minimize the features one has to build, which may not be core to the application. Some examples are - ePost for summons delivery, CCTNS, SMS providers, Email providers, Payment gateway etc.
Finally, right at the top will be the following
Front end services: These provide various visual interfaces to the application and are the ways the community/masses will access the system. Some examples are - web, mobile, chatbot etc.
Dashboards: These provide access to the relevant KPIs or metrics from the system. These are the analytics/reporting arm of the system. Same examples are - metrics on # cases, types of cases, case statuses, across states, courts, etc.
Ecosystem players: While these are also integrations, but the key difference is that in the previous layer, the integrations where from DRIST to the other system to get some functionality of DRIST addressed, which ecosystem players are those who are access DRISTI system, mostly the data, to create their own applications and services for the community. This is the place where most ecosystem innovations start to happen and are critical to open up and provide various kinds of access to the case/dispute data in this case.