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
[email protected]
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 Complex Information Systems Daniel Pascot Faouzi Bouslama Sehl Mellouli
Received: /Accepted:
Abstract Information systems developments face dierent dimensions and components that do not change at the same time emanating from the multitude of cycles of applications previously developed in silos and from the dierence in paces between the organizational and the technological developments. This paper shows that existing solutions only partially address one or the other or both of the problems. Capitalizing on these solutions, this paper proposes a more comprehensive answer for the development of an enterprise architecture that takes into consideration these challenges and which guarantees the evolution of the organization in such context. This architecture is based on two main elements: a reference enterprise architecture framework and a two-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 subschemas. The FAs capture the persistent information of the reality on the ground. They are the key reusable components of the process architecture. The CCDM provides a coherent global information model of the knowledge domain, and the Views model information for dierent stakeholders. All of these key components are 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 with complexities of the models. This approach is being implemented to create an enterprise architecture of the healthcare system at the Ministry of Health and Social Services of Quebec to manage the complexities and monitor the evolution of this large government organization.
Keywords Entreprise architecture, Information architecture, Field actions, CCDM, Views, Business processes, Two track model, Health informatics.
1 Introduction The transformations witnessed nowadays in medium and large organizations to become more eective while meeting their strategic objectives and external constraints are quite complex and always take place under many challenges and di culties. One of these di culties emanates from the multitude of life cycles of the large number of applications which have been developed in silos over the years but continue to be in use by the dierent 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 rue de la Terasse, Quebec (QC) G1V 0A6, Canada. E-mail:
[email protected] E-mail:
[email protected] E-mail:
[email protected]
2
in the creation of this multitude of applications more or less autonomous, which have the contradictory eect to slow the adaptation of rms. The multitude of applications have been developed in isolation one after the other each with its own life cycle. Though, many of these organizations have been largely transformed and digitized, in reality they are still operating in silos, which has been hindering the processes of information sharing and integration, and therefore the corporate growth. Another major di culty in organizations is related to the dierence in pace of the organizational and technological development. The technological evolution pace both in computer hardware and software, though to a lesser extend in the software part, is dierent and often considerably faster than the rate of evolution of organizations. In fact, the lifespan of hardware or software to catalogue suppliers is just few years and sometimes few months, while the lifetime of critical applications in organizations is in the order of several tens of years. These di culties are more present especially in large and complex organizations such as those in the government sector. Given this dierence in rate of change of development, it is very unlikely for an organization to perform the right alignment between its organizational needs and technology's capabilities. As a consequence of these problems, organizations are faced with an increasing volume of complexity, ine ciency and rigidity that are due to the accumulation of the use of heteregeneous applications and systems. They are now looking for best approaches to manage and sort out these transformation-related complexities. These approaches are expected to allow managing and evolving together the many applications, and getting control over the organization's global model of information and pace of changes. But in order to ensure that organizations eectively manage their transformations, they need to create qualitative statements of business needs which can be used to formally plan, design and govern the transformations processes. To achieve this goal, organizations have been looking for appropriate modeling techniques of architecture which can be used to provide on one hand a global view to understand how an organization maps its processes, functions, entities and solutions to the real world, and on the other hand to create a set of detailed models describing its actors, actions, and data. Organizations operate using a speci c model but when there is a transformation, this model is subject to change as in the case of the strategic objective to integrate information architectures to foster cross-borders cooperation. To be able to describe how organizations work and how their transformations take place inline with their strategies and goals, several initiatives in enterprise architecture modeling have been created for this purpose. The Enterprise Architecture (EA) provides a holistic view and a mechanism to design, develop, communicate and understand the enterprise. It is designed to organize all the information that is created and communicated in an organizational system in order to secure progressively, in terms of information, consistency of all operational and management information levels systems. Moreover, in medium and large organizations, the management of complexities necessitates the development of an integrated and stable information architecture [1], [2], [3], [4]. The rst attempts to integrate information were performed in the context of the design of databases by C. Batini et al. [5]. To remove redundancy and create a uni ed data model, schemas of existing and future databases were integrated into a global and uni ed one. In [6], the authors presented an extensible ontology for information integration which expresses the basic concepts that are common to dierent domains. They argued that a core ontology is one of the key building block necessary to enable the scalable assimilation of information from diverse sources. This core ontology provides a global model into which data originating from distinct sources can be mapped and integrated. Moreover, this canonical form which provides a single knowledge base for cross-domains tools and services helps avoid application complexities resulting from pair wise mapping between individual metadata formats and ontologies [6]. In fact, the information integration whose goal is to access data from multiple sources requires two critical factors for the design and maintenance of distributed and cooperative applications and information systems [7]. These two factors are the conceptual modeling of the domain, and the reasoning support over the conceptual representation. Here, the knowledge representation 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 data in an organization, and to address the inherent problems of transformations-related complexities, there is a need for appropriate methodologies to support the information integration across organizational processes and application boundaries. For this purpose, many solutions have been proposed by business users and Information Technology (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 Architecture Framework (TOGAF) [14]; and
The eorts 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 show how to manage the multitude of life cycles of applications, and only partially address the dierent paces between the organizational and technological development of the organization This paper capitalizes on these solutions to propose a more comprehensive answer for the development of an information architecture that takes into consideration these challenges and which guarantees the evolution of the 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]. 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 [3]. The FAs which capture the persistent information of the reality on the ground is any action, decision or event involving one or several players that can be described independently of a particular business process [19], [20], [21]. A catalogue of all the 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 the main entities and attributes common to several information systems are de ned. The Views which model information for dierent stakeholders whows the relationship between the information architecture and the business and systems architectures [22] which themselves are articulated around the CCDM. Through the use of the two-track Y-model development process, all of these key components are articulated to create a certain degree of independence between business needs, the underlying technology, and the application development process. The obtained global data model can be very complex. Here, the concept of rubrics is used to simplify this 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 Health and 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 problem of the multitude of cycles that organizations are faced with resulting from the many applications that have been independently created over the years, and the problem of the dierent pace between the organizational and technological development. Section 3 provides a brief summary of the existing solutions and compare the contributions of each with respect to the complexity, agility and synergy dimensions. Section 4 presents the proposed enterprise architecture framework with its core components of FAs, CCDM and views, and the two-track Y-model for the development of Computer-Based Information Systems (CBIS). Section 5 shows the building process of the information systems architecture. Section 6 is a highlight of directions for future research work. 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 a single application life cycle. This system development life cycle (SDLC), which originally took the form of Royce's waterfall model [31], is the process of understanding how an information system is used to support the organization'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, implementation, maintenance, and phase out phases, respectively. The applications development moves through all six phases and when the application attains its obsolecence, then a new project cycle begins. The degree of information 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 and whose primary objective is to create value for the organization. With this cycle, system analysts and developers de ne the user needs and requirements, design and choose a solution, and then develop and implement that solution. But creating value for the organization is not an easy task as the understanding of how the system would support the organizations's goals, the existing business processes and other information systems can be very 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 of technology and any changes in either one aects the other as both of the needs and technology are integrated in the same cycle. In fact, there are many publications in Information Systems Requirements that focused on the link between technology and needs where methodologies implementing the SDLC attempted to de ne in a stable way the user needs. These methodologies placed primary emphasis on de ning the needs for which the developed systems should respond. The Objected-Oriented (OO) methodologies [32] for example use Use Case diagrams to identify and model the needs in software engineering. As for agiles methods, users are made to interact with technology so that together they adjust technology as the needs change. These approaches may work well for small applications but if the requirements are complex or unclear, things get confusing. The problem of de ning needs is in fact a di cult problem as shown by the place that this issue occupies in design methods and in the litterature on information requirements. Today, there are few developers who follow the original strutured design methodology of the waterfall approach as it takes them a long time before they discover the real problems of the information requirements. Moreover, most of this and other design methodologies have been focused on one application and the entire content of the analysis was limited to that application. The needs were the needs of the users of the application, and therefore this required a stabilization of the needs for the life cycle. Considering what happened in organizations from a historical point of view, a multitude of applications have been developed in isolation one after the other each with its own life cycle. The challenge today is to manage and to make evolve together all these applications, but given their overall size, it is no longer possible to apply a single life cycle to all applications within an organization. Instead of one single cycle representing the development, operation and support as in the case of a single application, there are n cycles in the case of multiple applications as depicted by Figure 2. These n cycles need to be continuously piloted and managed to allow 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 form of Corporate Conceptual Data Model (CCDM) as is proposed in this study. The CCDM can be thought of as the 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 is only a couple of years in which some needs evolve quickly while others are stable? How can organizations live with the multitude of life cycles? To overcome these challenges, organizations sought the help of information integrating 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 particular aspects 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 numerous applications which were developed inconsistently in silo, and also by the di culties emanating from the dierence in pace between the organizational and technological developments, respectively by acquiring and implementing various technological solutions. From Enterprise Resource Planning (ERP) systems to Enterprise Architecture (EA) frameworks and Urbanization of information systems, organizations have been looking for appropriate solutions to model their operations and transformations in order to understand complexities and to 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 disadvantages related to the very long time it takes to implement and test the system, and the poor communication mechanism to re ect on user needs. The developers of programs understood the necessity to stabilize the needs for the life cycle. But stabilizing the needs is di cult, and so researchers and practioners proposed dierent modi cations for the original waterfall life cycle. They proposed the typical V-shape cycle [33], [34], the spiral life cycle model [35], and new methodologies such as the Rapid Application Development (RAD) [10], the Extreme Programming (XP) [11], or the recently Agile methods [9] that focus on short development life cycles and close interaction with users. These methods are software development approaches that involve iterative development aiming at speeding up the analysis, design and implementation phases of the SDLC, and hence the applications' development process. However an important subtle problem remains which is the management of user expectations and system requirements. Each of these methods responds only partially to the problem. On the contrary, they have tendency to increase the complexity problem without addressing the articulation of multiple cycle of applications. Therefore, they are only local solutions that can not address the global transformation-related problems.
3.2 ERPs in integrating the business processes Among the solutions that organizations thought of using to address the transformations-related problems were the Enterprise Resource Planning (ERP) systems [8]. The ERP solution helped organizations collect all business areas in one system to support most of the business system needs. ERPs maintained in a single database all the data necessary to run the organization. Each functional unit within the organization uses its own supporting software applications and the ERP software links these applications and ensures their compatibility through the use of the common data storage. The bene t of using ERP is to streamline business processes which achieves e ciencies and therefore lower costs. However, ERP systems can grow to become very complex and di cult to manage as organizations transform themselves and become more complex themselves. ERPs are often customized for the speci c business processes that they support and to suit the needs of the organization. Very often, this customization is quite complex leading organization to rely on vendor solutions and external service providers to run and maintain the 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 service providers 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 solved partially 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 models of organizations and the communication and understanding of the enterprise. They provide a holistic view of the entire enterprise as they deal with a collection of organizations that have a common set of goals and linked together by common ownership. The term enterprise is used to denote all the information systems in the enterprise. The ANSI/IEEE Std 1471-2000 [12] de nes architecture as The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing 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 the business and technical lead. Among these frameworks, the Zachman Framework [13] is very often used as a standard to conceive the enterprise architecture. Other EA frameworks are equally important such as The Open 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 a multitude of applications that were developed at dierent times with dierent technologies. They all bring in a 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 used integrated framework for modeling and managing change and transformations in organizations. While being recognized as an easy to understand framework, the large number of cells makes it di cult when it comes to practical applicability considerations. The Zachman Framework provides a collection of perspectives to model the enterprise, its business, and architecture. In this framework, the structure is designed to identify all possible primitive representations with respect to an enterprise or organization. The framework uses a six by six two dimensional matrix to classify the components of the enterprise. The rows of the matrix represent dierent perspectives and roles of the enterprise whereas the columns model dierent areas of interest within those perspectives. Figure 3 depicts a simpli ed representation of the framework where the columns represent the views or domains and the rows represent the life cycles for the dierent 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 between the IT and the business needs, respectively. The Zachman Framework provides the ability to de ne an enterprise in a highly structured way and the need to manage the life cycles of applications is present. The framework refers 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 plan that takes into account the contributions of technology for the redesign of the organization. Moreover, the dimension of how one lives with a multitude of projects can not be seen within this framework. However, it is 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 Information Management (TAFIM) developed by the US Department of Defense (DoD), provides a comprehensive organization 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 blueprint for the application systems; and a Technology architecture to give an overview of the software and hardware capabilities that support the business, data, and application services. These four architecture principles were applied in a number of dierent ways to support the architecture governance and change managnement in organizations, and to nd solutions to complexities-related problems. Among the goals to be achieved were to use the TOGAF's architecture principles as primary requirements when formulating the architecture change management and governance processes, and to make informed decisions on which policies, processes, technologies, and systems need to be modi ed or replaced as the organization evolves over time. The TOGAF architecture certainly provides a solution to align IT needs with business strategy in order to improve performance. However, it only partially addresses the multiple-cycle and the dierent rate 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 the government sector. This includes the Department of Defense Architecture Framework (DoDAF) [37] and the Federal Enterprise Architecture Framework (FEAF). The DoDAF is a framework used to understand the US Department of Defense (DoD) as an enterprise. It is used to identify the operational requirements, make IT investment decisions and improve the interoperability among the various systems in the DoD. This architecture enables the DoD to rapidly respond to changing business and IT needs and strategies, and to be able to govern the evolution. However it is a more or less complicated and rigorous framework to adopt. As for the FEAF, it was created by the O ce of Management and Budget (OMB) in the US to help transform the Federal government into one enterprise that is citizen centered. The FEAF which is a business-based framework for governmentwide improvement was designed to assist Chief Information O cers (CIO) in realizing their mandates in the implementation of information management and IT. They are used to ease the sharing of information and resources across the US federal agencies while improving services to citizens and reducing operational costs. This framework is based on ve reference models dealing with the performance, business, service component, data and technical aspects of the organization. The performance reference model for example follows a performance improvement lifecycle in which EA are developed and maintained, IT is invested and solutions are implemented according to a transition strategy. Though both of DoDAF and FEAF are successful in streamlinig businesses and addressing information sharing problems, these frameworks are still burdened by the system's life cycle and only provide partial solutions to understand how to manage the discrepancies in the organizational and technological developments in 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 work done on Urbanization [16] of information systems. When there are projects in which employees redesign an existing information system, they have tendency to scrap it down and replace with a new one. It is interesting to 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 systems in organizations, organizes the gradual and continuous transformation of information systems while simplifying their use and optimizing their added values as shown in Figure 4. The urbanization plan should describe how to act on the four dimensions of an EA while showing how to see the architecture now, in its evolution, and in the 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 strategic development of the organization, while taking advantage of technological developments on the market. When developers urbanize a city for example, they do not raze it to the ground to make another one. They keep it as it 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 this approach is applied to information systems, it can be said that the information system will be made of many components 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 to ensure e ciency and exibility while an organization transforms itself. The development of a project in complex and large organizations should follow the logic of a business process-based approach within an urbanization perspective, and should be based on the fundamental components of the overall architecture. Urbanization here de nes the rules as well as a coherent and stable framework in which the various components or stakeholders of the information system interact with each other. Moreover, urbanization de nes, based on an overall plan, the evolution of information systems while taking into account the existing systems. Each project or a system can be thought of as a step in a global move. In this context, eective solutions of complex problems can be achieved based on the overall plan where the coordination with existing or under development systems is done, hence avoiding the development in silos. The overall plan for information is de ned by the overall architecture of information, 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 of an organization. If urbanization provides answers to the dierence in the organizational pace and the technological rate of development, it poorly addresses the problem of multitude of cycles. This is due to fact that urbanization still makes 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 complexities in organisations while trying to achieve agility, and on the other hand try to improve the synergy between the various organization units. In fact, the CEISAR's three dimensional cube [38] which uses complexity, agility and synergy as bases can be used as an underlying referential to provide a comparison of the existing solutions. The CEISAR's work [38] focusing on enterprise architectures provides a simpli ed yet consistent view of an enterprise based on only three key dimensions. These dimensions were based on the main business concerns of splitting the real world from its model, splitting the operations processes or the present from the transformations processes or the future, and appropriately balancing centralization vs decontralization and speci c elements vs shared and reused ones. Splitting the real world from its model leads to understanding the enterprise complexity whereas splitting the present from the future leads to an increase in agility. As for nding the good balance between centralization and decentralization, and between speci c and shared or reused elements, it leads to identifying the right synergy level for the enterprise. The complexity, agility, and synergy dimensions provide a framework to model the functioning of the enterprise as shown in Figure 5. This meta-model delivers dierent views 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 tranformationrelated 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 widely used to model the operations and tranformations of enterprises, and to understand and manage some of their complexities. The major disadvantage of these approaches is that they have been thought around one big cycle and one big project to ensure consistency. But, each of them has brought an important contribution in its own way to solve the transformation-related problems. In this paper, these contributions constitute valuable background on which the development of a more comprehensive solution is made. The solution exploits strengths of each partial solutioon as shown in Table 1. The details of relationships between these solutions and the proposed one is the subject of research under investigation by the authors.
10 Complexity
Agile solutions
ERPs
Zachman Framework
TOGAF, DoDAF, FEAF
Urbanization
Complexity may increase. These methods focus on streamlining the SDLC by eliminating much of the modeling tasks. They require a great deal of discipline to prevent projects from becoming unfocused and chaotic. They are eective for small projects with highly e cient teams. They may not help understand the enterprise complexity as they do not split the real world from its model. Very often, they reduce the ability to face complexity. The complexities increase as organizations grow. It helps understand complexity of the enterprise by splitting the real world from its models. It helps organize integrated models of an enterprise. They help understand complexity as they split the real world from its models.
It helps understand complexity in enterprises as it splits the real world from its model. It puts in place a referential of all information which makes clear what is confusing.
Agility
Synergy
Improves agility. Developers provide rapid feedback to end users and deliver results very quickly.
They increase the synergy. There is a local synergy by the reutilization of certain components. There is close collaboration between developers and close interaction with end users.
They increase agility. They are able to split the present from the future leading to an increase in agility. With ERPs orders run faster.
Add some synergy. ERPs streamline business proceses. They help identify a good synergy by nding the shared and reused elements in the enterprise.
It is not clear how it acts on agility. It does not clearly show how to split the present (operations) from the future (transformations).
It improves synergy. It helps identify a good balance and interaction between dierent shared models (cells).
Similar to other EA frameworks, it is not clear how these frameworks split the operations from the transformations processes, and consequently how they act on agility.
They improves synergy as they identify a good balance between speci c and shared or reused elements.
It promotes and enhances agility. Urbanization splits the present from the future, and it is possible to see if the information systems are able to evolve quickly and well to changing business needs.
It achieves a great deal of synergy to preserve, use, and manage the information heritage until its ultimate obsolescence. It helps identify a good balance between centralization and decentralization, and between the speci c and the reused and shared elements
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 of cycles in which other cycles, such as the technology cycle, can also come into play. In addition, the dierence in the 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 tranformation 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 multitude of cycles. Moreover, instead of being centered on an application, the information will be de ned and based on the 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 focus on modeling the domain rather than modeling the system. This brings the main argument in this research work to say that there is a shift from a process of how to manage a cycle to a process of how to pilot the evolution of a multitude of cycles. To bring focus to this information system which simply is no longer the application, there will be a shift from modeling with content of databases to modeling knowledge in the domain. Moreover, in these multitudes of applications, dierent paces of evolution exist: one pace for the development of needs and another pace for the evolution of technology. Therefore, there is a need to create a certain degree of 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 dierent technologies. The methods that exist are 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 in such complex context, there is a need for organizational concepts based on knowledge of the domain and the organizational reality on the ground. The framework of reasoning for developing this architecture is therefore based on a reference enterprise architecture that allows to think in a mutltitude of cycles way, and a two-track Y-model development cycle that ensures articulation and exibility. The details of these two main architectural elements are presented hereafter.
4.1 The retained framework The enterprise architecture is indispensable to model the operation of an organization and to coordinates its evolution. With a well-de ned architecture, organizations are able to understand how they operate and where they 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]. Figure 6 depicts the retained framework which can be used as a generic framework that abstracts the proposed enterprise architecture. This framework is made up of:
Three layers: a Business, a Functional, and a System layer, respectively; Three domains which are meaningful to dierent stakeholders in the organization: a Business, an Information (Data) and a Systems (Applications) domain, respectively; and
12
Five views to meet the needs of dierent 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 event involving 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 has at least two eld actions such as Register FA and Take blood sample FA. These eld actions can be used in dierent business processes. The Register eld action is independent of the request of a laboratory analysis business process but it can also be used in the case of a surgery business process. A catalogue of all the FAs can be established, and these FAs within the corporate conceptual data model give a coherent and global information model. The CCDM [22] which provides a holistic view of the information is a high level data model where only the main entities and attributes common to several information systems are de ned. The Views which model information for dierent stakeholders show the relationship between the information architecture and the business and systems architectures [22] which themselves are articulated around the CCDM. All of these key components are articulated to create a certain degree of independence between business needs, the underlying technology, and the application development process. In this framework, the CCDM is at the heart of the information architecture of an organization. It can be considered as a switching platform that connects the various models that constitute the information architecture. These models, called views here, are the various components that are reusable and the deliverables of a project with regard to the information. Four dierent views can be de ned as follows:
The eld actions view describes the information representing the actions and decisions that take place in reality.
The overall business domain view brings together all relevant data to a project as well as the view of business 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 systems or those being designed.
The messages view which matches with the standards of exchange and norms in use or to be used in the future 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 subschemas of the information contained in the CCDM which are at the same level of abstraction as with the CCDM. The eld actions view and the messages view have an aspect of generality. In fact, they are a priori independent of a particular business process which leads to the important feature of reusability. Although the FAs are de ned based on the reality on the ground, they are not speci c to either a particular business process or a business area in the organization. The same FA can be encountered in several business processes of the same business domain or several separate business areas. In the same way, each business process may have more 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 this enterprise 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 the development process of computer-based information systems (CBIS). This development process which stresses the initial non-correlation of the functional and technical aspects is important to ensure a certain degree of independance between the two aspects. To accomodate dierent life cycles, it is necessary to develop the information technology infrastructure independently of the needs of organizations and vice versa. In fact, this objective dates back to the mid 70s where designers of MERISE [26] [25] had an ambition to prevent IT changes aecting the use of information systems, such as to allow the change of database managmenet systems (DBMS) or the operating system without aecting the apparent functioning from the point of view of users. Many solutions have been developed which can be classi ed into two broad categories: technical solutions to improve IT tools, and methodological solutions to 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 two domains of intervention. The two-track Y-model is a solution to ensure the non-correlation between the two domains. The development process follows two paths, Functional and Technical, which correspond to two changes imposed on information systems. Then, the two track merge for the design of the system, which gives the form of a development process in Y as shown in Figure 7. The initial subdivision allows both to capitalize on the business 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 by the organization. Essentially this part captures the functional requirements to produce a model focused on the needs of business users. Based on the analysis of this part of the model, it is possible to assess in an early stage the risk of producing a system unsuited for business users. Consequently, developers will be able to consolidate the speci cations and verify their coherence and completeness. Moreover, this part of the Y model includes the analysis which consists of studying the functional speci cations in order to get an idea of what the system is expected 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 the technical 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 of the Y model helps identify all the constraints and choices aecting the system's design. For example, the idea of process re-engineering stipulates the use of the IT tools in the left arm of the Y model in order to redesign processes. For this purpose technology is needed to rearrange business processes so that organizations become more productive. IT human resources including analysts and programmers need to have this as a toolbox available to them and if possible any reusable component in order not to reinvent the wheel in each new project. These tools are organizational context independent where they involve the design, the editing and development of computer programs, respectively. The selected IT tools and components while taking into account the constraints of integration with existing modules generally aect the technical architecture prerequisites. This part of the Y model also includes the generic design which then de ne the necessary components to build the technical architecture. This is completely independent of the functional aspects. It aims at standardizing and reusing the same mechanisms for one system. The technical architecture builds the skeleton of the system and dismisses most of the technical risks. It is advisable to build a prototype to ensure validation. The central arm of the Y model which is called 'CBIS Development' represents the phases for the development of computer-based information systems. This part includes a delicate preliminary design phase which integrates 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 and validation. 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 their needs but only have a partial knowledge of technologies. On the other hand, developers are aware of IT tools but lack information of data and needs. Consequently, requests formulated by managers can be suboptimal making them either too simple or too complex. Moreover, they have di culties operating with design artifacts that are vague and abstract. To bene t from the contributions of technology, they must change in part their behavior and the operation of their organization. As for IT people, they have a strong and natural tendency to impose their technical preferences or the latest IT design, which are not necessarily the best suited to meet the needs of buisness people. On the other hand, one must recognize that these IT people often do not quitely understand the needs of the organization. With the two-track Y-model, the process of development of CBIS is iterative and incremental that integrates the best practices of system development which has the advantage of highlighting what the socio-technical CBIS system 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 encountered in the reality of a particular business domain and which are used in the multitude of information systems of an organization. However, attempting to model this whole domain at once could be a rather challenging and laborious task. Furthermore, attempting to construct a graphical representation of this global data model can 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 manageable parts, and on the other hand, there is a need to know how can these dierent parts of the same information architecture 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. In practice, a person acting within an organization will see his or her actions occur in a particular administrative process or context. If systems are independently developed from each others, then an analysis for each system is made even if common concepts are used between the systems. This leads to a less productive environment and to 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 architecture of 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 for building the information architecture, are any action, decision or event involving one or several players who contribute 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 elements in the enterprise architecture. Each of these actions can be depicted distinctively and explicitly with a separate data 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 corporate data model at the conceptual level. This model provides a coherent information model of the reality on the ground. 5.2 The Conceptual Corporate Data Model (CCDM) The CCDM provides a holistic view of the information in the entire organization. This abstract data model is 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 on the ground. The components that make this model are the ground level objects or entities, their attibutes depicting their properties, relationships showing ways to connect an entity with another in the model, and rules 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 is as neutral as possible, in other words independently of a particular use. It is conceptual, implying that this model represents the meanings (i.e. de nitions) and the relationships between the meanings. The CCDM is not a representation of the materialization in physical systems such as databases. This model is normalized where each data is represented there only once. Moreover, the CCDM is a high level model where only the main entities and attributes common to several applications are de ned. It should be viewed as a very large global data model that represents the entire system. When it is necessary to model a particular information system, it is not essential to include all entities and relations from the model. Only parts of it will be used although there is common subset of entities that is frequently reused in every dierent system.
5.3 The views and sub-schemas Another key component of the proposed information architecture are the Views or sub-schemas. The information architecture relies mainly on these views. In fact, these dierent views are meaningful to dierent stakeholders of the enterprise architecture. They are articulated around the CCDM which forms the hub of the information architecture putting in relation these dierent models. There are four views that can be deduced from the MCCD as shown in Figure 8. These are the Field Action view, the Buisness Process view, the Messages view and the Systems/DB view. For example, one of the business needs in terms of a message is adding a client to the system. Adding a client requires to ll in information such as name, address, and the insurance reference number. Some of these information may be common to dierent needs, and consequently they appear within the CCDM. Hence, a view is built by selecting the entities of the CCDM which contain the required information. This view can be updated by information which are speci cally used in this need and not shared with other needs. This view is also called sub-schema. Each view interests only the message's modeller (stakeholder). The Field Action View is a sub-schema of the CCDM that groups all the relevant components that make an FA. As for the Business Process View, it contains all the relevant business processes that are speci c to a particular project. The System/DB View is a view of the databases and interfaces of existing systems. It can also be a view of systems that are currently being implemented. As for the Messages View, it represents the relevant entities that compose a message. All of these views along with the CCDM ontology and the FAs form the 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 for this purpose called the CCDM Coupling Method that allows the transition between the conceptual and logical modeling 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 domain view. Each sub-schema contains concepts or entities and their associations which integrate data that is speci c to a particular project or system. These entities are associated in a way that is speci c to the project that the CDM represents. This allows a coherent approach for the information system under development since the entities 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 that are depicted in Figure 9 and explained hereafter. The rst step of the coupling method consists of creating an LDM 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 in the logical level of abstraction. The terminology of concepts at the logical level is what can be found in reality on the ground. A logical model is basically a conceptual model, but instead of using the terminology coming from the CCDM, terms originating from the information system under consideration are used. The terminology at the conceptual level can be sometimes dierent from the one used at the logical level as the conceptual level is a higher level of abstraction where the terminology used is common to all systems and applications in the architecture. For example, in the healthcare system of Quebec, there are several databases in use whose physical implementation have been achieved by IT specialists. The de nition and naming of the various concepts and entities used in the implementation process is usually taken care of by the IT specialists. These names address the needs of programmers and developers unfortunately and do not re ect the de nitions and naming used by users of these databases. This is in fact one of the obstacles to interoperability. Furthermore, at the conceptual level of modeling abstraction, dierent naming for concepts or entities may be necessary to create a unique way of representation. For example, at the logical level, a system may refer to client as a patient, and a care giver as a doctor. Another system may give dierent naming for the same entities at the logical level. Though there are various vocabularies encountered in the reality on the ground re ected by the LDMs, the CCDM presents a 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 and attributes in the CCDM. Every element from each of the logical models are manually picked and matched to the CDM being created for that particular LDM. If a corresponding entity or attribute in the LDM can not be found in the CCDM, the pertinence of adding it to the global model is evaluated as shown in Figure 9. As a result, the CDM of the information system will be gradually built, and in the same time, the CCDM-coupling process allows to re ne the CCDM by adding new entities and attributes if necessary. The LDM-CDM-Coupling approach can, thus, be considered as a bottom-up methodology. New data are discovered by analyzing existing information systems. These new data are added to the CCDM. Finally, the semantics of this new information is 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 be spread across a sub-schema taking the form of an CDM. The CCDM can be seen as the stable pivot that puts in relation the various schemas that compose the information architecture. The Views in the CCDM improve the 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 also serve as an eective tool to improve communication and understanding between all the stakeholders of an information 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 relationships are added to update the global data model, the latter can very easily grow to become very complex and di cult to maintain. Moreover, in this research project there was a need to establish a method for expressing 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 to other elds. The explicit modeling of all of this external information and its inclusion in the global model can make 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 allow the 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 views while at the same time, using strictly data that he or she is interested in and to which he or she has access rights. Some parts of these records can be components of many views and can have totally dierent aspects for every dierent view. This type of structure is exactly what it is being proposed in this paper along with the CCDM. In fact, it was stated in [40] that narratives or rubrics allow health professionals to share complex ideas in an e cient manner. They provide easily understandable content while representing complex and disparate data. 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 work with highly structured data. However, structured documents are necessary when information systems need to exchange data. In the proposed method, rubrics represent a block of text that can be shown to the user to obtain details about a certain aspect of a medical record as shown in Figure 10. Rubrics are presented together with a set of Meta tags that can help the user sort dierent rubrics. These Meta tags are directly taken from the CCDM and are attributes that are common to every possible representation format that the rubric can take. Rubrics contain plain text but can be structured using XML to facilitate their presentation to the user using for example style sheets. In the global model, a rubric is viewed as an entity. The main dierence with other entities is that a rubric can be broken into dierent sub-entities depending of the context. Therefore, in a particular sub-schema of the CCDM, a rubric will have additional attributes although it will always keep the attributes that 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 expressed only in their particular context. This also reduces the number of entities in the CCDM since only rubrics in the global model are kept. Their dierent specializations in sub-schemas are not kept. The use of rubrics in the 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 the FA where it is relevant;
the reuse of entities where the same entity can be reused in several FAs in dierent forms. This reduces the complexity 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 the appropriate FA.
The proposed CCDM-based enterprise architecture is being implemented to model the operations and the transformations processes of the Quebec healthcare organization in Canada. The goals of this implementation are 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 subschemas and models, and this therefore had required the use of an appropriate modeling tool to manage the complexity of this environment. The only software with functionalities that suited the research project's needs was the SILVERRUN software [42], presently called the SILVERRUN ModelSphere5 and oered by Grandite. The SILVERRUN tools while supporting the business process re-engineering projects, provide modeling capabilities to model data based on traditional entity-relationship method. The SILVERRUN ModelSphere5 tool can also be used to model business processes and to create business process mapping in which one can show 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 with multiple schemas and sub-schemas. This software tool which is designed in Java and works on a standard virtual machine can be installed on dierent platforms such as Linux and Windows. Users of this software tool can easily build their data models either from scratch or via reverse engineering from a variety of sources such as Relational Database Management Systems (RDBMS).
19
Another important tool that was developed to suupport this research is the CCDM_Extract [22] tool used to generate CCDM mapping matrices. The CCDM_Extract is a simple web-based software that allows the comparison of dierent data models with the global data model of the CCDM. It allows the identi cation of common elements and attributes between the models under investigation. Figure 11 shows an example of model matrix generated using CCDM_Extract where the letter 'X' indicate that an element is present in a speci c model. The CCDM_Extract tool helps identify any redundancy with respect to entities presence in existing information systems and applications. With the help of CCDM_Extract, organizations can create e cient new systems 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 information architecture for large and complex organizations. This architecture copes well with the problems emanating from managing complexities in attempting to pilot multiple applications developed in silos that many large organizations are nowadays faced with, and from the dierence between the organizational and the technological rates of development. The proposed methodology was based on two main elements: an enterpise framework and a two-track Y-model development cyle for information systems. Three core concepts were used in the framework: reusable eld actions representing persistent information on the ground, a central common canonical and global data model, and views used to represent the interest of stakeholders in the enterprise architecture. The development process of the information systems followed the two-track Y-model development process to guarantee a certain degree of independence between the business and IT needs. The two-track Y-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 to alleviate 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 an appropriate enterprise framework and an information system architecture to address the issues of understanding complexity in enterprises, how to increase their agility and nally how to nd the right synergy level. Each of the existing solutions discussed in this paper provided a contribution to nd an overall solution to transformations of organizations answering some aspects of the needs of complexity, agility and synergy. The enterprise frameworks have been found to be helpful for splitting the real world from its models. They were used to organize the many models of any enterprise hence helping understanding the business and therefore reducing the complexities. The urbanization of information systems approach has been helpful to nd the right synergy level between 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 of the organization, and therefore helped in improving the synergy of the enterprise. Agile methods on the other hand have been very sueful to increase the agility in the development process of information systems. All of these approaches have been instrumental in the development of the proposed approach. Moreover, with the use of the two-track Y-model for the CBIS life cycle, it was possible to achieve independence between the business and 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-Oriented Architectures (SOA). For creating durable systems, the state of the art to write programs that are exible refers to the use of SOA [44]. In the proposed Y model of a CBIS process development, the SOA is situated in the right side where the inputs to this branch are the IT services. The SOA by itself can not identify the elementary components that serve to write these programs. There is a need to use the left side of the Y model which includes inputs of the business processes of the organization in the form of eld actions. SOA, which oers a modular vision of an application where functionality is grouped as services, attempts to provide an 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. For an organization that seeks an IT exibility and a modularity of its processes, the deployment in the form of services that support its administrative tasks has become a strategic choice. In fact, the proposed CCDMbased approach can lead to the identi cation of these services, and also can assist in the design, coding, and deployment of software applications. In fact, the eld actions represent what an organisation should oer in terms of services. Thus, the de nition of SOA services based on eld actions will lead to the development of information systems that can meet the challenging needs of complex organizations. It is also essentiel to note that SOA can not be properly used unless it is supported by a global data model such as the CCDM ontology where data representing the organization will be used in the execution of services. The use of the CCDM will allow 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'Architecture et 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 Administration, Laval University, Quebec, Canada, 1999. http://loli.fsa.ulaval.ca/ leadmin/Methodes/Analyse/pdfdatarun/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 integration, 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 Information 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: Eective 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-8 11. 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.pdf 16. Jean, G., Urbanisation du business et des SI, Hermes 2000, Lavoisier 20002. ISBN: 2-7462-0135-6 17. 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-82228073-X 20. 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=478 23. The Quebec Health and Social Services System-Ministere de la Sante et des Services Sociaux, http://www.msss.gouv.qc.ca/en/index.php 24. Cadre methodologique, Direction adjointe à l'architecture et aux orientations technologiques (DAAOT), The Ministry 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-8 27. 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, NorthHolland, 1986. 29. Gane, C., and Sarson, T., Structured Systems Analysis: Tools and Techniques, Prentice-Hall, Inc., 1979. ISBN: 0-13-854547-2 30. De Marco, T., Structured Analysis and System Speci cation, Prentice-Hall, Inc., 1979. ISBN:0-13-854380-1 31. 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-2 33. Homan, M. and Beaumont, T., Application Development: Managing the Project Life Cycle, Mc Press, 1997. ISBN10: 1883884454 34. Pressman, R. S., Software Engineering: A Practitioner's Approach, The McGraw-Hill Companies, 2004. ISBN: 007301933X 35. 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.pdf 37. The Department of Defense Architecture Framework (DoDAF). http://www.defenselink.mil/cionii/docs/DoDAF_Volume_II.pdf 38. 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 avec SOA, Editions Hermes-Science, ISBN:978-2-7462-1829-1.
