Solution & Design Architecture

Transcription

1 Solution & Design Architecture

2 Agenda Key Requirements Independence to ULBs Workflow : Administrator Activities Solution To Address Key Requirements Flexibility in selection of services Application Usage Accounting Solution Architecture Diagram Security facility and Risks mitigation Facility of Audit Trail & Problem Detection Deployment Architecture Interface to external applications Helpdesk and SLA Monitoring URLs & Sub-domains Identification and Measurement of SLA Way forward Delivery of services in Offline Mode

3 Key Requirements Independence to ULBs to manage their data & environment ULB specific administrators to manage users & their access rights Implement dynamic workflow and by-laws Facility to accommodate ULB specific customization for dynamic business workflow, forms/reports, language Monitor, record & track different services related transactions for accounting purpose among ULBs Establishment of accountability & problem detection, the means by which changes to the information (inserts, updates and deletes) are recorded for 'audit' purposes Security features to protect information and control relevant accesses; i.e. capability to secure data using encryption, provide network and infrastructure security for reliable and transparent services

4 Key Requirements (contd ) Facility to accommodate external interfaces for GIS Payment Gateway Existing system in ULBS Selection from various applications available in the software solution for the services and sub-processes Designating specific domain names to individual ULBs (Urban Local Bodies); i.e. ULB specific identifiable name Identification & measurement of Service Level Agreements (SLAs) Continuation of service delivery during the time of crisis or disconnection from centralized network

5 Addressing Key Requirements

6 Independence to ULBs Administration for Multi-tenancy To provide independence to ULBs to manage their data & environment. State level administrator would create ULB administrator. ULB administrator to : Create and manage access and login rights of the ULB users. Handle ULB specific business logic and bye-laws in the application solution. The customizations specific to ULBs for dynamic business workflow, forms/reports, language, look and feel be taken care in the application solution. Manage contents of the application solution.

7 Workflow : Administrator Activities SLNA Administrator Features and Responsibilities: SLNA ADMINISTRATOR ACTIVITIES 1. Create customized workflows for each ULB MIS & REPORTING SLNA WORKFLOW MANAGEMENT ROLE DEFINITION UI REPOSITORY ULB PROCESS FLOW CUSTOMIZATION 2. Create roles that can be used by ULBs for their workflow 3. Be able to assign fine granularity tasks to roles, for greater flexibility 4. Should enforce system-behavior protocols- for e.g., load balancing etc. depending on time of the day. ULB Administrator Features and Responsibilities: 1. Be able to assign role(s) to employees according to the workflow for a process. ULB ADMINISTRATOR ACTIVITIES ROLE ASSIGNMENT DYNAMIC ROLE DELEGATION ULB WORKFLOW MANAGEMENT UI CUSTOMIZATION AND DYNAMIC FORM LIBRARY MIS & REPORTING 2. Allow Dynamic workflow management and dynamic farms. 3. Should be able to collapse or expand a workflow depending on the ULB s specific requirements

8 Flexibility in Selection of Service Scenario 1: Flexibility to ULBs to continue using existing applications by getting them integrated to the centralized application: i.e. if a ULB already has 2 applications and wants to continue using them along with centralized application solution for other services. Changes required to integrate existing application should be implemented in the centralized solution. Scenario 2: Flexibility to integrate new applications to centralized application to handle future needs: i.e. if a ULB has future requirements of more services, then existing centralized solution should be able to integrate these new applications to existing centralized application solution without impacting current services of application.

9 Application Usage (Transaction) Accounting Application would take care of accountings through a Transaction Accounting module for transactions done for services. Application would provide customized reports for MIS and Auditable reports. Reports provided by Transaction Accounting module would support & help in revenue/cost sharing model. During offline mode, the application should take care of transactions accounting. The online accounting should also be managed by the application.

10 Security Facility & Risks Mitigation Application solution should capture all aspects for reconciliation of risks to provide data security. Appropriate restrictions must be imposed to maintain ULB specific user level security and user specific conditional accesses. Application solution should provide sufficient network and infrastructure level security at the ULBs. Consideration for sufficient redundancy should be done to maintain recommended availability of the application.

11 Facility of Audit Trail & Problem Detection Application solution should be able to establish the accountability for data modification or deletion by maintaining audit trail logs and reports. Delivery of services to the citizens has to be maintained during the hour of crisis such as network failure or virus attack by tracking and resolving issues without negotiating with SLA.

12 Interface to External Applications Application solution to provide a gateway to have interface to external applications viz. Geographical Information System (GIS) for field surveys information and instant data, Payment gateways to enable online payment processing for secure, fast and traceable transactions, Interoperability to other existing applications

13 URLs & Sub-domains Each ULB may have a separate URL registered individually Would require dedicated front-end web server Separate URL id to be registered and customized ULB would require to establish and maintain components which would add to their ownership and expense. Common URL for state with provision for sub domains for ULBs Common URL is preferred solution at the state

14 Identification and Measurement of Service Level Agreements (SLA) Standard set to evaluate performance of the metrics and the processes executed through application solution. Service level agreements of the workflows in the application solution should be defined and escalated to the next level in case of breach of SLAs There should be deployment of SLA monitoring tool to establish a scrutiny on performance of service related transactions

15 Delivery of Services in Offline Mode SLNA/ULB need to identify the services which need to be provided in offline mode; (when connectivity to datacenter is not available, or the main server is down). For the services to be provided in offline mode, DPR should provide functionality of each service in offline mode. While providing services in offline mode, the risks should be clearly identified & the risk mitigation strategy should be clearly defined in DPR. Special care to be taken in case of transactions of financial nature.

16 Scalability and Future Provisioning It is envisaged that the same solution will be used for providing services in remaining ULBs of the State. Hardware sizing to be planned considering the Mission Cities in the State. Appropriate technologies to address software & hardware scalability (for remaining ULBs & seasonal peak loads) like virtualization, server farms, cloud computing, etc. should be evaluated and deployed.

17 Solution Architecture Diagram

18 Solution Architecture Diagram Separate presentation layer for all ULBs

19 Solution Architecture Diagram System administrators would be able to administer ULB specific components Multi tenancy

20 Solution Architecture Diagram Audit and reconciliation functionality

21 Solution Architecture Diagram System usage / Transaction accounting module providing MIS to support revenue / cost sharing System usage / Transaction accounting data repository

22 Solution Architecture Diagram Service-specific repository Would contain data about various ULBs (through association of data with ULB id)

23 Solution Architecture Diagram External Interfaces and Services

24 Deployment Architecture Suggestive deployment architecture would be centralized deployment architecture for e-municipality application. External users (citizens/business users) access non-restricted areas of application over internet. Internal users (Internal departmental) connected through SWAN (State Wide Area Network) and access the application over intranet. Other government agencies communicating between various emunicipality application may access the applications over SWAN.

25 Deployment Architecture (contd ) Existing Environment Security & networking infrastructure is available as part of hosting environment at state level. New Environment Application server, Database server & Storage facility to be made available by ASP as part of this project. Helpdesk facility to be made available by ASP as part of this project.

26 Deployment Architecture

27 Deployment Architecture Existing Environment New Environment To Be Hosted

28 Deployment Architecture (External Users)

29 Deployment Architecture (Internal Users)

30 Helpdesk and SLA Monitoring

31 Way Forward For Deployment State to identify Application Service Provider for procurement & installation of server side hardware & software Data ownership, its management and define the SLA (Service Level Agreement) with various ULBs and Applications Service Provider Roll out strategy in the number of ULBs Need & use of Support/ Help Desk for software application and other related infrastructure components ULB to provide Detail about the applications that are currently being used for providing services, particularly if any of them is a part of the new state solution Schema, database design that is being currently used to ASP (Application Service Provider) Details on how the existing networking components can be re-used or integrated with the new setup Details of the number of physical locations, departments / offices, users in the department, existing delivery channels like Citizen Facilitation Centers (CFC), SWAN, SDC etc

32 Way Forward State to identify : Users/Stakeholders of the application Various Access Channels Last mile connectivity Data center for server farms and hosting application External applications/interfaces Deployment System & Data Security Requirements Functional requirements of the applications ULB to provide : ULB specific customization requirements Details about existing applications Access rights requirements ULB specific By-laws

33 Q&A

34 Thank You