Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

وثيقة النموذج المرجعي للتطبيقات الوطنية

891 visualizaciones

Publicado el

وثيقة النموذج المرجعي للتطبيقات الوطنية:
تمكن هذه الوثيقة الجهات الحكومية من تصميم وتطوير التطبيقات لتلبية الاحتياجات و معالجة التحديات التي تواجهها

  • Inicia sesión para ver los comentarios

وثيقة النموذج المرجعي للتطبيقات الوطنية

  1. 1. e-Government Program (Yesser) Version: 2.0 Date: 12/31/2015 National Application Reference Model (Version 2.0)
  2. 2. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 2 / 88 Document Description Document Title National Application Reference Model Document version 2.0 Document Status Final Author National Enterprise Architecture Office Management at Yesser
  3. 3. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 3 / 88 Table of Contents 1.  Introduction ......................................................................................................................... 5  1.1.  Document Purpose ........................................................................................................ 5  1.2.  National Enterprise Architecture Framework ................................................................. 5  1.3.  ARM Defined.................................................................................................................. 5  1.4.  Values of ARM............................................................................................................... 5  1.5.  Goals of ARM................................................................................................................. 6  1.6.  Target Audience............................................................................................................. 6  1.7.  Document Structure....................................................................................................... 7  1.8.  Related Information........................................................................................................ 7  1.9.  Contact Information........................................................................................................ 8  2.  ARM Executive Summary................................................................................................... 9  2.1.  Background of NEA Framework .................................................................................... 9  2.2.  About ARM..................................................................................................................... 9  2.3.  ARM Relationship to Other Reference Models............................................................ 10  2.4.  Importance of ARM in Saudi Government ................................................................... 10  3.  Application Reference Model Principles......................................................................... 12  4.  Application Elements........................................................................................................ 14  4.1.  Application Systems..................................................................................................... 16  4.1.1.  Core application systems..................................................................................................................... 17  4.1.2.  Supporting application system classifications ..................................................................................... 18  4.1.3.  Supporting application system descriptions......................................................................................... 18  4.2.  Application Components.............................................................................................. 32  4.2.1.  Application component classifications ................................................................................................. 33  4.2.2.  Application component descriptions .................................................................................................... 33  4.2.3.  A sample of reusable component ........................................................................................................ 43  4.3.  Application Interface .................................................................................................... 45  4.3.1.  Application interface classifications ..................................................................................................... 47  4.3.2.  Application interface description .......................................................................................................... 48  4.4.  Best Practices & Guidelines......................................................................................... 53  4.4.1.  Application architectural style .............................................................................................................. 53  4.4.1.1.  Client/Server architectural style ........................................................................................................... 54  4.4.1.2.  Service-Oriented architectural style..................................................................................................... 54  4.4.1.3.  N-Tier / 3-Tier architectural style.......................................................................................................... 55  4.4.2.  Application development life-cycle model............................................................................................ 56  4.4.2.1.  Waterfall model .................................................................................................................................... 56  4.4.2.2.  Prototyping model ................................................................................................................................ 57  4.4.2.3.  Rapid application development (RAD) model...................................................................................... 57  4.4.2.4.  Spiral model.......................................................................................................................................... 58  4.4.2.5.  Yesser SDLC........................................................................................................................................ 59  4.4.3.  Application development methodology................................................................................................ 60  4.4.4.  Application environments..................................................................................................................... 63  4.4.5.  Application design ................................................................................................................................ 64  4.4.6.  Application development...................................................................................................................... 66  4.4.7.  Application interface............................................................................................................................. 68  4.4.7.1.  Libraries based Interface...................................................................................................................... 69  4.4.7.2.  Protocols based Interface .................................................................................................................... 69  4.4.7.3.  Yesser GSB.......................................................................................................................................... 70  4.4.8.  Application testing ................................................................................................................................ 75  4.4.9.  Application configuration management................................................................................................ 75  5.  Application Systems for Saudi Government.................................................................. 76  5.1.  Understand Business Requirements ........................................................................... 77  5.2.  Prioritize Business Requirements................................................................................ 79  5.3.  Review Current Application Systems........................................................................... 79  5.4.  Design High-Priority, Quick-to-Market Application Systems ........................................ 80  5.5.  Design High-Priority, Long-Term Application Systems ................................................ 81  5.6.  Reuse Application Systems for Low-Priority but Quick-to-Market ............................... 82 
  4. 4. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 4 / 88 Appendix: National Shared Application Systems ................................................................. 84  List of Tables Table 2-1. ARM relationship with other reference models ......................................................... 10  Table 3-1: ARM principles.......................................................................................................... 13  Table 4-1: Application elements................................................................................................. 14  Table 4-2 : Example of core application systems serving government functions....................... 17  Table 4-3: List of supporting application systems ...................................................................... 30  Table 4-4: Application component areas and categories ........................................................... 42  Table 4-5: Board management component sample ................................................................... 45  Table 4-6 : Application Interface areas and categories.............................................................. 52  Table 4-7: Sample of CBD artifacts............................................................................................ 61  Table 4-8: KSA GSB service catalogue ..................................................................................... 74  Table 5-1: Checklist review of current application systems........................................................ 80  Table 0-1 National shared application systems.......................................................................... 88  List of Figures Figure 4-1: Application elements................................................................................................ 15  Figure 4-2: Supporting application system classifications.......................................................... 18  Figure 4-3: Development framework, application components and system............................... 32  Figure 4-4: Application component classifications ..................................................................... 33  Figure 4-5: Common component and software development framework................................... 43  Figure 4-6: Application interface classifications ......................................................................... 47  Figure 4-7: Waterfall model........................................................................................................ 57  Figure 4-8: Prototyping model.................................................................................................... 57  Figure 4-9: RAD model............................................................................................................... 58  Figure 4-10: Spiral model........................................................................................................... 59  Figure 4-11: Yesser SDLC ......................................................................................................... 60  Figure 4-12: A simple example of several components (holiday reservation system represented in UML 2.0)................................................................................................................................. 62  Figure 4-13: V development process for CBD ........................................................................... 63  Figure 4-14: The benefit of SW framework ................................................................................ 64  Figure 4-15: SW development paradigm.................................................................................... 65  Figure 4-16: Korean government SW development framework’s composition functionalities... 66  Figure 4-17: Software development library ................................................................................ 68  Figure 4-18: GSB ....................................................................................................................... 71  Figure 5-1: Steps to identify & prioritize application systems ..................................................... 77  Figure 5-2: Examples of MOE’s LoBs, business functions and sub-business functions ............ 78  Figure 5-3: Priority vs Time matrix ............................................................................................. 79  Figure 5-4: National shared application systems & components ............................................... 81  Figure 5-5: National shared application systems (long-term)..................................................... 82 
  5. 5. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 5 / 88 1. Introduction 1.1. Document Purpose The purpose of this document is to describe the main application architecture elements and national-wide application systems that government agencies in the Kingdom of Saudi Arabia can refer. This Application Reference Model (ARM) is a good starting point to look for national - wide and agency-wide application solutions. 1.2. National Enterprise Architecture Framework The National Enterprise Architecture (NEA) Framework is a key element for the national e- government envisioned to incorporate a federate approach to enterprise architecture for the Kingdom of Saudi Arabia (KSA). NEA Framework supports the identification of re-usable components and services, and facilitates a basis for Information Technology (IT) investment optimization. In addition, NEA enables more cost-effective and timely delivery of e-services through a repository of standards, principles and reference models that assist in the design and delivery of business services to citizens, residents, commercial establishments and inter- government collaboration. 1.3. ARM Defined The ARM is one of the reference models in the NEA Framework. The ARM describes the main architectural elements of IT application solutions. It also provides a strategic reference to key national-wide solutions or application systems. With both the application architectural elements and national-wide solutions, government agencies can design and develop application systems to solve their respective challenges and needs. 1.4. Values of ARM The ARM provides a reference for all government agencies to analyze, review, develop and implement IT application systems that support the integrated functions and services across different government agencies. Instead of simply looking for the best solution for an agency, the ARM adds value by proposing IT application systems that can be use across government agencies.
  6. 6. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 6 / 88 The ARM encourages government agencies to use national-wide IT application systems. In addition, with structured design approach, IT application systems and their components are shareable and reusable. With proper follow through, the ARM will bring about the following potential benefits: 1. Improve government services to citizens and businesses 2. Enhance interoperability across government agencies 3. Leverage on current IT application investments and assets 4. Reduce total cost of ownership on future IT investments through the use of national shared application systems and reusable application components 5. Align government agencies’ IT application systems with national shared application systems & other central IT initiatives. 1.5. Goals of ARM The goals of ARM are: 1. Promoting national shared application systems for common functions in the government agencies 2. Promoting the identification and implementation of IT application systems that support the similar government or business functions across different government agencies 3. Promoting industry standards and best practices in IT application design to increase interoperability across the government 4. Sharing reusable application components to reduce total development cost and time for deployment 5. Identifying areas for IT application consolidation to support efficient acquisition and deployment such as software licenses and use of latest software versions. 1.6. Target Audience Since the ARM is a reference that provides an insight to both IT application solutions and application elements, the target audience are as follows: 1. Enterprise Architects 2. Application Architects 3. IT Architects 4. Project Managers 5. IT System Owners
  7. 7. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 7 / 88 6. IT Managers 7. IT Consultants 8. IT Vendors 1.7. Document Structure The ARM contains the following sections: 1. Executive Summary The executive summary describes the main features of ARM. After reading this section, the reader can understand how ARM guides the government agencies to analyze and design IT application systems. The executive summary is excellent for IT System Owners, IT Managers and Project Managers. 2. ARM Principles This section describes the principles that shape the ARM development and to guide the development of IT application systems. 3. Application Elements The main application elements – i.e. application systems, application components and application interfaces – are describe in this section. 4. Application Systems for Saudi Government This section provides the strategy and approach in looking for application systems for both national-wide and agency use only. 1.8. Related Information As the ARM is only one of the reference models in NEA Framework, it has important relationships with the other reference models. It is useful to refer to the following: 1. Business Reference Model 2. Data Reference Model 3. Technical Reference Model.
  8. 8. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 8 / 88 1.9. Contact Information For any feedback, comments or need for more information on the ARM, please email to nea@yesser.gov.sa
  9. 9. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 9 / 88 2. ARM Executive Summary 2.1. Background of NEA Framework The 2nd National e-Government Action Plan for Kingdom of Saudi Arabia (KSA) aims to transform the government in the delivery of services to the public. The National Enterprise Architecture (NEA) is a strategic initiative to support government agencies in delivering the targets set in the Action Plan. The vision of NEA is “Achieving performance driven IT investment and standardized services for a coherent whole of government by 2020” while the mission of NEA is “Leading transformation of government agencies through improvement of IT effectiveness and efficiency”. To fulfill the above vision and mission, the National Enterprise Architecture (NEA) Framework is a key element for the national e-government envisioned to incorporate a federate approach to enterprise architecture for the KSA. NEA Framework supports the identification of re-usable components and services, and facilitates a basis for Information Technology (IT) investment optimization. In addition, NEA enables more cost-effective and timely delivery of e-services through a repository of standards, principles and reference models that assist in the design and delivery of business services to citizens, residents, commercial establishments and inter-government collaboration. This is addressed by accentuating the full potential of the federated enterprise architecture by steering its adoption across the government through continuous engagement with all government agencies. 2.2. About ARM The ARM is one of the reference models in the NEA Framework. It provides a strategic reference to key national-wide solutions or application systems. With ARM, government agencies can design and develop application systems to solve their respective challenges and needs. However, instead of simply looking for the best solution for an agency, the ARM adds value by proposing IT application systems that can be use across government agencies. The ARM encourages government agencies to use national-wide IT application systems.
  10. 10. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 10 / 88 2.3. ARM Relationship to Other Reference Models The ARM has important relationships with the other reference models in the NEA Framework as listed in Table 2-1. Reference Model Relationship with ARM Business Reference Model (BRM) ARM can refer to business functions and sub-business functions in the BRM to identify areas for automation and improvements. Since the business function is a logical view, it also identifies related government agencies affected by the implementation of the IT applications to support the specific business function. Data Reference Model (DRM) As IT applications require data, the ARM has to cross- reference with DRM to identify key data attributes and the sources of data. Technical Reference Model (TRM) In designing IT solutions, the ARM has to also link with the TRM on technical standards and best practices. Table 2-1. ARM relationship with other reference models 2.4. Importance of ARM in Saudi Government IT application systems form the core solutions to solve business problems (in addition to business processes, data, skills, etc.). Unlike hardware and data, IT application systems are customize to meet the government business requirements so that government agencies can be efficient and effective to provide excellent services to the public and other stakeholders. While each government agency can design and develop the best application systems on their own, these applications would only serve the respective government agency’s performance. As part of the 2nd National e-Government Action Plan, government agencies have to continuously transform in order to deliver excellent public services. From ARM’s perspective, government agencies may transform their current modes of interaction, processing and service delivery in application architecture. With the use of ARM, government agencies can benefit the following:
  11. 11. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 11 / 88 1. Reduce the number, amount and time to develop various IT application systems. Instead, government agencies are encouraged to use national shared application systems for common functions 2. Prevent duplication of effort and duplication of application systems. By identifying government agencies involved in the implementation or automation of key business functions and business processes, the same or similar application system can be built together 3. Each government agency, that is leading a specific area of business function, can also identify all the agencies that are providing services within the business function. Not only will this prevent duplication of work, but more importantly, it will provide the opportunity to design an application to meet different requirements from the various affected government agencies. The end result would be an integrated system for the business function use by different agencies 4. Each government agency can reduce the total application development cost and time for deployment by using reusable application components 5. Through application interfaces, data and information can be easily and securely exchanged.
  12. 12. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 12 / 88 3. Application Reference Model Principles ARM principles describe the preferred directions, aspired attributes and practices required to guide both the development of the ARM and the government IT application systems. Table 3-1 describes the five ARM principles. S/No Principle Principle Description / Rationale 1 Strategic Driven Applications Design and prioritize application systems that deliver strategic outcomes. To support the government agencies to meet strategic goals, such as the national plans and the e-Government Action Plan, application systems have to be designed and prioritized according to these strategies and business needs. This principle ensures that there is focus and prioritization in the development and deployment of application systems. 2 Cross-Agency Application Systems Design and develop application systems that serve multiple government agencies. To develop application systems that support the business functions and business requirements. As a business function is typically carry out by more than one government agency, these application systems have to serve the requirements of multiple government agencies. This principle encourages application systems to meet cross-agency implementation requirements. 3 Easy-to-Use yet Secured Design and develop application systems that are easy- to-use and, at the same time, highly secured.
  13. 13. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 13 / 88 S/No Principle Principle Description / Rationale Application Systems To design and develop application systems that are intuitive, simple, secured and effective. Users need not know the underlying technologies used or the processes involved. This principle ensures that users can be productive in using the application systems. 4 Adaptable and Reusable Application Systems & Components Design and develop application systems using reusable components and systems while being adaptable to the constant changes. With constant changes and problems, application systems have to be adaptable to meet the changing conditions and requirements. Due to the dynamic changing demands and requirements, this principle allows quick and easy changes to the application systems. It also allows faster and lower cost in developing and maintaining application systems. 5 Vendor-Neutral Application Systems Design and develop vendor-neutral application systems. To design and develop application systems for long-term use that are independent on any specific vendor or product. This principle ensures that government application systems are not lock into any particular vendor or product that may result in vendor / product obsolescence or extreme price hikes. This principle also supports open technologies and free market competition. Table 3-1: ARM principles
  14. 14. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 14 / 88 4. Application Elements The application elements constitute the key artifact of the ARM. This section lists the application elements and describes the inter-relationships among these elements. There are three application elements in ARM as described in Table 4-1. S/No Element Name Element Description 1 Application System Describes the application system as an automated functional unit of operation. Typically, an application system has to support a government business function or task. Hence, the ARM links Business Reference Model (BRM) through the application system. 2 Application Component Describes the components that make up an application system. Many components will form an application system. Multiple application systems can utilize the shared or common components. 3 Application Interface Describes the various methods on how applications systems or application components can integrate. Table 4-1: Application elements The benefits of the application elements are: 1. To aid government agencies in planning the development of new application systems 2. To identify the removal or replacement of obsolete and duplicated application systems and/or components 3. To identify the potential re-use or sharing of application systems 4. To design application components that are re-usable and highly customizable
  15. 15. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 15 / 88 5. To design efficient and reliable application integration methods within the government agency (including remote branches) and across other government agencies. Figure 4-1 below illustrates the application elements in ARM. Figure 4-1: Application elements
  16. 16. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 16 / 88 4.1. Application Systems In IT, an application system typically consists of a user interface, a logic processing and a database or table to store data. However, from the ARM perspective, an application system is an IT automation, or part of the automation, of a government business function or task. In short, to improve the efficiency and effectiveness of government operations, an application system has to serve the government business function or sub-business function as described in the BRM. The benefits of application systems are: 1. Through IT automation, application systems improve efficiency and productivity 2. When compared to manual processing, application systems give quality output through standard validation of inputs and consistent processing rules 3. Total processing time is faster than manual processing. Applications systems can be define into two broad categories as follows: 1. Core Application Systems These application systems directly support the main government business functions or sub-business functions. Typically, government agency or agencies that are responsible for the government business function will use the core application systems. These application systems aid the effectiveness and efficiency of the specific government business function or sub-business function. 2. Supporting Application Systems Application systems that provide supporting government business functions or sub- business functions. These supporting application systems are to be use in most government agencies to improve general productivity.
  17. 17. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 17 / 88 4.1.1. Core application systems Core application systems are required to improve the performance of the government agencies. Through IT automation, the core application systems can improve the effectiveness and efficiency of the government primary business functions. Typically, a core application system will address the government primary business function or sub-business function. If the scope and complexity of the government function is manageable, then the core application system can be develop at the appropriate business function level. However, when the scope and complexity of the government function is too wide and challenging, the core application system(s) have to be develop at the sub-business function level. As an example, the Education government Line of Business (LoB) is huge and complex. Thus, each government sub-business function from pre-school to high school would have at least one corresponding core application system as shown in Table 4-2. However, for graduate and post- graduate education, it may be possible to have two integrated core application systems serving two sub-business functions. Business Function Business Sub-Function Core Application System Name Pre-School to High School Education Pre-School Pre-School Management System Primary School Primary School Management System High School High School Management System Graduate and Post- Graduate Education Graduate a. Graduate and Post- Graduate Management System b. Integrated University Admission System Post-Graduate Table 4-2 : Example of core application systems serving government functions
  18. 18. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 18 / 88 As core application systems are directly link to the government functions, the ARM will not provide the potential list of all core application systems. Reference to the BRM is necessary and self-explained. 4.1.2. Supporting application system classifications Supporting applications systems focus on the IT automation of the supporting government business functions or sub-business functions. These supporting application systems, unlike core application systems, can be use in most government agencies. While government agencies may have core application systems to deliver their core responsibilities and deliverables, supporting application systems further improves the productivity and efficiency of government agencies. The supporting application systems can be classified by the organizational support business functions. In total, there are ten common support business functions, although this list is not exhaustive. Figure 4-2 shows these ten common support business functions and the respective application systems. The description of these functions and application systems are in the next section. Figure 4-2: Supporting application system classifications 4.1.3. Supporting application system descriptions Supporting application systems can be classified within the organizational support business functions. Table 4-3 lists all the potential or recommended application systems within their respective ten supporting business functions.
  19. 19. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 19 / 88 App No Supporting Business Function / Application Name Application Description 1 Building Management Manages the various building components in the government agency including physical security. 1.1 Building Management System (BMS) Manages the building(s) of the government agency. The aim of this system is to manage all the building features such as electrical usage, mechanical usage and electronics usage. Examples include the control of air-conditioning, lighting and automated sliding doors in the building. The BMS is use only for government- owned buildings where the electronics, electrical and mechanical parts have been design in tandem with the building construction. Older and smaller buildings normally do not have BMS. 1.2 Security Management System Manages the physical security of the government agency. With this system, the government agency can better manage risks relating to physical security. The main features of this system includes employee access control (e.g. finger print check), door access control (e.g. to certain floors and sections of the building), time-based access (e.g. access between 7am and 3pm on weekdays), and circuit-camera TV (CCTV) for video recording of entrance/exits of critical places. This security system can also integrates into the 1.1 Building Management System (BMS). 2 Business Management Manages the key business processes in the government agency.
  20. 20. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 20 / 88 App No Supporting Business Function / Application Name Application Description 2.1 Business Process Management System (BPM) Manages the various important business processes in the government agency. The aim of BPM is to optimize the business processes that produce services (manual or e-services). It is both a tool and a process that requires disciplined methodology – from designing, modelling, documenting, executing, to optimizing or re-engineering. This system is useful when government agencies review and continuously improve their business processes as part of the e-transformation journey. 2.2 Business Request Management System Manages the different requests for services in the government agency. The aim of this system is to facilitate and automate the process from request, to assignment, to actual execution of the business request. This system helps to prioritize requests and to assign them to the available resources. It is a good system for government agencies that provide specific services based on request (e.g. from another government or another division). The system would also allow the review of all the requests statistics such as requests processed, incomplete actions and requests not done. 3 Communication & Collaboration Manages the internal communication, collaboration and knowledge sharing among government staff within the government agency and across agencies. 3.1 Email and Calendaring Manages the effective communication via email between the employees with other employees, public and suppliers. The calendaring tool is to aid scheduling of meetings and appointments in order to maximize the employees’ time.
  21. 21. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 21 / 88 App No Supporting Business Function / Application Name Application Description 3.2 Government Agency Intranet / Portal Manages one central system for access to information, data and applications of the government agency by the employees. Through standard portal or website, employees get the latest news & information, and ease the standard access to applications & data. 3.3 Knowledge Management System Manages the central repository of important data, information and documents. The aim of this system is to improve the information sharing so that employees can gain knowledge and pass on to the other employees. Another possible feature of the knowledge management system is to have an active electronic collaboration that allows online discussion by employees from anywhere. This system is good for government agencies with ‘knowledge-based’ and research- based employees. 4 Corporate Planning & Development Manages information that affects the government agency’s corporate performance and human resources. 4.1 Organization Management and Planning System Manages the planning and general management of the government agency. With this system, government agency can better organize, plan and execute its operations or events. The features of this system include organization definition & management, events planning & management, and events tracking.
  22. 22. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 22 / 88 App No Supporting Business Function / Application Name Application Description 4.2 Human Resource Management System (HRMS) Manages the government agency’s human resources such employees, part-time workers and contract workers. This system aims to optimize the human resources within the government agency and to maximize the employees’ performance. The HRMS has functions such as job scope/grade & job roadmap definitions, recruitment, performance setting & evaluation, skills development & training, attendance & leave management, employee awards and resume. 5 Financial Management Manages the finances of the government agency from budgeting and payment to monetary collection. 5.1 Budgeting System Manages the budgeting process of the government agency that, in turn, helps to improve the financial planning and expenditure. The system typically follows a life cycle from budget review, budget planning, budget allocation, budget tracking and budget reporting. 5.2 Financial Management System Manages the various complex aspects of finances in the government agency. The aim of this system is to maximize the financial resources of the government agency and to account for all revenues & expenditures. The system typically has modules such as general ledger, accounts receivables, accounts payables and cost center accounting. This system is normally link to 5.1 Budgeting System, 5.3 Payment System and 5.4 Monetary Collection System. Note that a large financial management system can incorporate all these four systems into one.
  23. 23. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 23 / 88 App No Supporting Business Function / Application Name Application Description 5.3 Payment System Manages accounts for all the payment transactions of the government agency. To ensure financial accuracy and compliance to financial laws, record all payment transactions into the system. This system should be able to track payments in all amounts and via different modes such as cash, cheque, inter-bank transfer and online payment. 5.4 Monetary Collection System Manages all the monies collected by the government agency at different locations. The aim of this system is ensure credibility by capturing all monetary collections via different modes such as cash, cheque, inter-bank transfer and online payment. 6 General Administration & Management Manages and administrates the official information in the government agency such as assets, documents, records and office resources. 6.1 Asset Inventory Management System Manages the inventory of assets in the government agency to improve accountability of all valuable assets in the government agency. Assets include office equipment and office stationaries. This system does not link the requirements to supply the inventory when it has reached a low level. For this, please refer to 9.2 Supply-Chain Management System. 6.2 Document Management System Manages the electronic documents of the government agency. This system can identify, search and retrieve all documents to improve office productivity. The system features include scanning or digitizing the document, storing, searching, retrieval and archiving.
  24. 24. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 24 / 88 App No Supporting Business Function / Application Name Application Description 6.3 Record Management System Manages the records of the government agency throughout their life cycle, from the time of document creation to their eventual disposal. This includes identifying, classifying, storing, securing, retrieving, tracking and destroying or permanently preserving records. The aim of this system is to ensure evidence of actual events or decisions made. 6.4 Workflow Management System Manages the automated workflow processes to speed up general efficiency. This general workflow management system is required to automate business processes and services of the government agency. The system allows business processes to be automated, actions routed and/or scheduled to specific person(s), and tracked. 6.5 Resource Booking System Manages the book resources such as meeting rooms, vehicles and even people. The aim of the system is to optimize the use of resources in the government agency. For meeting rooms booking only, government agency can leverage on 3.1 Email and Calendaring application system that includes basic resource booking as part of the calendaring function. 7 IT Management Manages the efficient use of IT resources in the government agency.
  25. 25. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 25 / 88 App No Supporting Business Function / Application Name Application Description 7.1 IT Helpdesk System Manages the helpdesk system that allows users or employees to call for help in the use of IT. The aim of this system is to support users in the effective use of IT devices and applications. The system normally tracks from the call by the user to the resolution of the problem. The IT Helpdesk System is useful when there are a large number of IT users or employees. 7.2 IT Infrastructure Management System Manages the various aspects of the IT infrastructure such as network management, server & storage management, and data center operations management. The aim of this system is to provide service excellence in managing the complex and dynamic IT environment. This suite of systems is suitable for government agencies with high demand in the use and operations of IT. 7.3 Application / IT Portfolio System Manages the IT and application inventories into a meaningful profile for the government agency. The aim of this system is to provide value on inter-related information about different aspects of IT (network, equipment, data, applications and IT support). It provides management information such as Total Cost of Ownership (TCO), Return on Investment (ROI) and Business Value of IT (ITBV). Other inter- relationship information includes life span of IT investments and duplicated investments. For large government agencies, this system is excellent when used in conjunction with 7.4 Enterprise Architecture System / Tool.
  26. 26. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 26 / 88 App No Supporting Business Function / Application Name Application Description 7.4 Enterprise Architecture System / Tool Manages the effectiveness of the Enterprise Architecture (EA) program in the government agency. With this system or tool, the architects can discover and analyze government agency- wide issues, duplications and limitations in both business and IT perspectives. This tool is use only when the EA project has started or completed in the government agency. 8 Management Reporting and Business Analytics Reporting of management information and strategic analytics in the government agency. 8.1 Statistics and Reporting System Manages the statistics and reports to the various management teams in the government agency. The aim is to provide reports for decision- making. On a fixed schedule (such as weekly, monthly and quarterly), the statistics and reports can be generated and sent out via email, portal or direct access to the application system. 8.2 Dashboard System Manages the overall key performance indicators (PKIs) and the status of major programs / projects in the government agency. The aim of this system is provide a comprehensive view of all the PKIs set by the management of the government agency. The dashboard provides a summary of the key status of events, programs, projects and other compliance measurements that have been set. It shows status of events or projects that are late or on schedule, and brief statistics to understand the potential impact to the government agency. Public feedback, complaints and other measurements from the social media can also be incorporate into the dashboard system.
  27. 27. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 27 / 88 App No Supporting Business Function / Application Name Application Description 8.3 Business Intelligence System Manages the combination of tools, technologies and processes to process and analyze data into meaningful information. The aim of this system is to understand and manage data complexity by filtering these data to provide “intelligence” for decision-making. Business intelligence include features such as benchmarking, analytics (trending, predictive & prescriptive), mining (text, data & process) and performance management analysis. This system requires reliable data and skilled analysts to carry out the intelligent discovery and findings. Typically, it is used by government agency with complex processing and voluminous data. 9 Procurement Management Manages the end-to-end procurement processes including project tendering & awarding, to supply-chain execution. 9.1 Tender or Bid Management System Manages the whole process of tendering or bidding by the government agency. The aim of this system is to ensure transparent & accurate recording of the tendering process of the various tender or bids by the government agency. This system includes modules such as vendor or tenderer information management, tender management and contract management.
  28. 28. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 28 / 88 App No Supporting Business Function / Application Name Application Description 9.2 Supply-Chain Management System Manages the supply of goods & services consumed by the government agency. The aim is to improve the efficiency of having readily available goods and services for the government agency from various suppliers. This system is useful for government agencies who require large-volume supplies such as medicine, and uniforms. Note that it is possible to combine this application with the above 9.1 Tender or Bid Management System. 10 Public Information & Communication (Customer Services) Publication of official information to the public, including official public interaction and communication. 10.1 Call Center Management System Manages the calls from public (citizens and businesses) to obtain services or information from the government agency. With this system, the government agency can better serve the public. This system may use for government agencies that are customer-centric, i.e. there are many interactions with the public. This system includes the processes to receive public request (by phone or email), service the request, and close the request. 10.2 Customer Relationship Management System (CRMS) Manages the customer (public) and government agency’s relationships. Like the Call Center Management System, this system aims to improve the customer service. This system stores and analyzes information about the public (citizens and businesses) and their interactions or needs from the government agency in order to improve and deliver quality customer service. The CRMS is also link to the 10.6 Social Media Management System.
  29. 29. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 29 / 88 App No Supporting Business Function / Application Name Application Description 10.3 Customer Complaints Management System Manages the complaints from the public (citizens and businesses). The aim of this system is manage complaints from public in order to serve them better by addressing their complaints and concerns. Recorded complaints are assign to staff for resolution and a follow-up to respond to the public. This system is important for government agencies that receive many complaints. Note that this system can link - or even develop as a module – under 10.2 Customer Relationship Management System (CRMS). However, for government agencies without CRMS, this can be a stand-alone system. 10.4 Customer Feedback & Survey System This system allows public (citizens and businesses) to feedback on selected issues to the government agency. In addition, the government agency can also carry out surveys on the public. With this system, government agencies can understand the needs and issues of the public. Responses can be stored and analyzed. Various survey results can be further analyze through 8.3 Business Intelligence System.
  30. 30. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 30 / 88 App No Supporting Business Function / Application Name Application Description 10.5 Content Management System Manages the content of the government agency. This system aims to produce and maintain standard and consistent content so that the public can be better and accurately informed. Content include information and data from various sources such as documents, and application systems. It includes management life cycle from creation, edition, publication, updates and deletion of the content. This system allows content to be centrally managed while the final approved content can be distributed and published via official websites, intranet and social media (see 10.6 Social Media Management). 10.6 Social Media Management Manages social media technologies such as Facebook, Twitter, LinkedIn and Instagram. This system allows the integration approach to better interact with the public on the various social media platforms. This system can connect to the CRMS (to get information about public) and Content Management System (to ensure the publishing of standard content through the social media platforms). Table 4-3: List of supporting application systems Important Note: The above list is not exhaustive. In addition, some of the above applications can be combined or separated. The aim of Table 4-3 is to give an idea of the main supporting application systems. Enterprise Resource Planning (ERP) system is a common term that combines a few enterprise functions such as financial management, HR and procurement – these have been described as separate application systems above. Thus, ERP is not listed specifically as a supporting application system but as separate application systems.
  31. 31. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 31 / 88
  32. 32. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 32 / 88 4.2. Application Components An application component is defined as a modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces1 . All application systems have separate components so that all of the data and functions inside each component are semantically related. With regard to system-wide co-ordination, application components communicate with each other via interfaces. Application components can be developed in advanced and shared. For example, if we prepare some common components such as Login. Bulletin board and PKI component they can be reused for other systems. When we use shared components in application system development, there are many benefits: 1. Reduce cost and development time: Once developed, it can be reused and developers only call a component when it is needed. 2. Increase flexibility: Runtime components can work independently and they are less dependent on the environment. 3. Easier management: Administrator can look at or work with individual components without bringing down entire application system. 4. Improve application system quality: The errors are fixed from reuse to reuse in application components across several application systems and this leads to a higher application system quality. Figure 4-3: Development framework, application components and system2 However, application components can be only used on same development framework3 or software language such as JAVA, visual C and C++. Development framework is a skeleton, 1 http://pubs.opengroup.org/architecture/archimate-doc/ts_archimate/index.html “ArchiMate® Version 1.0” 2 http://www.egovframe.kr “E-government standard framework”, NIA, Korea 3 Sometime development framework is called application framework (Wikipedia)
  33. 33. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 33 / 88 template or generic structure that will cater a skeleton for developing software in a certain application domain as the figure 4-3. Spring framework4 , e-government standard framework of Korea, and Oracle application development framework5 are widely used. 4.2.1. Application component classifications Application components can be classified based on the characteristics and functions of them. Figure 4-4 illustrates seven components’ area and related categories. The description of these components and sample components are in the next section. . Figure 4-4: Application component classifications 4.2.2. Application component descriptions Table 4-3 lists all the potential or recommended application components and it includes related sample component as well. Com. No Component area name / Component category name Component category description 4 http://projects.spring.io/spring-framework/ 5 http://www.oracle.com/technetwork/developer-tools/adf/adf-11-overview-1-129504.pdf
  34. 34. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 34 / 88 Com. No Component area name / Component category name Component category description 1 Collaboration The component that supports easy and effective communication and information sharing with the persons concerned. 1.1 Bulletin board The component that supports an online collection of electronic messages, posted by and accessible to any authorized user. (Sample components) · Board creation management · Board usage management · Board management · Board design template management · Reply management 1.2 Community The component that provides inquiry, registration, modification, and elimination function in order to support co- operation & information sharing among both users having common interest and common users’ work group and offers users’ management by a class, verification/administration of accumulated data, and creation of a community. (Sample components) · Community creation management · Community usage management · Community member management · Community template management 1.3 File sharing The component that supports distributing or providing access to digital media such as computer programs, multimedia (audio, images and video), documents or electronic books. (Sample components) · File management: Manage the attached files, which are required when handling the business logic, in order to use file list inquiry and file download functions
  35. 35. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 35 / 88 Com. No Component area name / Component category name Component category description 1.4 Messenger The component that supports text, voice and / or video communications between two or more users. 1.5 Online survey The component that supports a questionnaire that the target audience can complete over the Internet. Online surveys are usually created as Web forms with a database to store the answers and statistical software to provide analytics. (Sample components) · Questionnaire creation management · Questionnaire management · Questionnaire question management · Questionnaire response management · Questionnaire template management 1.6 Remote meeting The component that allows visual and audio transfer through voice over internet protocol. Discussion takes place in real time and may include graph, document and chart displays 1.7 Schedule sharing The component that supports whole teams or individuals to inspect, add, modify each other’s work schedules, meeting, activity, etc. (Sample components) · Schedule management: Manage the schedule events such as seminars, lectures, sessions, meetings and others, and it features monthly/weekly/daily schedule management 1.8 Text message The component known as short message service (SMS) that supports text messaging of phone, Web, or mobile communication systems. (Sample components) · SMS service: Manage the text message transmission interface for using SMS gateway
  36. 36. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 36 / 88 Com. No Component area name / Component category name Component category description 2 Data management The component that supports information’s accumulation, fulfillment, and delivery in organization. 2.1 Backup/Recovery The component that creates copies of data to restore the original after a data loss event or to restore and stabilize data sets to a consistent, desired state. (Sample components) · Backup management: Manage the backup schedule, task and results 2.2 Data quality management The component that ensures data are fit for their intended uses in operations, decision making and planning and to ensure internal consistency of the data. 2.3 Extraction The component that supports the extraction of data from a database. 2.4 Metadata Management The component that manages information where & what kind of information is stored, how it is encrypted, what kinds of relationship it has with others, where the data were created, and what kind of connection it has with work activity. 2.5 Translation / Conversion The component that supports the manipulation and change of data to a different format. (Sample components) · Converting date and time (to String or Number) · Gregorian Islamic calendar conversion · File conversion to doc, xls, ppt etc. · Number conversion to string, date, etc. 3 Information provision The component that supports processing of information for user such as reporting, searching and translating. 3.1 Language translation The component that supports changing the source-language text by means of an equivalent target-language text.
  37. 37. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 37 / 88 Com. No Component area name / Component category name Component category description 3.2 Geographical information The component that is design to capture, store, manipulate, analyze, manage, and present all types of spatial or geographical data. 3.3 Real-time information management The component that manages and delivers real-time information immediately upon collection. There is no delay in the timeliness of the information provided. 3.4 Search The component that searches typical / atypical information according to user requirements in the government agency and displays out relevant results. (Sample components) · String search · Number search 4 Integration management The component that supports integration of service, data, application and process to act as a coordinated whole. 4.1 Application Integration The component that supports the process of bringing data or a function from one application program together with that of another application program. 4.2 Data Integration The component that supports combining data residing in different sources and providing users with a unified view of these data. 4.3 Process Integration The component that supports to integrate business processes that are an accountable way of communicating information between entities like people, organizations and governments for an anticipated means. 4.4 Service Integration The component that supports to integrate multiple suppliers of service to a single business-facing IT organization. It aims at seamlessly integrating interdependent services from various internal and external service providers into end-to- end services in order to meet business requirements.
  38. 38. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 38 / 88 Com. No Component area name / Component category name Component category description 5 Security The component that prevents and protects information of government agencies & individuals from the internal and external threats. 5.1 Digital rights management The component that supports various access control technologies to restrict the usage of proprietary software, hardware, or content. (Sample components) · Copyright protection policy: Manages copyright protection policy and information sharing policy notified to users when registering 5.2 Digital signature The component that supports and manages electronic signatures 5.3 Encryption The component that converts plain text to cipher text with a cryptographic algorithm. (Sample components) · File Security: Manages a function to encrypt files using the encryption algorithm or to decrypt files using the decryption algorithm 5.4 User authentication The component that allows a device to verify the identity of someone who connects to a network resource. 5.5 User authorization The component that supports authorization towards computer, application, network’s users or group of users. (Sample components) · Authority management · Authority group management · Role management 5.6 Virus protection The component that prevents, detects, and removes self- replicating programs that run and spread by modifying other programs or files.
  39. 39. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 39 / 88 Com. No Component area name / Component category name Component category description 6 System operation The component that supports efficient operations of systems such as system configuring, monitoring, and error-responding tasks. 6.1 Configuration management The component that supports administration of system’s components (H/W, N/W, S/W, etc.) through identification, control, maintenance and verification of logical models or services. It also defines as the ability to properly control IT infrastructures and services in the organization. 6.2 Connection management The component that manages the activities and features of a device connection. (Sample components) · System connection status management · Connection statistics · SSO connection management 6.3 Failure management The component that supports handling the situation and make it possible to provide normal service at early time in case serious problems happen on application, data, network, etc. its definition is to aid works such as back-up / restore / damage-handling, etc. (Sample components) · Failure application management: Manage the functions of registering, modifying, deleting, inquiring and inquiring lists of failure application information 6.4 Remote control The component that supports performing - as using one’s own computer - software, server, network management works, such as program execution control, server load management, etc., in the distant area with transmitting graphic data in order to see remote computer’s screen from the control computer in real time.
  40. 40. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 40 / 88 Com. No Component area name / Component category name Component category description 6.5 S/W distribution The component that supports installed computer programs, application/delivery of components, installation & upgrade. It makes easy to install new program to many PCs. 6.6 Synchronization The component that synchronizes the time and data among physically separate systems. (Sample components) · File synchronization: Manage the functions to attach and download files by synchronizing AP servers 6.7 System monitoring The component that supports memory use of computers & applications, and balance & assignation of disk space & outcome. (Sample components) · Server resource monitoring · HTTP service monitoring · Network service monitoring · Process Monitoring · DB Service Monitoring · File System Monitoring 7 User support The component that improves user’s system usage experience. It makes system usage convenient and easy depending on personal traits. 7.1 Common Code Management The component that provides the function to register, update, inquire the list and inquire details of the common codes. (Sample components) · Common code management: Manage the function to register, update, inquire the list and inquire details of the common codes
  41. 41. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 41 / 88 Com. No Component area name / Component category name Component category description 7.2 Notification The component that notifies relative service to users such as mailing service, POP, message reception, etc. (Sample components) · Popup management · Event management 7.3 Online Help The component, which is one of the aid forms provided in an application program, offers explanation or instruction about using the function of application program, information, and help needed while using application program. (Sample components) · Online manual · FAQ management · Q&A management 7.4 Personalization The component that supports user’s interface or information offer according to a user or user needed type. (Sample components) · My page: Manage user-favorite information in the form the user likes such as: content register, modify, delete, view and configure my page. 7.5 Registration The component that registers internal / external users with identifiers for the right to access and use the relevant systems. 7.6 User Experience The component that manages a person's perceptions and responses that result from the use or anticipated use of a product, system or service.
  42. 42. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 42 / 88 Com. No Component area name / Component category name Component category description 7.7 Web Editor The component that supports ability to edit various documents in the web pages. (Sample components) · Web Editor: Manage freely editing the contents by the user at board, and memo pad of library. It shall have the functions of supporting the text & HTML editing function and of image upload and of displaying image to the editor. Web editor can be used at the location of web browser with the input function such as board, announcement, library, and photograph album Table 4-4: Application component areas and categories
  43. 43. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 43 / 88 4.2.3. A sample of reusable component After an organization adopts CBM and establish or select a software development framework, it can develop common components that are the collection of reusable common modules. At the same time, it can utilize the pre-existing components developed by same software development framework. The reusable components consider development and database environment, and MVC pattern6 . Figure 4-5: Common component and software development framework Below table shows the sample component guideline including the detail explanation of business rule, related source code, class diagram and database table. Criteria Description Example Name Name of component Board management Summary Detail information or functions of component Board management component provides registering the post and inquiring list of post registered for management of board to be used commonly for sharing of information between users 6 Model-View-Controller (MVC) is a software architectural pattern. It divided a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user.(Wikipedia)
  44. 44. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 44 / 88 Criteria Description Example Package Dependency Some components related with other components and packages Board package has direct functional dependency to the common package and system package as well as format/calculation/conversion package. Related Source Related source and original source code name Type Source Remarks Controller egovframework.com.cop.bbs. EgovBBSManageController.java Controller class for board management Service egovframework.com.cop.bbs.service. EgovBBSManageService.java Service interface for board management ServiceImpl egovframework.com.cop.bbs.service.impl. EgovBBSManageServiceImpl.java Service implementation class for board management Model egovframework.com.cop.bbs.service. Board.java Model class for board management Model egovframework.com.cop.bbs.service. BoardMaster.java Model class for management of board property information VO egovframework.com.cop.bbs.service. BoardVO.java VO class for board management VO egovframework.com.cop.bbs.service. BoardMasterVO.java VO class for management of board property information DAO egovframework.com.cop.bbs.service.impl. BBSManageDAO.java Data processing class for board management JSP /WEB-INF/jsp/egovframework/com/cop /bbs/EgovNoticeRegist.jsp jsp page for post creation JSP /WEB- INF/jsp/egovframework/com/cop/bbs/ EgovNoticeUpdt.jsp jsp page for update of created post JSP /WEB- INF/jsp/egovframework/com/cop/bbs/ EgovNoticeUpdt.jsp jsp page for update of created post … … … Class Diagram Class relationship diagram
  45. 45. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 45 / 88 Criteria Description Example Related Table Database table information Name Explanation COMTCCMMNDETAILCODE Board code management COMTNBBS Board information management COMTNBBSUSE Board usage management COMTNFILE Board attached file’s attribute management COMTNFILEDETAIL Board attached file’s information management COMTNTMPLATINFO Board template management Related Function Sub function, business rule, execute manual, and screen shot, etc. Board management is composed of post list inquiry, post detail inquiry, post update and answer writing function.  Post list inquiry (sample) Explanation Business rule Provide the screen to inquire the post list. List inquiry screen for posting exists in 3 types including URL link(system use board), access through community and access through society execute manual Board list is inquired by 10 items per page. The paging consists of 10 pages. The condition of search is implemented by the Board name and Board Type. To update the scope of search per page, update pageUnit, pageSize of context-properties.xml file. screen To register new posting, use the Register button on the top. To check the contents of posting, select the title to move to the Posting Detail Inquiry screen Reference See board creation management function Table 4-5: Board management component sample 4.3. Application Interface An interface expresses a software component in terms of its operations, inputs, outputs, and underlying types. It defines functionalities that are independent of their respective implementations, which allows definitions and implementations to vary without compromising the interface. It makes easier to develop an application by providing all the building blocks that can be put together. It can also ease the work of extending applications by facilitating the integration of new features into existing applications (a so-called "plug-in Interface").
  46. 46. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 46 / 88 Benefits Providing information and services through interfaces supports interoperability and openness. Well-designed application interfaces make data freely available for use within agencies, between agencies, in the private sector, or by citizens. 1. Increase the reach of system services by allowing other agencies, partners, and the private sector to integrate, and amplify, government agency’s data and content 2. Save costs by allowing third-party innovators to use information and services to create new, useful products that are beyond the scope - or budget - of government agency 3. Build markets by improving access to government resources like health, economic, energy, education, environmental resources for entrepreneurs to build upon 4. Leverage on government assets: Data and information produced by government agencies are a national asset, paid for by the citizens. APIs can expose data that was only available to a few and make it more available to everyone 5. Automation: It allows machines to handle the workload, which would otherwise require the manual work of a human. In addition, it enables integration between government agencies to run their business workflows so that they can be done with fewer steps and greater productivity without human involvement 6. Integration: It allows data and information exchange to be more easily throughout government agencies or other external enterprise applications. Thus, it ensures a smooth and integrated user experience, and relevant and up-to-date information, for the user. The information is delivered wherever it can be useful to users, not just in those places where data are created and maintained.
  47. 47. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 47 / 88 4.3.1. Application interface classifications The usefulness of an application system is extended when it can be linked or have an interface to another application system. Instead of performing all the functions required, an application system can interface to so that another application system can carry out a specific function and / or to pass processed data. An application interface can be either library-based or protocol- based as shown in Figure 4-6. Figure 4-6: Application interface classifications
  48. 48. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 48 / 88 4.3.2. Application interface description Table 4-6 lists all the recommended application Interfaces. Int. No Interface area name / Interface category name Interface category description 1 Library Based Interface: It is usually related to a software library; the interface describes and prescribes the expected behavior while the library is an actual implementation of this set of rules. It is usually specific to a given technology; hence a Library based Interface for a given language cannot be used in other languages, unless the function calls are wrapped with specific adaptation libraries. 1.1 API Application programming interface (API) comes in the form of a library that includes specifications for routines, data structures, object classes, and variables. To use this type of application interface, an application will reference or import a library of code or of binary functions, and use the functions/routines from that library to perform actions and exchange data and information. Object-Oriented based APIs provide data and functionality organized around classes, as defined in object-oriented languages. Each class offers a discrete set of information (attributes) and associated behaviors (methods). 2 Protocol Based Interface: It is usually a standardized service based on a common protocol (rules for how the service works) and formats (schema for using the service) that are familiar to developers.
  49. 49. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 49 / 88 Int. No Interface area name / Interface category name Interface category description 2.1 TCP/IP It is the computer networking model and set of communications protocols used on the Internet and similar computer networks. It is the most important protocols; the Transmission Control Protocol (TCP) and the Internet Protocol (IP) were the first networking protocols defined in this standard. TCP/IP provides end-to-end connectivity specifying how data should be packetized, addressed, transmitted, routed and received at the destination. This functionality is organized into four abstraction layers which are used to sort all related protocols according to the scope of networking involved From lowest to highest, the layers are the link layer, containing communication methods for data that remains within a single network segment (link); the internet layer, connecting independent networks, thus establishing internetworking; the transport layer handling host-to-host communication; and the application layer, which provides process-to-process data exchange for application. 2.2 HTTP The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web. Hypertext is structured text that uses logical links (hyperlinks) between nodes containing text. HTTP is the protocol to exchange or transfer hypertext. HTTP functions as a request-response protocol in the client- server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server.
  50. 50. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 50 / 88 Int. No Interface area name / Interface category name Interface category description 2.3 FTP File Transfer Protocol (FTP) is a standard network protocol used to copy a file from one host (network/internet connected computer) to another over a TCP-based network, such as the Internet. FTP is built on a client-server architecture and uses separate control and data connections between the client and the server. FTP is the standard method used for transferring files to a website or server and FTP is supported/offered by almost all web hosting companies/providers. 2.4 SOAP Simple object access protocol (SOAP) is a lightweight protocol that allows applications to pass messages and data back and forth between disparate systems in a distributed environment enabling remote method invocation. It codifies the use of XML as an encoding scheme for request and response parameters using HTTP protocol as a means for transport. It possesses send and receive HTTP (or other) transport protocol packets, and process XML messages (envelopes). It covers the following four main areas:  A message format for one-way communication describing how a message can be packed into an XML document.  A description of how a SOAP message should be transported using HTTP (for Web-based interaction) or SMTP (for e-mail-based interaction).  A set of rules that must be followed when processing a SOAP message and a simple classification of the entities involved in processing a SOAP message. A set of conventions on how to turn an RPC call into a SOAP message and back.
  51. 51. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 51 / 88 Int. No Interface area name / Interface category name Interface category description 2.5 REST Representational State Transfer (REST) defines a set of architectural principles by which Web services (Web APIs) can be designed that focus on a system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages. A concrete implementation of a REST Web service follows four basic design principles:  Use HTTP methods explicitly.  Be stateless.  Expose directory structure-like URIs.  Transfer XML, JavaScript Object Notation (JSON), or both. 2.6 GSB The Government Service Bus (GSB) is the national infrastructure that contains integrated structure of hardware and software designed to facilitate exchange of shared government data among government agencies for safe and timely online delivery of services. There are two aspects of integration with GSB. One aspect is integration of a government agency with GSB as a provider of services and data for use by other agencies through GSB. Each government agency can integrate with GBS as a consumer of services and data provided through GSB.
  52. 52. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 52 / 88 Int. No Interface area name / Interface category name Interface category description 2.7 EAI Enterprise application integration (EAI) is an integration framework composed of a collection of technologies and services which form a middleware to enable integration of systems and applications across an enterprise. EAI may involve developing a new total view of an enterprise's business and its applications, seeing how existing applications fit into the new view, and then devising ways to efficiently reuse what already exists while adding new applications and data. Table 4-6 : Application Interface areas and categories
  53. 53. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 53 / 88 4.4. Best Practices & Guidelines Although the application elements were describe in the previous sections, it is also good to follow best practices and guidelines in application design and development. Best practices and guidelines are a compilation of the best methods and techniques globally for application design and development. The basic idea is to learn from the internationally recognized practices so that government agencies can produce quality application systems, components and interfaces. These best practices and guidelines are not mandatory for government agencies. As the name suggest, these are very good things to follow and adopt where possible. Except when specific cases are describe, these best practices and guidelines apply to application systems, components and interfaces. In many instances, they are very much inter- related and, thus, these best practices would be applicable to the application systems, components and interfaces. These best practices and guidelines provide the following benefits: 1. Design and develop qualified application systems, components and interfaces that are agile and reusable 2. Reduce time to develop application systems 3. Prevent costly mistakes and errors commonly made. 4.4.1. Application architectural style An architectural style is a set of principles and patterns that provides an abstract framework for a family of systems. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. Another important benefit of architectural styles is that they provide a common technical architectural language. This facilitates a higher level of conversation that is inclusive of patterns and principles, without getting into specifics. Architectural styles include patterns such as client/server, service-oriented architecture (SOA), and N-tier. It is important to understand that the styles describe different aspects of applications. The following sub-sections list the common architectural styles that should be included in a typical application architecture:
  54. 54. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 54 / 88 4.4.1.1. Client/Server architectural style7 The client/server architectural style describes a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system. This style describes the relationship between a client and one or more servers, where the client initiates one or more requests, waits for replies, and processes the replies on receipt. The server typically authorizes the user and then carries out the processing required to generate the result. The server may send responses using a range of protocols and data formats to communicate information to the client. Common examples of computer applications that use the client/server architectural style are Email, network printer and the World Wide Web. 4.4.1.2. Service-Oriented architectural style Service-oriented architecture (SOA) enables application functionality to be provided as a set of services, and the creation of applications that make use of software services. Services are loosely coupled because they use standards-based interfaces that can be invoked, published, and discovered. The SOA style can package business processes into interoperable services, using a range of protocols and data formats to communicate information. Clients and other services can access local services running on the same tier, or access remote services over a connecting network. The key principles of the SOA architectural style are: 1. Services are autonomous. Each service is maintained, developed, deployed, and versioned independently 2. Services are distributable. Services can be located anywhere on a network, locally or remotely, as long as the network supports the required communication protocols 3. Services are loosely coupled. Each service is independent of others, and can be replaced or updated without breaking applications that use it as long as the interface is still compatible 4. Services share schema and contract, not class. Services share contracts and schemas when they communicate, not internal classes 7 Wikipedia
  55. 55. e-Government Program (Yesser) National Application Reference Model Confidential e-Government Program (Yesser) This document (either in whole or in part) cannot be modified or reproduced without the prior written permission of the e-Government Program (Yesser) Page 55 / 88 5. Compatibility is based on policy. Policy in this case means definition of features such as transport, protocol, and security. The main benefits of the SOA architectural style are: 1. Domain alignment. Reuse of common services with standard interfaces increases business and technology opportunities and reduces cost 2. Abstraction. Services are autonomous and accessed through a formal contract, which provides loose coupling and abstraction 3. Discoverability. Services can expose descriptions that allow other applications and services to locate them and automatically determine the interface 4. Interoperability. Because the protocols and data formats are based on industry standards, the provider and consumer of the service can be built and deployed on different platforms 5. Rationalization. Services can be granular in order to provide specific functionality, rather than duplicating the functionality in number of applications, which removes duplication. 4.4.1.3. N-Tier / 3-Tier architectural style N-tier and 3-tier are architectural deployment styles that describe the separation of functionality into segments each segment being a tier that can be located on a physically separate computer. N-tier application architecture is characterized by the functional decomposition of applications, service components, and their distributed deployment, providing improved scalability, availability, manageability, and resource utilization. Each tier is completely independent from all other tiers, except for those immediately above and below it. N-tier architectures usually have at least three separate logical parts, each located on a separate physical server. Each part is responsible for specific functionality. When using a layered design approach, a layer is deployed on a tier if more than one service or application is dependent on the functionality exposed by the layer. The main benefits of the N-tier/3-tier architectural style are: 1. Maintainability. Because each tier is independent of the other tiers, updates or changes can be carried out without affecting the application as a whole

×