In this chapter, I reconceptualize enterprise architectures by using the activity domain as the basic architectural entity, thus emphasizing the elements of communal meaning and transition between domains. I compare this view of the enterprise with influential EA frameworks such as the one proposed by Zachman. I discuss implications of the ADT approach and suggest how to operationalize the construction of enterprise architectures from the ADT perspective.
TopWhy Enterprise Architectures?
A number of reasons have been put forward to motivate investments in defining and maintaining an EA for the organization.
The most down-to-earth reason is simply that an organization cannot do without it. An integrated approach to business and IT is indispensable (Jonkers et al., 2006, p. 63). Integration has been conceived as “the act or process of making something whole and entire’’ (Kirsilä, Hellström, &Wikström, 2007, p. 715). “By referring to integration, we thus mean bringing or joining together a number of distinct things so that they move, operate and function as a harmonious, optimal unit” (ibid). Integration can only be achieved if an enterprise-wide point of view is taken (Goethals, Snoeck, Lemahieu, & Vandenbulcke, 2006, p. 70).The EA is the means by which an integrated view of the organization can be achieved. It provides “a coherent whole of principles, methods and models that are used in the design and realization of the enterprise’s organizational structure, business processes, information systems, and infrastructure. EA captures the essentials of the business, IT and its evolution” (Jonkers et al., 2006, p. 64). The importance of an integrated view is reinforced by the tendency of organizations to cooperate in networks. An EA can provide a means to understand the dependencies between the organization and its customers, suppliers, partners and competitors.
Organizations are ever changing entities. An EA is vital when it comes to managing these changes. It helps stakeholders to evaluate new circumstances and respond appropriately. Without an EA it is, for example, difficult to estimate the consequences of replacing legacy IT systems with an enterprise resource planning (ERP) system. Such systems (as offered by, for example, SAP) come with in-built EAs for specific types of businesses or industries. By comparing the architectures for the organization and the ERP-package, the effort of adapting either the organization or the ERP-package can be estimated.
A decision to introduce an ERP-system is one example of a wider issue, that of aligning the business strategy of the organization and its ICT-resources. New technological inventions such as the Internet, global restructuring of development and production, outdated and incompatible legacy systems, company down-sizing, changes in customer demands, are but some circumstances that put an ever increasing pressure on alignment. The “availability of architecture descriptions enhances agility. After all, it is easier to change something you know well, and architecture descriptions are of major help in getting to know and understand existing system” (Goethals, Snoeck, Lemahieu, & Vandenbulcke, 2006, p. 70). An EA provides a mechanism that enables the organization to relate business strategies to technological means. This however, requires that the EA is seen as a living entity that needs to be constantly updated and aligned to new circumstances.
Even if the EA must change, an important aspect of the EA is that it should provide stability to the organization. Without stability, an ordered change process is impossible. Thus, contrary to what is sometimes claimed (e.g. Appleton, 2004), flexibility and agility presume stability. The issue is rather the extent and detail to which the architecture prescribes the operations of the organization. An architectural description should focus on those entities of the organizations that are stable and can be expected to change at a slow pace. Examples of such entities are basic business rules for naming and identifying parts in products or services. Usually, these rules have been elaborated over a long time and are, so to say, part of the taken-for-granted in the organization.
If the EA shall be a sharp instrument in managing the organization, it must become a common asset among stakeholders. Only then can the EA provide a common foundation for discussions, evaluations and action. Each stakeholder brings his or her world-view to the arena of the EA. They might have different backgrounds, experiences and incentives for taking part in a joint definition of the EA. Moreover, each stakeholder is presumably interested in the particular view of the enterprise that concerns him or her the most.