Service Oriented Architecture (SOA) Recommendation for ...

916 views

Published on

  • Be the first to comment

Service Oriented Architecture (SOA) Recommendation for ...

  1. 1. ‘To-Be’ & Functional Requirement Specification Report `1 State Mission Mode Project, Uttar Pradesh Department of Information Technology Government of India Department of Information Technology 29 November 2007 Dep
  2. 2. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. TABLE OF CONTENTS Executive summary…………………………………………………………………………………………….3 I Critical Elements – To-Be Process Design………………………………………………………5 II Suggested Enterprise Architecture using SoA approach………………………………6 III Service Components – To-Be Process & FRS………………………………………………24 • Information Dissemination • Form Availability • Application Receipt • Payment • Verification • Rejection • Approval • Delivery/ Collection • Status • Monitoring • Workflow o Certificate o Public Distribution System (PDS) o Revenue Court o Grievance IV Next Deliverable…………………………………………………………………………………………118 Annexure 1. Legends of Cross Functional Process Map 2
  3. 3. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Executive Summary The business process re-engineering requirements report was submitted to the state government on November 23, 2007. Based on the framework in the report, TO Be Process Maps and the Functional Requirements Specifications for four service categories viz. Revenue Court Services, Certificate, Grievance Redressal and Public Distribution System have been prepared. This would form the base document for the implementation partner to work for development of the application. A overview of the technology architecture has been presented that the proposed application would be built upon. It about various technology layers of the application that the user would interact while accessing the database. The standard technical specifications of the components that serve as the building block of the architecture have been provided. During the preparation of application architecture standards specified in the e District guidelines have been strictly adhered. The proposed service flows have been explained with the help of TO BE process maps. These process maps capture the roles of various stakeholders as well as the flow of information and documents from one level to another. It also explains how the different components interact with the system for delivering the requested service in a timely and an efficient manner. A set of 11 components which were specified in the BPR report have been used to facilitate the service delivery. The components are linked with the ‘To-Be’ processes so as to provide a consolidated delivery of the services under the e-District Project. The streamlining of the front end, channels of delivery, service components and ‘To-Be’ process will provide comprehensive service delivery mechanism for better delivery of services to the citizen / customer. Further, it will improve 3
  4. 4. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. upon the internal efficiency of the delivery (departmental) and at the same time will aid and assist in monitoring and reporting of the services. The proposed Functional Requirements Specifications (FRS) in this document deals with the application’s intended capabilities and interactions with the users. The proposed FRS also mentions the functional aspects that the application needs to have to support the various requests that the users might require from the system. The FRS takes into account the various scenarios that the application might have to face during service request reprisal and also it specifies how the system will integrate with the various components specified in the BPR report. The report has been structured in way to cover the architectural framework to support the e district application, and then it explains the service components which serve as the building block for defining the To Be processes. The To Be processes thus helps to identify the various processes that would be re engineered using the components. The various To Be services will then help to specify the functional requirement that would go into the application development. The To be and FRS report would be prepared in two sections, in the first part it would cover a total of 4 service categories and the remaining 6 services would be covered in the consolidated report that would be submitted on December 12, 2007. 4
  5. 5. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Critical Elements – To-Be Process This report primarily aims at providing the To-Be Process maps for the selected services and highlighting the major processes improvements undertaken by using the accepted solutions as mentioned in the BPR report. The ‘To-Be’ Processes are based on generic solutions as proposed in the BPR report. A mention of the same is being provided for general understanding of the reader as these solutions are used for developing the process maps for all the identified services – 1. Use of security feature of login ID and password 2. Use of biometric authentication mechanism as additional security measure 3. Use of online form for making service request 4. Use of digital signature for highly securing approval, rejection and transfer of documents 5. Use of website as a tool for verification of output against service request 6. Use of application databases as defined in the services 7. Use of unique ID schema like document ID, CSC ID, etc as per requirement of the service 5
  6. 6. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Part I Suggested Enterprise Architecture for UP e-district 6
  7. 7. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Enterprise Architecture Recommendation for UP e- District Service Oriented Architecture (SOA) Recommendation for Overall Architecture Architecture is preferred to be ‘Service based architecture’. The granularity of web services is to be determined by the level of interaction in each of the processes as defined. This architecture is intended for use during the creation of a technical SOA road map for UP e-District. It helps in identifying the gaps in the current environment and the target SOA-based infrastructure. The architecture serves as a good reference for the projects that require development of reusable SOA frameworks. Mapping the logical architectural layers to a product matrix will assist in determining the SOA-related products required for use in projects. In order to ensure that the information is correct, current, and securely accessed, a publish/subscribe architecture is envisaged for eDistrict. This will permit Publishers to securely make available well defined web services and message based services by way of a Service Oriented Architecture (SOA) mechanism which can also be orchestrated and customized by the publisher. Loosely – coupled: It is highly recommended that the proposed solution for UP e-District ensures that the Publishers are loosely coupled to subscribers, and 7
  8. 8. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. need not even know of their existence. With the topic being the focus, publishers and subscribers are allowed to remain ignorant of system topology. Each can continue to operate normally regardless of the other. Scalability: It is also recommended to use the Publisher/Subscriber provides the opportunity for better scalability/granularity than traditional client-server, through parallel operation, message cashing, and tree-based routing. Brower-Based Solution: The proposed solution MUST be a browser-based solution. The proposed system is envisaged to have an architecture consisting of typically, the following layers (or substantially equivalent) layers in order to cater for the desired business functions stated in this document. For explanatory purposes, explanations of the layers of non SOA & SOA are given below: Non-SOA-specific layers: Existing layers UP e-District's IT infrastructure has systems built in various architectures and methodologies. The systems are Web-based, desktop-based, pure backend systems, or any other kind of application. The entire exiting system infrastructure can be broadly classified into three tiers: data tier, business tier and presentation tier. Enterprise data layer: Data tier The enterprise data layer is the enterprise's datastore. All data requirements for successful business operations are part of this logical layer. The data includes database information, file systems, hierarchical directories, legacy storage systems and all other storage media. This layer is the data tier of the traditional N-tier architecture. The data layer of the application provides clustering capabilities for failover and high availability at data center. The data stored in the database server can be retrieved as an XML document and the application can communicate this information with any system following open standards. The UP e-District applications shall be hosted at the e-District Data Centre. It will be accessed by CSCs via the internet. 8
  9. 9. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. The solution at the Citizen Service Center should have the capability to work in both online as well as offline mode ensuring that citizens can continue with their transactions irrespective of the connectivity with the datacenter or the connectivity of the datacenter with the departmental server Enterprise business layer: Business tier The enterprise business layer consists of the business applications (and logic) that exist in the enterprise. It includes applications (and logic) developed using .Net, Java Enterprise Edition, and various other technologies. The logic in stored procedures is also part of this layer. In short, this layer is the enterprise's existing business backbone and the traditional N-tier architecture's business tier. The Business Logic of the UP e-District application will be processed by the Application Server and Integration server deployed at the Datacenter. The application server processes the transactions submitted by the operators of the centers and appropriately updates the relevant department databases. Enterprise front-end apps/channels: Presentation tier All business front-end applications and channels are part of this third layer, including the entire desktop and Web-based front ends that work with the enterprise backbone. The business channels include external business-to- business interface systems like dealer access systems and address verification systems. This layer constitutes the presentation tier of traditional N-tier architectures. Due to an increasing convergence of standards, such as Web Services for Remote Portlets Version 2.0 and other technologies, that seek to leverage Web services at the application interface or presentation level is now being considered to be within the scope of SOA. It is also important to note that SOA decouples the user interface from the components, and that you ultimately need to provide an end-to-end solution from an access channel to a service or composition of services. 9
  10. 10. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. SOA-specific layers: Existing layers Operational systems layer. This consists of existing custom built applications, otherwise called legacy systems, packaged applications, and older object- oriented system implementations, as well as business intelligence applications. The composite layered architecture of an SOA can leverage existing systems and integrate them using service-oriented integration techniques. Enterprise components layer. This is the layer of enterprise components that are responsible for realizing functionality and maintaining the Quality of Service (QoS) of the exposed services. These special components are a managed, governed set of enterprise assets that are funded at the enterprise or the business unit level. As enterprise-scale assets, they are responsible for ensuring conformance to Service Level Agreements (SLAs) through the application of architectural best practices. This layer typically uses container- based technologies such as application servers to implement the components, workload management, high-availability, and load balancing. Services layer. The services the business chooses to fund and expose reside in this layer. They can be discovered or be statically bound and then invoked, or possibly, choreographed into a composite service. This service exposure layer also provides for the mechanism to take enterprise scale components, business unit specific components, and in some cases, project-specific components, and externalizes a subset of their interfaces in the form of service descriptions. Thus, the enterprise components provide service realization at runtime using the functionality provided by their interfaces. The interfaces get exported out as service descriptions in this layer, where they are exposed for use. They can exist in isolation or as a composite service. Business process composition or choreography layer. Compositions and choreographies of services exposed in Layer 3 are defined in this layer. Services are bundled into a flow through orchestration or choreography, and thus act together as a single application. These applications support specific use cases 10
  11. 11. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. and business processes. Here, visual flow composition tools can be used for the design of application flow. Integration (ESB) Layer: This layer enables the integration of services through the introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, often described as the Enterprise Service Bus (ESB). Web Services Description Language (WSDL) specifies a binding, which implies a location where the service is provided. On the other hand, an ESB provides a location independent mechanism for integration. QoS Layer: This layer provides the capabilities required to monitor, manage, and maintain QoS such as security, performance, and availability. This is a background process through sense-and-respond mechanisms and tools that monitor the health of SOA applications, including the all important standards implementations of WS-Management and other relevant protocols and standards that implement quality of service for a SOA. Recommended Framework for SOA We proposed UP e-District project team to carry out TOGAF (The Open Group Architecture Forum) approach which provides a valid framework for SOA. Using the ADM (Architecture Development Method) approach, SOA can be implemented. For the clarification, we are listing down all the phases of ADM: 11
  12. 12. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. The eight iterative phases are as follows. Architecture Vision: Creating a summary of the architecture and what it should achieve, for communication throughout the enterprise (and to obtain approval and funding). The Architecture Vision phase will set out the scope of the SOA project within the enterprise, and the level of SOA to be achieved. Business Architecture: describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on business principles, business goals, and strategic drivers. The Business Architecture phase of an SOA project may, as well as describing specific business operations, describe methods for developing new ones. 12
  13. 13. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. The scope of Business Architecture is as follows: Information Systems Architectures, comprising: Data Architecture: defining the major types and sources of data necessary to support the business. The Data Architecture part of the Information Systems Architectures phase is concerned with the Business Information component. Applications Architecture: defining the major kinds of application system necessary to process the data and support the business. The Applications Architecture part of the Information Systems Architectures phase is concerned with the Software Services component. When TOGAF is used to develop solution architecture, this phase may identify specific application components; but when it is used to develop a high-level enterprise architecture it will often just describe general application areas. Technology Architecture: delivering a specification of the technical solution at the level necessary to support implementation. Like the Information Systems Architectures phase, the Technology Architecture phase 13
  14. 14. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. must also consider how the new services will interwork with existing applications that will not be converted to services. Opportunities and Solutions: generating an overall implementation and migration strategy by evaluating implementation options, identifying parameters for change, and assessing dependencies, costs, and benefits. Migration Planning: sorting the various implementation projects into priority order and creating a detailed Implementation Plan and Migration Plan. Implementation Governance: developing and operating a process to ensure conformance with the defined architecture by implementation projects. SOA Governance is the application of Enterprise Architecture, IT, and Corporate Governance to Service Oriented Architecture.3 The SOA Governance processes focus on governing the service lifecycle, supporting service infrastructure, and compliance with the service oriented architecture of the organization With SOA, it is generally the case that each part of the enterprise depends on services provided by other parts. This helps to improve the overall efficiency of the enterprise, and allows for greater service re-use, and should therefore be encouraged. But it means that good governance is essential, so that the service users are assured that service provision will be maintained in the manner that they expect. Architecture Change Management: establishing a process for the evolution of the new enterprise architecture in the light of developments in technology and changes in the business environment. Modification of the architecture itself is addressed in the Architecture Change Management phase. SOA delivers agility. Changes to services and development of new services should no longer be regarded as changes to an architecture, when they are carried out using methods that are part of that 14
  15. 15. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. architecture. Projects that in a traditional architectural approach would be subject to Architecture Change Management may therefore be covered by Implementation Governance in SOA. Best Practices & Considerations for implementing SOA This section attempts to provide a set of concrete practices and considerations for implementing Service Oriented Architecture. These are some of the key areas in which practices need to be considered as part of typical strategic SOA planning efforts: Service Monitoring These are few points we can considers: • Availability a. The active availability of a service is generally defined within its accompanying service level agreement (SLA). Common availability considerations and guarantees include: i. When will the service be active and available? ii. Will all dependencies for this service also be available during the service's scheduled availability? • Logging a. The supporting service infrastructure should store (log) data about each service's access and usage patterns. This data is useful for troubleshooting, monitoring, and security control. Formal review processes may need to be in place to ensure that logs are routinely checked. This is especially important to raise awareness of certain usage trends that may indicate a need for infrastructure changes (usually associated with scalability and security measures). • Auditing a. Auditing is the analysis and reporting of logged information. The data collected at this stage should answer questions such as: i. How exactly is a service being used? ii. Who is using the service? 15
  16. 16. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. iii. What do the common request and response messages look like? (In other words, what are the most typical content exchange scenarios?) b. In addition to better understanding how a service is being used, these reports will also highlight the capabilities of the service not being utilized. • Performance Metrics a. Performance metrics and statistics for each Web service are kept so that services can be monitored to avoid potential runtime issues, such as performance bottlenecks and fault counts. It is frequently required (and recommended) that automated notification mechanisms be attached to collected statistics so that action can be taken well before an infrastructure's limitations are tested. • Debugging and Tracing a. The ability to optimize and track service activity during development and after deployment is important, especially for maintenance purposes. This focuses more on the service hosting platform's ability to provide front-end tools that allow for targeted investigation of specific activities (or sub-activities) as opposed to common general reporting features. • Synthetic (Dummy) Transactions a. The ability to utilize of synthetic (dummy) transactions is helpful to simulate service usage scenarios during development, testing, and debugging phases. Synthetic transaction modules can be configured to send periodic service requests according to pre- defined settings. Service Delivery • Methodology a. A methodology practice (such as Thomas Erl's mainstream SOA methodology) defines how a service is moved through lifecycle stages and also establishes any new phases required specifically in 16
  17. 17. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. support of SOA. In addition to shaping service logic in preparation for implementation, these formal approaches also need to provide governance processes in support of post-implementation management and evolution. • Standardized Service delivery Lifecycles a. Requirements gathering, business analysis, service modeling, design, and other delivery lifecycle phases need to be aligned with the service-orientation paradigm. This does not necessarily supersede object-oriented approaches, but the service implementation (and especially its contract) must reflect the design characteristics required to achieve the strategic goals behind service-oriented computing Service Directory • Awareness and Discovery a. The service consumer must have knowledge of the existence of the service provider and the location of its contract. This awareness increases the overall reuse potential within an enterprise. UDDI exposes the required meta information in an industry standard manner. (Note that awareness alone does not enable a service consumer to invoke a service.) • Publish Process a. Once a Web service is implemented, it will need to be registered in a local service directory or registry. Formal processes need to be in place to ensure that the registration and the documentation of associated metadata are performed in a consistent manner. • Subscription a. It is ideal to allow service consumer owners to subscribe to service directory records. If changes to the service contract are added or should there be outages or other events associated with the implemented service (such as a change to billing rates), consumer program owners can then be easily notified. 17
  18. 18. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. • Service Owner Contact Information a. Service consumer owners or designers of potential service consumer programs should have the ability to contact the owner or custodian of a service for questions and recommendations. Especially in larger organizations, it is best if this contact information is published alongside the service directory records. • Documentation a. The service registry should contain documentation to help owners of potential service consumers better interpret the service's capabilities. This information may exist in separately published documents or as annotations to the technical service contracts. • Rating a. It can be beneficial for quality assurance purposes to allow service consumer owners to rate services and provide feedback. Typically, ratings are in response to guarantees and promises made in an SLA as measured against a service's actual runtime performance. Service Level Agreements • Quality a. A dedicated practice is often needed to ensure that a service provider continually meets the quality contract promised to its consumers. Carrying out this practice may require a separate "quality assuror" and "quality broker" role. • Billing a. Whether a service is consumed within an enterprise or outside of the organization, a billing structure is often required to guarantee that the service owner (a department or the organization itself) is compensated. Usually, billing is based on a licensing agreement that ties into a per consumer or even a per usage payment model. • Configuration Management a. As each service is promoted through various environments it needs to be configured and tested. As the number of services increase, 18
  19. 19. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. managing the overall configuration management effort can be complex and will likely require formal processes. Configuration management of services can be much more challenging than traditional efforts. Therefore, new practices will likely need to be developed and configuration management implications may need to be expressed in the SLA. Exception Management • Error Trapping a. Runtime errors need to be recorded and reported as efficiently as possible. For example, the recorded response times and any logged timeouts need to be monitored to ensure that the service is kept inline with corresponding SLA requirements. • Root Cause Analysis a. It has become widely accepted that SOAP faults are not that useful. An SOA infrastructure needs to be able to drill down into the real reasons as to why a service is failing. Often this reveals issues such as code faults and hardware failure. With the right tools, a true root cause analysis (one that goes beyond just the vendor runtime) can be completed. • Notification Services a. A services infrastructure should be able to send out notifications when specific events are triggered. This notification mechanism needs to be configurable so that it can apply to individuals and broadcast groups. Version Management • Data Contracts a. Web services exchange data using pre-defined data models based on XML Schema. Changes to a published schema can therefore break the data contract and jeopardize all existing service consumers. If data contracts do need to be changed, a separate 19
  20. 20. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. version control practice may need to be in place. This is primarily in consideration of the fact that an XML data representation architecture will often need to be maintained and evolved separately from the service layers that utilize its schemas. • Messaging and Operation Contracts a. Service consumers are tightly coupled to the service provider through the service interface. However, extending a service contract without affecting existing service consumers may still be possible. A formal process is recommended even when just adding operations to an established WSDL definition. • Service Endpoint a. The service consumer is tied to the service endpoint (address). If the address of the service changes all active service consumers will be compromised. Therefore, a separate endpoint or address management practice may be required. • Policies a. Given the absence of an industry-wide policy expression language (cross-vendor implementations of WS-Policy still seem a distant reality), documenting and attaching policies to the technical service contract in a standardized manner can prove difficult. A common approach is to define policies as part of the accompanying SLA. Though the policies may be required, the SLA can often just request that service consumers adhere to policy rules. The enforcement of this practice sometimes requires that the service consumer owner sign a contract (or the SLA document) guaranteeing that all policies will be honored. • Internal Dependencies a. A service may be implemented using numerous proprietary components, databases, and other system resources. Changes to these underlying dependencies can raise all kinds of runtime exceptions. Therefore, internal practices may be required to ensure the integrity of each individual service-level technology architecture. 20
  21. 21. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. • Security Claims a. The service provider may be secured using a common identity technology, such as active directory roles and users. Any security changes in the infrastructure can also impact all consumers of a service. Changes to established security management processes and practices therefore become important considerations and may require formal reviews by committees. • Service Retirement a. Services do not live forever. When services are deprecated, service consumer owners must be notified in time to adapt their environments. Often this may require a graceful expiry period during which both old and new versions of a service contract co- exist for a pre-determined amount of time (sometimes this period can extend up to six months). • Dependency Analysis a. Service consumers can be classified as "known" and "unknown" consumers. Keeping a list of all the consumers associated with each service can simplify some versioning issues by allowing for organized notification. Policy and Security Considerations • Identity Store a. An identity store is a repository of users, their credentials and preferences. In order to access a secure service the service consumer must be validated against these identities. Various options exist for implementing an identity store including Active Directory or even a regular database. Ideally, an identity store is a standardized and centralized part of the overall infrastructure. Practices need to be in place to ensure it is consistently used and maintained. • Authentication and Authorization 21
  22. 22. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. a. The ability to verify the identity and permissions of service consumers raises a number of considerations, including how security claims from service consumers are validated and processed. • Exchange Policies and Contracts a. This practice should address how policies and contracts are exchanged between a service provider, its consumers, and the owners of its consumers. • Internet Security a. The issues associated with securing Internet firewalls and Internet facing servers and ports are amplified when moving toward a technology environment consisting of a combination of internal and external Web services. Practices need to be in place to ensure that acceptable measures of security are always maintained, but also to provide a level of adaptability in response to unforeseen external access requirements that may be raised by newly published services. • Usage Control and Metering a. Understanding the usage of a service may be important for a number of reasons. For example, we may need to bill the service consumer on a per usage basis or we may want to study service usage and load patterns. • Transport Security a. Here we deal with how Web services traffic is secured on the wire. Of course this usually involves the positioning of SSL, but several WS-* specifications can also enter the discussion. • Load Balancing a. Services with heavy or unpredictable volume loads often need to be dynamically load balanced across multiple servers. Various types of load balancing algorithms exist and services should be assessed individually to ensure that the most appropriate type of load balancing is always chosen. Sometimes, based on increased reuse or re-composition, services need to have their load 22
  23. 23. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. balancing algorithms "upgraded" in response to new usage demands. • Geo Clustering a. This consideration addresses issues that can arise from the physical proximity of clustered services within an enterprise. For example, service consumers may need to bind to services that are geographically closest to minimize server hops and latency issues. • Web Service Interoperability a. While Web services are designed to interoperate, enforcing WS-I Basic Profiles is often the only way to guarantee interoperability, especially across disparate platforms and organizational boundaries. When building services with some of the new WS-* technologies and especially within vendor-diverse enterprises, extensions or custom variations of the WS-I Basic Profiles may need to be created (although their usage will likely be limited to internal, controlled environments). 23
  24. 24. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Part II ‘To-Be’ Process & Functional Requirement Specification 24
  25. 25. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Information The information component is envisaged for handling the dissemination of information only since the lack of information was found to be a key impediment in availing of services on time and with minimum effort. It has been observed that lack of information regarding the processes and the supporting documents that needed to be submitted along with the application are two of the prime factors stalling the submission of application. Similarly, lack of awareness about the defined service levels among the citizens results in no appropriate action being initiated even in case of deviation. 25
  26. 26. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Information Dissemination Prepare a document on Send the document to Department changes to present local NIC DIO, and District schemes or declaration of Information Officer new schemes or rules NIC DIO Updates the information Receives the document on e-District Portal as per with required updates the document District Information Officer Ensures dissemination of Receives the document information through various with required updates channels like Wall Paintings, Hoardings newspapers etc . Figure 0-1 26
  27. 27. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Functional Requirements A. Information Dissemination Component S. No. Functional Requirement Specification 1 E district Application is the application meant for maintaining all the transactions related to e district services. The Information Dissemination Component of the e District component deals with providing information of all the services, schemes, benefits, process and mechanisms followed by the departments in lieu of a particular service 2 Should allow only the NIC / Department officials to update information obtained from the departments 3 Should provide information on the following topics to the user: • Scheme Name • Eligibility Criteria • Nodes of obtaining service • Application Fees • Grievance filing process • Authorities to contact • Forms and documents required • Other modes of obtaining detailed info 4 Should be able to add new components beside the above 5 Should be accessible to citizens, department officials, other government officials 6 Should update information only after digital signatures of the relevant authority have been put on the document 7 Should have a ticker at the bottom of the page to record the number of people hitting the website, this would prove beneficial in capturing the usefulness of information 8 NIC should update the information within 2 days of receiving it from the relevant authorities, if this system is not followed an auto generated escalation grievance from the department should be fired to DM. 27
  28. 28. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Forms availability Service inputs are accumulated with the aid of various Forms. Forms could be in physical or non-physical format. Forms in both formats consist of various fields of required information, which would be the basis for any process to be initiated. In physical format, form availability becomes an important consideration as this can depend on a variety of external factors. Lack of availability of forms would impede the process. Non-physical or electronic forms would address the lack of availability issue and would standardize the fields using a system approach. Form availability would ensure that the services can be accessed. Forms once available with the appropriate fields will not only form the basis for accessing any particular service, but would also be used in creating an incremental database. The purpose of the element as envisaged in the proposed BPR framework has been listed below – 1. To make available the relevant form available for making service request for the selected services 2. To standardize the format for the form pertaining to selected services 28
  29. 29. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Application Form Availability Obtains paper based Fills the paper based Applicant form from Dept Office / application form and CSC / e district portal / submits it at the e Open Market district centre CSC / Govt. e district centre Requests for Fills in the details Receives paper based department page at Selects application provided by the form the applicant the e district form section applicant in the paper application form online E-District Application Returns requested Return application Registers applicant page form section details online 29
  30. 30. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Functional Requirements B. Application Form Availability S.No Functional Requirement Specification The system should store all the service request form at predefined 1 location for the selected services The system should be able to retrieve service request form from the 2 predefined location The system should allow for service request form to be easily 3 downloadable both through HTML and word format The system should provide for printable version of the service request 4 form The system should give an error message in case it is not able to retrieve 5 the application from the given location The system should have a provision for uploading new version of the forms 6 as and when it is required to change the version The system should maintain the version control for the service request 7 form The system should have a security feature embedded for changing the 8 version of the form and should allow only predefined process owners to change the form version The system should maintain log for all version change with the details of 9 the process owner making version change The system should not allow to change the content of the form and should 10 be in read only version The system should be able to make available service request form should be through 11 • Online / website • CSC 12 The system should allow for easy searching of the service request form The system should allow for easy and user friendly layout for locating the 13 service request form The system should be able to export forms in multiple formats so as to 14 ensure compatibility of forms The system should have a life counter feature to keep track of number of 15 forms being downloaded from the application 30
  31. 31. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Application receipt This Component will handle submission of the application. As the component exits operation, an acknowledgement would be generated for the applicant containing a unique reference ID for status tracking, date of application, department responsible, date of delivery, information about delivery channels, service fee receipt etc. The receipt also helps the applicant to track the status of the application with the help of the unique registration number provided with the receipt besides enabling the system to uniquely identify each and every application along with the candidate. According to BPR framework this receipt would be automatically generated by the system thus minimizing the duplication of effort and redundancy in the process. 31
  32. 32. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Application receipt Application e-District Registers the request Loads the online and sends it to selected application form authority and generates a receipt CSC / Suvidha Schedules the Receives the Takes out a printout Signs the form Issues a copy of Operator Hardcopy for Center request and opens Fills up the of the completed using his digital submitted logs into the daily dispatch the relevant online form for application form, and signature, and application along e-District to Tehsil or departments the request asks the applicant to submits it to the e- with a receipt to Application BDO. application verify the details District application the applicant Proves his Signs or Puts the Identity Thumb impression on Receives a Start No If all details the hard copy and copy of using Biometrics correct gives it back to application and operator along with a receipt Application required fees Travels to the Submits his CSC / Suvidha request to the center. Operator 32
  33. 33. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. C. Application Receipt S.No Functional Requirement Specification 1 If the citizen is submitting an application for the first time, then the CSC operator should be able to use the e-District Application (eDA) to register his details, which include generating his Unique ID, Name, Address, Age, Photo, and Biometric Identity and save these into the Citizen Database 2 The citizen should be able to establish his or her identity to the CSC operator using his Unique ID and biometric details. 3 The CSC Operator should be able to retrieve and load the online application forms of departments registered with the system, specific to the request. 4 The eDA should assign an Application Number to each form loaded and also embed the CSC Operator’s login details onto the form performa. 5 The CSC Operator should be able to fill up the online form and take a printout of the completed form. 6 The CSC Operator should be able to digitally sign the form and submit the same in to the eDA. 7 The eDA should save the application form with filled in details in a database along with CSC User ID and date and time of submission. 8 The CSC Operator should be able to take a printout of any submitted application. 9 The Printout of the submitted application should have the Application Number, CSC User ID, Date and Time of Submission imprinted on it. 10 The eDA should be able to immediately route the application to its recipient department’s process owner & notify him or her of the pending new application 33
  34. 34. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Payments Payment element of the proposed framework will define the overall process of payment for the selected services under the e-district project. It will account for the flow of funds from the collection points (i.e. CSC) to the concerned departments where the payment needs to be deposited. The purpose of the element as envisaged in the proposed BPR framework has been listed below – 1. Provide secured and trusted process of payment collection and deposit in the concerned departmental head for the selected services 2. Ensure exact payment by the citizen as defined for the service 34
  35. 35. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Payment Mechanism CSC (Privately Owned) Makes Transaction Prints Receives CSC Issues receipt to Acknowledgeme payment fees applicant nt Receipt from citizen E District Application Issues Registers Acknowledgement transaction Receipt Issues daily report for the number of transactions Receives department Makes Payment as per number of wise daily transaction transaction to the department from details payment account SCA Receives payment against Receives daily Department transaction the transaction from the SCA on daily basis details 35
  36. 36. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Payment Mechanism e District Centre (Government Run Centres) Centre Prints Receives Deposits collection charges after Makes Issues receipt to Acknowledgeme payment fees reaching a particular amount in transaction applicant nt Receipt from the citizen various department heads E District Application Issues Registers Acknowledgement transaction Receipt Issues daily report for the number of transactions Department Receives daily Receives payment against transaction the transaction from the details Govt. Centre 36
  37. 37. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. D. Payment S.No. Functional Requirement Specifications 1 The system should provide for and allow financial transaction functions 2 The system should check for all details of the service request form before initiating the payment 3 The system should enable the payment option only when all the fields of service request forms are filled 4 The system should return back and highlight the field which have inconsistencies / error for user to rectify the error 5 The system should retain all the information of the service request form besides those having inconsistencies 6 The system should return back after successful checking of the fields with the prompt of confirmation to open the payment page 7 The system should open a new page for recording payment details against the service request 8 The system should allow payment to be registered on the service application request against the following – • payment against the service • payment against the dues / payments as defined under service charter of the specific service 9 The system should record and maintain all details of payment against a unique service application number 10 The system should be able to maintain all the payment records in a database and retrieve the same as and when record 11 The system should be able to open a page with declaration on successful payment output 12 The system should able to record specific payment details on the service request form after successful payment has been made 13 The system should be such that it should allow for part payment function 14 The system should be able to retrieve information of first part payment during the final delivery of service output for final payment as per the overall payment specified for service request • Unique application number for requested service 37
  38. 38. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. • CSC details and unique number for CSC 15 The system should be able follow the payment cycle as mentioned above for the final payment also 16 The system should be able to maintain all records of part payments as well as consolidated payment amount against the service request Only for utility services (bill payments, etc.) 17 The system should allow transaction through approved financial instruments • Credit cards • Debit cards 18 On-line payment – The System should support online payment, including the following fields: • Facilitate payment against dues and recoveries online through a payment gateway interface with a bank. • Allow the user / customer to make payment only till the last date of payment has not passed. • Facilitate automatic updation of the information on the applicant record, upon realization of the submitted money 19 The payment function should be against specific invoice / bills for the given services 20 The system should ask for the final confirmation from user before initiating payments function 21 The system should allow for user re-verification before initiating payment function through transaction unique ID allocated to the user 22 The system should provide for migration to a secure payment gateways from the portal in a secured manner 23 The system should allow predefined data / information to be provided to payment gateways 24 The system should be able to generate unique ID codes for every transaction 25 The system should be able to correlate and confirm • User data / information through unique ID code generated • Payment gateway data information through Unique ID code 26 The system should provide for confirmation of transaction to the user 27 The system should provide for payment receipt against the payment 38
  39. 39. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. 28 The system should provide printable version of receipt 29 The system should not store any critical information of the user provided on the secured payment gateway 30 The system should allow for data / information transfer / flow to e- district application 31 The system should facilitate automatic updation of the information on the applicant record on successful payments made 32 The system should not allow any initiation of payment function beyond prescribed days limit for transaction • The system should be able to provide user friendly information for such transactions 33 The system should not allow for initiation of payment in case of non availability of records of invoice / bills against which payment function is initiated • The system should be able to provide user friendly information for such transactions 34 The system should provide for database security 35 The system should provide for application security 36 The system should provide user friendly information wherever required 37 The system should produce alphanumeric code for confirmation and verification for manual user Vs. computerized payments 38 The system should follow predefined payment rules and regulation as defined from time to time in the e-District application 39 The confirmatory receipt issued should have a unique registration number against the transaction 40 The system should maintain records of such transaction for users accounts respectively 41 The system should allow for printable version of the confirmatory receipt for all such successful transactions. 42 The system should be able to send emails on registry value of the user account on the payments. 43 The system should maintain all information and records of user transaction tagged to the user account and also provide for viewing of such information as and when required by the user 44 The system should not allow any changes to be made by the user into 39
  40. 40. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. the following – • Past records • Ongoing transaction once confirmation on initiation of such a transaction is given by the user • Any values maintained for such transaction 45 The system should be compatible for easy integration with accounting and financial application either inbuilt at a later stage into the portal or external with a interface with the portal 40
  41. 41. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Verification Verification component of the BPR is going to deal with the authentication of a particular service request. Verification process would ensure that no counterfeit or frivolous applications are lodged in to the system also it will help to identify and validate the right beneficiary availing the services. Verification also helps to establish that the application meets the regulatory and the service requirements. The verification components envisaged in the BPR report can be broadly categorized under two categories: a. Physical Verification b. Non Physical Verification Physical Verification There are certain cases where documentary proof doesn’t suffices the requirement of proving an applicant genuine for availing the benefits of a particular service. In these cases physical verification is the only medium to prove the genuineness of the individual and to validate the information supplied by him in the application. Though physical verification is a costly and time consuming mechanism for proving the genuineness of a particular individual but it also helps to capture the correct information at the particular moment of time. Whereas the non physical verification does not guarantees any change of information from date of last updation. Non Physical Verification Non physical verification component is going to deal with all such components that help to validate applicant’s genuineness and the benefits accrued by him by presenting the same. This kind of verification facilitates the non-presence of the applicant at the time of service avail ness. It also saves applicant time, money and efforts to be present at the location for physical verification. Non physical verification can be carried out with the help of the following means: a. Database b. Documents proof 41
  42. 42. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Using Database: The non-physical verification can be carried out using validated databases; these databases can help to validate the applicant by matching the details provided with the information stored in the database. These databases eliminate the need of physical verification that was previously carried out to validate the information provided by the citizen. The information that would be fed into the database would be validated, cross checked and entered by the department officials that are managing the database. Documents Proof: Authentic documents / copy of authentic documents signed by authority holding important designations can also work as proofs against the physical verification. These documents prove that the applicant is genuine and he is the same person as proved in the documents. 42
  43. 43. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Verification Checks the details Yes Yes Approves of the applicant in Details Details Found the the relevant Correct? Process Owner application databse No No Orders a physical Rejects the verification application Application e-District Returns the System notifies the results of the Field Officer of a query Pending Inquiry Field Officer Submits the Physically visits and Links the Citizen application back verifies details. Enters Receives the Database with the with the verified these details into the application. Department’s database details Department’s Database Figure 0-2 43
  44. 44. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. E. Verification S.No. Functional Requirements Specifications 1 The Process Owner should be able to use the e-District Application (eDA) to query the Departmental Databases using the name or other details of the applicant 2 The eDA should be able to retrieve various information from the individual databases and aggregate it before displaying it. 3 The eDA should be able decode the digital signed data and display the details of the signatory. 4 The eDA should allow forwarding of the application to another user using digital sign. 5 The eDA should notify the recipient of the application, that a new application is pending his or her attention. 6 The eDA should log all the electronic movements of the application with date and time details along with the sender’s and receiver’s information. 7 The eDA should provide an interface for the authorized Field Officer or Database owner to create a reference entry in the Citizen Database and thus linking the Citizen Database with the Department’s Database 8 The eDA should allow the Field Officer to enter his comments about the verification and forward the application back to the process owner. 44
  45. 45. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Rejection Rejection element of the proposed BPR framework is envisaged to meet all the rejection related functions of concerned departments for the selected services under the e-district project. This element allows rejecting the service request at the defined designated levels basis predefined requirement being not meet in the service request or otherwise also as deemed necessary the designated authority or otherwise also. This element will also act as a precursor for providing stated reason for rejection to the applicant. The purpose of the rejection element as envisaged in the proposed BPR framework has been listed below – 1. Allow designated government official to reject service request in case prerequisite conditions are not met along with the service request 2. Allow designated government officials to reject service request subject to their best judgment and interest of the power vested in them by the government 3. Allow rejecting authority to provide reasons for rejection of the service request 4. Allow requesting applicant / citizen to have valid reason for rejection of their service request 45
  46. 46. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Rejection E-District Application Receives request Returns the System registers the from authority to Query results change and notifies notify Field Officer Authority for field verification Rejects the Receives the Checks the details Details Yes Details Yes application online application in the DataBase Found? Incorrect using digital sign Authority No Marks the application for verification to Field officer Field Officer Updates the Department Physically visits the Receives the Data Base with all the applicant to verify the application. recorded details. details 46
  47. 47. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. F. Rejection S.No. Functional Requirements Specifications 1 The system should allow defined users to login to the system for reject the service request based on rejection criteria as mentioned for the service through a valid user ID and password 2 The system should show a login failure screen in case the user name and password are not verified by the e-district application 3 The system should intimate the users through predefined channels for pending service request application on a daily basis 4 The pending service request application should be highlighted for the predefined process owners on entering the application 5 The pending application should be intimated to the predefined process owners through SMS 6 The system should have a provision to mark the rejection of service request 7 The system should have a provision where the predefined process owner states the reason for rejection of the service request 8 The system should open a page with marked rejected application form and text entry provision against all the rejected application form 9 The system should close the service request once the text box is filled 10 The system should be able to retrieve the closed rejected service request on the new page for digitally signing it 11 The system should allow the user the digitally sign all the closed rejected service request at one go 12 The system should open a page for all rejected service request with a prompt of digital signature in form a button to initiate the process of digital signing 13 The system should reconfirm from the user for initiating the digital signing before actually initiating the process 14 The system should allow the user to terminate the rejection process at any point of time during rejection 15 The system should keep and maintain the data in a data repository 47
  48. 48. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. (database) for all the rejection made 16 The system should be able to keep the records of all transaction performed and link it to the unique code of digital signature 17 The system should open a page informing the user of successful completion of rejection function 18 The system should open page at any point of process in case the process termination with the request to restart the process 19 The system should not allow the user to initiate the process of digital signature in case of no selection of pending service request for rejection 20 The system should not allow the user to modify the rejection once it has been digitally signed 21 The system should not allow the user to delete any service request pending for approval at his end 48
  49. 49. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Approval Approval service component of the framework is envisaged to provide for mechanism for approval of service request. It allows the concerned responsibility center to approve the service request through a secured method. The approval will be linked either directly through the database. The approving authority will use the databases to decide whether the claim made in the application is correct or not. In case the claim is found to be verified by the database, the authority would approve the application using his digital signature. The purpose of the approval service component are enumerated below – • To allow the responsibility center to approve the service request • To integrate and embed secured process through which approval will happen 49
  50. 50. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Application Approval E-District Application Receives request System registers the Returns the Query results from authority to change and notifies notify Field Officer Authority for field verification Approves the Receives the Checks the details Details Yes Details Yes Yes application online application in the DataBase Found? Correct using digital sign Authority No Marks the application for verification to Field officer Field Officer Updates the Department Physically visits the Receives the Data Base with all the applicant to verify the application. recorded details. details 50
  51. 51. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. G. Approval S.No. Functional Requirements Specifications 1 The system should allow defined users to login to the system for approving the service request through a valid user ID and password 2 The system should show a login failure screen in case the user name and password are not verified by the application 3 The system should intimate the users through predefined channels for pending approval on a daily basis 4 The pending approvals should highlighted for the users on entering the application 5 The pending approvals should be intimated to the users through SMS 6 The system should have a provision to mark the approval of service request 7 The system should allow the user the digitally sign all the selected approved service request at one go 8 The system should open a page for all approved service request with a prompt of digital signature in form a button to initiate the process of digital signing 9 The system should reconfirm from the user for initiating the digital signing before actually initiating the process 10 The system should allow the user to terminate the approval process at any point of time during approval 11 The system should keep and maintain the data in a data repository (database) for all the approval made 12 The system should be able to keep the records of all transaction performed and link it to the unique code of digital signature 13 The system should open a page informing the user of successful completion of approval 14 The system should open a page at any point of process in case the process termination with the request to restart the process 15 The system should not allow the user to initiate the process of digital signature in case of no selection of pending service request for approval 16 The system should not allow the user to modify the approval once it has been digitally signed 51
  52. 52. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. 17 The system should not allow the user to delete any service request pending for approval at his end 52
  53. 53. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Delivery / collection The delivery service component of the proposed BPR framework relates to the delivery / collection of the service output for the service request made by the applicant. It is envisaged that this component will detail out the specifics involved for service delivery of the listed service under the e-District project. This will involve the use of security features like digital signatures, passwords, etc to be employed for service delivery at the front end where the citizen receives the output for the service request. The purpose of the element as envisaged in the proposed BPR framework has been listed below – 1. To provide output against the service request by the citizen through a defined and secured process 53
  54. 54. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Delivery Mechanism Application Notifies the CSC Retrieves the Displays the e-District & applicant that digitally signed document along his delivery is document saved with the due against the Signatory’s Receipt No. information CSC / Suvidha Center Enters the Prints out the Receives Receipt No. into document and notification of the e-District stamps it with his pending delivery application seal and signs it Quotes the Receives Travels to any Receipt Number Receives the Application notification of CSC / Suvidha and requests signed and pending delivery center. delivery of stamped document document 54
  55. 55. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. H. Delivery S.No. Functional Requirement Specifications 1 The system should be able to provide delivery against all service request made 2 The system should be able to link delivery against specific service request through unique service application request number 3 The system should allow delivery only when the service request has been either approved / rejected 4 The system should allow only validated predefined users to log into the e-district application for retrieving the delivery against the service request 5 The system should ask for unique service request number / unique application number to retrieve specific service delivery 6 The system should ask for the digital verification from the authenticated predefined users 7 The system should allow downloading of the service delivery output only after matching the digital verification 8 The system should provide for the printable version of the service output 9 The system should be able to print the unique kiosk number, unique application number on the every service output generated through it 10 The system should be able to print the <url> of the site from where the content of the service delivery could be verified 11 The system should open new page specifying error in case of incorrect digital verification 12 The system should be able to maintain the database of the all the service delivery output in a logical manner to ease the retrieval of the same as and when required 13 The system should have a life counter to keep log of all delivery made with specific association of unique service application number and unique CSC number 55
  56. 56. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Status The objective of this component is to keep track of the service levels of the various processes involved in a given service. This component is solely related with status tracking from the consumer’s perspective as well as the department/administration perspective. Each application by a consumer will be logged against a unique reference number generated at the time of application submission and given to the consumer for future references and status tracking. The purpose of having the status component is to ensure the following facets of good governance in day to day working of the government services: • To ensure transparency in service processing by the government to the citizen for the service request made • To establish the validity and sanctity of the well defined service level • To ensure and define responsibility and ownership of the actors towards service delivery 56
  57. 57. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. Status Tracking Displays the Updates the Retrieves the Detects changes document along Status information If any mobile or Status information in status of with the associated with a email is registered associated with the application Signatory’s Receipt No. Receipt No. information e-District Application Yes Notifies the If specified No Applicant about Service Level his application’s exceeded status Escalates the Yes application to higher level and notifies him Authority Takes cognizance Higher of the escalation and acts as necessary Receives Yes notification of Status of his application Applicant If had registered mobile or email Accesses the e- Enters the Receives the District Portal Receipt No. of Status of his No through internet his application application 57
  58. 58. I. Status tracking and auto escalation The system should have integrated auto status tracking and auto ‘T0-Be’ escalation features embedded in the overall architecture of the system & FRS Report – Pilot e-District, U.P. The system should keep track of all the service requests from the citizens along with the respective reference id generated at the time of the application receipt The system should be available in public and administrative view The system should be able to keep track of the status of all the service requests with the help of the respective reference id (application id) and map the current status with the pre-defined service level against each process The system should be able to highlight and auto escalate any deviation in the service level against a given reference id (application id) to the relevant higher authority The system should be able to detect any change in the status of a given reference id In case there is a change in the status of a reference id, the system should update the status information in the database The system should have provisions for intimating the applicant about the current status of his/her application through SMS and/or Email especially if there is a change in the status with respect to the final delivery of the service The system should not provide details about the internal SLAs to the applicant and only provide update about the status with respect to the final delivery. This feature should also allow the system to update the applicant if there is any change in the service level of the final delivery The system should also allow the applicant to retrieve update about his/her service request through the web portal by entering the reference id in the link provided on the portal The system should display an appropriate message if the system is unable to retrieve the details due to any reason like connectivity issues, maintenance issues, etc and also provide contact details of the system administrator and alternate link (if available) The System should have Side Menu on each page so as to reflect the contents of the containing directory , making it easier to navigate the site and locate the link for retrieving update against a given reference id The system should be adequate security features built in the architecture of the system to ensure that it cannot be hacked or manipulated The system should not allow 58 the users to edit the details of the application upon retrieving the status update against a given reference id The System should allow the end user to print the status update
  59. 59. ‘T0-Be’ & FRS Report – Pilot e-District, U.P. 59

×