An Experiment Applying the Enterprise Architecture Case Study: Algerian Government Agency Mâache Salah

Transcription

1 An Experiment Applying the Enterprise Architecture Case Study: Algerian Government Agency Mâache Salah Computer Science Department, University ElBachir ElIbrahimi Bordj BouArreridj, Algeria 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 company s 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 welldefined 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 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 interrelationships, and the principles and guidelines governing their design and evolution over time /Copyright 2016, IJRMST, April

2 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 sector organizations; - A whole company or society; - Public institutions, universities, research centers, 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] Business layer: Describes in this layer in general: - Strategy maps, goals, company policies, operating model; - Functional decompositions (eg IDEF0, SADT) capabilities Trades and organizational models; - Business processes, workflow and rules that articulate the assigned authorities, responsibilities and policies; - Organization of cycles, periods and schedule; - Equipment suppliers, software and services Data layer: This field affects the part of the information and data that is collected, organized, stored and distributed. Some points can be cited for the content of this layer: - Information architecture is a global view of the flow of information in an enterprise; - 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 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 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; - 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 /Copyright 2016, IJRMST, April

3 Framework) of the Department of Defense who was created to define the military functions of the department of defense, and MODAF (modaf). Another framework widely used is TOGAF. 2.5 Tools and languages Architectural languages are modeling tools and set of concepts and notations that support the Framework and help enterprise architects to create, visualize, analyze and model the enterprise architecture. Among the enterprise architecture development solutions existed the following is cited: the pair ArchiMate [1] based on TOGAF [11]. This solution is used in this work we will discuss them in detail in the next sections. 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 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 to improve performance of IT developments within an enterprise [8] The parts of TOGAF The Figure 1 represents the content of TOGAF which is divided into seven parts Architecture Development Method The core of TOGAF is the wheel ADM (Architecture Development Method), the represents and exposes the structure of the method with the phases and transitions of ADM. 2.7 ArchiMate TOGAF does not impose specific modeling language [2]. ArchiMate is a standard of Open Group, an open and independent modeling language for enterprise architecture which is supported by different tool providers and consulting firms. ArchiMate provides instruments to enable enterprise architects to describe, analyze and visualize the relationships between the business areas in an unambiguous way[1]. Figure 3 Architecture Development Method [11] Structure of language and correspondence with TOGAF: The ArchiMate language is structured in layers and aspects Figure 2 The main parts of TOGAF[3] Figure 4 ArchiMate structure and correspondence with TOGAF [1] /Copyright 2016, IJRMST, April

4 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 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; Figure 5 notation concepts extract of ArchiMate - 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 /Copyright 2016, IJRMST, April

5 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; 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 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: 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: 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] /Copyright 2016, IJRMST, April

6 Architecture Viewpoints 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 the main behavior of applications, or in identifying 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 Business layer Application layer Technology layer Implementation and Migration Extension Phase B: business dictionary. Catalogue Service / function. organizational units. The mission of the NRC. Phase C: Phase D: Matrix application / function. Catalog application components. Technology Portfolio catalog. The phases E, F, G The preliminary phase: The methods and tools. Phase A: Matrix of stakeholders. objectives catalog. the catalog of business processes. Detailed records of a business process. Requirements management: Catalogue Functional requirements. Catalogue NotFunctional requirements. Table 1 Process followed in the construction of the ArchiCNR model Figure 8 An extract from the motivation viewpoint model /Copyright 2016, IJRMST, April

7 Figure 11 An extract from the project viewpoint model Figure 9 Application behavior viewpoint model extract Figure 10 Application usage viewpoint model extract 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. 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 /Copyright 2016, IJRMST, April

8 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-Hélène Thevenet. (2008). Enterprise Architecture, des problèmes pratiques à l innovation. Ingénierie des Systèmes d'information 13(1): [3] CIGREF. (2008). L Architecture d Entreprise Un cadre global de coopération pour les acteurs de l entreprise. Paris. [4] Desfray, P., & Raymond, G. (2012). TOGAF EN PRATIQUE modèles d architecture d entreprise. Paris: (Dunod, Éd.). [5] Hewlett, N. E. (2006). The USDA Enterprise Architecture Program. PMP CEA, Enterprise Architecture Team, USDA- OCIO. January 25, [6] Jean-Claude. ( (Septembre 2010)). L architecture d entreprise intégrée. 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. 2ème édition. (V. H. Publishing, Éd.) Français. [8] Matthieu, A. (2009). Atelier de modélisation TOGAF. (U. d. Nantes, Éd.). [9] Peristeras V., Carvalho J. (2001). State of the Art. project report n1, WP1. Infocitizen (IST ). [10] Site of CNR, [11] TOGAF. (2011). TOGAF version 9.1 «Entreprise Edition». TOGAF. [12] WEF. (2013). The Global. Competitiveness Report. World Economic Forum [13] Zachman, J. (2005). Enterprise Architecture vs Application Development Artifacts. ZIFA report. [14] Zachman, J. A. (2012). Zachman International, Inc. International Journal of Research in Management, Science & Technology (E-ISSN: ) /Copyright 2016, IJRMST, April