International Journal of Research in Management, Science & Technology (E-ISSN: 2321-3264)
Vol. 4, No. 1, April 2016
An Experiment Applying the Enterprise
Architecture Case Study: Algerian
Government Agency
Mache Salah
Computer Science Department,
University ElBachir ElIbrahimi
Bordj BouArreridj, Algeria
maachesalah@gmail.com
Abstract-- Companies are always looking for ways to
solve the equation "do more and better with less." The
current difficulties encountered in companies such as: -
Environment increasingly competitive; - Complexity
produced because of the lack of model that describes the
companys operations or the existing enterprise models
not followed; - Lack of consistency between the
Information Technology IT solutions; - Successive
generation IT solutions; - lack of alignment between
business strategy and IT strategy; - difficult to anticipate
IT solutions; - Lack of agility due to lack of target
models for the enterprise transformation. All these
issues and others appear in Algerian firms more than
firms in developed countries, that's why this area has
drawn our attention and forced us to look for solutions
and propose case studies based on the only solution
currently exists for deal with such complex issues is the
Enterprise Architecture EA. These case studies aim to: -
show the EA promise to enterprises; clarify and simplify
the application of EA techniques to enterprises; enrich
the field cases EA studies who suffers from a major lack
in this level. So in this paper, we present an enterprise
architecture building case study for an Algerian public
organization using the framework TOGAF and the
modeling language and notation ArchiMate. Before
starting the description of this work we will do a fly over
on the theoretical aspects, definitions, frameworks,
languages and tools used in this study.
Keywords-- Enterprise Architecture EA, Information
Technology, Enterprise Management, TOGAF,
Archimate.
1. INTRODUCTION
The architecture of business is the rigorous description of all
structures, behavior and information within a company, it
affects the areas business, information, application and
technology. Its main objective to align business strategy
with IT strategy. To build a successful enterprise
architecture, efficient and applicable, it will follow a well-
defined approach based on best practices framework,
TOGAF is the most used, which proposes a method and also
a full content of architecture. TOGAF does not impose
specific notations for that we need a modeling language and
notation, the most adapted to the TOGAF is ArchiMate.
So in this work we will detail our contribution that is a case
study based on TOGAF and ArchiMate for build an
enterprise architecture of an Algerian public organization
2321-3264/Copyright2016, IJRMST, April 2016
Available at www.ijrmst.org
CNR "National retirement fund", before beginning this
study we will fly over the definitions and theoretical
approaches which rotates around TOGAF and ArchiMate.
2. ARCHITECTURE ENTREPRISE
In this section we will try to explain what's enterprise
architecture, the layers of EA, will finally see the TOGAF
framework and the modeling language and notation used in
this work.
2.1 Definitions
The EA field is a new field, for that we find several
definitions proposed by researchers in the field [2], we may
mention in particular the following:
1. the set of primitive, descriptive artifacts that constitute
the knowledge infrastructure of the Enterprise [13];
2. An EA represents a structured body of knowledge for
engineering and integration of the enterprise, which
include knowledge of analysis and detailed description,
the design and development of project engineering and
the operation of enterprise [9];
3. the fundamental organization of a system included in
its components, their relationships to each other and
the environment, and the principles governing its
design and evolution[3][7] ;
4. This is the logic for structuring business processes and
IT infrastructure reflecting the integration and
standardization requirements of the operating model of
the enterprise [5];
5. According to TOGAF / The Open Group Architecture
Framework [11] a definition of Enterprise Architecture
is addressed in 2 constituent parts enterprise and
architecture. TOGAF defines enterprise as any
collection of organizations that has a common set of
goals. For example, an enterprise could be a
government agency, a whole corporation, a division of
a corporation, a single department, or a chain of
geographically distant organizations linked together by
common ownership. In TOGAF, architecture has
two meanings depending upon the context:
A formal description of a system, or a detailed
plan of the system at component level to guide its
implementation;
The structure of components, their inter-
relationships, and the principles and guidelines
governing their design and evolution over time
100
 International Journal of Research in Management, Science & Technology (E-ISSN: 2321-3264)
2.2 Application Domain
Generally, we can apply enterprise architecture in any
organizational system capitalist or not, or in sectors of the
economy or in the structures of the administration and
government, including:
- Government agency, public or private
organizations;
- A whole company or society;
- Public institutions, universities, research
associations;
- A part of a large company (such as a business unit);
- A conglomerate of several organizations, including a
joint venture or partnership;
- An outsourced business operation multiplies;
2.3 EA Layers
The enterprise architecture layers are fields or practice areas
to properly describe the enterprise according to well
determined specifications. The number of layers and their
definitions differ according to the definition of EA, the
framework, the EA construction methods, tools and
modeling languages.
For example, the framework TOGAF divided EA into three
practice areas [11]: Business Architecture; Information
Systems Architecture (divided in two information and
application); and Technology Architecture.
According to Hewlett [5] the four most popular common
areas and components shown in Figure 1, we give below a
small description so in each layer:
Figure 1 The four layers of AE[5]
2.3.1 Business layer:
Describes in this layer in general:
- Strategy maps, goals, company policies, operating
model;
- Functional decompositions (eg IDEF0,
capabilities Trades and organizational models;
- Business processes, workflow and rules that articulate
the assigned authorities, responsibilities and policies;
2321-3264/Copyright2016, IJRMST, April 2016
Vol. 4, No. 1, April 2016
Available at www.ijrmst.org
- Organization of cycles, periods and schedule;
- Equipment suppliers, software and services.
2.3.2 Data layer:
This field affects the part of the information and data that is
collected, organized, stored and distributed. Some points
sector can be cited for the content of this layer:
- Information architecture is a global view of the flow of
information in an enterprise;
centers, - Data architecture that describes the flow of data and
how the data will be processed, stored;
- Master Data Management;
- Business Intelligence Analytics & Reporting BI this
includes Reporting Data Stores, Operational Data Store
(ODS), DataMart and Data Warehouse;
- Data quality to identify, analyze, improve and measure
the quality of data, integrity issues and data
improvement efforts;
- Data models abstraction of physical or logical database;
- The data lifecycle management is how to create,
organize, update, use, distribute, and archive, obsolete
data and information.
2.3.3 Applications layer:
In this layer, a rigorous description can be done of software
applications, for example:
- An inventory of applications and software diagrams;
- The interfaces between applications that are: events,
messages.
2.3.4 Technology layer:
Some sub-field to be treated by the technology architecture,
we can mention here:
- Middleware;
- The runtime applications and Framework;
- Application server and operating systems,
authentication and authorization environments, security
systems and operating and monitoring systems,
hardware platforms and hosting servers;
- Computer centers and labs, LAN and WAN networks,
Internet connectivity diagrams, intranet, extranet,
Internet, electronic commerce;
- DBMS, programming languages.
2.4 Architecture frameworks
The interest of using architecture frameworks are many we
quote here some of them:
- Provide methods and content to design the architecture;
- Reduce architectural construction costs;
- Ensure portability of architectural models;
- Maintain, flexibility and evolution of models;
SADT) - Encourage the reuse of architectural components.
As for frameworks exist we can say that the Zachman
framework [14] is considered the first framework
architecture, which are derived the other frameworks such
as DoDAF (Department of Defense Architecture
101
 International Journal of Research in Management, Science & Technology (E-ISSN: 2321-3264)
Vol. 4, No. 1, April 2016
Available at www.ijrmst.org

Framework) of the Department of Defense who was created 2.6.2 Architecture Development Method
to define the military functions of the department of The core of TOGAF is the wheel ADM (Architecture
defense, and MODAF (modaf). Another framework widely Development Method), the represents and exposes the
used is TOGAF. structure of the method with the phases and transitions of
ADM.
2.5 Tools and languages
Architectural languages are modeling tools and set of 2.7 ArchiMate
concepts and notations that support the Framework and help TOGAF does not impose specific modeling language [2].
enterprise architects to create, visualize, analyze and model ArchiMate is a standard of Open Group, an open and
the enterprise architecture. Among the enterprise independent modeling language for enterprise architecture
architecture development solutions existed the following is which is supported by different tool providers and
cited: the pair ArchiMate [1] based on TOGAF [11]. This consulting firms. ArchiMate provides instruments to enable
solution is used in this work we will discuss them in detail enterprise architects to describe, analyze and visualize the
in the next sections. relationships between the business areas in an unambiguous
way[1].
2.6 TOGAF
The Open Group Architecture Framework is a framework -
a detailed method and a set of supporting tools - for
developing an enterprise architecture. It may be used freely
by any organization wishing to develop an enterprise
architecture for use within that organization [11]. TOGAF is
developed and maintained by members of The Open Group,
working within the Architecture Forum (refer to
www.opengroup.org/architecture).
The original development of TOGAF Version 1 in 1995 was
based on the Technical Architecture Framework for
Information Management (TAFIM), developed by the US
Department of Defense (DoD). The DoD gave The Open
Group explicit permission and encouragement to create
TOGAF by building on the TAFIM, which itself was the
result of many years of development effort and many
millions of dollars of US Government investment.
TOGAF has been proposed to allow users to implement
open solutions to lower costs, simplify processes associated
with designing, planning, acquisition and integration of
open systems, and help CIOs (Chief information officer) to
better communicate their goals and strategies for decision
makers [2]. Moreover, TOGAF has been proposed in order Figure 3 Architecture Development Method [11]
to improve performance of IT developments within an Structure of language and correspondence with
enterprise [8]. TOGAF: The ArchiMate language is structured in layers
and aspects
2.6.1 The parts of TOGAF
The Figure 1 represents the content of TOGAF which is
divided into seven parts.

Figure 4 ArchiMate structure and correspondence with

Figure 2 The main parts of TOGAF[3] TOGAF [1]

2321-3264/Copyright2016, IJRMST, April 2016 102

 International Journal of Research in Management, Science & Technology (E-ISSN: 2321-3264)
Vol. 4, No. 1, April 2016
Available at www.ijrmst.org

2.7.2 The notion of architectural viewpoints

We saw earlier the classification of concepts in their layer
and aspect, until present we cannot build a clear enterprise
architecture, coherent and well-organized that addresses the
point of view of the recipients of architectural models, in
this approach, the ArchiMate proposes to build the
architecture models according viewpoints.
ArchiMate defines three important notions to create reliable
architecture models: the stakeholder; view; the point of
view. Views are an ideal mechanism to purposefully convey
information about architecture areas. In general, a view is
defined as a part of an architecture description that
addresses a set of related concerns and is addressed to a set
of stakeholders. A view is specified by means of a
viewpoint, which prescribes the concepts, models, analysis
techniques, and visualizations that are provided by the view.
Simply put, a view is what you see and a viewpoint is where
you are looking from [1].

Figure 4 shows the general structure of the ArchiMate

language with correspondence with the TOGAF ADM
wheel, the reason of this correspondence is to simplify the
use of the concepts of ArchiMate according to TOGAF
approach
2.7.1 Concepts and notations of ArchiMate
ArchiMate defines concepts for each architecture layer and
gives their corresponding notations. For the business layer
defines sixteen concepts, to the application layer gives us
seven and nine concepts for technology layer, all these
concepts are classified according to three aspects: structure,
behavior, and information. Figure 5 notation concepts
extract of ArchiMateshows a part of notations concepts of
the three layers.

Figure 6 Classification of Enterprise Architecture

viewpoints [1]

ArchiMate defines the classification of viewpoints and

views according to two dimensions: purpose and content.
The goal of this classification is to assist architects and
others find suitable viewpoints given their task at hand.
The three types of architecture support the purpose
dimension of architecture views are: Designing, Deciding,
and Informing.
For characterizing the content of a view we define the
following abstraction levels: Details, Coherence, Overview.
The Figure 6 displays the dimensions of purpose and
abstraction level, together with examples of typical
stakeholders that are addressed by these viewpoints.
ArchiMate offers three categories of viewpoint:
- Motivation viewpoints contain six viewpoints;

- Architectural viewpoints contain eighteen

viewpoints;The implementation and migration
viewpoints contains three viewpoints; ArchiMate helps
architectural designers by meta-models that contain the
concepts necessary for every point of view, Figure 7
shows a meta-model with concepts and relationships to
Figure 5 notation concepts extract of ArchiMate

2321-3264/Copyright2016, IJRMST, April 2016 103

 International Journal of Research in Management, Science & Technology (E-ISSN: 2321-3264)
build the Application usage viewpoint.
Figure 7 Application usage viewpoint Metamodel
3. CASE STUDY: A PUBLIC AGENCY
The major lack of case studies in the field of enterprise
architecture worldwide and the total lack in public or private
Algerian economic enterprises have encouraged us to
propose studies to demonstrate the role and added value of
enterprise architecture to the Algerian economic sector. Our
studies were conducted as part of the subjects of master's
degree offered in this area, these studies are based on the
most used TOGAF architecture framework and technical
standard modeling language and notation and ArchiMate.
Our studies affecting public and private companies, but in
this paper we will only see a study on a public agency which
is the CNR "National retirement fund".
3.1 PROBLEMATIC
Based on our study and analysis within CNR, we mention in
this section the major current challenges:
1. CNR hasn't models that describe the enterprise's
operations, and even if we find some operational models
we observed CNR performs its business processes in the
real world without seeing these models, we said that
management of CRN is too complex;
2. Regarding the acquisition of IT resources, CNR built its
IT by successive generation solutions without thinking
about the consistency between them or according to a
well-defined strategy. CNR purchases and installs
hardware and software solutions depending of release of
new versions without need to it or to see of well-defined
goals
3. In this study we noticed the lack of an IT strategy. The
CNR agency focuses only on business strategy, the only
IT strategy is the program and answer the IT resource
needs, these needs are identified depending on demand
services or to keep up the technology. Seeing that the
major objective of EI is to align business strategy and IT
strategy. Under these conditions, CNR seems a fertile
business to apply EA techniques to solve this major
problem.
4. In the absence of IT strategy and alignment between
business strategy and IT CNR agency is not capable of
anticipating the needs of IT solutions and resources;
2321-3264/Copyright2016, IJRMST, April 2016
Vol. 4, No. 1, April 2016
Available at www.ijrmst.org
5. Also in the absence of target model to ensure the
transformation and innovation, in general this agency is
satisfied with the operational model. In this way it is
impossible for CNR ensures the agility to change and
transform.
3.2 Our Technics choice
Our strategic choice for developing enterprise architecture
for this agency is based on TOGAF and ArchiMate pair,
since according to Open Group TOGAF was adopted by
more than 80% of the biggest companies in the world.
TOGAF certification was also obtained by tens of
thousands of people around the world. Concerning the
modeling language, homogeneity of solutions Open Group
and the compliance with TOGAF that made us adopt this
language.
3.3 Construction of EA for CNR
The CNR Error! Reference source not found. is a public
sector organization, which provides a monthly payment to
insured after retirement. Its main mission is to manage the
pensions and allowances of pensioners and right holders.
3.3.1 The model ArchiCNR based on ADM
To build the architecture of CNR personalized demarche
was proposed as required by the study, the characteristics of
the enterprise in the study and specifications modeling
language. This approach is mainly based on the TOGAF
ADM methodology with little modification. We ignored the
H phase used to establish a management change requests an
existing initial architecture, and because we will achieve a
new architecture for our organization this phase will not be
helpful in our case. Table 1 shows the detail of each phase
followed in building the model:
3.3.2 Model Description by viewpoints
Construction of views is achieved step by step according to
our approach, here we give the main steps of ArchiCNR
model with extracts from viewpoints associated:
3.3.2.1 motivation viewpoints
A motivator is defined as an element that provides the
context or reason behind the enterprise architecture. To
write the motivation of the architecture according to
TOGAF we must discuss it at the preliminary part, the
phase "A vision of architecture", change and evolution of
existing designs, without forgetting the requirements of
management.
ArchiMate facilitates us this description with specifications
and extension meta-models as well organized viewpoints.
We mention the most important of which we have used to
design this important part of AE: Stakeholder Viewpoint;
Goal Realization Viewpoint; Goal Contribution Viewpoint;
Principles Viewpoint; Requirements Realization Viewpoint;
Motivation Viewpoint.
Figure 8 An extract from the motivation viewpoint
modelshows an extract from one of the viewpoints is the
motivation viewpoint which allows the designer or analyst
to model the motivation aspect, without focusing on certain
elements within this aspect. For example, this viewpoint can
be used to present a complete or partial overview of the
motivation aspect by relating stakeholders, their primary
goals, the principles that are applied, and the main
requirements on services, processes, applications, and
objects[1].
104
 International Journal of Research in Management, Science & Technology (E-ISSN: 2321-3264)
Vol. 4, No. 1, April 2016
Available at www.ijrmst.org

3.3.2.2 Architecture Viewpoints the main behavior of applications, or in identifying

The essential work of AE design starts mainly here, the
architectural viewpoints in general affect the concepts of the
three layers (business, application and technology) in a
manner to be separated or mixed viewpoints representing an
architecture that mixes between the concepts of the three
layers.
ArchiMate offers eighteen model to describe this phase,
mention the main viewpoints used in this study:
Organization Viewpoint; Actor Co-operation Viewpoint;
Business Process Viewpoint; Application Behavior
Viewpoint; Application Structure Viewpoint; Application
Usage Viewpoint; Infrastructure Viewpoint; Infrastructure
Usage Viewpoint. Figure 9 shows one of these viewpoints is
Application Behavior Viewpoint, it describes the internal
behavior of an application. It makes in the enterprise a
specific service. To perform this service, the application is
based on several components, each is assigned to a clearly
defined function. This viewpoint is useful in the design of
functional overlap between applications.
We give in this context also another very important
viewpoint used for this study is the view application usage.
The viewpoint of application usage describe how
applications are used to support one or more business
processes, and how they are used by other applications.
It can be used in the design of an application by identifying
the services required by business processes and other
applications, or in the design of business processes by
describing the services that are available.
In addition, it identifies the dependencies of business
processes at applications; it may be helpful to the
operational managers responsible for these processes. An
extract of this point appears in Figure 10, which represents
the correspondence modules e.g. pensions and control with
adequate sub-processes.

Motivation Extension

Phase B: The preliminary phase:

business dictionary. The methods and tools.
Business layer Catalogue Service / function.
Phase A:
organizational units.
Matrix of stakeholders.
The mission of the NRC. objectives catalog.
the catalog of business processes.
Phase C:
Detailed records of a business process.
Application layer Matrix application / function.
Requirements management:
Catalog application components. Catalogue Functional requirements.
Catalogue NotFunctional requirements.
Phase D:
Technology layer
Technology Portfolio catalog.

Implementation and
Migration Extension The phases E, F, G

Table 1 Process followed in the construction of the ArchiCNR model

Figure 8 An extract from the motivation viewpoint model

2321-3264/Copyright2016, IJRMST, April 2016 105

 International Journal of Research in Management, Science & Technology (E-ISSN: 2321-3264)
Figure 9 Application behavior viewpoint model extract
Figure 10 Application usage viewpoint model extract
3.3.2.3 Implementation and Migration Extension
Viewpoints
ArchiMate offers three viewpoints to represent the
migration and implementation of architecture: Project
Viewpoint; Migration Viewpoint; Implementation and
Migration Viewpoint. We present in this section one of
viewpoints used in this study is the project viewpoint, is
given in Figure 11, this view is mainly used to model the
management of architectural change.
4. Discussion and Conclusion
Through these case studies and based on the world rankings
in 2013 of information and communications technology
(ICT) published by World Economic Forum (WEF) has
shown that Algeria to 131st place in the world rankings of
144 countries [12], and also lost 13 places compared with to
the year 2012 during which it held the 118th rank.
2321-3264/Copyright2016, IJRMST, April 2016
Vol. 4, No. 1, April 2016
Available at www.ijrmst.org
Figure 11 An extract from the project viewpoint model
We can justify our choice to treat the AE as an important
and timely subject, the case study in this area demonstrated
that:
In cases where enterprises separate their work in the real
world of their business model, we say that these enterprises
fall into the complexity. Our preliminary studies show that
the majority of Algerian enterprises generally do not have
business models, then the complexity will be lighter than
the developed world enterprises. From this study we can say
that the enterprise architecture will serve these enterprises at
least by operational models at all levels: strategic; business;
application; technology. These models will therefore
decrease evidently the complexity of these enterprises. And
the strict application of these models will guide the
enterprise towards simplicity.
A key objective of EI is the alignment of business strategy
with IT strategy, so the first thing that can serve Algerian
companies through the development of AE is to introduce
the concept of IT strategy, realized from purely dedicated
model application. The second thing is that the modeling of
the business layer in architectural viewpoint discussed in the
previous section will help the enterprise to get organized
and build its business model that is driven by a business
strategy. Then we propose models for correspondence
between this strategy and the IT strategy as the view model
application usage, these models showed that the majority of
business processes are performed in a manual way, making
brake the good start of these process and involves an
anticipation of the need for IT. By against modeling
application or technology layer as described in the previous
section demonstrated the need for companies is to use
applications designed by the component approach, or to
understand why buy and install IT applications without
seeing their goals or their business tasks and not even know
how to use or work with, such as network installation and
internet without our applications using these technologies.
Ensure agility is when enterprise can understand and
separate their business processes of their transformation
process, innovation and evolution. As AE provides a
solution for the static view of companies, also offers target
models to ensure the dynamic part of the enterprise through
the implementation and migration viewpoint.
5. ACKNOWLEDGMENTS
This work was done in the context of Master Degree project
in University College Bachir el ibrahimi of Bordj Bou
arreridj. Our thanks to all who participated to make this
106
 International Journal of Research in Management, Science & Technology (E-ISSN: 2321-3264)
Vol. 4, No. 1, April 2016
Available at www.ijrmst.org

work: students of Master Saadi Anssar and Belkhiri Samia,

CNR experts and managers.

REFERENCES
[1] ArchiMate. (2012). ArchiMate 2.0 Specification.
[2] Camille Salinesi, Laure-Hlne Thevenet. (2008). Enterprise
Architecture, des problmes pratiques linnovation.
Ingnierie des Systmes d'Information 13(1):75-105.
[3] CIGREF. (2008). LArchitecture dEntreprise Un cadre
global de coopration pour les acteurs de lentreprise . Paris.
[4] Desfray, P., & Raymond, G. (2012). TOGAF EN
PRATIQUE modles darchitecture dentreprise. Paris:
(Dunod, d.).
[5] Hewlett, N. E. (2006). The USDA Enterprise Architecture
Program. PMP CEA, Enterprise Architecture Team, USDA-
OCIO. January 25, 2006.
[6] Jean-Claude. ( (Septembre 2010)). Larchitecture
dentreprise intgre. 14. Seattle, Paris: CASE France &
Future Tech Systems Inc.
[7] Josey, A., Group, T. O., Rachel, P., Consulting, S. E.,
Homan, P., IBM, et al. (2009). TOGAF Version 9 Guide
de Poche. 2me dition. (V. H. Publishing, d.) Franais.
[8] Matthieu, A. (2009). Atelier de modlisation TOGAF. (U. d.
Nantes, d.).
[9] Peristeras V., Carvalho J. (2001). State of the Art. project
report n1, WP1. Infocitizen (IST2000 - 28759).
[10] Site of CNR, http://cnr-dz.com/, 2016.
[11] TOGAF. (2011). TOGAF version 9.1 Entreprise
Edition . TOGAF.
[12] WEF. (2013). The Global. Competitiveness Report. World
Economic Forum 2013.
[13] Zachman, J. (2005). Enterprise Architecture vs Application
Development Artifacts. ZIFA report.
[14] Zachman, J. A. (2012). Zachman International, Inc.

2321-3264/Copyright2016, IJRMST, April 2016 107