be identified, ranging from top-level management to soft-. H. Jonkers ( )· M. M. ... Netherlands; School of Computer Science, University of. Waterloo, Waterloo ...
Inf Syst Front (2006) 8:63–66 DOI 10.1007/s10796-006-7970-2
Enterprise architecture: Management tool and blueprint for the organisation Henk Jonkers · Marc M. Lankhorst · Hugo W.L. ter Doest · Farhad Arbab · Hans Bosma · Roel J. Wieringa
C Springer Science + Business Media, LLC 2006
In current business practice, an integrated approach to business and IT is indispensable. Take for example a company that needs to assess the impact of introducing a new product in its portfolio. This may require defining additional business processes, hiring extra personnel, changing the supporting applications, and augmenting the technological infrastructure to support the additional load of these applications. Perhaps this may even require a change of the organisational structure. However, in many companies such an integrated view of the entire enterprise is still far off. This is an important problem, because changes in a company’s strategy and business goals have significant consequences within all domains of the enterprise, such as the organisation structure, business processes, software systems, data management and technical infrastructure. Companies have to adjust processes to their environment, open up internal systems and make them transparent to both internal and external parties. Many stakeholders within and outside the company can be identified, ranging from top-level management to softH. Jonkers ()· M. M. Lankhorst · H. W. L. ter Doest Telematica Instituut, PO Box 589, 7500 AN Enschede, The Netherlands F. Arbab CWI, PO Box 94079, 1090 GB Amsterdam, the Netherlands; Leiden Institute of Advanced Computer Science, Leiden, the Netherlands; School of Computer Science, University of Waterloo, Waterloo, ON, Canada H. Bosma Ordina Public BV, PO Box 7101, 3430 JC Nieuwegein, the Netherlands R. J. Wieringa Department of Computer Science, University of Twente PO Box 217, 7500 AE Enschede, the Netherlands
ware engineers. Each stakeholder requires specific information presented in an accessible form, to deal with the impact of such wide-ranging developments. It is necessary but very difficult to obtain an overview of these changes and their impact on each other, and to provide both decision makers and engineers implementing the changes with the information they need.
What is enterprise architecture? It is often said that to get a grip on the complexity of any large organisation or system, you need an architecture. But what exactly does this notion of “architecture” mean? Of course, the term has been known for a long time in the context of building architecture. There, the architect specifies the spatial structure, dimensions, functions, materials, colours, and construction of a building, based on the requirements of its future owners and users, and in accordance with applicable regulations. But even in building architecture, the term ‘architecture’ is not unambiguous. It can signify the art and science of designing the built environment, or the product of such a design. Thus, the term architecture encompasses both the blueprint for a building and the general underlying principles such as its style, as in ‘gothic architecture’. A commonly used definition of architecture in the IT world is the one of the IEEE Standard 1471-2000 (IEEE Computer Society, 2000): Architecture is the fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment, and the principle guiding its design and evolution. More succinctly, we could define architecture as “structure with a vision”. An architecture provides an integrated view of the system being designed or studied. Springer
64
Inf Syst Front (2006) 8:63–66
Fig. 1 Enterprise architecture: Integrating architectural domains
Architecture at the level of an entire organisation is commonly referred to as “enterprise architecture” (EA). It is a coherent whole of principles, methods and models that are used in the design and realisation of the enterprise’s organisational structure, business processes, information systems, and infrastructure. EA captures the essentials of the business, IT and its evolution. The idea is that the essentials are much more stable than the specific solutions that are found for the problems currently at hand. Architecture is therefore helpful in guarding the essentials of the business, while still allowing for maximal flexibility and adaptability. EA provides the “blueprint” for systematically defining an organisation’s current or future environment, coupled with a process for development and maintenance. As a key planning discipline it helps guide and optimise an organisation’s IT investments and translate business strategies into implementable technology solutions. The most important characteristic of an enterprise architecture is that it provides a holistic view on the enterprise. Within restricted domains of expertise that are present in an enterprise, some sort of architectural practice often exists, with varying degrees of maturity. However, due to the heterogeneity of the methods and techniques used to document the architectures, it is very difficult to determine how the different domains are interrelated (Fig. 1). Within individual domains local optimisation will take place and from a reductionist point of view, the architectures within each domain may be optimal. However, this need not lead to a desired situation for the company as a whole. For example, a highly optimised technical infrastructure that offers great performance at low cost might turn out to be too rigid and inflexible if it needs to support highly agile and rapidly changing business processes. A good enterprise architecture provides the insight needed to balance these requirements and facilitates the translation from corporate strategy to daily operations. Architecture is a process as well as a product. The product serves to guide managers in designing business processes and system developers in building applications in a way that is in line with business objectives and policies. The effects of Springer
the process reach further than the mere creation of the architecture product—the awareness of stakeholders with respect to business objectives and information flow will be raised. It is important to realise that most stakeholders of a system are probably not interested in its architecture, but only in the impact of this on their concerns. However, an architect needs to be aware of these concerns and discuss them with the stakeholders, and thus should be able to explain the architecture to all stakeholders involved, who will often have completely different backgrounds. This points to one of the most important roles of an enterprise architecture: it serves as an instrument in the communication among diverse groups and interests and provides a common ground for discussion and decision making.
Why enterprise architecture? It may seem that architecture is something static, confining everything within its rules and boundaries, and hampering innovation. This is not the case. A well-defined architecture is an important asset in positioning new developments within the context of the existing processes, IT systems, and other assets of an organisation, and it helps in identifying necessary changes. Thus, a good architectural practice helps a company innovate and change by providing both stability and flexibility. The insight provided by an enterprise architecture is needed on the one hand in determining the needs and priorities for change from a business perspective, and on the other hand in assessing how the company may benefit from technological innovations. Moreover, in an increasingly networked world, no enterprise can focus solely on its own operations. To get a grip on the wealth of interconnections with its customers, suppliers, and other partners, an enterprise architecture is a valuable asset. Next to the internal drive to effectively execute an organisation’s strategy and optimise its operations, there are also external pressures that push organisations toward adopting an enterprise architecture practice. The regulatory framework increasingly demands that companies and governmental institutions can prove that they have a clear insight into their operations and that they comply with the applicable laws on, e.g., financial transactions. In the US, the Clinger-Cohen Act of 1996 demands that every government agency have an information technology architecture, which is defined as: “an integrated framework for evolving or maintaining existing information technology and acquiring new information technology to achieve the agency’s strategic goals and information resource management goals.” Section 5125(b) of the Act assigns to the Agency Chief Information Officer (CIO) the responsibility of “developing, maintaining, and facilitating the
Inf Syst Front (2006) 8:63–66
implementation of a sound and integrated information technology architecture.” The Basel II capital adequacy framework, endorsed in 2004 by the central bank governors and the heads of bank supervisory authorities in the Group of Ten (G10) countries, imposes strict regulations on banks in terms of risk measurement and management, with wide-ranging implications for both their organisations and their IT systems. Given this wide scope and the detailed requirements on risk management, compliance with Basel II can hardly be envisaged without a sound architectural approach. Another US act, the Sarbanes-Oxley Act of 2002, also has a major impact. This act, formally known as the Public Company Accounting Reform and Investor Protection Act, was drawn up in the aftermath of the Enron scandal, to force companies to adopt good corporate governance practices and to make company executives personally accountable. These accountability regulations make it very important for a company to clearly specify the responsibilities of each employee. IT systems must provide the necessary accounting information to allow the audits required by the Act, and should force their users to have appropriate authorisation. Again, enterprise architecture may be of assistance in providing the necessary insight, and many companies are improving their architecture practice to conform to these regulations. And given that this act applies to all companies that have their stocks quoted on the US stock exchanges, it has a worldwide impact.
Instruments for enterprise architecture The instruments needed for creating and using enterprise architectures are still in their infancy. The perhaps best-known tools are enterprise architecture frameworks, such as the Zachman framework (Sowa and Zachman, 1992) and The Open Group Architecture Framework (TOGAF) (Open Group, 2003). These offer high-level guidance in identifying which areas of business and technology should be considered when creating an enterprise architecture, but they provide little assistance in creating the architectural artefacts themselves. To create an integrated perspective on an enterprise, techniques are needed for describing architectures in a coherent manner and communicating them with all relevant stakeholders. Furthermore, architectures are subject to change, and methods for analysing the effects of these changes are necessary in planning future developments. Often, an enterprise architect has to rely on existing methods and techniques from disparate domains, without being able to create the ‘big picture’ that puts these domains together. This requires an integrated set of methods and techniques for the specification, analysis and communication of enterprise architectures
65
that fulfils the needs of the different types of stakeholders involved. In order to fully benefit from enterprise architecture, different stakeholders need their own appropriate instruments. Managers should be able to use enterprise architecture together with other management instruments in an integrated way. Enterprise architects and domain architects need tools to support the whole architecture lifecycle. Finally, developers need instruments to guide the process from architecture to implementation: not only for the development of IT systems, but also, e.g., of business processes that realise the products of an organisation, and of the technical infrastructure. The papers in this Special Issue address enterprise architecture from the points of view of these different stakeholders, thus making a contribution to the realisation of such instruments.
Papers in this special issue The contributions in this Special Issue cover various aspects of enterprise architecture, ranging from EA as a management instrument, through a comparison of frameworks and design methods, to the application of UML as a notation to represent EA models. Goethals, Snoeck, Lemahieu and Vandenbulcke argue in their paper that doing enterprise architecture should be part of the normal course of doing business in every organisation; it should be embedded in the classic management processes that organizations know. Lindstr¨om, Johnson, Johansson, Ekstedt and Simonsson identify the Chief Information Officer (CIO) of an enterprise as one of the main stakeholders of architectural descriptions. Their article presents the results of a survey in which Swedish CIOs have prioritised their most important concerns and evaluates how well two existing EA frameworks address these concerns. Versteeg and Bouwman discuss the concept of “business architecture”, which they define as the structuring of responsibilities around the most important business activities prior to any further effort to structure individual aspects (processes, data, functions, organization, etc.). The resulting business domains help to clarify the complexity within an organization and form a useful starting point from which the subsequent development of functional, information, process and application architectures can proceed. Potential users of enterprise architecture are faced with a huge number of architecture frameworks and description methods, using seemingly contradicting terminology. In their paper, Greefhorst, Koning and Van Vliet compare existing architecture frameworks, and produce a number of fundamental dimensions that underlie architectural thinking. Given the wide scope of enterprise architecture, the size and scalability of EA models quickly becomes a major Springer
66
Inf Syst Front (2006) 8:63–66
problem. Balabko and Wegmann offer concern-based design methods as a potential solution to this problem, by considering EA models as a composition of smaller, manageable parts—concerns. Although frameworks such as Zachman’s are fairly well established among the practitioners of enterprise architecture, there is no commonly accepted standard for a language to express architectural descriptions in the different cells of these frameworks. UML may be able to cover part of this. Fatolahi and Shams have investigated in which of the cells in the Zachman framework UML models can be used. About the guest editors The guest editors of this special issue are involved in a Dutch applied research project that aims to improve the instruments
Springer
available to enterprise architects. This project, called ArchiMate (see http://archimate.telin.nl), is a cooperation between several partners from business and academia that provides concepts and techniques to support enterprise architects in the visualisation, communication and analysis of integrated architectures.
References IEEE Computer Society. IEEE Recommended Practice for Architectural Description of Software Intensive Systems. IEEE Standard 1471-2000, Oct. 9, 2000. Open Group. The Open Group Architectural Framework Version 8, 2003. http://www.opengroup.org/togaf/. Sowa JF, Zachman JA. Extending and formalizing the framework for information systems architecture. IBM Systems Journal 1992; 31(3):590–616.
