L-GENEAF, a Generic Business-Driven EA Framework

Transcription

1 L-GENEAF, a Generic Business-Driven EA Framework Mohammad Kazem Haki, Maia Wentland Forte Institute of Information Systems, Faculty of Business and Economics, University of Lausanne, Switzerland Abstract -An increasing number of business organizations are supporting business-driven Enterprise Architecture (EA) efforts but most of these projects mix multiple EA frameworks leading to in-house developments. It seems that, based on Gartner survey, the upcoming EA frameworks will take advantage of the already existing different sets of reference frameworks and methodologies to develop pragmatic and generic business-driven ones. In this paper, we propose a roadmap that offers a mature business-driven EA framework by combining the structure of our previously developed Lausanne EA Framework (LEAF), with the business-oriented artifacts of an existing Systemic Enterprise Architecture Methodology called SEAM. This combination, relying on an articulated synergy of both the LEAF and SEAM, results in a novel EA framework, baptized L-GENEAF. Keywords: L-GENEAF (Lausanne GENeric EA Framework); SEAM (Systemic Enterprise Architecture Methodology); LEAF (Lausanne EA Framework); Businessdriven framework 1 Introduction Because Enterprise Architecture (EA) features a coherent set of principles, methods and models it has become an important instrument to address the issue of a company-wide integration. This set can be used in the design and construction of the enterprise organizational structure, business processes, information systems, and infrastructure [1, 9]. It also provides a systematic documentation depicting the integration between the different architectural layers [12]. Zachman s framework, an Information Systems Architecture framework, was the first one as a basis for formalizing reference EA frameworks such as TOGAF, DoDAF, FEAF, TEAF, etc. Thereafter, a number of EA frameworks derived by these reference frameworks were proposed, such as the TOGAF-based comprehensive architecture framework [18] or the VECCF (Virtual Enterprise Chain Collaboration Framework) [3]. [25] proposed different integrations between some of the wellknown EA frameworks (Zachman, Four-domain, TOGAF and RM-ODP) dealing with the following architectural layers: enterprise environment, enterprise, enterprise systems and infrastructure. PERDAF, an ISO 9126-based enterprise architecture meta-model, consists of classes and related attributes that can be used to create quality-based enterprise architecture models [11]. [2] developed a layered EA framework that includes not only the strategy, the organizational, the application and the software component layers but their interdependencies as well. Finally, [13] developed a basis for information architecture for public administration. All of these frameworks, derived from reference frameworks, are mainly conceptual and/or area-specific meaning that they contain no practical nor step-by-step guidance for real world projects. Their applicability in different type of organizations and the possibility of focusing on business requirements are debatable. On the other hand, based upon the Hype Cycle for EA 2010 developed by Gartner [5], it appears that: Most organizations leverage a combination of frameworks by picking and choosing the elements, artifacts and practices that best reflect and suit their business, IT and cultural needs. According to this survey, approximately 80% of Gartner s clients are using multiple EA frameworks; To prepare for 2015, EA practitioners should ensure that EA practices are driven based on a clear and contextually pertinent business vision, articulating business strategy and requirements, as well as ensuring a business-driven enterprise architecture effort thus supporting a more business-vision-focused EA effort. We advocate that a pragmatic EA framework should take into consideration contextual project management issues - as the vital part of each project - and determine the project activities step-by-step so as to cover all the framework s components and artifacts. The applicability of such a framework, in any kind of organizations (e.g. public sectors, manufacturing companies, etc.), is an important caveat that leads to developing a generic framework. In this paper, we propose a business-driven EA framework (L-GENEAF for Lausanne GENeric EA Framework) born from integrating (1) the SEAM modeling techniques that contribute to the business-driven notations and artifacts as well as to business analysis techniques within the structure of (2) LEAF (our previously developed EA framework) that sets universal EA project phases, steps and activities by including the project management considerations of the Project Management Body of Knowledge (PMBOK) into the FEAF. Because the LEAF has a very well organized structure and the SEAM offers very good techniques to investigate the business layers of an enterprise, the resulting framework allows meeting the requirements of the future EA projects. After describing SEAM and LEAF, the building blocks of our proposed L-GENEAF, we then show how by using the SEAM artifacts and notations in the structure of LEAF, it is possible to get the best of both worlds achieving the necessary synergy to enrich the business analysis of LEAF

2 and consequently meet the requirements of future EA projects. Before concluding, we will illustrate the use of L- GENEAF with a small business-case. 2 Building blocks of the L-GENEAF framework L-GENEAF utilizes the principles, artifacts and notations of SEAM for following the phases, steps and activities of LEAF. 2.1 LEAF Our previously developed framework [6, 7, 8] finds its roots in the FEAF, the PMBOK, and the authors experiences in EA projects (more than 10 EA projects in manufacturing and service organizations). The Federal Enterprise Architecture Framework (version 1.1, 1999) [4] is a government framework designed for public-sector consumption. FEAF is a conceptual framework that begins by defining a documented and coordinated structure for cross-cutting businesses and design developments in the Government. The main components of this framework are: architecture drivers, strategic direction, current architecture, target architecture, transitional processes, architectural segments, architectural models and standards. The FEAF has a very well-organized structure that is well-adapted to the logic of EA. This is why its main structure (as-is architecture, to-be architecture and, migration plan) has been utilized for developing the meta-model of LEAF. But it does not contain a detailed description of how to generate the EA deliverables [10] and does not provide business-related artifacts [24]. Moreover, it does not encompass a project management solution for following its components in the real projects. As a reference framework, Project Management Body of Knowledge (PMBOK) is a guideline describing the project management processes, tools, and techniques that are needed to lead a project towards a successful outcome. Based upon the PMBOK framework, project management contains nine Knowledge Areas namely Project Integration, Scope, Time, Cost, Quality, Human Resource, Communication, Risk and, Procurement Management [15]. As the preferred mechanism for ensuring that the EA roadmap is executed, we claim that project management is a critical element of the EA process. The EA roadmap and the implementation plan must continually be communicated on an enterprise-wide scale. It appears that an EA project management solution provides the ability to facilitate continual communication between IT and Business and to trace the actual changes in the enterprise scale [14] LEAF s contribution on FEAF As mentioned, FEAF is a conceptual EA reference framework for the public sector and governmental organizations. LEAF contributes to FEAF by: Distributing EA artifacts into the different phases of a real project to bring in a sense of practicality. LEAF defines the phases of the EA project and determines how to utilize the EA artifacts for investigating the asis architecture, developing the to-be architecture as well as proposing an action plan for migration; Modifying FEAF for developing a more generic framework that is applicable in any kind of organizations (e.g. public sector, manufacturing, etc.). It has been developed during an incremental process which included real projects in different type of organization; Adding project management considerations as one of the critical success factors of EA projects by using PMBOK guideline [7]. Since LEAF is based on a practical approach, in addition to mentioning the different levels of architecture, it also contributes to determine the phases and deliverables covering all the architectural layers of EA projects. Its major characteristics are: Coverage of the three architectural layers, namely a) the business architecture b) the information systems architecture and c) the infrastructure architecture. It determines, for each of them, the as-is and the to-be architecture of an organization; Its phases: phase 0, the planning phase, needed for including the PMBOK knowledge areas; phase 1, the asis architecture; phase 2, the analysis of as-is architecture; phase 3, the to-be architecture and phase 4, the migration plan. Each phase contains some steps, each step consisting of a set of activities and each activity producing a project deliverable. A pragmatic and generic framework, that includes the phases, steps and activities of a universal EA project, emerges. At this stage, the business analysis notations and artifacts are still missing. As previously mentioned, prospective EA frameworks should consider business architecture as the vital part of their meta-model in order to meet the requirements of future EA projects. Here SEAM comes into play contributing to a business-driven EA framework. 2.2 The SEAM SEAM (Systemic Enterprise Architecture Methodology) [19, 20, 21, 22, 23] analyzes the foundations of EA and formalizes them in a systemic paradigm i.e. customized implementation of the systematic paradigm in the field of EA. SEAM systemic paradigm includes the SEAM philosophy, the SEAM theory, the SEAM method and tools [23]. System concepts are at the core of SEAM in so far the modeler considers an enterprise as a complex system. In SEAM a family of methods has been proposed that addresses business, EA and software development. In this paper, we focus on SEAM for EA. In SEAM for EA [22] the organization is considered as a hierarchy of systems that span from business down to the IT system. It consists, typically, of four sets of views:

3 1) The Service view conceptualizes the business context with modeling the overall services provided by a group of companies to the customer value network. It is useful for understanding the overall needs and expectations as well as value exchanged and how these values are exchanged between value networks. 2) The Value network view identifies precisely the responsibility and contribution of each company in the value network that is useful for determining outsourcing strategies as well as inter-organizational business processes and services. 3) The Company view shows the company as a composite of different business roles and IT systems. 4) The IT view considers the relationship between IT components and services. These views could be shown as a composite [C] or as a whole [W]. When represented as a whole, the focus is on the provided service; when shown as a composite, focus is set on how the service is implemented. SEAM includes two main modeling techniques: the behavior model and the goal-belief model. The goal-belief model is a Goal-Oriented Requirement Engineering (GORE) method that has been developed by using goal-oriented approach in open system literature. It is a method for identifying the requirements of a system in an ever-changing environment. The building blocks of this method are [16, 17]: The Goal, a state a system tries to achieve or maintain; The Belief, an interpretation of the system viewed from the observer point of view. Indeed, goal-belief shows the needs, expectations and value exchanged within the system. The behavior model specifies how the exchange is done i.e. it represents the exchanges of messages that support the exchange of values identified in the goal-belief view [22]. In a nutshell, SEAM proposes a hierarchical model in which each level could be analyzed by goal- belief (to understand motivations, norms, etc.) and behavior model. 3 The L-GENEAF In this section, we follow the logic of EA step-by-step by utilizing LEAF so as to cover the modeling techniques of the SEAM for EA. To achieve this, we have allocated SEAM for EA s artifacts and notations to the phases and steps of LEAF. Table 1 illustrates SEAM for EA artifacts in each phases of the EA project. These artifacts are not applicable for phase 4 (migration plan). To be noted that Phase 0 (project planning) is organized based on PMBOK framework. In the business side of phase 1, both the goal-belief and the behavior model are used in a hierarchical manner to identify the values exchanged and the way they are exchanged in the system from the service to the company level. From the IT side of phase 1, the goal-belief model is utilized to take a snapshot of the current situation to establish a comparison with the expected IT requirements. In the analysis phase (phase 2), an extended goal-belief model, covering all set of views, helps analyze both business and IT bottlenecks (business-it requirement engineering). Finally in phase 3, the optimal situation is identified in detail by utilizing the behavior model at each hierarchical level of the system. This approach leads to a business-driven requirement engineering of the IT system by taking into account the requirements of each level of the system. Table 1: Mapping between SEAM and EA framework 3.1 Phase 0: Project planning This preliminary phase of any EA project analyzes the project goal and defines the project scope. It determines the roles involved, the methodologies and tools that could be used and the deliverables to be produced and yields to develop EA Project Charter. The project management documents are described based on the PMBOK framework Knowledge Areas and processes. The main activities deployed in this phase are: Defining the scope of the project: Correctly defining the EA project scope is the most important success factor. At the end of this phase, implementer and employer should have fully agreed upon the outputs of the project and must have the same understanding and expectations. Its PMBOK counterpart is the Project Scope Management Knowledge Area (collect requirements based on project applicant s RFP as well as list of services section of contract; define scope, including project scope description, deliverables, exclusions, constraints and, assumptions; create WBS, verify scope and, control scope). Organizing the project team: Because the enterprise is investigated from its business layer to its IT infrastructure layer, the project is multidisciplinary and cross-functional. All concerned fields of expertise need to be listed and the project manager must organize the team ensuring all are involved at the right time in the pertinent different project groups. This activity corresponds to the PMBOK Project HR Management Knowledge Area that deals with the development of a human resource plan (organization chart, roles and responsibilities, position description and, staffing management plan), as well as acquire, develop and manage project team. Developing EA project charter: This activity serves as reference plan in all subsequent negotiations and project meetings. It is one of the processes of PMBOK Project

4 Integration Management Knowledge Area but additionally includes an executive summary of all the Knowledge Areas. In developing the nine Knowledge Areas and processes of PMBOK framework, the project manager will be able to design a well-organized structure considerably enhancing the project chances for success. 3.2 Phase 1: as-is architecture This phase is meant to provide a snapshot of what is really happening in the organization in order to have a good understanding of the situation and identify the requirements of the IT systems Business as-is architecture The analyst should carefully depict the situation be all along the production chain be it externally (market, customers, competitors, etc.) or internally (business functions, business processes, stakeholders, etc.). The main activities to be conducted are: Identifying the overall business structure: in order to have an overall view of the organization s business structure, the structure of the market in which the organization is acting as well as its relationship with all stakeholders i.e. organization s macro and micro environment should be examined. This activity calls for identifying the market structure and actors. Here the service and value network views of SAEM for EA can greatly help. The service view of the company has to be analyzed in order to determine the flow of services between the company and the customer value networks. The value network view has to be developed for identifying, within the value network, the existing relationships between the partners and their respective roles. For that purpose the company value network, as well as the main competitors and the main customers value networks should be assessed. The goal-belief model and behavior model of SEAM are mobilized to display the strategic relationships between the organization as a system - with its stakeholders as well as exchanged messages. Extracting organization s business strategy components: after having determined the market structure, the project team should examine the strategic components of the organization so as to clarify the long-term business objectives. The business strategic plan is the reference document for this activity. Identifying detail business structure: the internal business structure of the organization is investigated in detail. The organizational structure, the departmental (divisional or business-unit) functions, the organizational business process (primary and support business processes) and the data entities undergo a meticulous screening. This activity calls up the company view of SEAM as well as its goal-belief model to highlight, amongst others, the relationships existing between the different internal business units of the company. By the same token, the behavior model is a useful technique to develop the detail exchanged data entities. Extracting as-is business services: by using the output of the previous activity as an input, the implementer determines the main business services IT as-is architecture The state of the IT systems should be digged into and tidily reported. The IT view of SEAM for EA, as well as its goal-belief model, is very useful to get an overall view of the IT systems in the connection with the organization s business goals. This activity consists in: Identifying the technical IT resources, such as information systems, applications, services, databases, security, hardware, network, etc. in order to have a snapshot of information systems and infrastructure layers. Identifying the non-technical IT resources, such as the organizational structure of the IT management department (group, team, etc.), the decision making structure for IT investment, the IT human and financial resources allocation and human resources fields of experience and expertise. 3.3 Phase 2: analysis of as-is architecture This phase encompasses the analysis of both business and IT as-is architecture. From the business perspective, the compatibility of company s mission, strategies and business functions with the current business processes, information flow and services should be looked upon. The main analysis points consist of coverage level of strategic components and business functions with current business processes, conflicts and overlap between business processes, business process bottlenecks, data flow and data format problems, as well as business process areas and data areas subject to change (improvement or reengineering). From the IT point of view, the compatibility, the adequacy and alignment of company s technical and nontechnical resources with business requirements should be investigated e.g. adequateness of current information systems to support all data subjects and business processes. The main goal of this activity being determining the requirements of the company s IT systems as well as identifying the improvement and/or re-engineering areas for the business functions, the goal-belief model of SEAM for analyzing the current situation and identifying the requirements of the to-be business and IT architecture can be used. 3.4 Phase 3: to-be architecture The to-be architecture is a backed-up description of the optimal situation the organization should move to. By using the results of the previous phases as input, the implementer will document in this phase the to-be architecture of the business and IT systems. The main inputs to identify optimal situation consist of strategic business and IT components, the results of phase 2 (analysis of as-is architecture) as well as lessons learned by best practices and reference models (e.g. business reference model, data reference model, technical reference model, etc.).

5 3.4.1 Business to-be architecture Based on the results of the business as-is architecture analysis, both the to-be business processes and business services will be attended to here. Three types of business services can be expected: Core business services that are related to the primary business processes (front office); Non-core business services that refer to the support business processes (back-office); External services that consider the stakeholders and the organization environment. In this phase, the service, value network and company views of SEAM for EA need to be reshaped for representing the optimal situation. A justification of how the proposed to-be business architecture will support all the identified requirements (ref. goal-belief model developed in phase 2) is needed. The behavior model is used to represent the optimal data exchange between business entities in different hierarchical levels IT to-be architecture Depending on the previous results of identifying the IT systems requirements and according to the specifications of to-be business architecture, the to-be IT services will be developed. The IT view of SEAM for EA is used for determining the information systems and the IT infrastructure. This step consists in documenting the application and the infrastructure architectures. The application architecture will be first identified based on the business services, then the infrastructure architecture can be determined so as to support the application architecture. 3.5 Phase 4: Migration plan A plan to migrate from the as-is architecture to the to-be architecture must be devised. The proposed steps that need to be performed to reach this goal are: Gap analysis: if gaps between the as-is and the to-be architectures are detected, the implementer should determine the basic fields of gaps from both the business and the IT perspectives and propose a remedial plan. Obviously differences between the as-is and the to-be architectures should be clarified before establishing any migration plan. Identifying projects and prioritizing: according to the gaps detected, the implementer will define the projects, their sequence and prioritization, the estimated time and resources to be allocated, etc. Developing evaluation and updating plan (Performance Reference Model): in this activity, the implementer proposes performance indicators in order to evaluate the progress of the overall plan as well as an updating plan in order to be able to modify the overall plan according to business and/or technology changes. Proposing IT management structure (a Project Management Office- PMO): A team, group or department, is needed for managing the proposed projects (outsourced projects and or in-house projects) and evaluating the progress and updating the overall plan. Most of the times, IT department plays the role of the PMO. Therefore, in this activity, an IT management structure with detailed functions, job descriptions, required training and resources should be proposed. In this activity, standards such as ITIL and/or COBIT are helpful to suggest the main services and functions of the PMO. 4 Illustrations In order to illustrate how the L-GENEAF can be used we will explain, by means of a simple example, how by using the SEAM modeling techniques (set of views, goal-belief and behavior model) we obtain the desired added-value into LEAF. Let us suppose a business organization called BestPipe Inc. (BP) that manufactures large and small diameter steel pipes for oil and gas (sour and sweet) transfer; it also produces the pipes internal and external coating. The main actors in the supply chain of BP are: Plates and raw material suppliers; National Oil and Gas Company (O&G Co.) as the main customer of BP; Shipping company that is in charge of in(out)bound logistics for delivering raw material to BP as well as shipping pipes to customers. BP is organized into 4 primary and some support departments. The primary departments are the Engineering and Development Dpt. that deals with controlling the manufacturing process, the Marketing and Sales Dpt. in charge of sale and after sale services as well as taking part in tenders in the national and international market, the Procurement Dpt. preparing plates and raw material, and the Manufacturing Dpt. producing the pipes and coating. Figure 1 shows the overall strategic relationships between business partners in the supply chain of BP. This diagram, presenting a bottom-up aggregation and a top-down decomposition, is one of the results obtained after complying with the first phase of LEAF. It belongs to the identifying the overall business structure activity of phase 1 (cf ). Figure 1. Set of views for BP Inc.

6 The BP as-is architecture, is examined as a set of views, that can in turn be decomposed in service view, value network view and company view. The service view contains the value network of BP as a whole and O&G Co. value network as a composite. The O&G Co. has two main business lines for producing natural gas and crude oil: (i) the gas business line, comprises refineries that refine and purify gas. Gas dispatch is performed through spread-around-the-country regional companies that distribute through provincial entities and (ii) the oil business line for purchasing and reconstructing drilling units as well as exploring for and producing crude oil. The value network view contains BP value network as a composite. BP value network in turn encompasses plates and raw material suppliers, shipping companies as well as BP itself, all 3 of them shown as a whole. The company view breaks down BP into its 4 primary departments, BP being shown here as a composite of those 4. In this view we only showed the primary departments. These sets of views are useful for analyzing the strategic relationships BP has developed with its business partners. The added-value it brings to LEAF relates to representing the situation of the company within its market and value chain. Based on a systematic approach that consists into taking into account the strategic business requirements, it contributes to identifying the overall business structure for developing IT solutions. Figure 2 shows an example of the goal-belief modeling technique for analyzing BP business as-is architecture describing the relationship between BP and its main partners. This very high level analysis depicts the goals of each of the four actors in BP value network and O&G Co. value network as well as the observer s beliefs related to each goal. It also shows the relationships between the goals and beliefs of each actor as well as the relationships between the actors. It will serve as one of the deliverables of the second phase of LEAF (cf. 3.3). The 2 beliefs of plates and raw material suppliers respectively the need to schedule material shipment and the need to predict procurement lead-time, and The 2 goals of the shipping companies, respectively ontime material delivery to BP and on-time pipe delivery to O&G Co.. Let us suppose now that on-time access to raw material is one of the main beliefs of BP, a belief related to the goals of the plates and raw material suppliers. This on-time access to raw material belief is derived from the BP predicting manufacturing lead-time and producing highquality pipes goals. It requires meeting the plates and raw material suppliers goals namely providing plates for producing pipes, JIT and providing coating material, JIT. This technique adds a Goal-Oriented Requirement Engineering approach to the business and IT analysis activity in LEAF. The analyst is hence able to compare the business objectives with the actual performance. It also provides a goal-to-goal and belief-to-belief analysis technique to understand how the company regulates its relationship with its business partners. Figure 3 illustrates, as an example, the BP to-be business processes for the manufacturing control business process. It serves as one of the deliverable of the phase 3 of LEAF (cf ). It shows the BP company as a composite, from the aforementioned process point of view, using the behavior modeling technique that represents the data entities exchanged between actors. Figure 3. To-be manufacturing control business process in the company view of BP Inc. Figure 2. Goal-belief analysis of the value network view of BP Inc. If we assume that one of the main goals of BP is predicting manufacturing lead-time (a goal related to producing high-quality pipes ), it could be met by satisfying: The aim of this process is to monitor the manufacturing process. Whereas the main customer of BP is O&G Co., BP takes part in national and international tenders in order to produce pipes for other customers. Once BP wins a tender, the Marketing and Sales Dpt. sends indent form to the Engineering and Development Dpt. The Engineering and Development Dpt. predicts the required material for Manufacturing and checks their availability in the inventory. If materials (plates and coating materials) are available they will be sent to the Manufacturing Dpt. for producing the ordered pipes. Else, it sends a purchasing request to the Procurement Dpt. Finally, the Manufacturing Dpt. sends the products to Marketing and Sales Dpt. for shipping.

7 Behavior modeling technique represents the exchange of messages supporting the exchange of values that are identified in the goal-belief view. It enriches the enterprise data modeling activities of LEAF by explicitly representing data generation and data consumption by each activity of business processes. 5 Conclusions Organizations are looking for IT solutions to meet the needs of an overly competitive and fast-changing business environment. Enterprise Architecture (EA), being a wellsuited approach for aligning the requirements of the IT systems with the ever-changing business needs, appears to be a good solution. Up to now, different reference frameworks have been developed but most of the EA projects are utilizing multiple frameworks to develop their own meta-model. In this paper, we first showed how by introducing the PMBOK guideline as well as a step-by-step roadmap into FEAF we could improve it and palliate to its lack of considerations of the real-world project management issues, which led to introduce Lausanne EA Framework (LEAF). We then described how by using the modeling techniques of SEAM for EA onto the LEAF the requirements of the future EA projects could be met. The building blocks of this new framework, baptized, L-GENEAF are: 1. SEAM for EA that analyzes the foundations of EA and formalizes them in a systemic paradigm. It addresses business requirements by taking advantage of some modeling techniques that are the set of views, the goalbelief model and the behavior model. These techniques contribute a goal-oriented and business-driven EA. 2. The LEAF, with the Federal Enterprise Architecture Framework (FEAF) as backbone, allocates EA artifacts to the phases of a real project to come to a practical framework. It modifies FEAF for developing a more generic framework that is applicable in any kind of organizations; also adds project management considerations by utilizing PMBOK guideline. In a nutshell, our proposed framework integrates the modeling techniques of SEAM for EA into the phase of the LEAF that has given yield to develop a step-by-step businessdriven framework. The contribution of this work on SEAM is to give a practical structure (a step-by-step roadmap) in order to formalize different modeling techniques in the different steps of an EA project. Also, its contribution on LEAF is to introduce a business-driven framework. As a next step, we will test the proposed framework either in real EA projects or by gathering EA experts viewpoints to come to an expert judgment on the framework. 6 References [1] Bernus, P., Nemes, L., and Schmidt, G. Handbook on Enterprise Architecture, Berlin: Springer, (2003) [2] Braun, C. and Winter, R. A Comprehensive Enterprise Architecture Metamodel and Its Implementation Using a Metamodeling Platform, GIEdition Lecture Notes in Informatics (LNI), Enterprise Modeling and Information Systems Architectures, Proc. of the Workshop in Klagenfurt, Klagenfurt, pp , (2005) [3] Choi, Younghwan., Kang, Dongwoo., Chae, Heekwon., and Kim, Kwangsoo. An enterprise architecture framework for collaboration of virtual enterprise chains, The International Journal of Advanced Manufacturing Technology, Vol. 35, No , pp , (2008) [4] Federal Enterprise Architecture Framework, Version 1.1, The Chief Information Officers (CIO) Council of US government, September (1999) [5] Gartner.: Hype Cycle for Enterprise Architecture, July (2010) [6] Haki M. Kazem, and Wentland M. Service-Oriented Business-IT Alignment: a SOA Governance Model, International Journal of Advances in Information Sciences and Service Sciences, Vol. 2, No. 2, pp , (2010) [7] Haki M. Kazem, and Wentland M. Service Oriented Enterprise Architecture Framework, IEEE 6th World Congress on Services, IEEE 2010 International Workshop on Net-Centric Service Enterprises: Theory and Application (NCSE2010), Miami, Florida, USA, (2010) [8] Haki M. Kazem, and Wentland M. Proposal of a Service Oriented Architecture Governance Model to serve as a practical framework for Business-IT Alignment, 4th IEEE International Conference on New Trends in Information Sciences and Service Sciences, Gyeongju, South Korea, (2010) [9] Lankhorst, M. Enterprises Architecture Modeling-the Issue of Integration, Advanced Engineering Informatics, Vol. 18, pp , (2004) [10] Leist, Susanne., and Zellner, Gregor. Evaluation of Current Architecture Frameworks, in SAC 06: Proceedings of the 2006 ACM symposium on Applied computing, New York, NY, USA: ACM, pp (2006) [11] Närman, P., Johnson, P., and Nordström, L. Enterprise Architecture: A Framework Supporting System Quality Analysis, Proceedings of the 11th International IEEE EDOC Conference, Annapolis, USA, (2007) [12] Nayak, N., Linehan, M., Nigam, A., Marson, D., J.Jeng, J., Y.Wu, F., Boullery, D., F.White, L., Nandi, P., and L.C.Sanz, J. Core Business Architecture for a Service Oriented Enterprise, IBM Systems Journal, Vol. 46, No. 4, pp , (2007) [13] Peristeras, Vasilis., and Tarabani, Konstantinos. Towards an Enterprise Architecture for Public Administration Using a Top-Down Approach, European Journal of Information Systems, Vol. 9, Issue 4, December (2000) [14] Pieterse, Jurgens. Enterprise Project Management, Feb 1, (2005) [15] PMBOK Guide. A Guide to the Project Management Body of Knowledge, Project Management Institute (PMI), Fourth Edition, (2008) [16] Regev, Gil., and Wegmann, Alain. Defining Early IT System Requirements with Regulation Principles: The Lightswitch Approach, 2th IEEE International Requirements Engineering Conference 2004 (RE 04), September 6-10, Kyoto, Japan, (2004) [17] Regev, Gil., and Wegmann, Alain. Where do Goals Come from: the Underlying Principles of Goal-Oriented Requirements Engineering, Proceedings of the 13th IEEE International Conference on Requirements Engineering, Paris, France, (2005) [18] Rohloff, Michael. Enterprise Architecture Framework and Methodology for the Design of Architectures in the Large, European Conference on Information Systems (ECIS), (2005) [19] Wegmann A., Julia P., Regev R., Perroud O., and Rychkova I. Early Requirements and Business-IT Alignment with SEAM for Business, Proceedings of the 15th IEEE International Requirements Engineering Conference (RE 07) Dehli, India, (2007) [20] Wegmann, A, Balabko, P., Lê, L.S., Regev, G. and Rychkova, I. A Method and Tool for Business- IT Alignment in Enterprise Architecture, CAiSE`05 Forum, (2005) [21] Wegmann, Alain., and Perroud, Olivier. SEAM in Business: A Systemic Method for Understanding Stakeholders Needs in Value Networks, EPFL 2006, LAMS-REPORT , (2006)

8 [22] Wegmann, Alain., et al. Business and IT Alignment with SEAM for Enterprise Architecture, 11th IEEE International EDOC Conference (EDOC 2007), Annapolis, Maryland, October 15-19, (2007) [23] Wegmann, Alain. on The Systematic Enterprise Architecture Methodology (SEAM), International Conference on Enterprise Information Systems 2003 (ICEIS 2003), Angers, France, (2003) [24] Winter, R.; and Fischer, R. Essential Layers, Artifacts, and Dependencies of Enterprise Architecture, EDOC Workshop on Trends in Enterprise Architecture Research (TEAR 2006) within The Tenth IEEE International EDOC Conference (EDOC 2006), Hong Kong, (2006) [25] Zarvic, Novica., and Wieringa, Roel. An Integrated Enterprise Architecture Framework for Business-IT Alignment, Proceedings of Workshop of Business/IT Alignment and Interoperability (BUSITAL 06) at CAiSE 06., pp , (2006)