5.2.5 Technical Framework for the OSS Model

3. adjust the procedural rules suitable for operating the OSS 4. establish a clear legal ground for municipalities to act as service providers 5. establish clear rules for the service owner to conduct supervision procedures over the municipality.

5.2.5 Technical Framework for the OSS Model

Implementation of the OSS in Timor-Leste requires the implementation and modernization of several technical infrastructure elements. Following the long-term vision of how an OSS should resolve the challenges and problems in the society, the technical topics can be separated into the following categories: • Generic enablers – infrastructure that enables the OSS implementation • OSS components – ICT framework and solutions that define the core of the OSS As described in the chapter "OSS model suggestions for Timor-Leste" , the long-term goal is to maximize the use of the digital environment for providing public services. Therefore, generic enablers for OSS are described briefly, as this is not specific to an OSS. On the other hand, special care and a critical level of details are put into describing the OSS components.

5.2.5.1Genericenablers

Physical infrastructure in Timor-Leste for enabling the OSS: • Physical road network. Reasonable access to municipality centres must be enabled by transportation infrastructure. It is not expected to have high level investments to road infrastructure - keeping roads usable is the goal. • Buildings. As one of the channels of the first phase is physical service centres, there must exist the ability to accommodate the OSS’ physical service locations. The property used must be sufficient to comply with the requirements defined by the SOPs. The OSS provider must choose the location of the OSS by following the locations people visit during their regular day-to-day activities – these are not offices of the public administration. Choosing a location close to market areas has been a good practice for municipal service centres. • Electricity. There are strong indications of issues related to access to electrical energy existing in different regions of Timor-Leste. Establishing service quality standards and monitoring their fulfilment is necessary to improve the stability of the electrical network. • Public internet. For the OSS, there is no requirement of having good external internet connectivity for Timor-Leste. It is important to ensure high quality connectivity inside TimorLeste – the type of connectivity must follow its users’ needs and expectations. For governmental institutions and large corporations a good, wired connection is needed. Citizens and small enterprises require internet over air – either mobile or some other wireless technology. For the GOTL it is critical to monitor the situation in the telecommunications market, to keep the technical and financial entry barrier low. With the generic enablers, it is critical to identify the enablers that feed into a fast return of investment for the OSS project. For example, physical transportation and buildings are temporary 55

solutions to accommodate the first steps of the OSS. Therefore, investing heavily into those is not recommended for the OSS implementation. At the same time power and network infrastructure shall be needed in the long term, and investments related to high-quality network services is critical to make the OSS successful.

Depending on the practical implementation considerations there may be additional generic enablers – identifying the reasonable level of generic services is critical to implement the OSS in a good pace.

5.2.5.2OSS Components

The proposed approach for the Timor-Leste OSS defines ICT and digital governance solutions as one of the most critical parts of the technical framework. It is critical to understand that the ICT solutions play important roles in two segments: • Information systems built and operated by governmental organizations and used for providing public services. These are often custom built or highly customized solutions that provide specific services in a given business domain. These solutions are the responsibility of specific authorities and governmental organizations. Owners of these systems must have a high level of autonomy for building information systems. Recommendations for building those systems is not in the scope of this current report. • OSS components - ICT solutions that simplify service provision and interoperability for governmental organizations. The OSS components must be domain neutral and support the information systems to provide digital services in a simpler way. In this chapter the emphasis is on those digital enablers. The experience of several countries shows that implementing a comprehensive digital governance system is complicated, and the process must be well governed. Some generic recommendations that are relevant to every OSS component are described below: • Find experienced consultants from other countries to support local teams during the implementation. The best know-how comes from practical experience - people who have planned and managed the implementation of digital governance. • Strengthen the local ICT-sector to be able to improve the local economy and have local support for ICT related challenges. • Strengthen ICT-related procurement capabilities in public administration. Good understanding of service ownership and product ownership are relevant and must be gained. • Have a persistent vision of what you want to reach and the people who are responsible for driving the public administrations towards that vision. • Implement in increments and avoid big projects. Define a practical implementation strategy and do not plan too far ahead - a clear vision and a general path are sufficient. • Use existing mature and well-maintained solutions whenever possible. Especially for digital governance core components, avoid development. For specific administrative domains, the development of solutions might be reasonable.

56

• Use an agile approach for the implementation of the technical components. While having a clear long-term vision, it is recommended not to make extensive plans but rather implement the OSS components in reasonable steps. This ensures that the stakeholders and users adopt to the changing environment, and the acceptance of the OSS shall be better. • All components that face citizens and entrepreneurs must be multilingual. Components that are working in the back-office could be implemented without the complexity of multilingual solutions.

The different stages require the following components to be introduced in the OSS technical core. Each component is described through its main functionality and services.

Catalogueof public services

• Owner: executive body • Functionality: o Central registry for: ▪ public authorities, ▪ public services, ▪ contact attributes where a service can be requested, ▪ required documents for a public service, ▪ etc. o Organizational and technical compliance procedures. o Statistics related to registry items could be consolidated in the catalogue. • Users and clients: o Citizens (digitally capable): information about public services - where and how the public services can be reached/accessed. o Service provider: public service browsing and describing functionality. o OSS governing body: reporting and information about public services for governance decisions.

Portal/app

• Owner: OSS provider • Functionality: o Responsive website and/or mobile app that provides a consistent look and feel for end-user (citizens, entrepreneurs) services. o Connected to backend solutions using a data exchange layer (when available). • Users and clients: o Citizens can find information about offline services from an unauthenticated view, if applicable, also download forms to be filled. o Authenticated citizens can find information about themselves from the portal.

57

o Authenticated citizens can submit service requests for themselves through the portal. • Remarks: o As the long-term vision is to provide services at a high automation level, it is not recommended to implement and launch intermediate solutions such as e-form submissions. o Portals are usually the solutions that tend to aggregate a lot of support functionalities - notifications, event calendar, personal inbox, etc. – this should be avoided, and the portal should be kept at minimal functionality.

Digital identity

• Owner: executive body • Functionality: o issuance of digital identity tokens to citizens based on the authentic register of citizens. o solutions and services for e-service authentication. o solutions and/or services for creating digital signatures. o contains PKI or some other trust technology component. • Users and clients: o Citizens can use identity tokens to authenticate themselves in digital solutions like the portal/app. o Citizens can use identity tokens to give consent on digital assets (files).

Data exchange layer

• Owner: executive body • Functionality: o Secure transfer of information between information systems using web services. o Managing the identity of participating information system owners/organizations. o Web service catalogue. • Users and clients: o Information systems owners can publish their web services on the platform and give authorizations for other organizations to use their services. o Information system owners can consume web services from service providers.

Information security methodology

• Owner: governing body • Functionality: o Standard and guidelines for protecting information. o Training for improving information security of information systems. • Users and clients:

58