The Architectural Dilemma: Division of Work versus Knowledge Integration Marlies van Steenbergen1, Sjaak Brinkkemper2, 1 Sogeti Netherlands, Wildenborch 3, 1112 XB Diemen, The Netherlands Marlies.van.Steenbergen@sogeti.nl 2 Department of Information and Computing Sciences, Utrecht University, Padualaan 14, 3584 CH Utrecht, The Netherlands S.Brinkkemper@cs.uu.nl Abstract. In this paper we investigate the tension that exists in many large organizations between the need for division of work among architects and the requirement of developing an integrated set of architectural principles and models spanning all aspects of the organization. Two types of division of work are presented that set different requirements on knowledge integration. Drawing from insights of the fields of IS research (business-IT alignment), organizational theory (knowledge-based theory of the firm) and sociology (boundary objects) we arrive at a conceptual model linking knowledge integration mechanisms to types of division of work. We test this conceptual model in three cases. The results show that the concepts of boundary objects and of interconnectedness are relevant in realizing the integration required. Keywords: enterprise architecture, knowledge integration, division of work, alignment, boundary object, case study, knowledge based theory of the firm. 1 Introduction Enterprise architecture is a growing discipline within the field of Information Systems. Awareness is increasing that large organizations need some kind of direction-giving frameworks to manage information systems development in order to prevent an unmanageable increase in IT complexity. Enterprises, and with them the management of information, are changing so fast and becoming so complex that some kind of reference framework is needed to keep in control. Enterprise architecture provides such a framework [1, 2, 3]. We define enterprise architecture as a consistent set of rules and models that guide the design and implementation of processes, organizational structures, information flows, and technical infrastructure within an enterprise [4]. Enterprise architecture provides an integrated set of direction-giving architectural principles and models concerning all aspects of the enterprise: products, processes, organization, data, applications, technical infrastructure. The value of enterprise architecture lies in the fact that it provides an integrated view taking all these aspects into account, instead of the isolated view on only one aspect that may be provided by specialists. Proceedings of BUSITAL 2009 As enterprise architecture takes all aspects of the enterprise into account, it becomes too all-encompassing to be assigned to one or just a few architects. With architecture, as with other functions [5, 6, 7], we see forms of functional specialization emerging with different types of architects. In large organizations the number of architects may easily run up to more than a hundred. These architects represent various roles that can be distinguished along two dimensions, as depicted in figure 1. The first dimension is the management level the architect operates on. In practice we see architects act on all of the well-known levels of strategic, tactic and operational management [8, 9, 10]. At strategic level the architect interacts with senior management on fundamental strategic choices for the organization. These fundamental strategic choices are translated by the architect into high-level designs and design principles, usually called the enterprise architecture. These high-level designs and principles are further developed at the tactical level into directions and designs per business line and per technical domain, the so-called domain architectures. At the operational level the directions from strategic and tactical level are translated into specific rules for projects in the project start architectures [4, 8]. The second dimension against which types of architects can be distinguished, is the dimension of content. Architects may have their own field of expertise like business architect, application architect, data architect, middleware architect, etc. Which exact domains are distinguished differs between organizations. Often a division is made in business domains per business line (for instance retail, wholesale, production) plus technical domains per technical aspect (for instance software development, middleware, network). This distinction is particularly clear at the tactical level in the form of various domain architectures. Thus we see that the architecture of an enterprise usually consists of many documents covering different aspects of the enterprise and authored by different architects. Fig. 1. Division of architectural work. This division of work is necessary because no single person or team can grasp all aspects anymore. However, as the purpose of architecture is to provide guidance to Proceedings of BUSITAL 2009 changes in the organization by setting a coherent set of rules and models spanning all aspects of the organization, the various types of architects cannot work in isolation each on their own subject, but the rules and models they develop must be aligned with each other. Thus a principle like ‘core data are maintained in only one place’ at strategic level translates to a tactical level principle ‘customer data are only maintained in our customer database’. And if an enterprise adopts a service oriented architecture, the services identified at application level should match the services identified at process level. Real life shows that this kind of alignment, however, is hard to achieve. The number of architects is too large to trust upon spontaneous collaboration. This is evidenced by the emergence of contradictions between the rules of the different management levels, by gaps in the coverage of the models and by discrepancies between the rules for different aspects. Management is thus faced with the question how to achieve the integration that is needed to ensure that though a great number of architects are at work, each with his or her own special focus, together they produce a coherent set of architectural principles and models. In this paper we investigate how within the context of division of work among architects, the cohesion of the architectural content can be maintained. In doing so, we draw upon ideas about alignment and integration already developed in the fields of organization, sociology and IS theory. The contribution of this paper is twofold: it applies existing theory on knowledge integration to the new field of enterprise architecture, and in doing so, it combines theoretical concepts from various domains in one conceptual model. The research approach followed is that of a theory testing case study as described by [11]. As not much theory has been built yet concerning the division and integration of architecture, our research concerns initial theory-testing. Whereas the research question emerged from observations in the field of architecture, the first step in answering it was done by investigating how existing theories might apply. This led to the building of a conceptual model combining concepts from various fields of research. This model is presented in section 2. From this conceptual model a number of propositions were formulated and tested in three different organizations. The results from these case studies are discussed in section 3. Evaluation and conclusions are given in section 4. 2 Architectural Knowledge Integration 2.1 The Conceptual Model for Architectural Knowledge Integration The division of work among architects requires a manner of knowledge integration in order to ensure integrated architectural deliverables. The concept of knowledge integration has been thoroughly investigated in organizational theory, especially the knowledge-based theory of the firm [6, 12]. Four integration mechanisms are distinguished: rules and directives, sequencing, routines and group problem solving and decision making [12]. These mechanisms differ, among others, in the intensity and mode of interaction. The extent to which the required knowledge integration is Proceedings of BUSITAL 2009 achieved depends on whether the organization is able to employ the right integration mechanisms. The successful employment of specific integration mechanisms is greatly influenced by organizational characteristics [7, 13, 14]. Based on these ideas we developed the conceptual model of architectural knowledge integration presented in figure 2 and explained below. Fig. 2. The conceptual model for architectural knowledge integration. The model reflects the idea that the efficiency of knowledge integration depends on the match between the integration requirement set by the type of division of work and the integration capacity that depends on organizational characteristics (see [13] for a comparable model for the multimedia domain). We explain the concepts of the model below. In section 3 we elaborate the model into a number of propositions. Division of work we define as the manner in which the architectural work is divided over a number of different architectural roles. As shown in figure 1 we distinguish two kinds of division of work: division along management levels, which we will refer to as vertical division of work and division along content, which we refer to as horizontal division of work. The division of work leads to the need for some kind of knowledge integration: the knowledge integration requirement. Knowledge integration requirement we define as the kind of knowledge integration that is required in an organization because of division of work over more than one person. Knowledge integration capacity is the kind of knowledge integration that an organization is capable of achieving. The capacity is partly dependent on organizational characteristics. By organizational characteristics we mean both fixed and changeable characteristics of an organization, like structure and modes of collaboration. If the knowledge integration capacity matches the knowledge integration requirement it is possible to achieve efficiency of knowledge integration. The efficiency of knowledge integration is the extent to which the organization accesses and utilizes the specialist knowledge held by individual organizational members [6]. In the case of architectural knowledge integration the efficiency is evidenced by the measure in which an integral, coherent and consistent set of architectural principles and models is available for use to the organization. 2.2 Dependencies between the Concepts The next step is to see whether it is possible to say anything about the relations between the concepts in the model. Using ideas from the fields of IS research, organizational theory and sociology we will arrive at a number of propositions. Proceedings of BUSITAL 2009 We start with investigating the relation between organizational characteristics and knowledge integration capacity to answer the question what organizational characteristics influence the knowledge integration capacity. First of all we should further elaborate the concept of knowledge integration capacity. For this we turn to the knowledge-based theory of the firm which distinguishes four mechanisms for integrating knowledge: rules and directives, sequencing, routines and group problem solving and decision making [12]. Rules and directives are written down directions. They are suitable for communicating explicit knowledge among specialists and between specialists and non-specialists. Integration is done by ensuring that one’s own rules are compliant with the ones written down by others. The second integration mechanism is sequencing. Sequencing is characterized by organizing activities in a time-patterned sequence. In this way each participant can do his own piece of work, based on a prescribed input. This kind of integration requires a minimum of communication. The third integration mechanism, routines, requires a bit more communication, but communication is still very much restricted to a minimum. In contrast to sequencing, routines allow the participants to perform their tasks simultaneously. It also allows for more variation during execution than sequencing. Like sequencing, routines can only be developed for repetitive tasks in which it can be predefined how the various participants are to react to certain events [15, 16, 17]. The fourth and final integration mechanism mentioned by [12] is group problem solving and decision making. This mechanism requires the most interaction and communication of the four mechanisms. It is suitable to non-standardized tasks characterized by task complexity and task uncertainty. According to [6] three factors are important in determining the success of knowledge integration: the level of common knowledge, the frequency and variability of task performance, and structure. Frequency and variability of task performance are more or less a given, but common knowledge and structure are organizational characteristics that can be manipulated. The first factor mentioned by [6] is the level of common knowledge. To be able to integrate knowledge some kind of common ground is needed, without the participants having to share all their specialist knowledge. From sociology we learn that boundary objects can provide such common ground [18]. When people from different perspectives work together this can be facilitated by boundary objects. A boundary object is an artifact that has different meanings in different social worlds but that has a structure that is common enough to more than one world to make it recognizable. This makes boundary objects into means of maintaining coherence across intersecting social worlds. Examples of boundary objects are shared concepts, repositories, frameworks and templates, for instance the use of maps by ecologists [18] and the use of layered plans and ordering lists by physical architects [19]. The work of physical architects is described as “individual, team-based and multi-disciplinary, enlisting multiple professional competences and perspectives, at the same time” ([19], p.262). In this world boundary objects play various roles of integration. This is reminiscent of the world of ‘digital’ architects. Which leads to our first proposition. Proposition 1. The use of boundary objects is a viable way of achieving knowledge integration in the field of architecture. Proceedings of BUSITAL 2009 The second organization dependent factor to influence knowledge integration mentioned by [6] is structure, especially the extent to which the structure enables the right amount of communication. In [14], interconnectedness is mentioned as one of the relevant structural factors. Interconnectedness is defined as the richness and frequency of contact and information exchange among the different parts of a system [14]. The importance of interconnectedness for alignment between disciplines is also shown by research into business-IT alignment [21, 22, 23, 24, 25]. Though in this paper we do not look at business and IT alignment as such, we investigate alignment between the various architects, who, besides, may be concerned either with business aspects or IT aspects. Business-IT alignment research indicates that cross- participation and sharing of knowledge is important in achieving alignment. Interconnectedness seems to be especially relevant for the relatively unstructured integration mechanism of group problem solving and decision making [21]. This gives us our second proposition. Proposition 2. Interconnectedness is an important factor in achieving knowledge integration by way of group problem solving and decision making in the field of architecture. The second relation in the model to discuss is the relation between division of work and knowledge integration requirement. Vertical and horizontal division of work each put specific requirements on how the knowledge of the participants is to be integrated. Vertical integration is concerned with setting directions and constraints on the level below. The issue here is to provide clear, unambiguous directions, guidelines, fundamental choices and high level design rules. In terms of knowledge complexity as defined by [7], vertical division of work causes computational knowledge complexity: the knowledge of the strategic level is to be spread to many agents that are to use this knowledge in many kinds of activities. According to [7], computational complex knowledge can be integrated by documents and codification. This all points in the direction of using the mechanism of rules and directives for vertical integration. This leads to our third proposition. Proposition 3. Vertical division of work requires rules and directives for knowledge integration. Horizontal division of work is quite different. Though it may be argued that there is some kind of order in specifying the various aspects, with processes dictating choices in the supporting applications, in practice the specification of the aspects is a matter of mutual interaction. It is a matter of bi-directional integration rather than uni- directional. This requires more face-to-face interaction discussing the impact of choices in one aspect on the other aspects. The architects have to work together to design a coherent framework in which the knowledge of all the different domains comes together in an integrated whole. Often tacit knowledge is involved: each participant applying his or her knowledge to arrive at a consistent and effective set of directions. Each participant is autonomous in his/her own domain, but within limits because of the interdependencies with the other domains. The knowledge complexity involved is of a technical and cognitional type [7]. Proceedings of BUSITAL 2009 As horizontal integration is concerned with tacit knowledge and bi-directionality, rules and directives are less suitable. This leaves us with sequencing, routines and group problem solving and decision making. Sequencing does not seem to be appropriate because of the strong bi-directional nature of the integration. Routines might be a suitable integration mechanism. However, the present maturity of the architectural field may not allow for routines as yet. The frequency of task performance may be moderately high for full time architects, but the variability is usually high too. For efficient routines a high frequency and a low variability are best. Which leaves us with group problem solving and decision making: solving architectural issues together in face-to-face communication. Face-to-face communication is also the integration mechanism suggested by [7] for cognitional complex knowledge. Proposition 4. Horizontal division of work requires group problem solving and decision making for knowledge integration. Binding everything together is the third relation in the model, the relation between the knowledge integration requirements and knowledge integration capacity and the efficiency of knowledge integration as expressed in our final proposition. Proposition 5. The measure in which the integration capacity matches the integration requirements determines the efficiency of architecture knowledge integration. To summarize the model, the type of division of work (vertical or horizontal) determines the knowledge integration requirements. For an efficient integration of knowledge, these requirements must match the integration mechanisms chosen (rules and directives, sequencing, routines or group problem solving and decision making). The capacity for choosing an integration mechanism is determined by organizational characteristics like the use of boundary objects and the extent of interconnectedness. 3 Case Studies To seek support or rejection for our conceptual model, we analyzed three cases. We think the choice for a case study is appropriate as we are dealing with a ‘how’ question regarding a contemporary event over which the researcher has little control and in which the borders between the phenomenon of interest and its context are not clear [26]. Besides, the nature of our research is strongly exploratory and we are seeking initial support. 3.1 Validity The three cases, two financial institutions and one semi-governmental agency, were partly chosen because of practical reasons. All three had been subject to an assessment, in which one of the authors participated, on the architecture practice. The assessments consisted of interviewing architects and their stakeholders and studying Proceedings of BUSITAL 2009 documentation. At the interviews two investigators were present, one of them taking notes. The interviews were semi-structured, based on an existing architecture maturity assessment instrument [27], thus providing greater reliability. Construct validity is supported by using multiple sources and by having the results of the assessments reviewed by the interviewees either in an interactive session or by commenting on the assessment document. The object of analysis of the assessments was the entire architecture practice, i.e. the whole of activities, responsibilities and actors involved in the development and application of architecture within the organization. The material resulting from the assessments, consisting for each case of interview notes and an assessment report approved by the architecture manager, provided the data for our study. As the assessments had a wider scope than the object of analysis of our study, we mined the material for data that was relevant to our study in the sense that it provided evidence for or against our propositions. We provided focus by using our conceptual model as a framework, thus supporting internal validity [26]. 3.2 Background of the Case Organizations The cases we selected are two banks and a semi-governmental institution. BANK1 is a multinational bank with more than 40,000 employees. The some 150 architects are divided over various departments but reside mainly in the Operations division (14,000 employees). The architects are divided both vertically and horizontally. Vertically a distinction is made between (1) enterprise architects with a global scope, (2) information systems (IS) architects with a business line scope and information technology (IT) architects with an IT scope, (3) domain architects with a business or technical domain scope and (4) application and solution architects with a project scope (see figure 3a). Horizontally at the levels of IS/IT architects and domain architects a division is made according to business aspect or technical aspect. The main type of architectural deliverable is the enterprise architecture (EA) at strategic level and the project start architecture (PSA) at operational level. The architects have an advisory task concerning project design choices. Decision making is done by line management. Fig. 3. Division of work in BANK1 (a), BANK2 (b) and GOVERNMENTAL (c) BANK2 is a national bank with some 40,000 employees. The 80 architects reside in the IT department and are vertically divided into (1) enterprise architects and (2) domain architects (figure 3b). The domain architects also function as project architects. The domain architects represent various business domains. The enterprise Proceedings of BUSITAL 2009 architects represent information or technical aspects. The top-level architecture is the enterprise architecture. All other architectural documents must be in line with the EA. Each project has a project start architecture made at the start. For many domains there is a domain architecture. The architects have an important say in project design choices. Only in cases of disagreement between architect, project manager and business line manager is senior management involved in decision making. GOVERNMENTAL is an independent semi-governmental institution of some 1000 employees that works primarily for the ministry of education. Its architects reside in the Operations department. There are three types of architects: (1) enterprise architects, (2) domain architects and (3) project architects (see figure 3c). Enterprise architect and domain architect is a function, project architect is a role. The domain architects are assigned to a specific business domain or are technical architects. The enterprise architects may have their specialism as well. In all there are some 20 employees working as architect, with some six of them being full time architect (the enterprise architects). There is an enterprise architecture and there are project start architectures. The first domain architecture is still under construction. 3.3 Data Analysis An overview of the integration mechanisms found in the cases is given in table 1. Table 1. Case findings concerning integration mechanisms. Case Vertical Horizontal Boundary Inter- Fit integration integration objects connectedness BANK1 High level EA; At operational level Templates at Architects work Lack of Sporadic by sequencing; tactical and individualistically: integration guidelines; At tactical level by operational no architectural at tactical Lack of DA’s individual level; community over level; architects No framework departments; Gap Initiatives to between increase strategic and interconnectedness operational level BANK2 Enterprise Informal network; Framework Architecture Lack of architecture; By review at and templates community integration Great variety strategic and at strategic and meeting four times at tactical in domain operational level operational a year level; architectures level; No insight No boundary in interde- objects at pendencies tactical level GOVERN- Enterprise Only at strategic Framework; Active architecture Lack of MENTAL architecture; and operational Templates at community structural DA’s to be level, tactical level all levels meeting once a integration developed yet still being week at tactical developed; level Informal network Proceedings of BUSITAL 2009 Vertical integration. In all cases both vertical and horizontal division of work are found. As figure 3 shows, the levels of architects vary from two to four levels. In the case of two levels, the operational task of supporting projects is performed by architects at the tactical level or, less frequently, the strategic level. In all cases architects that support projects are expected to conform to rules and directions laid down in an enterprise architecture and domain architectures where available. Thus all cases confirm that there is some form of vertical knowledge integration required. The extent of the rules and directives, however, varies between the cases. BANK1 has but few direction-setting architectural documents. There is a high- level enterprise architecture, but this is regarded by many as too abstract. It is not fully understood and is not always considered useful. Much architectural effort is spent on the operational level, providing projects with a project start architecture. Between the PSA and the EA there is a gap. As a consequence, the architects do not work from a common background and there is no overall view of how the various sub domains are related to each other. Each architect has to establish the relations to other programs and domains anew and has to find the appropriate persons to ensure alignment. In some sub domains guideline documents are produced, like integration guidelines and principles for customer relation management. These types of documents are considered very valuable and useful by program managers. A source of tension between the IS architects and the IT architects of BANK1 is the difference in assignment for the two. IS is focused on supporting the dynamics of the business while IT is focused on standardization and industrialization. There is no overarching architecture to solve this difference in goal. BANK2 and GOVERNMENTAL both have an enterprise architecture that sets directions and guidelines for the other levels. BANK2 in addition has lower levels of architectural documents. Counting all levels of architecture, starting at holding level and all the way through to project level BANK2 distinguishes 4 levels of architecture. Horizontal integration. Horizontal division of work is seen especially at the tactical level, where in all three cases a division in domains is made, with architects being assigned to a specific domain and architecture being split up in various domain architectures. Domain architectures may be business line oriented (processes and applications) or technical oriented (aspects of technical infrastructure). This is a difference with the strategic and operational level where the various aspects and domains are integrated into one document, the EA respectively the PSA. As one person is usually end responsible for EA or PSA, even though more architects may be involved, integration of the various specialized knowledge domains is guarded by this person. At the tactical level this end responsibility is less evident and less easily fulfilled. This is illustrated in all cases, as each case is wrestling with the tactical level, though in different ways. Whereas BANK1 and GOVERNMENTAL deal with a lack of domain architectures, BANK2 deals with a wide variation of domain architectures of differing scope, content and format. One way of addressing the issue of integration we found in BANK2 and GOVERNMENTAL is to educate the architects in frameworks and concepts and to form a kind of architecture community that convenes regularly. Within the IT department of BANK1 a few architects are assigned the task of guarding the coherence of the domain architectures over the various technical domains. They find this a very hard task to do. Only recently they changed tack from Proceedings of BUSITAL 2009 discussing issues with each domain architect separately to getting the domain architects together. This is felt as an improvement, but is still in its infant stage. At operational level a tension is felt in BANK1 by some solution architects between the application part and the technical infrastructure part of the PSA. These two parts fall under different responsibilities and the processes of approval are not always aligned. This shows that at the operational level too, horizontal integration may be an issue. Also, some technical architects feel their involvement in writing a PSA is not timely enough. They are involved at too late a stage. Many feel that in this process, IT could be involved at an earlier stage and that a more collaborative mode of operation is desirable. BANK1 tends to use sequencing at the operational level, business talking with IS and IS talking with IT, but this is not found very satisfactory by IT: the last in the line keeps running after the facts. In BANK2 domain architects are found to be of differing success in defining domain architectures. Those efforts that are perceived as being the most successful are the ones in which there is a close collaboration between the various parties involved and in which the domain architect is also involved in the programs that are to realize the domain architecture. GOVERNMENTAL is still in the process of implementing the tactical level. There is an EA as well as a PSA process. As a gap is felt between EA and PSA, initiatives have started to appoint domain architects that are to develop business domain architectures. A template for domain architectures has been defined. The boundaries of the domain architectures are defined in the EA. Boundary objects. The use of boundary objects can be encountered in various ways in the cases. Both BANK2 and GOVERNMENTAL make use of an architectural framework to support integration. Horizontal integration is supported by the sharing of concepts from the framework. It provides a common ground that facilitates integration. Besides, in GOVERNMENTAL the EA defines the boundaries of the domains at the tactical level. Vertical integration is supported by reflecting the framework in templates for enterprise architecture, domain architectures and project start architectures. By using the structure of the framework as the outline for the architectures at the different levels, it is easier to check the alignment of the levels. At BANK2, however, there have been a number of initiatives recently to develop new kinds of domain architectures, using other architectural frameworks and templates. These initiatives emerged bottom up. This undermines the use of frameworks and templates as boundary objects. The result is that it has become increasingly difficult to identify interdependencies between domains. This was identified as problematic by program managers. Interconnectedness. The cases also differ in how interconnectedness between the architects is realized. In BANK2 interconnectedness is large, primarily because collaboration and using one’s informal network is a basic part of the organizational culture. Much architecture emerges in what the architects themselves call an organic fashion: there is much collaboration and many regard their informal network as an important success factor. All architects are part of the architectural community that meets for a day at least four times a year. When asked about responsibilities the answer frequently is that responsibility is shared among the stakeholders. Architectural documents are approved by having them reviewed by a large number of stakeholders. Proceedings of BUSITAL 2009 In GOVERNMENTAL too, interconnectedness is large. The architects know each other. A kernel team meets weekly, mainly to discuss architectural issues but topics concerned with methods and processes can also be put on the agenda. A lot of knowledge integration is thus done in an informal manner. In BANK1 the architects work very much individualistically, though there are differences between the business lines. On the whole there is no architecture community to speak of, nor is there a common language. This applies especially to the tactical level. Architects at this level mainly work with analysts and project managers. If architects work with other architects, this is because the project requires it. There is little discussion on meta level about methods, best practices, joint architectural products or architecture vision. In some business lines, however, architects are starting to engage in sharing knowledge in regular meetings. Not long after our case study, the IS architects of the different business domains decided to convene regularly to exchange knowledge and experiences and to align decisions, as they felt that this was missing in the formal structure. Also one of the architects responsible for the resilience of the architecture changed tack from having bilateral meetings with various domain architects to getting all domain architects together to discuss interdependencies. These developments illustrate a need for interaction among architects at tactical level. Fit between requirements and capacity. As for the fit between requirements and capacity, we see that BANK1 seems to have something of a mismatch with regard to horizontal integration at tactical level. The large amount of domain architects in this case asks for explicit integration efforts, but the only integration mechanism offered is that of templates. Interconnectedness was not encouraged or facilitated in the past and is only now being developed. Thus group problem solving and decision making as integration mechanism is not implemented yet. As for vertical integration, a gap exists between the strategic level and the operational level, which makes it more difficult for the project architects to formulate the guidelines for projects. Though interconnectedness in BANK2 is much larger, in BANK2 too, integration at tactical level is problematic. Though interconnectedness is better developed than in BANK1, as there are regular meetings and as there is a large informal network, what seems to be lacking is the full use of a framework and templates as boundary objects. It is felt by many that the cohesion between the many architectural documents is unclear and that nobody knows the whole picture anymore. At GOVERNMENTAL integration issues are limited to strategic and operational level, as the tactical level is not implemented yet. Horizontal integration is mainly realized by interconnectedness. This is sufficient for GOVERMENTAL at the moment because the number of architects is still small. Most issues are solved at the weekly architecture meeting. Vertical integration is implemented by way of an enterprise architecture. Gaps between the enterprise architecture and the project start architecture are solved through interconnectedness. 3.4 Discussion The cases seem to largely support our conceptual model. The suitability of rules and directives as integration mechanism for vertical integration is supported by all cases, Proceedings of BUSITAL 2009 in the form of architectural documents at the different management levels (enterprise architecture, domain architectures and project start architectures). Where there is a lack of architectural documents, integration between strategic, tactical and operational level is less efficient. The cases also support the statement that rules and directives are not suitable to horizontal integration. Horizontal integration appears to be a tough issue, especially at the tactical level. The cases seem to support the proposition that group problem solving and decision making is needed. Architectural documents regularly function as boundary objects. Templates can be regarded standardized forms and an architectural framework provides coincident boundaries (vertical integration). Both the use of boundary objects and sufficient interconnectedness are found to facilitate group problem solving and decision making at the tactical level, though neither seems sufficient in itself. It appears that it is important to find the right balance between the use of boundary objects and interconnectedness. If this mix is not present, we see a mismatch with the integration requirements of tactical integration and a consequent lack of successful integration. The horizontal integration needs explicit attention especially at the tactical level, as at this level there is no one single document that is being worked on as is the case at the strategic and operational level. 4 Evaluation and Conclusions In this paper we investigated the tension that exists in many large enterprises between the need for division of work among architects and the requirement of developing an integrated set of architectural principles and models spanning all aspects of the enterprise. We found that there are two types of division of work that set different requirements on knowledge integration. Making use of results from the fields of IS research, organizational theory and sociology we arrived at a conceptual model of architectural knowledge integration linking knowledge integration mechanisms to types of division of work. We tested the propositions derived from this conceptual model in a case study. The cases confirm that forms of integration among architects are needed and that the use of boundary objects and the measure of interconnectedness are important factors in achieving this integration. There are limitations to our research. Though the conceptual model of architectural knowledge integration seems to be supported by the cases, our research represents initial theory-testing and a series of replications is needed to enhance the theory’s generalizability as well as to further investigate whether other factors may be relevant to our model. The results so far, however, are promising. Our research suggests some additional areas of investigation. The apparent importance of interconnectedness in realizing the knowledge integration mechanism of group problem solving and decision making warrants further investigation in how this interconnectedness might be stimulated. One of the areas of research that seems a promising venue to further investigate this, is research into communities of practice [28, 29] and epistemic communities [15]. A community of practice is a group whose members regularly engage in sharing and learning, based on their common interests. Communities of practice develop connections among practitioners, fostering Proceedings of BUSITAL 2009 relationships that build a sense of trust and mutual obligation and creating a common language and context. The common ground for architects would be the architectural discipline, even if the domain of architecture differs. An epistemic community is a group of agents that share a common goal of knowledge creation. Where they are self- organized they share some characteristics with communities of practice. Another direction that in our view merits further investigation is that of routines. A question that remains to be answered is whether the field of architecture has just not matured enough to make routines feasible, especially for horizontal knowledge integration, or whether this will never be the case because of the nature of architecture. In other words: is the lack of routines in present day architecture work a matter of time (architecture being still a relatively immature field) or is architecture work inherently too diverse to ever be supported by routines. The implications of our research for practitioners are twofold. First our research suggests that practitioners should invest in building an architecture community in which architects exchange ideas, experiences and best practices, and discuss the interdependencies between their respective areas of expertise. An important part of best practices is the effective use of boundary objects. Practitioners should invest in choosing a common framework and in developing usable templates that can bind the various domains together. Acknowledgments. The authors wish to thank Rik Bos, Wiel Bruls and Ralph Foorthuis for their stimulating discussions during the execution of this research. References 1. Lankhorst et al.: Enterprise Architecture at Work. Springer, Heidelberg (2005) 2. Ross, J.W., Weill, P., Robertson, D.: Enterprise Architecture as Strategy. Harvard Business School Press, Boston (2006) 3. Versteeg, G., Bouwman, H.: Business architecture: a new paradigm to relate business strategy to ICT. Information Systems Frontier, 8, 91-102 (2006) 4. Wagter, R., Van den Berg, M., Luijpers, L., Van Steenbergen, M.: Dynamic Enterprise Architecture: how to make it work. Wiley, Hoboken (2005) 5. Buchanan, D., Huczynski, A.: Organizational behavior, an introductory text. Fifth edition. Prentice Hall (2004) 6. Grant, R.M.: Prospering in dynamically-competitive environments: organizational capability as knowledge integration. Organization Sciences, 7 (4), 375-387 (1996) 7. Ditillo, A.: Dealing with uncertainty in knowledge-intensive firms: the role of management control systems as knowledge integration mechanisms. Accounting, Organizations and Society, 29, 401-421 (2004) 8. Van den Berg, M., Van Steenbergen, M.: Building an enterprise architecture practice. Springer, Dordrecht (2006) 9. Foorthuis, R.M., Brinkkemper, S.: A Framework for Local Project Architecture in the Context of Enterprise Architecture. Journal of Enterprise Architecture, 3 (4), 51-63 (2007) 10. Van der Raadt, B., Van Vliet, H.: Designing the Enterprise Architecture Function. In: Becker, S., Plasil, F., Reussner, R. (Eds.) QoSA 2008, LNCS 5281, 103-118, Springer- Verlag Berlin Heidelberg (2008) 11. Dul, J., Hak, T.: Case study methodology in business research. Butterworth-Heinemann, Oxford (2008) Proceedings of BUSITAL 2009 12. Grant, R.M.: Toward a knowledge-based theory of the firm. Strategic Management Journal, 17, 109-122 (1996) 13. De Boer, M., Van den Bosch, F.A.J., Volberda, H.W.: Managing organizational knowledge integration in the emerging multimedia complex. Journal of Management Studies, 36 (3), 379-398 (1999) 14. Ravasi, D., Verona, G.: Organising the process of knowledge integration: the benefits of structural ambiguity. Scandinavian Journal of Management, 17, 41-66 (2001) 15. Cohendet, P., Llerena, P.: Routines and incentives: the role of communities in the firm. Industrial and Corporate Change, 12 (2), 271-297 (2003) 16. Becker, M.C.: Organizational routines: a review of the literature. Industrial and Corporate Change, 13 (4), 643-677 (2004) 17. Pentland, B.T., Feldman, M.S.: Designing routines: on the folly of designing artifacts, while hoping for patterns of action. Information and Organization, 18, 235-250 (2008) 18. Star, S.L., Griesemer, J.R.: Institutional ecology, ‘translations’ and boundary objects: amateurs and professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39. Social Studies of Science, 19 (3), 387-420 (1989) 19. Reich, B.H., Benbasat, I.: Factors that influence the social dimension of alignment between business and information technology objectives. MIS Quarterly, 24 (1), 81-113 (2000) 20. Schmidt, K., Wagner, I.: Coordinative artifacts in architectural practice. In: Blay- Fornarino et al. (eds.) Proceedings of the fifth international conference on the design of cooperative systems, 257-274, IOS Press, Amsterdam (2002) 21. Huang, J.C., Newell, S.: Knowledge integration processes and dynamics within the context of cross-functional projects. International Journal of Project Management, 21, 167- 176 (2003) 22. Kearns, G.S., Lederer, A.L.: A resource-based view of strategic IT alignment: how knowledge sharing creates competitive advantage. Decision sciences, 34 (1), 1-29 (2003) 23. Van Eck, P., Blanken, H., Wieringa, R.: Project GRAAL: Towards Operational Architecture Alignment. International Journal of Cooperative Information Systems, 13(3):235-255 (2004) 24. Campbell, B.: Alignment: Resolving ambiguity within bounded choices, PACIS 2005, Bangkok, Thailand, 1-14 (2005) 25. Chan, Y.E., Reich, B.H.: IT alignment: what have we learned? Journal of Information Technology, 22, 297-315 (2007) 26. Yin, R.K.: Case Study Research, design and methods, third edition. SAGE Publications, London (2003) 27. Van Steenbergen, M., Van den Berg, M., Brinkkemper, S.: A Balanced Approach to Developing the Enterprise Architecture Practice. In: Filipe, J., Cordeiro, J., Cardoso, J. (Eds.) Enterprise Information Systems, LNBIP 12, 240-253 (2007) 28. Brown, J.S., Duguid, P.: Organizational learning and communities-of-practice: toward a unified view of working, learning, and innovation. Organization Science, 2 (1), 40-57 (1991) 29. Lesser, E.L., Storck, J.: Communities of practice and organizational performance. IBM Systems Journal, 40 (4), 831-841 (2001)