Three core imperatives are essential for modern businesses and organizations: seamless integration of customer and operational processes, agility, and the ability to change. These imperatives are thus relevant in view of successfully executing strategic choices, but all too often not satisfied. Businesses and organizations can be viewed as complex adaptive socio-technical systems. Two fundamentally different perspectives on systems play a role: the functional (black-box) perspective and the constructional (white-box) perspective. Management and governance of businesses and organizations regard the functional, black-box perspective, which is inherently ill-suited for addressing the imperatives mentioned. Rather, establishing system integration, agility and change requires a focus on the system's design, hence entails the constructional perspective. Both perspectives are relevant. The concept of architecture plays a fundamental role for operationalizing the constructional perspective. Next to the more familiar notion of technology architecture, the concepts of business and organizational architecture are formally introduced and elucidated. In view of the important role of information in customer and operational processes, the notion of information architecture will be additionally discussed, specifically the relationships with other architectures. Various domains within these architectures will be highlighted, whereby the importance of coherence and consistency is stressed, especially in view of the ability to change. Collectively, the four architectures are labeled Enterprise Architecture. Finally, enterprise architecture will be positioned as a crucial means for linking strategy development and execution. The functional and constructional perspective A system may be defined as an identifiable bounded set of functionally and/or methodically related elements or principles with a certain operational purpose. Within this definition, a plethora of systems can be mentioned: a payment system, an accounting system, a transport Enterprise Architecture 2 system or a communication system, to name but a few. More specifically, socio-technical "systems" of human endeavor, like businesses and organizations are the focus of this paper. Realizing artifacts (systems) always involves two different perspectives: the functional and constructional perspective [Dietz 1996] . Within the functional perspective the central question regards what the system is required to deliver in terms of the system's behavior, performance and interface characteristics, as well as regards the system's operational conditions such as pertinent to reliability, availability, resilience, effectiveness and efficiency. The functional perspective can be labeled as the "black box" perspective: knowledge about the system's design and internal operation is not required. The constructional perspective on the other hand regards the question of how the system is to be designed and built. Here, knowledge about the system's internal operation is essential. Hence, we might speak of the "white box" perspective [o.c.]. The distinction between both perspectives becomes vividly clear when observing the difference mentioned earlier between managing a system and changing a system. Change without knowledge about the system's operation and design seems no prudent approach and is often disastrous. It seems clear that this insight similarly holds for systems of human endeavor, such as businesses and organizations. Business and organizational change thus necessitates a constructional perspective. Implementing strategic choices inevitably entails change. As Collis and Montgomery observe, "an outstanding corporate strategy is not a random collection of individual building blocks but a carefully constructed system of interdependent parts" [in Kaplan and Norton 2001] . This observation likewise indicates that the white box (constructional) perspective needs to be applied to other domains than merely the technology domain. This notion will be further explored blow. One might argue that the functional and constructional perspectives are incommensurable since they entail fundamentally different concepts and languages pertinent to the same system. Concepts used within the functional perceptive are for example: customer and employee satisfaction or retention, response times, return on capital employed, or efficiency. Black-box Functional Perspective Hence, concepts that regard the system's performance. On the other hand, within the constructional perspective concepts such as operating channels, resources deployment, process orientation, culture or management practices play a role. These are concepts that are relevant in view of the system's design. Nonetheless despite an apparent incommensurability between the two perspectives, some bridging concept is required that enables operationalizing the constructional perspective through design guidelines that can be linked to, and justified or reasoned from the functional perspective. In other words, the bridging concept thus provides an important communication vehicle about high-level constructional aspects. We feel the required concept is that of enterprise architecture, which we will further elucidate below. Historically, the notion of architecture was probably first introduced by the Roman architect Vitruvius who lived around 100 years BC and wrote ten books about architecture: "De Architectura Libri Decem" [1998]. These books contained a plethora of principles for properly designing squares and buildings, identified under labels such as "symmetria", "ordinatio", "proportio", and "harmonia". Unfortunately, despite the historic view on architecture as design principles, many other definitions of architecture currently exist. Some examples are: a topdown description of the structure of systems; a family of guidelines (rules, concepts, principles, patterns, standards) for design; a formal description of a system organized in a way that supports reasoning about the structural properties of the system; a blueprint of design; the fundamental organization of a system embodied by its components, their relationships to each other and the environment, and the principles guiding its design and evolution. Two basic approaches can be noticed regarding these definitions: one sees architecture as a descriptive concept that factually describes the characteristics of existing artifacts, whereas the other sees architecture as a prescriptive concept that defines how artifacts should be realized. In the latter sense, architecture limits design freedom [Dietz 1998 ]. We will use the concept of architecture in a prescriptive manner, viewed as a consistent set of design principles and standards that guide design. Below this notion will be further elucidated. There are multiple important reasons, argued in this paper, that necessitate extending the notion of "design" and associated "design principles" also beyond the realm of technical systems, hence to other domains than the technology domain only. In particular, we will argue that businesses and organizations -seen as "systems" of human endeavor -need to be included in an integrated design perspective next to technology that supports and enables those systems. Complementary to the technology architecture, also the concepts of business Enterprise Architecture 4 architecture, organizational and information architecture will be formally introduced in order to enable the constructional perspective on businesses and organizations. Reasons for introducing these new concepts are three-fold. The first reason has to do with the ability to realize integrated human and technology systems operation. It seems evident that enterprise integration has more facets than just technology. Obviously, having an integrated telephone network is not a sufficient condition for intelligible communication between remote sources, while the introduction of technology for local employee decision making seems pointless in a context where decision making is seen as a management prerogative. Making technology work thus requires a wider perspective than technology only, whereby contextual aspects are included in the design perspective such that the context and technology are optimally matched and integrated. Many failed introductions of technology and related systems prove the importance of this notion [Scott Morton 1991, Galliers and]. The notion of integration will become increasingly important. Appreciably, the more extended a "system" needs to operate seamlessly, the more architecture is essential. For example, effective execution of e-business, which calls for integration of multiple customer interfaces as well as front and back office processes, but also the seamless operation of a network of businesses and suppliers, all require an integrated (mutually consistent) business, organizational and technology design [Moss Kanter 2001] . This requirement necessitates an integrated design perspective and design principles that safeguard and enable integration. what is to be desired, not how it is accomplished. Recalling the perspective on strategy mentioned earlier, the wider design perspective is similarly stressed by Collis and Montgomery stating that strategy needs to be "a carefully constructed system of interdependent parts" [in Kaplan and Norton 2001] . Clearly, the notions of construction and interdependence call for design principles. Again, integration is key, since "in a great corporate strategy all elements (resources, business and organization) are aligned with one another" [ o.c.]. In view of these observations, the first purpose of architecture therefore regards integration. Understandably, implementation -which consequently entails business, organizational, and technology change -subsequently follows design. Often change is of major concern and amounts to business and organizational transformation. Noticeably, a survey among more than 500 CEO's identified the transformation to a new business model and the successful integration of new technology into the organization as the top-two challenges [ Pohlmann 2001 ]. Clearly, apart from the integration aspect, these concerns raise the question about Enterprise Architecture 5 successful change. Comparably, one study reported that the ability to execute a strategyhence realize successful change -turned out to be more important than the quality of the strategy itself [Kaplan and Norton 2001] . As emphasized before, change must be addressed from the constructional perspective, which entails design principles. Moreover, as will be argued later, change efforts are only successful under consistency and coherence of concepts used, which in turn is reflected by coherent and consistent design principles. In the words of Fritz, architecture avoids "structural conflict" that otherwise would be manifest in conflicting concepts [1996]. According to the "congruence theorem", the higher the degree of fit -or congruence among the various components -the more effective the enterprise becomes [Nadler and Tushman 1997] . The second important purpose of architecture thus regards safeguarding and enabling change. Increasing business and societal dynamics further imply that both the necessity and frequency of responses to these dynamics -such as pertinent to new products and services -also increases. Consequently, the response time in answering the increased dynamics should decrease. In other words, there is an increasing need for business and organizational agility. Contrary to this need, existing business and organizational arrangements often rather exemplify inert characteristics -inherent in the design -that limit prompt actions. Hence, the third important purpose of architecture is providing agility. In summary, design principles and standards -collectively identified as architecture -should be defined such that integration, successful change, and agility is arranged and enabled. In its customary meaning, the term "enterprise" refers to a (commercial) business organization. More generally however, this term can be used for intentional and systematic purposeful activities. As will be elucidated and illustrated below, the design of those activities need to be addressed from the four core perspectives mentioned, each having their associated design principles, hence the four different architecture domains identified in the above. Collectively the design principles are identified as enterprise architecture. Figure 2 graphically shows the four domains of the enterprise architecture. In view of the focus of this paper, the business, organizational and information architecture will be discussed.  This perspective addresses how a particular area of purposeful and gainful activities is to be exploited, explored and developed. Within a commercial context, this perspective regards for example the design principles pertinent to a chosen area of commercial endeavor, such as regarding revenue generation or the channels to be used for delivering products and services to customers. These aspects will be further explored below. Appreciably, for non-profit or governmental undertakings design principles are likewise relevant. For example, the Internal Revenue Service might contemplate about how the area of tax collection is to be exploited and explored. Further, purposeful and gainful activities are ideally based on an explicit mission and strategy. The mission is viewed as the more timeless expression of purpose and reason for existence of the entity engaged in purposeful activities, hence the mission has to do with "sense making" and imbuing activities with "meaning". Enterprise Architecture In order to differentiate our current perspective from the overall enterprise perspective, we will use the term "business" -also generally viewed as purposeful activities -in relation with exploiting, exploring and developing a particular field of (commercial) endeavor. With reference to the strategic intentions and mission, the business architecture can be defined as a logically consistent set of principles and standards that guides how a particular field of (commercial) endeavor will be exploited and explored. Hence, business architecture guides business engineering. Noticeably, the term business model is often mentioned in the literature. As with architecture, also the term "model" can have different meanings. A model can mean a conceptual abstraction and representation of a complex reality. Also, the term model might refer to an example for imitation or emulation, or a pattern for others to follow. In these latter cases the
The four architecture domains have their associated design principles, and these design principles are identified in EA REF .
Enterprise Architecture: Enabling Integration, Agility and Change
Int. J. Cooperative Inf. Syst.
Int. J. Cooperative Inf. Syst.
Computer Science