Use Cases of the Application Reference Model in IRAN

Hassan Haghighi

, Maziar Mobasheri

, Farhoud Jafari Kaleibar

and Faezeh Hoseini

Faculty of Computer Science and Engineering, Shahid Beheshti University G.C., Tehran, Iran

Information Technology Organization of Iran, Tehran, Iran

Keywords: e-Government Reference Models, Use Cases of Application Reference Model, Enterprise Architecture.

Abstract: In this article, the main elements of the Iranian Application Reference Model, called INARM, are briefly

introduced. This model includes three levels of systems, application components, and interfaces. In the

“system” section of this model, there are 11 system groups, 74 systems and more than 250 modules. The

section of application components contains 4 application component groups, 36 application components and

more than 100 modules. Finally, the section of interfaces contains 16 interfaces. The mere provision of the

application reference model is not very helpful, and it is necessary to specify the use cases of the model. It is

also necessary to make clear the considerations and risks of using the model for government agencies. In this

regard, this paper describes 10 use cases for the INARM. As a specific use case, the government’s

participation in procuring public software for the agencies (based on INARM and with the aim of cost

reduction in system’s procurement and maintenance, and increasing system quality) is explained.

1 INTRODUCTION

Application Reference Models (ARMs) assist in

categorizing software applications and components

used in government agencies to aid in identifying

opportunities for software sharing and reuse.

ARMs provided in various countries usually

consist of three levels (CIO Council, 2013): Systems,

Application Components, and Interfaces. Systems are

organized for the collection, processing, maintenance,

use, sharing, and dissemination of information in

support of a specific business process. Application

Components are self-contained software that can be

aggregated or configured to support, or contribute to

achieving, many different business objectives. For

example, the document management system can

support multiple IT systems and business processes.

Interfaces are protocols used to transfer information

from system to system.

The national application reference model of Iran,

called INARM, has been developed by studing other

ARMs in the world, reviewing software applications in

the country, investigating the upstream documents and

documents of related projects and researches.

This paper first introduces the main elements of

INARM in addition to reviewing the method to design

this model. Then, it describes the use cases and

applications of INARM. As of the main application,

the government participation in the procurement and

provisioning of public software systems for agencies

(based on INARM) is elaborated in detail.

The reminder of this paper is organized as follows.

In Section two, INARM is briefly introduced. Section

3 describes use cases of INARM. Section 4 ilusstrates

how the government can participate in procuring

public software systems for agencies, based on

INARM. In sectoin 5, some comparison with related

studies is done. Finally, Section 6 concludes the paper.

2 IRAN APPLICATION

REFERENCE MODEL

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 INARM

with respect to the elements in other reference models

3. Reviewing upstream documents which force

some elements to INARM

4. Analyzing software systems provided within

the country with the aim of ensuring the feasibility of

executing INARM in IRAN

To ensure integrity and appropriateness of the

proposed model, in addition to the above activities, we

674

Haghighi, H., Mobasheri, M., Kaleibar, F. and Hoseini, F.

Use Cases of the Application Reference Model in IRAN.

DOI: 10.5220/0007762706740681

In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019), pages 674-681

ISBN: 978-989-758-372-8

studied the process categorization framework

presented by APQC Center (APQC Center, 2016) as

well as comprehensive software solutions (especially

enterprise resource planning solutions) provided by

leading companies.

For performing comparative studies, reference

model documents for countries of the United States

(CIO Council, 2013), Saudi Arabia (National

Enterprise Architecture Office Management at Yesser,

2015), 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), and the

United Kingdom (Walters and Turton, 2012), were

studied.

Then, to ensure the consistency of the application

reference model with other national reference models,

the national performance reference model (Shams

Aliee et al., 2017), the government interoperability

framework (Information Technology Organization of

Iran, 2016), the national service reference model or

business reference model (Shams Aliee et al., 2018)

and the national security reference model (Information

Technology Organization of Iran, 2017) were

investigated. For example, in relation to the service

reference model, we had to make sure that for each

business service in the service reference model, a

module is introduced in the systems or components of

INARM that provides this service.

Subsequently, the materials and sentences in each

of the related upstream documents were studied and

their effects on the INARM were identified. In this

study, all upstream documents, IT development

programs and e-government development programs at

the national level were studied. At last, to analyse the

software systems used more in internal agencies (and

it would be better to consider them in the customization

and localization of the national ARM), 18 software

providers were selected as candidates and their

software products were investigated.

An overall schema of the first part of INARM, the

software systems, is presented in Figure 1. This schema

has four main layers. At the highest level, a dedicated

system for strategic planning is located. The results of

this planning, as 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.

The second layer includes the service management

system. Since the main mission of government

agencies is to provide services to citizens, businesses,

and other government organizations, this layer is

considered the most important layer after the highest

level.

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. All system groups

and systems are shown in Figure 2.

Due to space limitation, we do not present the lists

of INARM application components and interfaces.

3 USE CASES OF INARM

In this section, use cases of INARM for government

agencies and software providers are expressed. To

derive these use cases, the following steps have been

performed:

1. Reviewing the use cases of other countries'

reference models, mentioned in Section 2

2. Interviews with senior managers of the

Ministry of Information and Communications

Technology of Iran

3. Interviews with elected governmental agencies

of Iran

4. Interviews with the executive managers of

some software companies whose products are used by

a significant number of agencies.

Figure 1: An overall schema of INARM.

Use Cases of the Application Reference Model in IRAN

675

Figure 2: Systems Hierarchy of INARM.

3.1 Use Case 1: Reducing the Cost of IT

in Agencies

Each 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.

3.2 Use Case 2: Identifying Appropriate

Software Solutions to Meet the

Requirements of Agencies

The purpose of this use case is to identify the appro-

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

676

priate 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).

3.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.

3.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.

3.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.

3.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. Using the

relationship between INARM and other national

reference models, 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

 The degree of coverage of the required data

 The degree of compliance with the criteria

proposed in the IRAN security reference model

3.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. 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 business process reengineering and improvement of

the organization business.

Use Cases of the Application Reference Model in IRAN

677

3.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).

3.9 Use Case 9: Determining

Performance Metrics

Using 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.

3.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.

4 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.

4. Finally, the current status of any software

system in government agencies is determined based on

available information.

By aggregating the results of the above stages, it is

determined what will be the best practice and level of

government participation for each of the existing

public software systems.

4.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.

4.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.

2. (A2) Development of common application

components (such as document management system)

by the government and delivering them to the agencies.

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.

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

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

678

due to the renewal of the license and / or the software

support period for several agencies.

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 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 to improve and upgrade their software system.

4.3 Mapping the Current States to the

Suitable Actions

Regarding the two previous subsections, Table 1

determines appropriate actions required for each

current status. In Table 2, the current state of each of

the INARM systems, in Iran organizations, is

presented. By observing the status of each system, on

one hand, and using Table 1, on the other hand, it is

possible to infer the actions required for that system.

Table 1: Appropriate actions required for each current status.

Current

State

Related Actions

S1/S3

The following actions should be taken in parallel:

 Action A3 for agencies that do not have the desired system. Negotiations are conducted with the

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.

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.

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.

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.

Table 2: The current state of each of the INARM systems,

in Iran organizations.

Systems

AS-IS

Strategic Planning

External Environment Analysis

Internal Environment Analysis

Identify and Review Strategic Components

Service Management

Service Portfolio Management

Service Development and Deployment

Promotion

Customer Relationship Management

Human Capital Management

Human Resource Planning

Recruitment

Labor and Contracts

Training and Skill Extension

Attendance Management

Employee Information and Records

Retirement

Reward and Retain

Employee Assessment

Employee Relationship Management

Suggestion System

Disciplinary Committee Management

Employee Service Counter

Use Cases of the Application Reference Model in IRAN

679

Table 2: The current state of each of the INARM systems,

in Iran organizations (cont.).

Financial Resource Management

Financing

Planning, Budgeting and Financial Analysis

Cost Accounting and Control

Accounts Receivable

Accounts Payable

General Accounting

Treasury Management

Fixed Asset Accounting

Contract Accounting

Payroll Accounting

Investment and Productive Asset Projects

Accounting

Warehouse Accounting

Tax Management

Internal Controls

Procurement and warehouse

Purchase Order Management

Supplier Relationship Management

Tender and Auction

Purchase and Procurement

Shipping and Logistics

Warehouse Management

Asset Management and Maintenance

Productive Asset Projects

Asset Management

Maintenance

IT Management

IT Planning

Organization Information Management

IT Solution Development/Procurement

IT Solution Deployment

IT Solution Maintenance

Client Management

Organizational Capabilities Development

Organizational Structure and Process

Management

Project Management

Quality Management

Knowledge Management

Change Management

Research, Technology and Innovation

Management

Safety, Health and Environment Management

Organization Performance Management

Business Continuity

Adaption Management

Crisis And Passive Defense Management

Business Recovery

Risk Management

Ad-Hoc Management

Administrative Services

Protection And Physical Security

Vehicle Management

Hospitality

Organizational Collaboration Management

Secretariat And Correspondence Management

Document Archive Management

External Relations

Managing Relationships With Investors,

Industrial And Commercial Group

Managing Relationships With Governmental

Institutions

Legal Advice

International Relationship Management

Public Communication And Media

5 COMPARISON WITH

RELARED STUDIES

In the following, the use cases derived from other

countries, are listed. We present those items defined

for INARM in Italic.

 United States (CIO Council, 2013)

o IT cost reduction through IT/Application

Portfolio Management

o Determining the correct technologies to meet

a well understood business need

 Saudi Arabia (National Enterprise

Architecture Office Management at Yesser, 2015)

o Improving government services to citizens

and businesses

o Enhancing interoperability across

government agencies

o Leveraging on current IT application

investments and assets

o Reducing total cost of ownership on future IT

investments through the use of national shared

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

680

application systems and reusable application

components

o Aligning government agencies’ IT application

systems with national shared application systems

 India (Ministry of Electronics and Information

Technology Government of India, 2017)

o Acting as the bridge between the Business

Reference Model and the Technical Reference Model

o Mapping the commonality of functions of

various domains and identifying the applications and

components

o Enabling government to provide effective and

integrated services to its stakeholders

o Suggesting appropriate methods for software

development

o Defining building blocks required to develop

high-level application architecture

 South Africa (Government Information

Technology Officer’s Council of South Africa, 2010)

o Providing guidance to develop the EA

products/deliverables that form the fundamental

building blocks of an Enterprise Architecture Plan.

o Providing guidance to direct, coordinate,

validate and monitor the performance and

conformance of Enterprise Architecture Plans within

and across departments/agencies

 New Zealand (Deleu and Clendon, 2015)

o Providing a government wide common

language for applications and ICT services

o Identification of opportunities for sharing, re-

use and consolidation of services

o Providing a basis for the objective review of

ICT investment by the government

 United Kingdom (Walters and Turton, 2012).

o Identifying opportunities for re-use

6 CONCLUSIONS

In this paper, 10 use cases were introduced for the

Iranian application reference model, called INARM.

As a specific use case, we described how the

government can participate in procuring or

development of public software for the government

agencies. As some directions of future work, the

following cases are aimed:

 Designing a framework for assessing the

quality of developed systems based on INARM

 Developing a tool to support the mapping of

organizations' systems and business requirements to

INARM

ACKNOWLEDGEMENTS

This paper is based upon work supported by the

Information Technology Organization of Iran. We

express our gratitude to Dr. Nazemi, Dr. Saraian and

Mr. Bagheriasl for their great support.

REFERENCES

CIO Council (2013). Federal enterprise architecture

framework.

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.

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 Organization of Iran (2016).

Electronic Government Interoperability Framework (e-

GIF) (In Persian).

Information Technology Organization of Iran (2017). Iran

Security Reference Model (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.

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

Proc. of the 19th International Conference on Enterprise

Information Systems, Portugal, April, 2017.

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.

Use Cases of the Application Reference Model in IRAN

681