Towars a Framework for Enterprise Frameworks Comparison an Selection Saber Aballah Faculty of Computers an Information, Cairo University Saber_aballah@hotmail.com Abstract A number of Enterprise Frameworks (EAF) o exist, which are sometimes ifferent in approaches an at other times are base on other frameworks. This paper presents a survey of the current state of EAF. Comparisons will be hel among some selecte frameworks base upon ifferent criteria. These criteria will inclue the current market share of the selecte frameworks, goals, inputs, outcomes, strengths, weaknesses an frameworks supporte tools. Conclusion is mae concerning EAF selection. Key wors: Enterprise Frameworks (EAF), Information Systems Frameworks comparisons, Enterprise Frameworks selection criteria. 1. Introuction This paper starts by outlining the basic terms of architecture, enterprise, framework an Enterprise Frameworks (EAF). Backgroun on ifferent frameworks an a classification of these frameworks will be presente. Different criteria for EAF will be iscusse. At the en of this paper we will conclue how to choose an EAF regaring these criteria an the current state of EAF. Also recommenations for further research in this area will be presente. In this paper we will use EAF an information system frameworks interchangeably. 1.2 Basic efinitions : In this paper, we will use the IEEE Stanar 1471-2000 for the term architecture. It is efine as The funamental organization of a system emboie in its components, their relationships to each other, an to the environment, an the principles guiing its esign an evolution. [1], where: funamental organization means essential, unifying concepts an principles. Galal Hassan Galal-Eeen Faculty of Computers an Information, Cairo University & The British University in Egypt G.Galal@fci-cu.eu.eg / Galal@bue.eu.eg system inclues the application software system, platform, system-of-systems, enterprise, prouct line,... environment is evelopmental, operational, programmatic, context of the system. Framework: The framework is funamentally a conceptual moel [2]. A framework is a structure within which the key components of the architecture an the relationships between these components are efine. A framework [3]: Helps organize thinking about the architecture Provies a escription of the architectural artefacts Helps ensure that everyone is using the same set of semantics an presents them to the group of stakeholers intereste in the contents of the architecture. Provies a way to communicate the architecture It level-sets stakeholers about the contents of the architecture by proviing common efinitions an concepts It shows the relationships between business an technology elements, ensuring that there is coherence between all elements an that every business element can map to a corresponing element in the technical architecture an, similarly, that technical elements can be seen as supporting key business requirements. Enterprise: Any collection of organizations that has a common set of goals an/or a single bottom line [4]. In that sense, an enterprise can be a government agency, a whole corporation, a ivision of a corporation, a single epartment, or a chain of geographically istant organizations linke together by common ownership. Enterprise architecture (EA): A coherent whole of principles, methos, an moels that are use in the esign of an enterprise's organizational structure, business processes, information systems, an infrastructure [5]. The most important characteristic of an EA is that it provies a holistic view of the enterprise. Enterprise Framework (EAF):
The EAF is an instrument. When utilize it facilitates a holistic (cross-organizational, cross-functional, collaborative view of, elivery of an approach to the following key concepts [6]: Communication Organization aroun EA Mapping technical elements to business strategy Priority planning Asset an artifact management Service elivery Semantics Which collectively, guie the organization in the evelopment of the EA. An EAF is comprise of a coupling of two major components: Methoology an Framework. Table (1) shows the main characteristics of both components. Methoology Framework Describes stanarize processes for eveloping the EA. Describes stanarize eliverables an processes for eveloping the EA Table (1) Methoology an Framework characteristics Software : Stanarize classification tool for the EA eliverables or artifacts. Describes the "What" of EA. A place for everything an everything in it's place The software architecture of a system or a collection of systems consists of the important esign ecisions about the software structures an the interactions between those structures that comprise the systems. These esign ecisions support a esire set of qualities that the system shoul support to be successful. The esign ecisions provie a conceptual basis for system evelopment, support, an maintenance [7]. It relates requirements, fixe system harware, an infrastructure (i.e., COTS, GOTS) to software structures in orer to emonstrate software effectiveness [8]. Information System : An information system architecture typically encompasses an overview of the entire information system incluing the software, harware, an information architectures (the structure of the ata that systems will use). In this sense, the information system architecture is a meta-architecture [2]. It relates the requirements an the external worl to system / solution structures, incluing both harware an software, so that the effectiveness of a system esign concept can be communicate [8]. View: It is a representation of one or more structural aspects of an architecture that illustrate how the architecture aresses one or more concerns hel by one or more of its stakeholer [9]. Viewpoint It is a collection of patterns, templates, an conventions for constructing one type of view. It efines the stakeholers whose concepts are reflecte in the viewpoint an the guielines, principles, an template moels for constructing its views [9]. Stakeholer: An iniviual, team, or organization (or classes of thereof) with interests in, or concerns relative to, a system [5]. Most stakeholers of a system are not probably intereste in its architecture, but only on the impact of this on their concerns. However, an architect nees to be aware of these concerns an iscuss them with the stakeholers, an thus shoul be able to explain the architecture to all stakeholers involve, who will often have completely ifferent backgrouns. 2. Enterprise Frameworks 2.1 EAF history an taxonomies EA gaine popularity when John Zachman evelope his framework for ealing with large information systems on 1987 [10]. Figure (1), [8] illustrates the historical relationships among several frameworks. We notice that most enterprise architecture frameworks have a common history an are built on refinements an a-ons of other frameworks. Zachman framework is the olest an the father of the most frameworks. Different taxonomies are there for EAF. One of these is ifferentiations between two classes of frameworks: classic EAF, an feerate EAF [11]. The feerate enterprise architecture eals with creating integrate architectures. Examples of feerate enterprise architectures are C4ISR architecture framework, the feeral enterprise architecture framework an the treasury enterprise framework. Another taxonomy has been put by ISO 15704 [12], it consiere that there are two an only two types of architectures that eal with enterprise integration: System architectures (sometimes referre to as "type 1" architectures) that eal with the esign of a system, e.g. the system part of an overall enterprise integration; Enterprise-reference projects (sometimes referre to as "type 2" architectures) that eal with the organisation of the evelopment an implementation of a project such as an enterprise integration or other enterprise evelopment programme. In other wors, type 1 architecture represents system or sub-system in terms of its structure an behaviours. The type 2 architecture is actually framework aiming at structuring activities/tasks 2
necessary to esign an buil a system. For example, Zach-man s architecture is type 2 architecture [13]. Outsie the EA ifferent taxonomies, we can fin three main types of architecture. These three types are: EA, software architecture an system JTA architecture, which previously efine. Figure (2), represents the Relationships among System, Software, an Enterprise. referenc es DoDAF 2003 ISO/IEC 14252 Zachman 1987 DoDTRM supporte by TAFIM aopte by EAP 1992 referenc es TOGAF 1995 referenc es FEAF 1999 TISAF 1997 C4ISR 1999 supporte by TEAF 2000 Supporte by TOGAF 2002 Zachman 2003 FEAF 2003 E2AF 2003 UVA Moel 1994 IAF v1 1996 1985 1990 1995 2000 2005 Figure (1) Historical relationship among EAF IAF v3 EE 2001 XAF 2003 3
Enterprise Architects Strategic Governance Business Technology Strategy Enterprise Architects Enterprise System Architects Solution Design Business System Information Information System Technology Infrastructure System Architects (B&I an IS&TI) Solution Delivery BPM/CRM/ER P Supply Chain Management Workflow Analysis Information Analysis Software Data Security Network Software Architects Intra Designers (CID) Security Specialists Governance Specialists Figure (2): Relationship among System, Software, an Enterprise 2.2 Enterprise survey The most important survey report in EAF is publishe yearly since 2003 by Institute For Enterprise Developments (IFEAD). This report presents the results of the thir electronic survey [14], its title is "Trens in Enterprise : How are Organizations Progressing?". The report is base on a 25 questions survey, aressing geographical aspects, branch aspects, EA implementations aspects as well about tools an methoologies use in Enterprise programs an the role of architects in organizations. 79 responents fille in the EA 2005 survey. One of these issues is "What kin of Enterprise Framework oes your organization use?". The following table represents the result of the survey question. What kin of Enterprise Framework oes your organization use? Framework Rate Zachman Framework 0.25 Organization own 0.22 C4ISR, US Defense Framework 0.11 TOGAF, The Open Group Framework 0.11 Extene Enterprise Framework (E2AF) 0.09 FEAF, US Feeral Enterprise Framework 0.09 Other 0.09 IAF, Capgemini's (Integrate Framework) 0.03 TAFIM, US Defense (Technical Framework for Information Management) 0.02 ISO/IEC 14252 (IEEE St 1003.0) Guie to the POSIX Open System Environment 0 None 0 TEAF, US (Treasury Enterprise Framework) 0 Table (1) Enterprise Framework Market share Table (1) shows the most use framework in 2005 is Zachman s Enterprise Framework an organization's own EAF came in the secon. When ealing with such surveys, we shoul take into consieration the following points: Filling in the EA survey 2005 at the website of IFEAD was voluntary, so the results can be a little bit istorte by the fact that only people who are intereste in Enterprise are taking the effort to fill in this survey. The rate of framework may iffer from year to year, an other frameworks may be isappeare from the survey. 3. Enterprise Framework selection criteria There are ifferent criteria that can be use to help in selecting an EAF. These criteria can be categorize into 4
four sections, these section are goals, inputs, outcomes an miscellaneous as shown in the following subsections. Other criteria elements coul be ae to these sections, specially when taking into consieration the software frameworks architecture, which may be in some EAF inclue in it, such as TOGAF. These criteria will be efine only in each section uner Other Criteria, but not inclue into comparison table. 3.1 Enterprise Goals The following goals are common, inepenent of inustry omain, architecture style an system size [15]. Definition an Unerstaning make use of stanar terms, principles an guielines for consistent application of the framework for the communication of architecture information to stakeholers. Process employ a well-efine process to guie the construction of architecture. Evolution Support employ processes an mechanisms that support systems evolution. Stanarization ensure evelopment an architectural stanars are maintaine. Knowlege Base provie consistent representation an repository of esign an architecture esign rationale. Other Goal Criteria: Moels provie consistent stanars to ocument architecture specifications for the planning, management, communication an execution of activities relate to system evelopment. Analysis provie a set of viewpoints to guie the collection an analysis of information for making architecture choices. 3.2 Enterprise Inputs Inputs represent information that architecture moelling consiers. Typical inputs to architecture esign activities are the following [15]. Business Drivers business goals, irection, principles, strategies an priorities Technology Inputs strategic architecture irection incluing technology platforms, future architecture, systems interoperability an emerging technology stanars. Other Inputs Criteria Business Requirements users requirements, functional requirements, ata requirements an other business system relate requirements Information System Environment buget, scheule, technical constraints, resources an expertise, organization structure, other constraints, enterprise knowlege base. Current current stanars an infrastructure. Non Functional Requirements some of these requirements are also referre to as Quality Attributes (QA) or Quality of Services (QoS). These requirements inclue availability, reliability, scalability, security, performance, inter-operability, moifiability, maintainability, usability an manageability. 3.3 Enterprise Outcomes Outcomes represent results an eliverables. Typical outputs to architecture activities are the following [15]. Business Moel escribes business moels, business requirements, business process, system roles, an policy statements. Transitional Design provies esigns an plans to support system transition an evolution. Other Outcomes Criteria System Moel moels major components of the system. To arrive at a system architecture moel, major traeoffs an esign ecisions are mae. Future system enhancements are also taken into consieration Information Moel contains ata moel, ata transformation an ata interface Computation Moel contains system functional escription, system process flow, system operations, software components an interactions. Software Configuration Moel escribes how software is package, store, configure, manage an share. Software Processing Moel escribes how software processes, software threas an run-time environment are structure. Implementation Moel escribes physical system structure such as operating environment, harware components an networking components of the system. Moels implementation processes such as installation, eployment, configuration an management. Platforms escribe platform software such as operating systems, harware an networking components, protocols an stanars. Non-functional Requirements Design moels the structure of the system to reflect esign of nonfunctional requirements. Design Rationale ocuments reasons of esign base on analysis an traeoffs that involve multiple imensions of inputs. 3.4 Other Criteria Conformance - The moeling metho shoul support the ability to efine conformance testing criteria (of the implementation to the architecture specification). Otherwise, the "architecture specification" may or may not specify the architecture of the resultant system no one will know for sure without provable tests. Some moels provie compliant test criteria to ensure the architecture moel is compliant with the moeling metho [16]. Clinger-Cohen Act (CCA) Compliance - The CCA specifies how the U.S. government is to plan, manage, an acquire information technology. This legislation 5
focuses on carrying through the information technology aspects of Government Performance an Results (GPRA) [17]. CCA manates the following : U.S. government agencies are to establish strategic performance goals for any information technology that supports the agency. Agencies are to achieve at least a five percent ecrease in the costs incurre to operate an maintain IT systems, an a five percent increase in agency operational efficiency as a result of IT investments every year. Each feeral agency is to have a chief information officer (CIO). The CIO is to help foster better technology investment, accountability, an ecision making within the agency. The CIO is to implement capital planning an investment controls for IT acquisition an management, where performance outcomes are measure, analyze, an reporte (per GPRA). Visualization tool - The visualization is a graphical of architecture or some part of architecture. Here we investigate if the framework has a graphical tool or not. Different tools are available in the market, an each one of them has its capabilities an supporte framework(s), such as Allen Systems Group (ASG) Rochae, Casewise Corporate Moeler, Computas Metis, IDS Scheer ARIS, MEGA International, Popkin Software System Architect, Proforma ProVision an Ptech Enterprise FrameWork. A comparison among these tools can be foun in [18]. 4. Frameworks In this section we provie a high level comparison an analysis of three EAFs. Our selection for the three EAF is base on table (1) of enterprise architecture framework market share. We select the high ranking (equal or over 11%). The three selecte EAF contain the basic two classes of EAF: two classical an one feerate. The classical are Zachman an TOGAF, an the feerate is C4ISR. Table (2) provie an overview an comparisons of EAFs. The following notations are use to express the framework status for supporting an element in the table: Y : If a framework explicitly supports an element. N : If a framework oes not support an element or there is no mention of that element in the ocumentation. P : Where a framework partially supports or elues to support an element. The extent to which each EAF supports an interpret an element may iffer even when they have the same values in the same row. The following subsections will provie etails analysis for each EAF escribe in table (2). Goals Definition an Unerstaning Zachman TOGA F P Y Y Process N Y Y C4ISR Evolution Support N Y Y Stanarization N Y Y Knowlege Base N Y Y Inputs Business Drivers P Y Y Technology Inputs N Y Y Outcomes Business Moel Y Y Y Transitional Design N Y Y Miscellaneous Conformance N Y P (CCA)Compliance P P P Visualization tool Y Y Y Table (2): Comparisons of EAFs 4.1 Zachman Information System Framework 4.1.1 Introuction John Zachman is the "Father" of the Zachman Framework for Enterprise an Information Systems. The primary goals of Zachman framework are for enterprise architecture analysis an moelling an it is also concerne with perspectives of constructing an information system. A perspective is a row in a table representing how a stakeholer in a project team woul view the system [15]. Scope (Planer) Contextual Enterprise Moel (owner) Conceptual System Moel (esigner) Logical Technology Moel (builer) Physical What Data List of things Semantic moel Logical ata moel Physical ata moel How Function List of processes Business process Where Network List of locations Business logistics Who People List of organizations When Time List of events Workflow moel Master scheule Why Motivation List of goals Business plan Application Distribute Human interface Processing Business rule architecture system architecture architecture structure moel System esign Detaile Data Program Representations efinition Technology Presentation architecture architecture Network Security architecture architecture Control structure Timing efinition Rule esign Rule specification Functioning Data Function Network Organization Scheule Strategy Enterprise (Subcontractor) Table (3): The Zachman Framework The framework architecture is a matrix of 30 cells, where the rows represent the ifferent perspectives an the columns the things viewe from each perspective. The examples suggeste by Zachman for each cell are shown, slightly abbreviate table (3) [19]. Each Cell is an outcome of an architecture activity base on an aspect of a system for a particular group of people an a singular focus on one aspect of the architecture such as ata, process or location. ZACHMAN has six rules, these rules helps in builing the EAF. The six rules are as follows [20]: Rule 1: Columns have no orer Rule 2: Each column has a simple, basic moel Rule 3: Basic moel of each column is unique Rule 4: Each row represents a istinct view 6
Rule 5: Each cell is unique Rule 6: Combining the cells in one row forms a complete escription from that view 4.1.2 Zachman Framework Discussion Although Zachman has been referre to an use in frameworks such as FEAF, DoDAF an TOGAF, it oesn't support most of the comparison criteria. Below some of Zachman framework rawbacks. Zachman uses an analogy from classical builing architecture an military aircraft manufacturing to help efine information systems architecture (ISA). This approach is useful when the final outcome is a system because ISA helps in unerstaning the components that make up each iniviual application or system. Information Framework (IFW) uses the alternative analogy of a city plan rather than a builing plan. It provies an effective way to graually evelop a complete city of information. This compilation inclues information about iniviual applications an systems, as well as information output from other types of projects such as strategic planning or business process reengineering. [21]. The relation between one cell an another is not efine. That is, the consistency of the artefacts is not aresse. There is no iscussion as to the consistency from one cell to another, or from one row to another, or from one column to another [16]. A solution was provie by [22] to facilitate using of Zachman an relates in a consistency way among cells. Semantic behaviour, an how that behaviour affects the functioning of the components an their interactions, is not aresse [16]. The Zachman framework is not a stanar written by a professional organization, so no explicit compliance rules have been publishe. However, if the framework is use in its entirely an all the given relationship rules are followe, then compliance can be assume by efault [8]. Many visualization tools support Zachman are available, such as Popkin an IDS Scheer ARIS. 4.2 The Open Group Framework (TOGAF) 4.2.1 Introuction TOGAF evelope by the Open Group in 1995. TOGAF is base on the Technical Framework for Information Management (TAFIM), which evelope by the Department of Defence (DoD). Version 8.0 of TOGAF is calle the 'Enterprise Eition' an is eicate to EA. The main components of the TOGAF are escribe in figure (3) [5]. Figure (3): TOGAF main components Development Metho (ADM), which is a specific process efine by TOGAF for the evelopment an maintenance of the organization's technical architecture [23]. The ADM consists of seven major phases: initiations an framework, baseline escription, target architecture, opportunities an solutions, migration planning, implementation, an architectural maintenance. The ADM is consiere to be the core of TOGAF, an consists of a stepwise cyclic approach for the evelopment of the overall enterprise architecture [5]. The TOGAF Enterprise Continuum, which aggregates two continua, the architectural continuum an the solutions continuum. The architectural continuum escribes the generalization / specialization of architectural components, whereas the solutions continuum illustrates the actual implementation of the components [23], an TOGAF Founation that contains the Technical Reference Moel, The Open Group's Stanars Information Base (SIB), an The Builing Blocks Information Base (BBIB) [5]. The TOGAF Resource Base, which is a set of resources incluing guielines templates an backgroun information to help the architect in the use of the ADM. TOGAF has a list of recommene architecture views as part of its resource base. These architecture views can be ivie into two main views, as follows: Business architecture views, which aresses the concerns of the users of the system, an escribes the flows of business information between people an business processes (e.g., People View, Process View, Function View, Business Information View, Usability View, Performance View) [5]. Technical architecture views, which inclue: 7
o o o Engineering views, which aress the concerns of System an Software Engineers an inclue Security, Software engineering, Data, System engineering, an Communications engineering view. Operations views, which aress the concerns of Operators, Aministrators an Managers an inclue Security, Software, Data, Computing / Harware, Communications view. Acquirers views which aress the concerns of procurement personnel responsible for acquiring the Commercial Off-The-Shelf (COTS) software an harware an inclue Builing blocks cost, Stanars view. 4.2.2 The Open Group Framework iscussion TOGAF has "Y" for all of the comparison criteria, except for (CCA) Compliance, it gets "P". TOGAF is like Zachman in its compliance with CCA. CCA compliancy can be it can be achieve using TOGAF when following the compliancy rules [8]. From our point of view, TOGAF has many strengths an may be the leaer of Enterprise Framework. The strengths are: TOGAF is supporte by an open strong committee, which anyone can participate on an provie a fully publishe prouct of its results. Proven Metho TOGAF offers a proven metho that is the result of years of research an evelopment by the worl's leaing enterprise architects. Common Vocabulary TOGAF guies architects in using a stanar taxonomy for business, information systems, an technology moelling. This share vocabulary means that everyone in an organization can rea an unerstan the information. Communication Moels of the enterprise architecture give visual representation to business concepts, an, when publishe on the corporate intranet, isseminate knowlege of the business to the workforce. Comman Decisions A business-focuse enterprise architecture provies knowlege about an organization an enables managers to make betterinforme ecisions. Reuce complexity A well evelope architecture leas to a better integrate solution portfolio, fewer interfaces, increase ata sharing, improve reliability of the solutions, an easier maintenance. Business-IT alignment The business focus of the architecture evelopment process an the strong emphasis on the nee for the implemente solution to be architecture-compliant together will help ensure that IT solutions are aligne to the nees of the business. Many visualization tools support TOGAF are available, such as MEGA an Popkin. 4.3 The Comman, Control, Communications, Intelligence, Surveillance, an Reconnaissance (C4ISR) 4.3.1 Introuction The Comman, Control, Communications, Intelligence, Surveillance, an Reconnaissance (C4ISR) Framework, came from Defence Science Boar, who etermine in the early 1990s that one of the key means for ensuring interoperable an cost effective military systems is to establish comprehensive architectural guiance for all of DoD. Consequently, the C4ISR Integration Task Force evelope version 1.0 of the C4ISR Framework in June of 1996, an the C4ISR Working Group complete version 2.0 in December of 1997 [24]. C4ISR consiers three viewpoints, namely, an operational viewpoint, a systems viewpoint, an a technical viewpoint. The three views an their relationships are shown in figure (4) [11]. The operational view escribes the tasks an activities, the operational noes, an the information flows between noes that are require to accomplish or support an operation. The operational view escribes the nature of information exchanges in etail sufficient to etermine what specific egree of information-exchange interoperability is require. The systems view translates the require egree of interoperability into a set of system capabilities neee, ientifies current systems that are use in support of the operational requirements (or postulate systems that coul be use), an facilitates the comparison of current/postulate system implementations with the neee capabilities. The technical view articulates the criteria that govern the implementation of require system capabilities [24]. 8
4.3.2 C4ISR iscussion Figure (4): C4ISR views an their linkages The kins of information represente in each architecture view are highlighte in each view box. The wors on the arrows between the ifferent architecture views represent the manner in which the framework provies consistency among the ifferent views. The architecture proucts result from each of the views, plus the general information artefacts [16]. Table (4) represents the essential proucts of C4ISR framework. Applicable View All Views (Context) All Views (Terms) Systems Prouct Overview an Summary Information Integrate Dictionary High-level Concept Graphic Noe Connectivity Description Information Exchange Matrix System Interface Description General Nature Scope, purpose, intene users, environment epicte, analytical finings of the architecture. Definitions of all terms use in all proucts. High-level graphical escription of operational concept (high-level organizations, missions, geographic configuration, connectivity, etc.). noes, activities performe at each noe, connectivity & information flow between noes. Information exchange between noes an the relevant attributes of that exchange such as meia, quality, quantity, an the level of interoperability require. Ientification of systems an system components an their interfaces, within an between noes. Technical Technical Extraction of stanars that apply to the given architecture. Profile Table (4): C4ISR Framework Proucts C4ISR has "Y" for most of the comparison criteria; except for Conformance an (CCA) Compliance it gets "P. There is no conformance of a system to the architecture, there are only conformance criteria for the use of C4ISR in an architecture representation [16]. In orer to comply with CCA, the architecture escription must [8]: a. Inclue the appropriate set of proucts for the intene use. b. Use the common terms an efinitions as specifie in the framework. c. Be consistent with the Global Information Gri (GIG) an the Joint Technical (JTA).. Describe interoperability requirements in a stanar way. C4ISR is intentionally venor-tool-inepenent. Venor proucts exist to provie the framework proucts, but no specific venor is require. Some of the venor tools that coul be use are Ptech FrameWork, netviz an Sterling Software's COOL tools. Consistency across the architecture views is not truly aresse an Relationships among the concepts, an rules of structure, are minimal [16]. 5. Conclusions This paper has review the current state of EAF an the criteria that can be taken into consieration for the election of EAF. An examination of the literature will reveal the following very popular themes: There is no one best Framework No one framework is fully complete. Rather, each has strengths an weaknesses. It is important to match a framework s strengths with the particular "pain points" in your organization, so that the specific aspects of the framework that you nee are well represente in the choice you make. Also, it is not our expectation that any framework will be implemente in its entirety. Rather, think of a framework as a restaurant menu, where you can pick from among the most-appetizing ishes, an in oing so, think about implementing those pieces in a sequence that makes sense. Frameworks have strengths an weaknesses Frameworks are aaptable Tailoring the framework you choose is not only acceptable, it is expecte Selecting a framework shoul not consume a great eal of resources (get in an get out). 9
References About the authors: Saber Aballah is a PhD stuent at the epartment of information systems, faculty of computers an informatics, Cairo University. He is conucting research into enabling an supporting ebate uring architecting activities. Dr Galal H. Galal-Eeen is an associate professor of information systems at the faculty of computers an informatics, Cairo University an a professor of information systems at the British University in Egypt. 10