Publié par : Published by: Publicación de la:

Faculté des sciences de l’administration Université Laval Québec (Québec) Canada G1K 7P4 Tél. Ph. Tel. : (418) 656-3644 Télec. Fax : (418) 656-7047

Édition électronique : Electronic publishing: Edición electrónica:

Aline Guimont Vice-décanat - Recherche et affaires académiques Faculté des sciences de l’administration

Disponible sur Internet : Available on Internet Disponible por Internet :

http://www5.fsa.ulaval.ca/sgc/documentsdetravail rd@fsa.ulaval.ca

DOCUMENT DE TRAVAIL 2009-006

AN ENTREPRISE ARCHITECTURE FRAMEWORK FOR LARGE INTEGRATED COMPLEX INFORMATION SYSTEMS Daniel PASCOT Faouzi BOUSLAMA Sehl MELLOULI

Version originale : Original manuscript: Version original:

ISBN – 978-2-89524-332-8

Série électronique mise à jour : On-line publication updated : Seria electrónica, puesta al dia

02-2009

Noname manuscript No.(will be inserted by the editor)

An Entreprise Architecture Framework for Large Integrated ComplexInformation Systems

Daniel Pascot Faouzi Bouslama Sehl Mellouli

Received: /Accepted:

Abstract Information systems developments face di�erent dimensions and components that do not changeat the same time emanating from the multitude of cycles of applications previously developed in silos andfrom the di�erence in paces between the organizational and the technological developments. This paper showsthat existing solutions only partially address one or the other or both of the problems. Capitalizing on thesesolutions, this paper proposes a more comprehensive answer for the development of an enterprise architecturethat takes into consideration these challenges and which guarantees the evolution of the organization in suchcontext. This architecture is based on two main elements: a reference enterprise architecture framework and atwo-track Y-model development cycle. The proposed framework is based on three core organisational concepts: Field actions (FAs), a common canonical Corporate Conceptual Data Model (CCDM), and Views or sub-schemas. The FAs capture the persistent information of the reality on the ground. They are the key reusablecomponents of the process architecture. The CCDM provides a coherent global information model of theknowledge domain, and the Views model information for di�erent stakeholders. All of these key componentsare articulated to create a certain degree of independence between business needs, the underlying technology,and the application development process. A CCDM-coupling method and rubrics are developed to cope withcomplexities of the models. This approach is being implemented to create an enterprise architecture of thehealthcare system at the Ministry of Health and Social Services of Quebec to manage the complexities andmonitor the evolution of this large government organization.

Keywords Entreprise architecture, Information architecture, Field actions, CCDM, Views, Businessprocesses, Two track model, Health informatics.

1 Introduction

The transformations witnessed nowadays in medium and large organizations to become more e�ective whilemeeting their strategic objectives and external constraints are quite complex and always take place undermany challenges and di�culties. One of these di�culties emanates from the multitude of life cycles of the largenumber of applications which have been developed in silos over the years but continue to be in use by thedi�erent units within the organization. The increasing integration and use of IT in organizations has resulted

Management Information Systems Department Faculty of Business Administration, Pavillon Palasis-Prince, 2325 ruede la Terasse, Quebec (QC) G1V 0A6, Canada.

E-mail: daniel.pascot@sio.ulaval.ca

E-mail: faouzi.bouslama@fsa.ulaval.ca

E-mail: sehl.mellouli@sio.ulaval.ca

2

in the creation of this multitude of applications more or less autonomous, which have the contradictory e�ectto slow the adaptation of �rms. The multitude of applications have been developed in isolation one after theother each with its own life cycle. Though, many of these organizations have been largely transformed anddigitized, in reality they are still operating in silos, which has been hindering the processes of informationsharing and integration, and therefore the corporate growth.

Another major di�culty in organizations is related to the di�erence in pace of the organizational andtechnological development. The technological evolution pace both in computer hardware and software, thoughto a lesser extend in the software part, is di�erent and often considerably faster than the rate of evolutionof organizations. In fact, the lifespan of hardware or software to catalogue suppliers is just few years andsometimes few months, while the lifetime of critical applications in organizations is in the order of severaltens of years. These di�culties are more present especially in large and complex organizations such as thosein the government sector. Given this di�erence in rate of change of development, it is very unlikely for anorganization to perform the right alignment between its organizational needs and technology's capabilities. Asa consequence of these problems, organizations are faced with an increasing volume of complexity, ine�ciencyand rigidity that are due to the accumulation of the use of heteregeneous applications and systems. Theyare now looking for best approaches to manage and sort out these transformation-related complexities. Theseapproaches are expected to allow managing and evolving together the many applications, and getting controlover the organization's global model of information and pace of changes.

But in order to ensure that organizations e�ectively manage their transformations, they need to createqualitative statements of business needs which can be used to formally plan, design and govern the transforma-tions processes. To achieve this goal, organizations have been looking for appropriate modeling techniques ofarchitecture which can be used to provide on one hand a global view to understand how an organization mapsits processes, functions, entities and solutions to the real world, and on the other hand to create a set of detailedmodels describing its actors, actions, and data. Organizations operate using a speci�c model but when there is atransformation, this model is subject to change as in the case of the strategic objective to integrate informationarchitectures to foster cross-borders cooperation. To be able to describe how organizations work and how theirtransformations take place inline with their strategies and goals, several initiatives in enterprise architecturemodeling have been created for this purpose. The Enterprise Architecture (EA) provides a holistic view and amechanism to design, develop, communicate and understand the enterprise. It is designed to organize all theinformation that is created and communicated in an organizational system in order to secure progressively, interms of information, consistency of all operational and management information levels systems. Moreover, inmedium and large organizations, the management of complexities necessitates the development of an integratedand stable information architecture [1], [2], [3], [4].

The �rst attempts to integrate information were performed in the context of the design of databases byC. Batini et al. [5]. To remove redundancy and create a uni�ed data model, schemas of existing and futuredatabases were integrated into a global and uni�ed one. In [6], the authors presented an extensible ontologyfor information integration which expresses the basic concepts that are common to di�erent domains. Theyargued that a core ontology is one of the key building block necessary to enable the scalable assimilationof information from diverse sources. This core ontology provides a global model into which data originatingfrom distinct sources can be mapped and integrated. Moreover, this canonical form which provides a singleknowledge base for cross-domains tools and services helps avoid application complexities resulting from pairwise mapping between individual metadata formats and ontologies [6]. In fact, the information integrationwhose goal is to access data from multiple sources requires two critical factors for the design and maintenanceof distributed and cooperative applications and information systems [7]. These two factors are the conceptualmodeling of the domain, and the reasoning support over the conceptual representation. Here, the knowledgerepresentation and the reasoning techniques both play an equally important role.

To create information architectures that allow a non-redundant and uni�ed representation of all datain an organization, and to address the inherent problems of transformations-related complexities, there is aneed for appropriate methodologies to support the information integration across organizational processes andapplication boundaries. For this purpose, many solutions have been proposed by business users and InformationTechnology (IT) professionals including:� Enterprise Resource Planning (ERP) systems [8];� Agile software development techniques [9],� Rapid Application Development (RAD) approches [10], and Extreme Programming (XP) [11]

3

� Enterprise Architectures (EA) such as the Zachman Framework [13] and the Open Group ArchitectureFramework (TOGAF) [14]; and

� The e�orts of Urbanisation [16].

All of these solutions have been widely used to model and manage tranformations in organizations. However,they only provide partial solutions to the complexities of tranformations. In fact, they do not explicitly showhow to manage the multitude of life cycles of applications, and only partially address the di�erent paces betweenthe organizational and technological development of the organization

This paper capitalizes on these solutions to propose a more comprehensive answer for the development of aninformation architecture that takes into consideration these challenges and which guarantees the evolution ofthe organization in such context. The development process of this architecture is based on two main elements:a reference enterprise architecture framework and a two-track Y-model development cycle [17], [3], [18]. Theproposed framework is based on three core organisational concepts: Field actions (FAs), a common canonicalCorporate Conceptual Data Model (CCDM) , and Views or sub-schemas [3]. The FAs which capture thepersistent information of the reality on the ground is any action, decision or event involving one or severalplayers that can be described independently of a particular business process [19], [20], [21]. A catalogue of allthe FAs can be established, and these FAs within the CCDM give a coherent and global information model.The CCDM [22] which provides a global view of the information is a high level data model where only themain entities and attributes common to several information systems are de�ned. The Views which modelinformation for di�erent stakeholders whows the relationship between the information architecture and thebusiness and systems architectures [22] which themselves are articulated around the CCDM. Through the useof the two-track Y-model development process, all of these key components are articulated to create a certaindegree of independence between business needs, the underlying technology, and the application developmentprocess. The obtained global data model can be very complex. Here, the concept of rubrics is used to simplifythis data model since details about entities in the CCDM can be expressed only in their particular context.This architecture enterprise is being implemented to model the healthcare system at the Ministry of Healthand Social Services of the Quebec Province in Canada (MSSS) [23], [24].

The rest of the paper is organized as follows. Section 2 presents a historical perspective showing the problemof the multitude of cycles that organizations are faced with resulting from the many applications that havebeen independently created over the years, and the problem of the di�erent pace between the organizationaland technological development. Section 3 provides a brief summary of the existing solutions and comparethe contributions of each with respect to the complexity, agility and synergy dimensions. Section 4 presentsthe proposed enterprise architecture framework with its core components of FAs, CCDM and views, and thetwo-track Y-model for the development of Computer-Based Information Systems (CBIS). Section 5 shows thebuilding process of the information systems architecture. Section 6 is a highlight of directions for future researchwork. Finally Section 7 is the conclusion.

2 From application design to IS architecture

From a historical point of view, design methods such as MERISE [25], [26], Information Engineering [27],[28], and Structured Analysis [29], [30], which have been developed over the years, were concentrated on asingle application life cycle. This system development life cycle (SDLC), which originally took the form ofRoyce's waterfall model [31], is the process of understanding how an information system is used to support theorganization's business needs, then to design, build and implement this system, and later to deliver it to users.

The SDLC includes six main phases as shown in Figure 1: initial study, design, development, implemen-tation, maintenance, and phase out phases, respectively. The applications development moves through allsix phases and when the application attains its obsolecence, then a new project cycle begins. The degree ofinformation systems' involvement varies as the life cycle evolves over the time.

The waterfall model is in fact a project management cycle that information systems projects follow andwhose primary objective is to create value for the organization. With this cycle, system analysts and developersde�ne the user needs and requirements, design and choose a solution, and then develop and implement thatsolution. But creating value for the organization is not an easy task as the understanding of how the systemwould support the organizations's goals, the existing business processes and other information systems can bevery challenging. In this cycle, a major di�culty resides with the de�nition of the needs and the instability to

4

Fig. 1 The waterfall SDLC of a single application and the involvement of human IS resources in the process.

some extent witnessed in those needs. This approach closely links the de�nition of needs with the choice oftechnology and any changes in either one a�ects the other as both of the needs and technology are integratedin the same cycle.

In fact, there are many publications in Information Systems Requirements that focused on the link betweentechnology and needs where methodologies implementing the SDLC attempted to de�ne in a stable way theuser needs. These methodologies placed primary emphasis on de�ning the needs for which the developedsystems should respond. The Objected-Oriented (OO) methodologies [32] for example use Use Case diagramsto identify and model the needs in software engineering. As for agiles methods, users are made to interactwith technology so that together they adjust technology as the needs change. These approaches may work wellfor small applications but if the requirements are complex or unclear, things get confusing. The problem ofde�ning needs is in fact a di�cult problem as shown by the place that this issue occupies in design methodsand in the litterature on information requirements. Today, there are few developers who follow the originalstrutured design methodology of the waterfall approach as it takes them a long time before they discover thereal problems of the information requirements. Moreover, most of this and other design methodologies havebeen focused on one application and the entire content of the analysis was limited to that application. Theneeds were the needs of the users of the application, and therefore this required a stabilization of the needs forthe life cycle.

Considering what happened in organizations from a historical point of view, a multitude of applicationshave been developed in isolation one after the other each with its own life cycle. The challenge today is tomanage and to make evolve together all these applications, but given their overall size, it is no longer possibleto apply a single life cycle to all applications within an organization. Instead of one single cycle representingthe development, operation and support as in the case of a single application, there are n cycles in the case ofmultiple applications as depicted by Figure 2. These n cycles need to be continuously piloted and managed toallow the organization to evolve over the time.

Fig. 2 From a signle to many applications.

In this context of many applications, the knowledge domain can be represented by an ontology in the formof Corporate Conceptual Data Model (CCDM) as is proposed in this study. The CCDM can be thought of asthe union of the individual Conceptual Data Models (CDMs) for each application. But how can organizations

5

act on their information systems that are supposed to last for decades when the life cycle of technology isonly a couple of years in which some needs evolve quickly while others are stable? How can organizations livewith the multitude of life cycles? To overcome these challenges, organizations sought the help of informationintegrating solutions and architecture frameworks to model their complexities and manage their evolutions.The following section provides a summary of these existing solutions and shows how they address particularaspects of the transformation-related complexities.

3 Existing solutions to transformations-related complexities

Many large organizations have been trying to overcome the confusion they were locked in by these numer-ous applications which were developed inconsistently in silo, and also by the di�culties emanating from thedi�erence in pace between the organizational and technological developments, respectively by acquiring andimplementing various technological solutions. From Enterprise Resource Planning (ERP) systems to EnterpriseArchitecture (EA) frameworks and Urbanization of information systems, organizations have been looking forappropriate solutions to model their operations and transformations in order to understand complexities andto manage their evolution.

3.1 Modi�ed SDLC models and agile methods

The original waterfall development methodology has been modi�ed to compensate for the two key disadvantagesrelated to the very long time it takes to implement and test the system, and the poor communication mechanismto re�ect on user needs. The developers of programs understood the necessity to stabilize the needs for the lifecycle. But stabilizing the needs is di�cult, and so researchers and practioners proposed di�erent modi�cationsfor the original waterfall life cycle. They proposed the typical V-shape cycle [33], [34], the spiral life cyclemodel [35], and new methodologies such as the Rapid Application Development (RAD) [10], the ExtremeProgramming (XP) [11], or the recently Agile methods [9] that focus on short development life cycles and closeinteraction with users.

These methods are software development approaches that involve iterative development aiming at speedingup the analysis, design and implementation phases of the SDLC, and hence the applications' developmentprocess. However an important subtle problem remains which is the management of user expectations andsystem requirements. Each of these methods responds only partially to the problem. On the contrary, theyhave tendency to increase the complexity problem without addressing the articulation of multiple cycle ofapplications. Therefore, they are only local solutions that can not address the global transformation-relatedproblems.

3.2 ERPs in integrating the business processes

Among the solutions that organizations thought of using to address the transformations-related problems werethe Enterprise Resource Planning (ERP) systems [8]. The ERP solution helped organizations collect all businessareas in one system to support most of the business system needs. ERPs maintained in a single database all thedata necessary to run the organization. Each functional unit within the organization uses its own supportingsoftware applications and the ERP software links these applications and ensures their compatibility throughthe use of the common data storage.

The bene�t of using ERP is to streamline business processes which achieves e�ciencies and thereforelower costs. However, ERP systems can grow to become very complex and di�cult to manage as organizationstransform themselves and become more complex themselves. ERPs are often customized for the speci�c businessprocesses that they support and to suit the needs of the organization. Very often, this customization is quitecomplex leading organization to rely on vendor solutions and external service providers to run and maintainthe ERP solution. As vendors of this technology do not allow any altering of the structure of the software,this situation has created a depency between the organization from one side and the vendors and the serviceproviders from the other side. This dependency results in more expenses and less e�ciency. Though ERPs

6

address the incohenrence problem and the lack of synergy, their di�cult and costly implementation solvedpartially the integration process while creating other problems in complexities-related transformations.

3.3 Frameworks for managing life cycles

Another solution to model and understand complexities in organizations is to use Enterprise Architecture (EA)frameworks [36]. The latters provide a mechanism enabling the design and development of integrated modelsof organizations and the communication and understanding of the enterprise. They provide a holistic viewof the entire enterprise as they deal with a collection of organizations that have a common set of goals andlinked together by common ownership. The term enterprise is used to denote all the information systems inthe enterprise. The ANSI/IEEE Std 1471-2000 [12] de�nes architecture as �The fundamental organization of asystem, embodied in its components, their relationships to each other and the environment, and the principlesgoverning its design and evolution.�

Several EA frameworks are available to help people architect enterprises in order to manage complexities,align business strategies and implementations as well as pilot the transformations and change to maintain thebusiness and technical lead. Among these frameworks, the Zachman Framework [13] is very often used as astandard to conceive the enterprise architecture. Other EA frameworks are equally important such as TheOpen Group Architecture Framework (TOGAF) [14], the US Department of Defense Architecture Framework(DoDAF) [37] and the FEAF [15]. All of the EA frameworks can help elucidate how organizations live with amultitude of applications that were developed at di�erent times with di�erent technologies. They all bring ina certain number of answers to the transformation-related problems.

3.3.1 The Zachman Framework

The Zachman Framework [13] which describes the organizing architectural artifacts remains a widely usedintegrated framework for modeling and managing change and transformations in organizations. While beingrecognized as an easy to understand framework, the large number of cells makes it di�cult when it comes topractical applicability considerations.

The Zachman Framework provides a collection of perspectives to model the enterprise, its business, andarchitecture. In this framework, the structure is designed to identify all possible primitive representations withrespect to an enterprise or organization. The framework uses a six by six two dimensional matrix to classify thecomponents of the enterprise. The rows of the matrix represent di�erent perspectives and roles of the enterprisewhereas the columns model di�erent areas of interest within those perspectives. Figure 3 depicts a simpli�edrepresentation of the framework where the columns represent the views or domains and the rows represent thelife cycles for the di�erent stakeholders.

In this framework, each cell in the matrix must be aligned with the cells immediately above and below it.Moreover, all horizontal cells must be integrated to allow indication and assessment of the alignment betweenthe IT and the business needs, respectively. The Zachman Framework provides the ability to de�ne an enterprisein a highly structured way and the need to manage the life cycles of applications is present. The frameworkrefers to a typical project management where the technology is situated at the bottom of the framework. But,it is not clear how to re�ect on and articulate the technology's contribution in the redesign of the organization.In the Zachman Framework, there is not enough guidance on how to make reasoning to deduce a work planthat takes into account the contributions of technology for the redesign of the organization. Moreover, thedimension of how one lives with a multitude of projects can not be seen within this framework. However, itis very useful to use this framework as a base as it incorporates the various levels of modeling abstraction(Conceptual, Logical, and Physical) underlying the research work presented in this paper.

3.3.2 The TOGAF Framework

The TOGAF Framework [14] which was inspired by the Technical Architecture Framework for InformationManagement (TAFIM) developed by the US Department of Defense (DoD), provides a comprehensive organi-zation model to business and IT stakeholders. It provides a business architecture to de�ne the business strategy,the governance, the organization, and the business processes; a Data or Information architecture to describe the

7

Fig. 3 A simpli�ed representation of the Zachman Framework.

data assets and the data management resources; an Application or Systems architecture to provide a blueprintfor the application systems; and a Technology architecture to give an overview of the software and hardwarecapabilities that support the business, data, and application services. These four architecture principles wereapplied in a number of di�erent ways to support the architecture governance and change managnement inorganizations, and to �nd solutions to complexities-related problems.

Among the goals to be achieved were to use the TOGAF's architecture principles as primary requirementswhen formulating the architecture change management and governance processes, and to make informed deci-sions on which policies, processes, technologies, and systems need to be modi�ed or replaced as the organizationevolves over time. The TOGAF architecture certainly provides a solution to align IT needs with business strat-egy in order to improve performance. However, it only partially addresses the multiple-cycle and the di�erentrate of development issues.

3.3.3 Other frameworks-DoDAF, FEAF

Other EA frameworks have been created to help design, organize and govern the enterprise especially in thegovernment sector. This includes the Department of Defense Architecture Framework (DoDAF) [37] and theFederal Enterprise Architecture Framework (FEAF). The DoDAF is a framework used to understand the USDepartment of Defense (DoD) as an enterprise. It is used to identify the operational requirements, make ITinvestment decisions and improve the interoperability among the various systems in the DoD. This architectureenables the DoD to rapidly respond to changing business and IT needs and strategies, and to be able to governthe evolution. However it is a more or less complicated and rigorous framework to adopt. As for the FEAF, it wascreated by the O�ce of Management and Budget (OMB) in the US to help transform the Federal governmentinto one enterprise that is citizen centered. The FEAF which is a business-based framework for government-wide improvement was designed to assist Chief Information O�cers (CIO) in realizing their mandates inthe implementation of information management and IT. They are used to ease the sharing of information andresources across the US federal agencies while improving services to citizens and reducing operational costs. Thisframework is based on �ve reference models dealing with the performance, business, service component, dataand technical aspects of the organization. The performance reference model for example follows a performanceimprovement lifecycle in which EA are developed and maintained, IT is invested and solutions are implementedaccording to a transition strategy.

Though both of DoDAF and FEAF are successful in streamlinig businesses and addressing informationsharing problems, these frameworks are still burdened by the system's life cycle and only provide partialsolutions to understand how to manage the discrepancies in the organizational and technological developmentsin government-wide enterprises.

8

3.4 The Urbanisation approach to complexities

Another potential approach that contributed to solutions for transformations and their complexities is the workdone on Urbanization [16] of information systems. When there are projects in which employees redesign anexisting information system, they have tendency to scrap it down and replace with a new one. It is interestingto see how the concept of urbanization approaches this problem.

The concepts of urbanization, which have been used to formalize or model the layout of information systemsin organizations, organizes the gradual and continuous transformation of information systems while simplifyingtheir use and optimizing their added values as shown in Figure 4. The urbanization plan should describe howto act on the four dimensions of an EA while showing how to see the architecture now, in its evolution, and inthe future. The four dimensions are Business, Information, Systems/Applications, and Technology. Moreover,with urbanization informations systems are made more responsive and �exible with respect to the strategicdevelopment of the organization, while taking advantage of technological developments on the market. Whendevelopers urbanize a city for example, they do not raze it to the ground to make another one. They keep it asit is but look for an articulation. They de�ne an evolution strategy to keep old components, to add new ones,and further to modify an added component, but the city will live in its evolution all the time. As soon as thisapproach is applied to information systems, it can be said that the information system will be made of manycomponents that will have to live together but that some of them ultimately be obsolete and will be removed.

Fig. 4 The interrelationships of the EA dimensions.

The urbanization of information systems has a general goal of consistent progressive information system toensure e�ciency and �exibility while an organization transforms itself. The development of a project in complexand large organizations should follow the logic of a business process-based approach within an urbanizationperspective, and should be based on the fundamental components of the overall architecture. Urbanization herede�nes the rules as well as a coherent and stable framework in which the various components or stakeholders ofthe information system interact with each other. Moreover, urbanization de�nes, based on an overall plan, theevolution of information systems while taking into account the existing systems. Each project or a system canbe thought of as a step in a global move. In this context, e�ective solutions of complex problems can be achievedbased on the overall plan where the coordination with existing or under development systems is done, henceavoiding the development in silos. The overall plan for information is de�ned by the overall architecture ofinformation, and the data model should constitute the stable element of this information architecture. However,the data model can be constantly updated to answer the needs of future projects and information systems ofan organization.

If urbanization provides answers to the di�erence in the organizational pace and the technological rate ofdevelopment, it poorly addresses the problem of multitude of cycles. This is due to fact that urbanization stillmakes reasoning based on one big cycle instead of many.

9

Fig. 5 The CEISAR's complexity-agility-synergy EA framework.

3.5 A perspective of existing solutions with respect to CEISAR's referential

The solutions presented earlier attempt on one hand to bring an understanding to tranformations-related com-plexities in organisations while trying to achieve agility, and on the other hand try to improve the synergybetween the various organization units. In fact, the CEISAR's three dimensional cube [38] which uses com-plexity, agility and synergy as bases can be used as an underlying referential to provide a comparison of theexisting solutions.

The CEISAR's work [38] focusing on enterprise architectures provides a simpli�ed yet consistent view of anenterprise based on only three key dimensions. These dimensions were based on the main business concerns ofsplitting the real world from its model, splitting the operations processes or the present from the transformationsprocesses or the future, and appropriately balancing centralization vs decontralization and speci�c elements vsshared and reused ones. Splitting the real world from its model leads to understanding the enterprise complexitywhereas splitting the present from the future leads to an increase in agility. As for �nding the good balancebetween centralization and decentralization, and between speci�c and shared or reused elements, it leads toidentifying the right synergy level for the enterprise. The complexity, agility, and synergy dimensions provide aframework to model the functioning of the enterprise as shown in Figure 5. This meta-model delivers di�erentviews including a global view for deciders, a business view for business analysts, an IT view for designers, and�nally a detailed view for people who operate and transform.

The contribution of the existing solutions introduced in Sectrion 3 to the understanding of the tranformation-related complexities can now be evaluated with respect to each of the dimension of the CEISAR's referential.The results of this evaluation are shown in Table 1. All of the solutions shown in Table 1 have been widelyused to model the operations and tranformations of enterprises, and to understand and manage some of theircomplexities. The major disadvantage of these approaches is that they have been thought around one big cycleand one big project to ensure consistency. But, each of them has brought an important contribution in its ownway to solve the transformation-related problems. In this paper, these contributions constitute valuable back-ground on which the development of a more comprehensive solution is made. The solution exploits strengthsof each partial solutioon as shown in Table 1. The details of relationships between these solutions and theproposed one is the subject of research under investigation by the authors.

10

Complexity Agility Synergy

Agile solutions

Complexity may increase. Thesemethods focus on streamlining theSDLC by eliminating much of themodeling tasks. They require agreat deal of discipline to preventprojects from becoming unfocusedand chaotic. They are e�ective forsmall projects with highly e�cientteams.

Improves agility. Developers pro-vide rapid feedback to end usersand deliver results very quickly.

They increase the synergy.There is a local synergy bythe reutilization of certaincomponents. There is closecollaboration between devel-opers and close interactionwith end users.

ERPs

They may not help understand theenterprise complexity as they donot split the real world from itsmodel. Very often, they reduce theability to face complexity. The com-plexities increase as organizationsgrow.

They increase agility. They are ableto split the present from the futureleading to an increase in agility.With ERPs orders run faster.

Add some synergy. ERPsstreamline business proceses.They help identify a goodsynergy by �nding the sharedand reused elements in theenterprise.

ZachmanFramework

It helps understand complexity ofthe enterprise by splitting the realworld from its models. It helps or-ganize integrated models of an en-terprise.

It is not clear how it acts on agility.It does not clearly show how to splitthe present (operations) from thefuture (transformations).

It improves synergy. It helpsidentify a good balance andinteraction between di�erentshared models (cells).

TOGAF, DoDAF,FEAF

They help understand complexityas they split the real world from itsmodels.

Similar to other EA frameworks,it is not clear how these frame-works split the operations from thetransformations processes, and con-sequently how they act on agility.

They improves synergy asthey identify a good balancebetween speci�c and sharedor reused elements.

Urbanization

It helps understand complexity inenterprises as it splits the real worldfrom its model. It puts in place areferential of all information whichmakes clear what is confusing.

It promotes and enhances agility.Urbanization splits the presentfrom the future, and it is possible tosee if the information systems areable to evolve quickly and well tochanging business needs.

It achieves a great deal ofsynergy to preserve, use, andmanage the information her-itage until its ultimate ob-solescence. It helps identifya good balance between cen-tralization and decentraliza-tion, and between the speci�cand the reused and shared el-ements

Table 1 Contribution of existing solutions with respect to CEISAR's referential.

4 A comprehensive solution to address complexities

The proposed approach in this paper recognizes the fact that organizations must live with this multitude ofcycles in which other cycles, such as the technology cycle, can also come into play. In addition, the di�erence inthe rate of development between the organization and its IT is another important challenge that it addresses.Therefore, in the proposed approach the authors seek to �nd a solution that allows in this context of tranfor-mation complexities the appropriate use and the evolution of the information systems within the organization.But, instead of focusing on a single cycle, the focus shifts to how to drive and pilot the evolution of a multitudeof cycles. Moreover, instead of being centered on an application, the information will be de�ned and based onthe whole organization leading to an ontology that establishes a corporate model.

In fact, there are a number of indicators that show that more and more developers are starting to focuson modeling the domain rather than modeling the system. This brings the main argument in this researchwork to say that there is a shift from a process of how to manage a cycle to a process of how to pilot theevolution of a multitude of cycles. To bring focus to this information system which simply is no longer theapplication, there will be a shift from modeling with content of databases to modeling knowledge in the domain.Moreover, in these multitudes of applications, di�erent paces of evolution exist: one pace for the developmentof needs and another pace for the evolution of technology. Therefore, there is a need to create a certain degreeof independence between these two paces of development. It is important to understand that organizations has

11

Fig. 6 The proposed enterprise architecture framework.

no choice but to deal with systems that were developed using di�erent technologies. The methods that existare no longer adapted to the situation for which they were made.

To create an information architetcure that guarantees the operation and evolution of the organization insuch complex context, there is a need for organizational concepts based on knowledge of the domain and theorganizational reality on the ground. The framework of reasoning for developing this architecture is thereforebased on a reference enterprise architecture that allows to think in a mutltitude of cycles way, and a two-trackY-model development cycle that ensures articulation and �exibility. The details of these two main architecturalelements are presented hereafter.

4.1 The retained framework

The enterprise architecture is indispensable to model the operation of an organization and to coordinates itsevolution. With a well-de�ned architecture, organizations are able to understand how they operate and wherethey want to evolve. The proposed framework is based on three core organizational concepts: Field actions(FAs), a common canonical Corporate Conceptual Data Model (CCDM), and Views or sub-schemas [3]. Figure6 depicts the retained framework which can be used as a generic framework that abstracts the proposedenterprise architecture.

This framework is made up of:

� Three layers: a Business, a Functional, and a System layer, respectively;� Three domains which are meaningful to di�erent stakeholders in the organization: a Business, an Informa-

tion (Data) and a Systems (Applications) domain, respectively; and

12

� Five views to meet the needs of di�erent stakeholders: Field actions view, Process view, Service view,Messages view, and System view.

The FAs which capture the persistent information of the reality on the ground are any action, decision or eventinvolving one or several parties that can be described independently of a particular business process [19], [20],[21]. For example, a business process may be a request for a laboratory analysis. This business process hasat least two �eld actions such as Register FA and Take blood sample FA. These �eld actions can be used indi�erent business processes. The Register �eld action is independent of the request of a laboratory analysisbusiness process but it can also be used in the case of a surgery business process. A catalogue of all theFAs can be established, and these FAs within the corporate conceptual data model give a coherent and globalinformation model. The CCDM [22] which provides a holistic view of the information is a high level data modelwhere only the main entities and attributes common to several information systems are de�ned. The Viewswhich model information for di�erent stakeholders show the relationship between the information architectureand the business and systems architectures [22] which themselves are articulated around the CCDM. All ofthese key components are articulated to create a certain degree of independence between business needs, theunderlying technology, and the application development process.

In this framework, the CCDM is at the heart of the information architecture of an organization. It can beconsidered as a switching platform that connects the various models that constitute the information architec-ture. These models, called views here, are the various components that are reusable and the deliverables of aproject with regard to the information. Four di�erent views can be de�ned as follows:

� The �eld actions view describes the information representing the actions and decisions that take place inreality.

� The overall business domain view brings together all relevant data to a project as well as the view ofbusiness processes and activities which describes the information created and used by a business process.

� The existing systems view. These are the views of databases and interfaces (services) of existing systemsor those being designed.

� The messages view which matches with the standards of exchange and norms in use or to be used in thefuture in the organization, and messaging in use or under development in systems.

In the information architecture, these views are normalized based on the CCDM. They are in fact sub-schemas of the information contained in the CCDM which are at the same level of abstraction as with theCCDM. The �eld actions view and the messages view have an aspect of generality. In fact, they are a prioriindependent of a particular business process which leads to the important feature of reusability. Although theFAs are de�ned based on the reality on the ground, they are not speci�c to either a particular business processor a business area in the organization. The same FA can be encountered in several business processes of thesame business domain or several separate business areas. In the same way, each business process may havemore than one FA. Therefore, it is proper to say that there is exists a relationship of many to many or n to n[3] as depicted by the red bi-directional arrows shown in Figure 6. Moreover, the development process of thisenterprise architecture is iterative and incremental.

4.2 The two-track Y-model development cycle of CBIS

Another important element in the proposed methodology is the two-track Y-model [17] cycle used as thedevelopment process of computer-based information systems (CBIS). This development process which stressesthe initial non-correlation of the functional and technical aspects is important to ensure a certain degree ofindependance between the two aspects.

To accomodate di�erent life cycles, it is necessary to develop the information technology infrastructureindependently of the needs of organizations and vice versa. In fact, this objective dates back to the mid 70swhere designers of MERISE [26] [25] had an ambition to prevent IT changes a�ecting the use of informationsystems, such as to allow the change of database managmenet systems (DBMS) or the operating system withouta�ecting the apparent functioning from the point of view of users. Many solutions have been developed whichcan be classi�ed into two broad categories: technical solutions to improve IT tools, and methodological solutionsto organize the management process and implementation of CBIS. The present challenge is to design or select

13

a solution in each of the two domains and articulate them to ensure a degree of independence between the twodomains of intervention. The two-track Y-model is a solution to ensure the non-correlation between the twodomains.

The development process follows two paths, Functional and Technical, which correspond to two changesimposed on information systems. Then, the two track merge for the design of the system, which gives the formof a development process in Y as shown in Figure 7. The initial subdivision allows both to capitalize on thebusiness knowledge on the left arm and reuse the know-how on the right arm. The left arm of the Y model,known as 'Functional requirements', is to identify the information system speci�cations which are requested bythe organization. Essentially this part captures the functional requirements to produce a model focused on theneeds of business users. Based on the analysis of this part of the model, it is possible to assess in an early stagethe risk of producing a system unsuited for business users. Consequently, developers will be able to consolidatethe speci�cations and verify their coherence and completeness. Moreover, this part of the Y model includes theanalysis which consists of studying the functional speci�cations in order to get an idea of what the system isexpected to perform in terms of business. This analysis is independant of any particular technology.

Fig. 7 The two-track Y-model development cycle for CBIS.

The right arm of the Y model, known as 'Engineering Tools and Technical Needs', is used to capture thetechnical needs including the software architectures, frameworks, operating systems, programming languages,libraries, and utilities necessary for the design and implementation of the information systems. This part ofthe Y model helps identify all the constraints and choices a�ecting the system's design. For example, theidea of process re-engineering stipulates the use of the IT tools in the left arm of the Y model in order toredesign processes. For this purpose technology is needed to rearrange business processes so that organizationsbecome more productive. IT human resources including analysts and programmers need to have this as atoolbox available to them and if possible any reusable component in order not to reinvent the wheel in eachnew project. These tools are organizational context independent where they involve the design, the editingand development of computer programs, respectively. The selected IT tools and components while takinginto account the constraints of integration with existing modules generally a�ect the technical architectureprerequisites. This part of the Y model also includes the generic design which then de�ne the necessarycomponents to build the technical architecture. This is completely independent of the functional aspects. Itaims at standardizing and reusing the same mechanisms for one system. The technical architecture builds theskeleton of the system and dismisses most of the technical risks. It is advisable to build a prototype to ensurevalidation.

The central arm of the Y model which is called 'CBIS Development' represents the phases for the devel-opment of computer-based information systems. This part includes a delicate preliminary design phase whichintegrates the analysis model in the technical architecture in order to picture the system components to develop,the detailed system design showing how to achieve each component, software coding, and �nally testing andvalidation. The challenge here is the design and implementation of a socio-technical CBIS system where upon

14

which developers can constantly navigate between several dimensions. Business managers know very well theirneeds but only have a partial knowledge of technologies. On the other hand, developers are aware of IT toolsbut lack information of data and needs. Consequently, requests formulated by managers can be suboptimalmaking them either too simple or too complex. Moreover, they have di�culties operating with design artifactsthat are vague and abstract. To bene�t from the contributions of technology, they must change in part theirbehavior and the operation of their organization. As for IT people, they have a strong and natural tendencyto impose their technical preferences or the latest IT design, which are not necessarily the best suited to meetthe needs of buisness people. On the other hand, one must recognize that these IT people often do not quitelyunderstand the needs of the organization.

With the two-track Y-model, the process of development of CBIS is iterative and incremental that integratesthe best practices of system development which has the advantage of highlighting what the socio-technical CBISsystem requires and what can be independent in each of the arms of the model.

5 Building the information systems architecture

The aim of the CCDM, the global conceptual and corporate data model, is to model the many concepts encoun-tered in the reality of a particular business domain and which are used in the multitude of information systemsof an organization. However, attempting to model this whole domain at once could be a rather challengingand laborious task. Furthermore, attempting to construct a graphical representation of this global data modelcan be easily become so large and complex that it will ultimately be di�cult to read or maintain. Therefore,there is a need, on one hand, to partition this large and complex modeling task into smaller and manageableparts, and on the other hand, there is a need to know how can these di�erent parts of the same informationarchitecture be identi�ed and partioned.

To stay close to reality, it could be a good idea to base the data models on real life events and actions. Inpractice, a person acting within an organization will see his or her actions occur in a particular administrativeprocess or context. If systems are independently developed from each others, then an analysis for each system ismade even if common concepts are used between the systems. This leads to a less productive environment andto redundancy. To be able to solve this problem and to better describe the environment under consideration,it is proposed in [3] to use the concept of Field Action in the process of modeling the information architectureof an organization.

5.1 The �eld actions

The �eld actions (FAs) [1] [3]which constitute one of the key concepts used in the proposed methodology forbuilding the information architecture, are any action, decision or event involving one or several players whocontribute signi�cantly to the achievement of a business process. An FA has the following characteristics:

� it contains relevant information,� it contains information that is persistent, and� it represents the reality on the ground.

In fact, an FA can be described independently of any particular business process. They are the reusable elementsin the enterprise architecture. Each of these actions can be depicted distinctively and explicitly with a separatedata model involving an ensemble of concepts depicting the reality on the ground and their relationships.

A list of all the FAs in the enterprise architecture is progressively formed to re�ect on all the actions,decisions and events that take place in the enterprise. The set of the FAs are used to form the global corporatedata model at the conceptual level. This model provides a coherent information model of the reality on theground.

5.2 The Conceptual Corporate Data Model (CCDM)

The CCDM provides a holistic view of the information in the entire organization. This abstract data modelis a formal representation of a set of concepts within a particular domain, and the relationships between

15

Fig. 8 The views of the CCDM.

those concepts. In other words it is the ontology for this domain that represents knowledge about reality onthe ground. The components that make this model are the ground level objects or entities, their attibutesdepicting their properties, relationships showing ways to connect an entity with another in the model, andrules and restrictions.

This model is said to be corporate as within which only data that are primary or natives can be found.In fact, these are data that describe either elements of reality or events de�ned from a point of view that isas neutral as possible, in other words independently of a particular use. It is conceptual, implying that thismodel represents the meanings (i.e. de�nitions) and the relationships between the meanings. The CCDM isnot a representation of the materialization in physical systems such as databases. This model is normalizedwhere each data is represented there only once. Moreover, the CCDM is a high level model where only themain entities and attributes common to several applications are de�ned. It should be viewed as a very largeglobal data model that represents the entire system. When it is necessary to model a particular informationsystem, it is not essential to include all entities and relations from the model. Only parts of it will be usedalthough there is common subset of entities that is frequently reused in every di�erent system.

5.3 The views and sub-schemas

Another key component of the proposed information architecture are the Views or sub-schemas. The infor-mation architecture relies mainly on these views. In fact, these di�erent views are meaningful to di�erentstakeholders of the enterprise architecture. They are articulated around the CCDM which forms the hub ofthe information architecture putting in relation these di�erent models. There are four views that can be de-duced from the MCCD as shown in Figure 8. These are the Field Action view, the Buisness Process view, theMessages view and the Systems/DB view. For example, one of the business needs in terms of a message isadding a client to the system. Adding a client requires to �ll in information such as name, address, and theinsurance reference number. Some of these information may be common to di�erent needs, and consequentlythey appear within the CCDM. Hence, a view is built by selecting the entities of the CCDM which containthe required information. This view can be updated by information which are speci�cally used in this needand not shared with other needs. This view is also called sub-schema. Each view interests only the message'smodeller (stakeholder).

The Field Action View is a sub-schema of the CCDM that groups all the relevant components that makean FA. As for the Business Process View, it contains all the relevant business processes that are speci�c to aparticular project. The System/DB View is a view of the databases and interfaces of existing systems. It canalso be a view of systems that are currently being implemented. As for the Messages View, it represents therelevant entities that compose a message. All of these views along with the CCDM ontology and the FAs formthe core components of the proposed information architecture.

16

To generate these views or sub-shemas out of the ontology, the authors developed a dedicated approach forthis purpose called the CCDM Coupling Method that allows the transition between the conceptual and logicalmodeling levels of the proposed methodology.

5.4 The CCDM coupling method

All sub-schemas generated using the CCDM are Conceptual Data Model (CDM) in their respective domainview. Each sub-schema contains concepts or entities and their associations which integrate data that is speci�cto a particular project or system. These entities are associated in a way that is speci�c to the project thatthe CDM represents. This allows a coherent approach for the information system under development since theentities are always taken from the same source which is the CCDM model.

The process of creating a CDM and connecting it to a Logical Data Model (LDM) follows a set of steps thatare depicted in Figure 9 and explained hereafter. The �rst step of the coupling method consists of creating anLDM of the information system, application, database or message to be integrated to the CCDM. This is the�rst level of abstraction where modelers represent concepts encountered in physical level by their conterparts inthe logical level of abstraction. The terminology of concepts at the logical level is what can be found in realityon the ground. A logical model is basically a conceptual model, but instead of using the terminology comingfrom the CCDM, terms originating from the information system under consideration are used. The terminologyat the conceptual level can be sometimes di�erent from the one used at the logical level as the conceptual levelis a higher level of abstraction where the terminology used is common to all systems and applications in thearchitecture. For example, in the healthcare system of Quebec, there are several databases in use whose physicalimplementation have been achieved by IT specialists. The de�nition and naming of the various concepts andentities used in the implementation process is usually taken care of by the IT specialists. These names addressthe needs of programmers and developers unfortunately and do not re�ect the de�nitions and naming used byusers of these databases. This is in fact one of the obstacles to interoperability. Furthermore, at the conceptuallevel of modeling abstraction, di�erent naming for concepts or entities may be necessary to create a unique wayof representation. For example, at the logical level, a system may refer to client as a patient, and a care giveras a doctor. Another system may give di�erent naming for the same entities at the logical level. Though thereare various vocabularies encountered in the reality on the ground re�ected by the LDMs, the CCDM presentsa common vocabulary for all systems and applications.

To integrate each of the logical models to the global one, there is a need to �nd corresponding entities andattributes in the CCDM. Every element from each of the logical models are manually picked and matched tothe CDM being created for that particular LDM. If a corresponding entity or attribute in the LDM can not befound in the CCDM, the pertinence of adding it to the global model is evaluated as shown in Figure 9. As aresult, the CDM of the information system will be gradually built, and in the same time, the CCDM-couplingprocess allows to re�ne the CCDM by adding new entities and attributes if necessary. The LDM-CDM-Couplingapproach can, thus, be considered as a bottom-up methodology. New data are discovered by analyzing existinginformation systems. These new data are added to the CCDM. Finally, the semantics of this new informationis veri�ed to see if the global data model remains comprehensive and most importantly coherent.

The CCDM speci�es, therefore, the global information architecture where the data it comprises can bespread across a sub-schema taking the form of an CDM. The CCDM can be seen as the stable pivot that putsin relation the various schemas that compose the information architecture. The Views in the CCDM improvethe cohesion between systems, harmonize the information, and allows the process of reutilization. Moreover,although the CCDM is used essentially to model the information architecture of an organization, it can alsoserve as an e�ective tool to improve communication and understanding between all the stakeholders of aninformation architecture including business managers, system analysts and application developers.

5.5 The rubrics

As new �eld actions are continuously identi�ed on the ground and consequently new concepts and their rela-tionships are added to update the global data model, the latter can very easily grow to become very complexand di�cult to maintain. Moreover, in this research project there was a need to establish a method for express-ing information that is external to the healthcare business domain under investigation including judicial data

17

Fig. 9 The CCDM coupling method.

needed for public health investigations, health standards and common vocabularies or information relating toother �elds. The explicit modeling of all of this external information and its inclusion in the global model canmake the CCDM data model even more complex.

To avoid the overloading of the global data model in order to keep the information architecture manageable,new concepts of rubrics are introduced to manage the graphical representation of the CCDM. Rubrics allowthe addition of information to a data model without being explicitly represented in the global model. In [39],the author states that the electronic health records should be presented to the person consulting it using viewswhile at the same time, using strictly data that he or she is interested in and to which he or she has accessrights. Some parts of these records can be components of many views and can have totally di�erent aspects forevery di�erent view. This type of structure is exactly what it is being proposed in this paper along with theCCDM. In fact, it was stated in [40] that narratives or rubrics allow health professionals to share complex ideasin an e�cient manner. They provide easily understandable content while representing complex and disparatedata. Compared to structured data, such as web forms, narratives are much more �exible, easy to interpret,and closer to the way caregivers are used to work with. Meaning can be lost when clinicians are forced to workwith highly structured data. However, structured documents are necessary when information systems need toexchange data.

In the proposed method, rubrics represent a block of text that can be shown to the user to obtain detailsabout a certain aspect of a medical record as shown in Figure 10. Rubrics are presented together with a set ofMeta tags that can help the user sort di�erent rubrics. These Meta tags are directly taken from the CCDMand are attributes that are common to every possible representation format that the rubric can take. Rubricscontain plain text but can be structured using XML to facilitate their presentation to the user using for examplestyle sheets. In the global model, a rubric is viewed as an entity. The main di�erence with other entities isthat a rubric can be broken into di�erent sub-entities depending of the context. Therefore, in a particularsub-schema of the CCDM, a rubric will have additional attributes although it will always keep the attributesthat were present in the CCDM (i.e. the Meta tags).

This method allows the simpli�cation of the global data model since details about entities can be expressedonly in their particular context. This also reduces the number of entities in the CCDM since only rubrics inthe global model are kept. Their di�erent specializations in sub-schemas are not kept. The use of rubrics inthe CCDM model brings in many advantages such as:

18

Fig. 10 The Prescription rubric.

� the simpli�cation of CCDM where the attributes speci�c to a particular context are only presented in theFA where it is relevant;

� the reuse of entities where the same entity can be reused in several FAs in di�erent forms. This reduces thecomplexity of our CCDM and renders the maintenance of our CCDM an easy task; and

� the use of attributes only in the appropriate context where the attributes of a rubric appear only in theappropriate FA.

The proposed CCDM-based enterprise architecture is being implemented to model the operations and thetransformations processes of the Quebec healthcare organization in Canada. The goals of this implementationare to understand the enterprise complexity, to increase its agility while �nding for it the right synergy level.The following sections present the implementation process and the achieved results.

5.6 Managing the graphical complexities of the CCDM by the use of proper modeling tools

The information architecture of the Quebec healthcare system is composed of a very large number of sub-schemas and models, and this therefore had required the use of an appropriate modeling tool to manage thecomplexity of this environment. The only software with functionalities that suited the research project's needswas the SILVERRUN software [42], presently called the SILVERRUN ModelSphere5 and o�ered by Grandite.

The SILVERRUN tools while supporting the business process re-engineering projects, provide modelingcapabilities to model data based on traditional entity-relationship method. The SILVERRUN ModelSphere5tool can also be used to model business processes and to create business process mapping in which one canshow the �eld actions. This tool provides a �exible environment for business processes, systems views, and�eld action views' management which can greatly help manage the complexities faced with when dealing withmultiple schemas and sub-schemas. This software tool which is designed in Java and works on a standardvirtual machine can be installed on di�erent platforms such as Linux and Windows. Users of this software toolcan easily build their data models either from scratch or via reverse engineering from a variety of sources suchas Relational Database Management Systems (RDBMS).

19

Another important tool that was developed to suupport this research is the CCDM_Extract [22] tool usedto generate CCDM mapping matrices. The CCDM_Extract is a simple web-based software that allows thecomparison of di�erent data models with the global data model of the CCDM. It allows the identi�cation ofcommon elements and attributes between the models under investigation. Figure 11 shows an example of modelmatrix generated using CCDM_Extract where the letter 'X' indicate that an element is present in a speci�cmodel. The CCDM_Extract tool helps identify any redundancy with respect to entities presence in existinginformation systems and applications. With the help of CCDM_Extract, organizations can create e�cient newsystems based on existing ones where the concept of re-utilization is exploited.

Fig. 11 An example of a CCDM_Extract matrix.

6 Conclusion and future work

This paper proposed an architecturing methodology to develop a stable and integrated yet extendable in-formation architecture for large and complex organizations. This architecture copes well with the problemsemanating from managing complexities in attempting to pilot multiple applications developed in silos thatmany large organizations are nowadays faced with, and from the di�erence between the organizational and thetechnological rates of development. The proposed methodology was based on two main elements: an enterpiseframework and a two-track Y-model development cyle for information systems. Three core concepts were usedin the framework: reusable �eld actions representing persistent information on the ground, a central commoncanonical and global data model, and views used to represent the interest of stakeholders in the enterprisearchitecture. The development process of the information systems followed the two-track Y-model develop-ment process to guarantee a certain degree of independence between the business and IT needs. The two-trackY-model was used in an iterative and incremental process to articulate the business requirements with the

20

technical needs in order to design appropriate information systems. The concept of rubrics was introduced toalleviate the global data model where details about entities were only expressed in their particular context.

The proposed solution to architecturing complex information systems in large organizations provides anappropriate enterprise framework and an information system architecture to address the issues of understand-ing complexity in enterprises, how to increase their agility and �nally how to �nd the right synergy level. Eachof the existing solutions discussed in this paper provided a contribution to �nd an overall solution to transfor-mations of organizations answering some aspects of the needs of complexity, agility and synergy. The enterpriseframeworks have been found to be helpful for splitting the real world from its models. They were used to orga-nize the many models of any enterprise hence helping understanding the business and therefore reducing thecomplexities. The urbanization of information systems approach has been helpful to �nd the right synergy levelbetween centralization and decentralization, and between the speci�c elements and reused or shared elements.It showed how the components of the enterprise architecture interact with other to garantee the evolution ofthe organization, and therefore helped in improving the synergy of the enterprise. Agile methods on the otherhand have been very sueful to increase the agility in the development process of information systems. All ofthese approaches have been instrumental in the development of the proposed approach. Moreover, with the useof the two-track Y-model for the CBIS life cycle, it was possible to achieve independence between the businessand technology needs in the design and development of information systems.

As for future work, the authors are focusing on extending this research projet to include Service-OrientedArchitectures (SOA). For creating durable systems, the state of the art to write programs that are �exiblerefers to the use of SOA [44]. In the proposed Y model of a CBIS process development, the SOA is situatedin the right side where the inputs to this branch are the IT services. The SOA by itself can not identifythe elementary components that serve to write these programs. There is a need to use the left side of the Ymodel which includes inputs of the business processes of the organization in the form of �eld actions. SOA,which o�ers a modular vision of an application where functionality is grouped as services, attempts to providean infrastructure where there is a loose coupling between the services with their underlying technologies.These services can be combined and reused in the making of business applications of an organization. Foran organization that seeks an IT �exibility and a modularity of its processes, the deployment in the form ofservices that support its administrative tasks has become a strategic choice. In fact, the proposed CCDM-based approach can lead to the identi�cation of these services, and also can assist in the design, coding, anddeployment of software applications. In fact, the �eld actions represent what an organisation should o�er interms of services. Thus, the de�nition of SOA services based on �eld actions will lead to the development ofinformation systems that can meet the challenging needs of complex organizations. It is also essentiel to notethat SOA can not be properly used unless it is supported by a global data model such as the CCDM ontologywhere data representing the organization will be used in the execution of services. The use of the CCDM willallow services to communicate under the same logic base while using a common information architecture.

Acknowledgments- This research work is being conducted at the DAAOT (Direction Adjointe à l'Architectureet aux Orientations Technologiques) at the Ministry of Health and Social Services of Quebec in Canada.

References

1. Le Moigne, J. L., Les systemes d'information dans les organisations, PUF 1973.2. Tardieu, H., Rochfeld, A., Colletti, R., Panet, G., and Vahee G., (1985). La methode Merise - Tome 2 Demarches et

pratiques. Editions d'organisation (Paris): 460 p. ISBN 2-7081-0703-8.3. D. Pascot, La methode Datarun, Management Information Systems Department, Faculty of Business Ad-

ministration, Laval University, Quebec, Canada, 1999. http://loli.fsa.ulaval.ca/�leadmin/Methodes/Analyse/pdf-datarun/DATARUN.pdf

4. M. Lankhorst, Enterprise Architecture At Work: Modeling Communications and Analysis, Springer, 2005.5. Batini, C., Lenzerini, M., and Navathe, S. B., A comparative analysis of methodologies for database schema inte-

gration, ACM Computing Surveys (CSUR), Vol. 18 , Issue 4, pp. 323- 364, 1986.6. Doerr, M., Hunter, J., and Lagoze, C., Towards a Core Ontology for Information Integration, Journal of Digital

Information, 4 (1), 2004 http://jodi.ecs.soton.ac.uk/Articles/v04/i01/Doerr/7. Calvanese, D., De Giacomo, G., Lenzerini, M., Nardi, D., and Rosati, R., Description Logic Framework for Informa-

tion Integration, Proc. of the 6th Int. Conf. on the Principles of Knowledge Representation and Reasoning (KR'98),Trento, IT, pp. 2-13, 1998.

8. Waldner, J. P., CIM: Principles of Computer Integrated Manufacturing, Chichester: John Wiley & Sons Ltd, p47,1992. ISBN: 047193450X

21

9. Ambler, S. W., Agile Modeling: E�ective Practices for Extreme Programming and the Uni�ed Process, New York:Wiley, 2002. ISBN: 0-471-20282-7

10. Martin, J., Rapid Application development, Macmillan Coll Div, 1991. ISBN: 0-02-376775-811. Beck, K., Extreme Programming Explained-Embrace Change, Reading, MA: Addison Wesley Longman, 2000.12. ANSI/IEEE 1471-2000, Recommended Practice for Architecture Description of Software-Intensive Systems.13. Zachman J. A., A Framework for Information System Architecture; IBM, System Journal, Vol. 26, No. 3, IBM

Publication G321-5298, 1987.14. The Open Group, TOGAF, The Open Group Architecture Framework. http://www.opengroup.org/architecture/togaf/15. Berck D., Presentation from the Chief Architect's Forum, CAF Quaterly Meeting, FEA PMO Update, October 11,

2006. http://www.whitehouse.gov/omb/egov/documents/2006_CAF_Qtrly_Mtg.pdf16. Jean, G., Urbanisation du business et des SI, Hermes 2000, Lavoisier 20002. ISBN: 2-7462-0135-617. P. Roques and F. Vallee, UML en action, de l,analyse des besoins à la conception en java, Deuxieme edition, Groupe

Eyrolles, 2003. ISBN: 2-212-11213-0.18. Dupuy-Chessa, S., Godet-bar, G., Juras, D., and Rieu, D., Principes pour une methode de conception de systemes

mixtes, in Proceedings of 19th Conference francophone sur l'Interaction Homme-Machine (IHM'2007)19. Kato, S., System Development Guide Book, NikkeiBP Publications, Printed in Japan, June 26, 2000 ISBN4-8222-

8073-X20. Pascot, D., and Ochimizu, K., C/S DataBase Sekkei Nyumon, A Japanese Translation of DATARUN Concepts,

Client/Server Power System Series, NikkeiBP Publications, Printed in Japan, 1996, ISBN4-8222-9015-8.21. PFU, The DATARUN Epoch-making Multi-Media teaching Materials, For Easy Understanding of the Business

Process Reengineering methodology DATARUN, CD-ROM, PFU Limited, Tokyo, Japan, 1996.22. Pascot, D. Conception des SIO, Lecture Notes, Management Information Systems Department, Faculty of Business

Administration, Laval University, Quebec, Canada (2007) http://loli.fsa.ulaval.ca/index.php?id=47823. The Quebec Health and Social Services System-Ministere de la Sante et des Services Sociaux,

http://www.msss.gouv.qc.ca/en/index.php24. Cadre methodologique, Direction adjointe à l'architecture et aux orientations technologiques (DAAOT), The Min-

istry of Health and Social Services (MSSS), Quebec, Canada, 2007.25. Tabourier, Y., De l'autre c�te de Merise: Systemes d'information et modeles d'entreprise, Les editions

d'organisation, ISBN: 2-7081-0762-3.26. Rochfeld A., and Morejon J., La Methode Merise, Tome 3, Gamme operatoire, Les editions d'Organisation, 1989.

ISBN: 2-7081-1057-827. Martin, J., and Finkelstein, C., Information Engineering, Technical Report (2 volumes), Savant Institute, Carnforth,

Lancs, UK, November 1981.28. Macdonald, I., Information Engineering in Information Systems Design Methodologies, ed TW Olle et al, North-

Holland, 1986.29. Gane, C., and Sarson, T., Structured Systems Analysis: Tools and Techniques, Prentice-Hall, Inc., 1979. ISBN:

0-13-854547-230. De Marco, T., Structured Analysis and System Speci�cation, Prentice-Hall, Inc., 1979. ISBN:0-13-854380-131. Royce, W. W., managing the development of large software systems, in Proceedings of IEEE WESCON, August

1970.32. Gamma, E., Helm, R., Johnson, R., and Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented

Software, Addison-Wesley, 1995. ISBN: 0-201-63361-233. Ho�man, M. and Beaumont, T., Application Development: Managing the Project Life Cycle, Mc Press, 1997. ISBN-

10: 188388445434. Pressman, R. S., Software Engineering: A Practitioner's Approach, The McGraw-Hill Companies, 2004. ISBN:

007301933X35. Boehm, B., A Spiral Model of Software Development and Enhancement, Computer, IEEE, 21(5):61-72, May 1988.36. The Federal Architecture Working Group (FAWG), A Practical Guide: Federal Enterprise Architecture Framework,

Version 1, February 2001. www.gao.gov/bestpractices/bpeaguide.pdf37. The Department of Defense Architecture Framework (DoDAF). http://www.defenselink.mil/cio-

nii/docs/DoDAF_Volume_II.pdf38. Enterprise Modeling: White paper, Center of Excellence in Enterprise Architecture-CEISAR, April 2008.

http://www.ceisar.org/39. Silberzahn, N., Le dossier medical informatise : Modelisation et consultation. Ph.D. Thesis, Faculte de medecine,

Universite de Caen, France, December 1997.40. Shapiro, J. S., Bakken, S., Hyun, S., Melton, G. B., Schlegel, C., and Johnson, S. B., Document ontology: Supporting

narrative documents in electronic health records, In Proceedings of AMIA Annual Symposium, pp. 684-688, 2005.41. Tardieu, H., Nanci, D., and Pascat, D., Conception d'un systeme d'information : Construction de la base de donnees,

Edition d'organisation, 1979.42. SILVERRUN Modeling Tools, Grandite, 2008. http://www.modelsphere.com/43. Logical View of Message Model PRPM_MT303010CA - Update Provider, Direction adjointe à l'architecture et

aux orientations technologiques (DAAOT), The Ministry of Health and Social Services (MSSS), Quebec, Canada,2008.

44. Bonnet, P., Detavernier, J.-M., and Vauquier, D., Le syteme d'information durable: la refonte progressive du SI avecSOA, Editions Hermes-Science, ISBN:978-2-7462-1829-1.