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.
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 [
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 [
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 [
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.
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 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 [
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 [
Based on these ideas we developed the conceptual model of architectural knowledge integration presented in figure 2 and explained below.
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 [
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 [
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.
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 [
According to [
Proposition 1. The use of boundary objects is a viable way of achieving knowledge
integration in the field of architecture.
The second organization dependent factor to influence knowledge integration
mentioned by [
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 [
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
unidirectional. 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 [
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 [
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
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 [
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
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 [
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. 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 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.
An overview of the integration mechanisms found in the cases is given in table 1. 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 highlevel 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 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.
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.
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, 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.
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
[
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.