1. Introduction

Information technology has been a priority for the Iranian government in the last four years. The government’s efforts to find out IT challenges and barriers in public sectors and agencies result in a solution in enterprise architecture (EA) area.  Focusing on EA, the EA experts realized that a national EA framework is a workable and ideal solution.

As an important section of the national EA framework, Iran’s National Application Reference Model (called INARM) was released in 2018 by the Information Technology Organization (ITO). In this document, we provide a brief report on the INARM.

 

2. ARM

E-government reference models are specifically defined for each government, in order to indicate relationships among government’s IT assets, enforce standards and specify a high-level framework for the government agencies. The Application Reference Model (ARM) is a categorization of different types of software, application components and interfaces.

ARM provides the basis for categorizing software applications and components used in government agencies to aid in identifying opportunities for software sharing and reuse. The information in ARM may be used in conjunction with the other reference models to identify these opportunities.

ARM consists of three levels: Systems, Application Components, and Interfaces.

• Systems are discrete sets of information technology, data, and related resources, organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of information in support of a specific business process. The ARM “Systems” category does not include mission-specific systems. In other words, it is restricted to the public (mission-independent) sections of agencies.
• Application Components are self-contained software that can be aggregated or configured to support, or contribute to achieving, many different business objectives. For example, workflow management, document management, records management and many other types of components can support multiple IT systems and business processes.
• Interfaces are protocols used to transfer information from system to system.

 

 

 

 

3. ARM in Iran

Over a decade of Enterprise Architecture lifetime in Iran, despite the vast achievements in this field, one of the major problems is lack of national reference models, including the national ARM, in the country. This resulted in challenges and obstacles to the maximum achievement of architectural designs and, more importantly, not symmetrical and integrated development of e-government in government agencies.

The following are the most remarkable reasons for proposing the ARM of Iran:

1. Reducing the cost of purchasing/renewal of software licenses at any government agency
2. Establishing an approach for systematically finding suitable software solutions for business needs of the government agencies
3. Providing a reference to unify the views of each government agency to software solutions
4. Creating a platform for balanced and consistent development of software systems in government agencies
5. Providing a platform for evaluating the progress of e-government plans and maturity of enterprise architectures in government agencies (just in the application layer)
6. Better management of software portfolios with a global view to the entire government and agencies for increasing collaboration throughout the government
7. Supporting current plans for IT investments
8. Assisting government agencies to eliminate spoof and replications, enhance sharing services and decline performance gaps

 

According to the above description, the national application reference model of Iran, called INARM, have been developed, by the support of “Iran Information Technology Organization”. INARM has been developed based on extensive comparative studies, reviewing existing software applications in the country, investigating the upstream documents and documents of related projects and researches.

4. INARM Development Method

The following activities have been performed to develop INARM:

1. Performing comparative studies on application reference models of selected countries
2. Reviewing other national reference models to identify items that should be considered in the national application reference model with respect to the elements in other reference models
3. Reviewing upstream documents which force some elements to the application reference model
4. Analyzing software systems provided within the country (in the area of public and common software) with the aim of making INARM close to the current state (as much as possible) and ensuring the feasibility of executing INARM in IRAN

 

Activities 2, 3 and 4 have been considered to localize the patterns derived from the first activity. Moreover, to ensure integrity and appropriateness of the proposed model, in addition to the above activities, we studied the process categorization framework presented by APQC Center as well as comprehensive software solutions (especially enterprise resource planning solutions) provided by leading companies such as SAP[1] and Sage[2].

4.1. Comparative studies

According to the development method of INARM, one of the main entries has been the results of comparative studies on reference models of selected countries. Initially, countries which had activities in e-government and reference models were identified. These included more than 40 countries. Then, 7 countries were selected from the initial list of 40 candidate countries based on the following general and specialized criteria:

General criteria:

• E-government Rank: this criterion represents the current rank of e-government across countries.
• E-government Archaism: this criterion represents the age of e-government in the country.
• Existence of ARM
• Existence of Other Reference Models: this criterion indicates the existence of other reference models alongside the application reference model.
• Availability of Related Documents
• Vicinity to Iran
• Diversity in Country Selection(Preferably from different continents)

 

Specific criteria:

• The existence of a list of software systems and their categorizations in accessible documents.
• The availability of information about relationships among proposed systems in accessible documents.
• The existence of a list of application components and their categorizations in accessible documents.
• The availability of information about relationships among proposed application components in accessible documents.
• The existence of information about interfaces and their details in accessible documents.
• The existence of information about relationship among ARM and other reference models.
• The existence of standards, technologies, best practices and guiding principles in the corresponding reference model.

 

According to the calculated scores based on the above criteria, the following countries achieved higher scores:

• The United States (CIO Council, 2013)
• India (Ministry of Electronics and Information Technology Government of India, 2017)
• South Africa (Government Information Technology Officer’s Council of South Africa, 2010)
• Australia (Australian Government Information Management Office, 2011).
• New Zealand (Deleu and Clendon, 2015)
• Great Britain (Walters and Turton, 2012)
• Saudi Arabia (National Enterprise Architecture Office Management at Yesser, 2015)

 

The existing and related documents from the above countries were studied and used as patterns for the development of INARM.

4.2. Review on Other National Reference Models

In this phase, the following national reference models were studied:

1. IRAN Performance Reference Model (Shams Aliee et al., 2017)
2. IRAN Service Reference Model (Business Reference Model) (Shams Aliee et al., 2018)
3. IRAN Government Interoperability Framework (Information Technology Organization of Iran, 2016)
4. IRAN Security Reference Model (Information Technology Organization of Iran, 2017)

 

4.2.1. Performance Reference Model

The Performance Reference Model (PRM) defines the metrics needed to manage and monitor inputs, operations and outputs of the organization. In this part, we had to make sure that for each metric of the IRAN PRM, there are module(s) in software system(s) or application component(s) of INARM which support the measurement of the value of that metric.

4.2.2. Service Reference Model

In this part, we had to ensure that for each business service in the IRAN SRM, there is at least one module in INARM which supports provisioning of that service. We only considered those sections of the IRAN SRM that contain public and common services, because addressing the specialized services of each agency is not within the scope of ARMs.

4.2.3. Government Interoperability Framework

The government interoperability framework includes various sections to explain the interoperability among government agencies. Our study has only considered the section of this framework which defines some common data entities among agencies. In this part, we had to make sure that for each data entity of the government interoperability framework, there is at least one module in systems or application components of INARM which manages (creates, edits, deletes) this data entity.

4.2.4. Security Reference Model

By studying the Security Reference Model (SeRM) of IRAN, it became clear that several parts of this model are important with respect to the ARM. The first significant part is software related standards presented in the SeRM. The second part is security’s basic principles. These principles have components and sub-components that had to be considered in INARM. Finally, as the last part, in the IRAN SeRM, different maturity levels of the security along with characteristics of each level are expressed in four areas: individuals, infrastructure, data, and software. We had to ensure that the components of each maturity level are covered by the systems and application components of INARM.

 

4.3. Review on Upstream Documents

In this phase, the content of up to 20 upstream documents, IT development programs and e-government development plans at the national level were studied and their impacts on INARM were identified. Some of the documents studied are:

• The 20-year vision of the development of the Islamic Republic of Iran
• The sixth 5-year plan for the development of the Islamic Republic of Iran (Islamic Parliament of Iran, 2017)
• The master plan of information technology in IRAN (Ministry of Communication and Information Technology, Government of Iran, 2008)
• Technical standards for e-government development in IRAN (Ministry of Communication and Information Technology, Government of Iran, 2014)
• Regulations for electronic services of government agencies (Superior Administrative Council of Iran, 2014)
• The strategic plan of information community of Iran (Shahriari, 2009)
• The roadmap of the m-government deployment in IRAN (Information Technology Center of Presidency of Iran, 2015)

 

For example, a few items extracted from upstream documents are listed below:

• Technical standards for e-government development in IRAN: All government agencies are obliged to develop a system for receiving questions, criticisms, suggestions, and complaints (requirement to existence of a specific system in INARM).
• The master plan of information technology in IRAN: The knowledge management system should be developed at the agencies level to share knowledge, skills and experience of government employees (requirement to existence of a specific application component in INARM).
• The strategic plan of information community of Iran: A system should be developed for continuous assessment of human resources skills in all agencies and organizations (requirement to existence of a specific system in INARM).

 

4.4. Internal Software Analysis

In order to analyze the software systems which are used more in internal agencies (and it would be better to consider them in the customization and localization of the national ARM), a number of software providers were selected as candidates and their software products were investigated. Among the various software providers in Iran, 18 companies were surveyed. This selection has been made based on various criteria such as available resources, reputation of the company and the multiplicity of the use of systems provided by the company in government agencies. After selection of candidate providers, all systems and sub-systems provided by these companies were investigated. We restricted the investigation to public and common software, usually used by government organizations.

Following these studies, software solutions provided by companies were matched with eight service domains presented in the IRAN SRM (Shams Aliee et al., 2018). These service domains include stakeholders’ relationships management, organizational capabilities development, planning and strategy, IT management, administrative services, asset management, financial resources management, and human capital management. The matching degree was calculated in terms of similarity of main functionalities and the coverage percentage of each of the service domains by the provided solutions. To do this, four coverage scores were considered (see Table 1).

 

Table 1: Coverage scores

Score	Description
0	No Coverage (NC): In this case, no service group of a service domain are covered by the system under review.
1	Low Coverage (LC): In this case, up to 30% of the service groups of a service domain are covered by the system under review.
2	Medium Coverage (MC): In this case, up to 60% of the service groups of a service domain are covered by the system under review.
3	Complete Coverage (CC): In this case, almost all service groups of a service domain are covered by the system under review.

 

The number of companies (of 18 under investigation companies) that achieved each of the above scores per service domain is shown in Table 2.

      

Table 2: The number of companies for each coverage score, and for each service domain

Domain name	NC	LC	MC	CC
Human Capital Management	1	8	7	2
Financial Resources Management	0	8	6	4
Asset Management	3	3	9	3
Administrative Services	8	10	0	0
IT Management	11	7	0	0
Planning and Strategy	6	12	0	0
Organizational Capability Development	8	10	0	0
Stakeholders’ Relationships Management	8	9	1	0

 

The chart in Figure 1 represents the coverage percentage of each of the service domains of the IRAN SRM by the studied software solutions. As shown, the three domains including human capital management, financial resources management and asset management have the highest coverage percentage, followed by planning and strategy and stakeholders’ relationships management. Since the systems provided by the companies under review are most likely to be used in most agencies, the presented percentages can be viewed as representation of the current state of the application layer architecture of the agencies toward the service domains of the IRAN SRM. Parts of the IRAN SRM which are not covered by the current software solutions had to be particularly seen in INARM in order to ensure the provisioning of them with a government-designated plan.

 

Figure 1: Coverage percentage of each of the service domains of the IRAN SRM

5. Iran Application Reference Model (INARM)

Like many other ARMs, INARM consists of three levels: Systems, Application Components, and Interfaces (see Section 2). In the following, these three layers are reviewed briefly.

Figure 2: An overall schema of INARM

Figure 3: Systems Hierarchy 

 

An overall schema of the first part of INARM, the software systems, is presented in Figure 2. This schema has four main layers. At the highest level, a dedicated system for strategic planning is located. Based on the internal and external analysis of the organization, this system addresses the strategic components of the organization, including the vision, mission, strategies, goals, and so on. The results of this planning, one of the main inputs, are presented to almost all the other systems of INARM to provide the basis for operational planning in each of these systems.   5.1. Systems

The second layer includes the product management system. Since the main mission of government agencies is to provide products (including goods, services and licenses) to citizens, businesses, and other government organizations, this layer is considered the most important layer after the highest level. The systems in this layer deals with areas related to the management of products provided to organization's customers (including the identification and planning of products to be provided, development, deployment and promotion of these products, and finally, customer relationship management).

The third layer deals with other public systems that act as back-office systems. This layer consists of 9 system groups, each of which in turn consists of several systems. Each system is also contains several modules.

Finally, there is the “Basic Information System” which is responsible for recording common data and information used by other systems. The hierarchy of all systems is shown in Figure 3. At the first level, system groups and, secondly, systems of each system group are presented.

It should be noted that in the main document of INARM, the detailed lists of all systems have been presented in three layers: firstly, system groups, then, systems, and finally, modules belonging to each system.

In Table 3, a part of the detailed list of the “Human Capital Management” system group (including just two of its systems, .i.e., “Human Resource Planning” and “Recruitment”, and the corresponding modules) are provided as a sample.

Table 3: The Human Capital Management system group

System Group/System/Module	Description
Human Capital Management	This software manages the agencies human resources and is created with the goal of optimizing human resources in the agencies and maximizing the efficiency of employees. It includes functions such as definition and management of career paths, recruitment, performance evaluation, training, and attendance management.
Human Resource Planning	A software which is responsible for planning in all different areas of human capital including recruitment, welfare, employee evaluation, retirement and etc.
Develop Human Resource Plan	Module that supports the development of human resource program in all areas of human capital. The program in each of these areas includes scheduling, cost estimation, risk analysis and resource allocation.
Monitor and Update Human Capital Plan	Module that includes the following functions: -          Measure goal achievement -          Assess participation in goals -          Revision and modification of the human capital plan -          Inform and present updated plans to stakeholders
Estimate Human Resources Need	Module that includes the functions of estimating organization’s need for human resources. This module includes the following functions: -          Identify strategic human resource needs -          Determine the roles and responsibilities required -          Collect needed skills -          Determine human resource costs -          Determine criteria for human resources -          Plan for urgent recruitment
Recruitment	All actions related to managing recruitment requests, selecting candidates, hiring and managing volunteer’s information are provided in this system.
Manage Recruitment Requests	Module that includes the following functions: -          Determine recruitment methods -          Find source of  workforce -          Advertise recruitment requests -          Manage advertising websites -          Update recruitment requests
Volunteer Information Management	Module that includes the following functions: -          Collect background information for volunteers -          Create file for applicants -          Record applicant information -          Complete the classification of the status and level of experience -          Archive and retain the records of those who are not hired -          Create a talent pool
Screen & Select Volunteers	Module that includes the following functions: -          Define the talent identification method and related indicators -          Issuance of the card for recruitment exam -          Conduct an evaluation for each round of talent identification -          Interview with the volunteers -          Select and dismiss volunteers
Recruit new workforce	Module that includes the following functions: -          Develop and submit a job offer to the new workforce -          Negotiate with a new workforce about the offer -          Recruit volunteer
Ceremony of the beginning of work	Module that supports the procedures for entering and starting new employees, such as referrals and on-the-job training, assignment of duties, personal filing, assignment of workplaces and equipment.

 

5.2. Application Components

The hierarchy of all application components of INARM is presented in Figure 4. At the first level, application component groups, and in the second level, the components of each group are specified.

In Table 4, a part of the detailed list of the “Software Development Management” application component group (including just one of its components, .i.e., “Document Management System”, and the corresponding modules) are provided as a sample.

 

Figure 4: Application Components

Table 4: The Software Development Management component group

Application Component Group/Application Component/Module	Description
Software Development Management	This group includes all functional components that can be used to develop enterprise software systems.
Document Management System	This software controls and manages the storage and maintenance of documents and files of an organization.
Scan & Upload Documents	Module that supports scan and upload of documents.
Refer Documents	Module that supports referrals to other documents and information to access related content.
Search & Retrieve Documents	Module that supports search and retrieve documents through a structured dataset.
Manage, Control and Verify Documents Versions	Module that supports editing, versioning and approval of documents before publishing them.
Library/Document Storage	Module that supports storage and archive of documents.

 

At last, it is worth noting that, we provided a list of 16 interfaces in INARM. But we ignore presenting them here because of the lack of space.

 

6. Use cases of INARM

In this section, use cases of INARM for government agencies and software providers are expressed. For each use case, in addition to the description of the case, we have developed a step-by-step approach and the risks and considerations that apply to its use (if any). However, in this document, there is merely a description of the use cases and related risks and considerations.

6.1. Use case 1: Reducing the cost of IT in agencies

Each of the agencies includes several sub-agencies with modern and legacy software systems. Each agency and sub-agency has its own portfolio of software systems. There is almost no doubt about the existence of duplicate systems in the government agencies and even within the sub-agencies of an agency. Obviously, the government and any agency are looking for an opportunity to reduce the cost of IT by removing duplicated software.

To detect duplicated software in agencies, the information of all the software available in agencies and sub-agencies should be mapped to INARM. After mapping, INARM needs to be searched in order to find opportunities for sharing and reusing software, integrating information systems, negotiating for sharing licenses, and negotiating with companies for price reductions. In this way, mappings are reviewed across government and government agencies in Iran to identify opportunities for sharing and reusing software. This analysis may lead to the following cases:

• The integration of existing applications
• The integration of licenses into licenses at the level of an agency (and in some cases at the level of all agencies)
• The choice of a new solution on the agency level (and in some cases at the level of all agencies), which is hosted on a cloud
• Changing the business processes of an agency to allow the reuse of an existing system

 

Regarding this use case, the following risks and considerations are raised:

• Agencies do not collaborate on the periodic mapping of their existing systems, modules, and components to INARM.
• Each government agency has its own portfolio of legacy and modern software systems. The mapping to INARM should be done at the appropriate granularity level and in the form of the components and taxonomy of INARM in order to maximize the level of shared software detection.
• Although the public consensus confirms the existence of duplicate information systems, it is difficult to identify them. In some cases, although the functions and capabilities of some systems are the same, but when components of these systems are mapped to INARM, they are not necessarily mapped to the same systems and models; this is because different companies might implement features and functions of the system through different architectures and structures. In other words, existing systems would have met the common requirements and functions of organizations in a variety of ways. For this reason, the identification of duplicate information systems should not merely consider system features; so, it is recommended to map, search and investigate common systems with respect to system capabilities instead of system features.
• The lack of effective cooperation between agencies in integrating or aggregating licenses, unifying systems, etc., due to the slowdown in the structure and processes of agencies
• The need for government support and accompany, especially by ITO, when negotiating with software providers to integrate and aggregate licenses, for example by providing incentive plans
• The lack of sufficient and high quality documentation about the current state of software systems as a prerequisite for mapping

 

6.2. Use case 2: Identifying appropriate software solutions to meet the requirements of agencies

The purpose of this use case is to identify the appropriate software solutions and technologies to meet the identified business requirements in an agency, as well as supporting the sharing perspective. This case also shows how INARM can be used in conjunction with other national reference models to reuse existing IT assets.

In order to achieve this goal, IT custodians and enterprise architects use the mapping repository of INARM (as described in use case 1) to identify systems, services, and solutions that may meet the requirements of an organization. But the prerequisite is to map the business requirements of the organization to the elements of INARM. In this way, and indirectly, the mapping between the business requirements of an organization and the existing software and IT solutions in Iran are obtained. By mapping between INARM and other national reference models, this case is not limited to the ARM; but also, the mapping of requirements to the elements of the other reference models can be identified (indirectly). Therefore, it is possible to identify the required components and potential for reuse, at the data, technology and security levels, as well. With all the inferred information, the responsible decision-makers in the organization can use standard methods to carry out a targeted data-driven analysis and identify a solution (if any) that adequately matches the organization's environment and its goals.

Regarding this use case, the following risks and considerations are raised:

• Both within the agencies and across the government, there may be many solutions that can be potential candidates. Therefore, quick and easy decision making (to choose the best solution) using available information is important.
• The lack of mapping other enterprise architecture layers of agencies (especially, technology and security) to the corresponding national reference model.
• There may be proper solutions in non-government organizations, but because they are not used by any government agency, they are not mentioned in the INRAM repository. Therefore, it is impossible to identify these solutions.

6.3. Use case 3: Evaluating the organizations in terms of the maturity of software systems

INARM has been developed based on the IRAN service reference model, considering other national reference models (to align with these models and having effective communication with them), benchmarking reference models of other countries, benchmarking known domestic and foreign software, and finally based on the upstream laws of the country and the up to date standards of software development. Therefore, it is a good baseline for assessing the maturity level of organizations' software systems and the digitalization level of their business needs and processes. By mapping existing software systems into INARM, on one hand, and mapping business requirements of organizations to INARM, on the other hand, and finally, assessing the extent of the requirements covered by the current systems of each organization, and the number of uncovered but coverable requirements by INARM, we can measure the maturity of organizations from the software systems perspective.

Regarding this use case, the following risks and considerations are raised:

• It may be difficult to determine the exact criteria for comparison based on the reference model.
• The lack of cooperation of organizations in mapping existing systems, modules and components to INARM
• The lack of cooperation of organizations in mapping their requirements to INARM

6.4. Use case 4: Facilitating the design of enterprise architecture

Government agencies can utilize the elements of INARM, as a main input and pattern, to design the application layer (at least the part of public and common applications) of their enterprise architecture.

Regarding this use case, the following risks and considerations are raised:

• Misunderstanding of agencies about enterprise architecture and reference models

6.5. Use case 5: Detecting opportunities for developing new systems

Companies providing enterprise software systems can detect opportunities for developing new systems by comparing the current state of systems existing in government organizations and the elements of ARM. Because, based on policies of the Iranian enterprise architecture framework, government agencies are moving toward the maximum compliance with INARM, agencies more likely will need new software to cover their requirements and upgrade their organization through more alignment with the ARM. As a result, software providers can take precedence in this area and add new systems needed by organizations in their solution portfolio.

Regarding this use case, the following risks and considerations are raised:

• The lack of knowledge and understanding of software providers about INARM
• The lack of cooperation of government agencies in mapping their existing systems, modules, and components to INARM

6.6. Use case 6: Providing a mechanism for ranking software providers

It is possible to examine the coverage of the systems, components, and functions proposed in INARM by the enterprise systems provided by the companies and, accordingly, rank these companies. In this regard, using the relationship between INARM and other national reference models, including the IRAN service reference model (Shams Aliee et al., 2018), the IRAN performance reference model (Shams Aliee et al., 2017), the IRAN security reference model, and the IRAN government interoperability framework, we can identify broader criteria for assessing software providers. Some metrics for ranking these providers are as follows:

• The degree of support for required functions (based on the mapping to INARM)
• The degree of support for calculating performance measures (based on the relationship between INARM and the IRAN performance reference model)
• The degree of coverage of the required data (based on the relationship between INARM and the IRAN government interoperability framework)
• The degree of overlap between the software components of the company and the elements in INARM
• The degree of compliance with the criteria proposed in the IRAN security reference model (based on the relationship between INARM and the IRAN security reference model)

 

Regarding this use case, the following risks and considerations are raised:

• Extracting criteria and assessment metrics from reference models and the relations between these models is difficult.
• Measurement of criteria and scoring requires a precise mechanism and may not be easily achieved.

 

6.7. Use case 7: Identifying new requirements and improving processes in organizations

By mapping the organization's existing systems into INARM, some deficiencies can be identified in the organization. So that some systems that are in INARM and are not available in the organization may be useful to the organization, even if the organization so far did not feel the need. Perhaps, the necessity of using such systems will lead to the business process reengineering and improvement of the organization business.

Regarding this use case, the following risks and considerations are raised:

• The lack of cooperation of organizations in mapping existing systems, modules and components to INARM

 

 

6.8. Use case 8: Finding opportunities for partnership with other software providers

Using the mappings of the solutions provided by software providers to the elements of INARM, these companies can both upgrade their systems and partner with other companies to provide integrated solutions (through engagement with each other to cover gaps in accordance with INARM).

Regarding this use case, the following risks and considerations are raised:

• Privacy considerations in providers' ideas, solutions, and systems that impede the establishment of a repository for their solutions
• A competitive environment between software providers
• The difficulty of partnership between software providers, due to the different technologies and platforms used by them

6.9. Use case 9: Determining performance metrics

Using the relationship between INARM and the IRAN performance reference model, we can determine the performance metrics that government agencies and software providers must take into account in procurement, developing and deploying enterprise software. Regarding the relationship between INARM and the IRAN performance reference model, when developing a new software system or component, it is possible to determine the relevant metrics and their computation mechanism.

Regarding this use case, the following risks and considerations are raised:

• The lack of knowledge and understanding of software providers about INARM and the relationship between national reference models

6.10. Use case 10: Determining security issues

Using the relationship between INARM and the IRAN security reference model, security standards, technologies and principles that government agencies and software providers have to consider in procurement, developing, and deploying any enterprise software can be identified. As a result, systems developed or procured will be based as far as possible on the security standards and principles set out in the IRAN security reference model.

Regarding this use case, the following risks and considerations are raised:

• The complexity of the trade-off between the importance of each principle and standard on one hand, and the budget of the organization on the other hand
• The lack of knowledge and understanding of software providers about INARM and the relationship between national reference models

 

7. Government Participation

In this section, as the main application of the national ARM, the ways of government involvement in the provision and procurement of public software systems for the agencies (based on INARM) are expressed. In this regard,

1. First, the types of the current states of the public software in agencies are explained.
2. Then, the types of government actions to procure public software systems are expressed.
3. At the third stage, we determine appropriate actions required for each current status.

By aggregating the results of the above stages as well as determining the current status of any software system in government agencies, it can be determined what will be the best practice and level of government participation for each of the existing public software systems.

 

7.1. Different categories of the current state of public software

We categorize the current state of public software systems in governmental agencies as follows:

1. Average or the high percentage of the agencies uses this software system.

• (S1) compared to INARM, modules and functions available in at least some of the instances of this software system are relatively complete, and these instances also have acceptable quality.
• (S2) in comparison with INARM, modules and functions available in all instances of this software system have significant defects, or these instances do not have acceptable quality.

2. A small percentage of the agencies have this software system.

• (S3) compared to INARM, modules and functions available in at least some of the instances of this software system are relatively complete, and these instances also have acceptable quality.
• (S4) in comparison with INARM, modules and functions available in all instances of this software system have significant defects, or these instances do not have acceptable quality.

3. (S5) none of the agencies have this software system.

7.2. Various types of government actions

We consider the following actions that the government can take to participate in software procurement for agencies:

1. (A1) Development of the software system by the government and delivering it to the agencies. If the government cloud platform is ready, then it is better to deliver the software system in the form of SaaS, so that the cost of provision is reduced and the processes of maintaining and delivering the system are also simplified.
2. (A2) The government develops common application components such as document management system, content management system, geographic information system, business intelligence, business process management and automation, etc., and deliver them to the agencies. In this way, in case of a defect of software systems due to the lack of these components, agencies can use the components provided by the government. If the government cloud platform is ready, it is better to provide these components on the government cloud platform, in the form of SaaS or PaaS, in order to reducing the cost of delivering and to simplify the processes of maintaining and providing the application components.
3. (A3) The government can negotiate and come to an agreement with one or more selected software providers to buy a software license for bulk purchases (for several agencies). Certainly, the basis of the negotiation should be considering significant discounts due to one-off sales of the software to several agencies. The advantage of this mechanism for the government is saving software costs, simpler maintenance, and more effective integration between software systems of various agencies. The advantage for software providers is to sale their software product to more agencies at the same time. If the government cloud platform is ready and the purchased software can be delivered in the form of SaaS, the benefits will be higher for both parties. There are the following open issues that should be investigated in the future:

• How many software providers should be selected for each system?
• What are the criteria for choosing candidate software providers?
• How to determine the amount of discounts due to major purchases?
• How to define possible benefits for both parties, exactly?

4. (A4) The government negotiates and agrees with one or more selected software provider to extend the software license time period in bulk (i.e., with respect to several agencies). Certainly, the basis of the negotiation should be considering significant discounts due to the renewal of the license and / or the software support period for several agencies. The benefits and open issues defined for action A3 can also be defined here.
5. (A5) The government forces using the template provided in INARM to prepare RFP for the development of public software.
6. (A6) The government forces using the standards, principles and best practices mentioned in INARM to develop public software.
7. (A7) The government obligates agencies to replace their existing software systems which are low-quality or do not have acceptable compliance with INARM, with more appropriate systems.
8. (A8) The government can negotiate and make an agreement with the software providers whose software products are used by a significant number of agencies, but do not have acceptable compliance with INARM, or its quality is not accepted, to improve and upgrade their software system.

 

7.3. Mapping the current states to the suitable actions

Regarding the two previous subsections, Table 5 determines appropriate actions required for each current status.

Table 5: Appropriate actions required for each current status

Current State	Related Actions
S1	The following actions should be taken in parallel: ·         Action A3 for agencies that do not have the desired system. Negotiations are conducted with the software provider(s) whose software products have the highest quality and the most alignment with INARM. ·         Action A4 for agencies that have the desired system. Negotiations are conducted with the software provider(s) whose software products have the highest quality and the most alignment with INARM. ·         Action A7 for agencies whose systems have low quality or low compliance with INARM.
S2	1-       First, take action A8. Actions A5 and A6 will also be used to upgrade existing systems. In addition, if the deficiencies are due to the lack of high quality common application components, action A2 will also be used accordingly. 2-      Then, the actions mentioned in the first row should be done in parallel.
S3	Like the first row (S1)
S4	1-       First, take action A1. In the development of the new system common application components (whether existing or made from the first) should be used, as far as possible. Also, for the development of these systems, actions A5 and A6 will also be used. 2-      Then, action A7 will be done for agencies whose systems have low quality or low compliance with INARM.
S5	First, take action A1. In the development of the new system common application components (whether existing or made from the first) should be used, as far as possible. Also, for the development of these systems, actions A5 and A6 will also be used.

 

By determining the status of each system in government agencies, on one hand, and using Table 5, on the other hand, it is possible to infer the actions required for that system.

 

 

 

References

APQC Center (2016). APQC’s Process Classification Framework.

Australian Government Information Management Office (2011). Australian government architecture reference models. www.finance.gov.au/sites/default/files/agaref- models.pdf.

CIO Council (2013). Federal enterprise architecture framework.

Deleu, R. and Clendon, J. (2015). Gea-nz v3.1business reference model and taxonomy. https://www.ict.govt.nz/assets/Guidance-and-Resources/GEA-NZ-v3.1-Business-Reference-Model-and-Taxonomy.pdf.

Government Information Technology Officer’s Council of South Africa (2010). Government-Wide Enterprise Architecture (GWEA) Framework Implementation Guide.

Information Technology Center of Presidency of Iran (2015). The roadmap of the m-government deployment in IRAN (In Persian).

Information Technology Organization of Iran (2016). Electronic Government Interoperability Framework (e-GIF) (In Persian).

Information Technology Organization of Iran (2017). Iran Security Reference Model (In Persian).

Islamic Parliament of Iran (2017). The sixth 5-year plan for the development of the Islamic Republic of Iran (In Persian).

Ministry of Communication and Information Technology, Government of Iran (2008). The master plan of information technology in IRAN (In Persian).

Ministry of Communication and Information Technology Government of Iran (2014). Technical standards for e-government development in IRAN (In Persian).

Ministry of Electronics and Information Technology Government of India (2017). IndEA Framework (India Enterprise Architecture Framework).

National Enterprise Architecture Office Management at Yesser (2015). National Application Reference Model.

Shahriari, H. (2009). The strategic plan of information community of Iran (In Persian).

Shams Aliee, F., Bagheriasl, R., Mahjoorian, A., Mobasheri, M., Hosieni, F. and Golpayegani, D. (2018). A Classification Taxonomy for Public Services in Iran. ICEIS (2) 2018: 712-718.

Shams Aliee, F., Bagheriasl, R., Mahjoorian, A., Mobasheri, M., Hoseini, F., and Golpayegani, D. (2017). Towards a national enterprise architecture framework in iran. In ICEIS 2017 - Proceedings of the 19th International Conference on Enterprise Information Systems, Volume 3, Porto, Portugal, April 26-29, 2017, pages 448–453.

Superior Administrative Council of Iran (2014). Regulations for electronic services of government agencies (In Persian).

Walters, S. and Turton, P. (2012). UK Government Reference Architecture.

https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/266169/govt-ict-sip.pdf.

[1] https://www.sap.com/index.html

[2] https://www.sage.com/company