Bekijk Paper.doc

Architecture – the notion and value

extracted and adapted from:“The Value of Architecture for Airline

Alliances”Graduation Thesis - Open University Business School, MBA B826

Robbert A. BoschProject Executive

Business Innovation ServicesIBM Global Services

October 29, 2000

Architecture – the notion and value Robbert BoschLandelijk Architectuur Congres, November 2000 IBM Nederland N.V

Table Of ContentsTABLE OF CONTENTS........................................................................................................................2

1 INTRODUCTION............................................................................................................................3

1.1 ARCHITECTURE TO CRAFT CHANGE – SUMMARY OF THE PAPER................................................31.2 BACKGROUND OF THIS PAPER....................................................................................................31.3 RESEARCH PARADIGM................................................................................................................41.4 STRUCTURE OF THE DOCUMENT.................................................................................................41.5 ACKNOWLEDGEMENTS...............................................................................................................5

2 UNDERSTANDING ARCHITECTURE – A LITERATURE REVIEW...................................6

2.1 DEFINING ARCHITECTURE..........................................................................................................62.2 ARCHITECTURE A TOOL TO “PRESCRIBE”...................................................................................62.3 ARCHITECTURE A TOOL FOR CHANGE........................................................................................62.4 ENTERPRISE ARCHITECTURE BEYOND COMPANY BORDERS.......................................................72.5 ARCHITECTURE CRAFTING BUSINESS AND IT.............................................................................82.6 THE POTENTIAL BENEFITS OF ARCHITECTURE............................................................................92.7 ARCHITECTURE MECHANISMS TOWARDS THE BENEFITS..........................................................10

3 THE VALUE OF ARCHITECTURE - ANALYSIS & CONCLUSION..................................14

3.1 THE PROBLEM OF QUANTIFYING THE BENEFITS.......................................................................143.2 VALUE CREATION - THE MECHANISMS BEHIND THE BENEFITS.................................................143.3 THE VALUE OF ARCHITECTURE – MAIN CONCLUSIONS.............................................................143.4 POSITIONING THIS PAPER..........................................................................................................15

APPENDIX A : RESEARCH METHODOLOGY & PROCESS......................................................16

APPENDIX B : TAXONOMY OF ARCHITECTURE METHODS................................................17

APPENDIX C : ARCHITECTURE ANALOGY – ZONING PLAN...............................................18

Appendix D : References.........................................................................................................................20

document.doc of 23


1 Introduction

1.1 Architecture to craft change – summary of the paper

Adaptiveness to change is what makes species survive (Darwin, 1859). Research shows that also for organizations, the ability to change is one of the most critical factors to ensure long-term survival (de Geus, 1997). This is not strange, as organizations show similarities with organisms (Burns and Stalker, 1961) and they seem to behave as complex social systems (Mitleton-Kelly, 1997). Architecture is the vehicle to facilitate change, which in the survival and adaptation context, gives architecture a much more important meaning for companies, than is often thought to be the case. This paper, which was extracted and adapted from a from a more elaborate management research study (Bosch, 2000), describes how architecture principles and mechanisms are valuable tools to craft change.

The conclusions out of the management research study are promising, meaning that architecture seems to have the potential to contribute substantially to the success of companies, whether these companies are engaging in alliances or other forms of inter-company collaboration or whether they are operating primarily on their own. The main conclusions were the following:

Architecture may help to set the right priorities throughout the whole company, which can (only truly) be achieved, if “developing with architecture” is institutionalised in- and adopted by all layers of the organization, and within both the business- and IT departments. Preferably architecture should be embedded within the existing planning- and control cycles of the company.

Architecture helps actors within- and among companies to discuss, set and measure their joint goals and objectives. A well-documented set of relevant and justified principles helps decision-making, establishing norms and evaluation.

Architecture encourages adopting a view of the wider business system a company is part of. In addition, architecture techniques – such as principles and the distinction between functionality and construction –, can be very useful to help integrating complex business- and IT systems.

If properly institutionalised, architecture will be a vehicle that brings a company’s strategy alive, thus contributing substantially to the company’s success. More importantly, architecture gives companies a common language to collaborate in today’s fast changing – networked – business environment and eventually the agility to survive.

1.2 Background of this paperThis paper has been composed for the Annual Architecture Conference, 2000 of The Netherlands (Landelijke Architectuur Congres, November 23 & 24, 2000). The content of the paper was extracted and adapted from a more elaborate report describing the results of a management research study, which was conducted by the author for MBA graduation (Bosch, 2000). The subject of this management research study, “The Value of Architecture for Airline Alliances”, came from KLM Royal Dutch Airlines, an airline actively engaged in alliances and architecture.

document.doc of 23


To meet the requirements of the Annual Architecture Conference in terms of subject and paper-length, the (airline) alliance specific elements of the research report, have not been included in this paper.

1.3 Research paradigmAlthough architecture may sound as a straightforward somewhat technical topic, at least the following aspects adjust that view:

Immaturity of the architecture disciplineThe research study confirmed that architecture in business and IT, is still quite immature. Companies are using architecture for direct cost-benefits whereas the real benefits are to be obtained from greater organizational effectiveness and agility (with a longer time-horizon). It is therefore questionable whether these companies are practicing architecture in the best optimal way.

The inherent complexity of organizationsIntensified by the immaturity of the discipline, the way architecture is embraced relies on the company using it, and the extent to which architecture is imbedded in the company. The fact that all organizations differ and may be compared with complex social systems similar to organisms (Burns and Stalker, 1961, Mitleton-Kelly, 1997), makes the concept of architecture a weakly defined notion, open to different interpretations.

Above aspects have set the research study in a so-called phenomological or interpretative paradigm, meaning that as long as architecture is not unambiguously defined, it should be treated as a phenomenon in the social world of organizations.

A description of the research methodology and process is included in appendix A.

1.4 Structure of the document This paper comprises of two main sections and four appendices. Understanding architecture – a literature reviewThe largest part of this document is a literature review about the “essentials” of architecture, such as its role in facilitating change, its significance within business and IT and its potential enterprise-wide scope. Then it continues to discuss the potential benefits of architecture and the mechanisms by which architecture generates these benefits.

The value of architecture – analysis & conclusionAfter the literature review, an analysis of the architectural mechanisms behind value creation is given, the main findings are summarized and the paper and the underlying study are positioned within a broader potential area of research.

Appendices, including reference to documentationAt the back of the document a series of appendices has been added. Appendix A describes the research methodology and process. Appendix B describes a classification framework (“taxonomy”) for architectures, which was developed as part of the research study. Appendix C applies the taxonomy to the field of developing cities and countries. The document ends with a full list of references to the documentation used (Appendix D).

document.doc of 23


1.5 AcknowledgementsThis paper – largely based on the results of a wider MBA Management Research Project – wouldn’t have been realized without the contribution and support of various people. Apart from the authors of the publications listed in the reference list at the back of this document, the following people deserve acknowledgement for their contributions:

Lotje Bosch-Driessen, Kees and Toon – my family Jan Hoogervorst, Edwin Borst, Pieter Janssen – KLM CIODenis Hageman, Ben Heideveld – ABN/AMRO Enterprise ArchitectureHans Loeve, FORTIS Enterprise Business Process ConsultantDries Driessen – Philips Corporate ITCarol Ann, Mark Jepson, Heidi Hasz, Joes Kloos, Mark Berkhoff – IBM Architecture Practice Jonathan Miller – IBM Business Intelligence

document.doc of 23


2 Understanding architecture – a literature review

This part of the research explores – mainly from existing sources –, what “architecture” actually is, what it does and what its merits are. After this section, an analysis about value creation follows in section 3 (The value of architecture - analysis & conclusion on page 14). The current section, reviews the literature on architecture studied.

The main sources to answer this particular part of the research were a Nolan Norton study (van der Zee et al., 2000), several papers and articles on architecture, and a number of Internet sites. In addition, various internal publications, presentations and memos were reviewed from IBM, KLM, and ABN/AMRO. A complete overview of materials used, is given in Appendix D : References on page 21.

2.1 Defining ArchitectureAt least one thing about architecture, for business and IT, appears to be consistent. This is the lack of consistency in definitions, which is widely recognized within the literature about architecture (Computable, 2000, IBM, 1999c, Annual Architecture Conference, 2000, Dietz, 1999). Different authors tend to describe in different ways what architecture is and does. Some describe architecture as a vision on a company’s current and future situation (Computable, 2000), some describe what architecture does; “giving context and focus to the development process” (Dietz, 1999). Others include in their definition what architecture consists of: “a logically consistent set of principles and high-level design” (META Group, 1999a).

2.2 Architecture a tool to “prescribe”Although not always explicitly stated in the literature, an important distinction can be made between architecture describing an object or a situation, or architecture prescribing the way things should be done. The dictionary gives some definitions of architecture that fall in the category of describing something, such as “style of a building” or “construction”, but also a definition that falls in the other category (prescribing) which reads “the art of building edifices or constructions of any kind” (Concise English Dictionary). This study focuses on the second category; architecture prescribing the way things should be done. The former category is less relevant in business and IT; just describing something lacks a purpose. In contrast, ”architecture that prescribes” is intrinsically purposeful as illustrated by Dietz, who states that “architecture is a deliberate restriction of design freedom, enforced for particular purposes” (Dietz, 1999). (How restriction of design freedom adds value will be explained later on in this document in the section Deliberate limitation of choices reduces complexity on page 12).

2.3 Architecture a tool for changeA company doesn't need architecture if its business or IT operations never change. Most literature on architecture confirms that it is meant to facilitate change (van der Zee, 2000, META Group 1999b, ABN/AMRO, 2000). The Nolan Norton study emphasises that the real value of architecture is that it is a tool for continuous change (van der Zee, 2000). The diagram bellow illustrates, in concept, how architecture guides change, triggered by reasons for change; either in the company’s business and IT environment (“the operation”), or in the external environment.

document.doc of 23


Figure 1 : Architecture in its business context

Note to the diagram: It could be argued that the transformation processes distinguished in above diagram, are not correct or complete, and that perhaps a “Development process” is missing between the “Design process” and “Implementation”. Dietz (1999), for instance, uses an architecture model with four what he calls “activity kinds”; Architecturing, Development, Implementation and Operations & Maintenance. In above diagram the development processes/activities may be considered to be part of the Design process; or development activities are both part of Design and Implementation. For the purpose of the overall research question, however, the precise placement of the development activities doesn’t matter too much, and various models may be equally valid.

2.4 Enterprise Architecture beyond company borders

The term “Enterprise Architecture” is often used to denote something that “guides the deployment and management of all I/T assets of an organization, in support of its business objectives” (IBM, 1999c). Taking it one step further, the Enterprise Architecture also helps to “shape the way business is conducted“ (META Group, 1999b). In an internal memo about Architectures, IBM distinguishes explicitly between “Enterprise-wide IT1 Architecture” and “System Level IT Architecture” (IBM, 1999c). A “System Level Architecture” generally deals with a single function with its supporting information technology, whereas an Enterprise Architecture addresses the full portfolio of functions, processes, applications and technologies that support a company in its business.

The diagram below illustrates that architecture can be applied to different levels of analysis. This study uses the term Function to indicate a sub-system of any kind. Functions can be, for instance, business processes, computer-applications, computer-networks, organizational departments, or any combination. The term Company is used to indicate the complex of interrelated Functions within a company from a company-internal viewpoint. Beyond-Company indicates that also the systems in the company’s external environment are considered, as far as these affect the performance of the company.

1 The memo was written before IBM extended its architecture scope to Business Architecture, and therefore refers to “IT Architecture” instead of just “Architecture”.

document.doc of 23


Figure 2 : The Architecture scope determines the level of analysis

Enterprise Architecture, as used throughout this study, adopts a Company scope or even a Beyond-Company scope. Viewing the company’s environment as a system, the Company scope looks at the Company System and the Beyond-Company scope looks at what could be called the company’s Business System. The diagram below shows a simplified representation of these systems.

Figure 3 : the Company (System) within its Business System

2.5 Architecture crafting business and IT There is a growing recognition that architecture should be applied to the fields of business and IT, rather than IT only. In companies, architecture started within IT departments (van der Zee et al., 2000). Therefore the focus in the early days was on the architecture of the IT assets and resources. Meanwhile, for the past ten

document.doc of 23


years, Business Process Reengineering (BPR) has demonstrated the benefits of a clear business process architecture, but alignment with IT was poor (van der Zee, 2000). Then followed the recognition that Business/IT-alignment was crucial, where it was assumed that IT needed to follow the business. Examples of this are IBM’s former Information Technology Architecture (“ITA” IBM, 1999c) and META Group’s Enterprise-wide Technical Architecture (“EWTA” META Group, 1999a). Nowadays, more and more architectures include business architecture, rather than just translating business requirements into IT. The fast technological developments that have created new business opportunities have driven IT to not only support, but also to “enable” the business. This is why authors like Dietz (1999) argue, that appropriate alignment needs to be bi-directional (see the diagram below).

Figure 4 : Architecture from IT-focused to Business/IT-aligned

2.6 The potential benefits of architectureSummarizing the literature studied, architecture can bring value in the following three generic areas:

1. Cost-saving : Cost reduction2. Agility : Ability to change (time-to-market, adaptiveness)3. Effectiveness : for stakeholders

2.6.1 Many companies use architecture to reduce IT costsThe main reason, today, for companies embracing architecture is that their IT costs have increased dramatically. Reasons for this include, for example, the need to manage their decentralized technical infrastructures. Gaining control and reducing costs are therefore important arguments for “developing with architecture”. Quantifying the precise benefits, however, appears to be difficult (van der Zee, 2000).

2.6.2 Architecture is a tactical tool to balance control and agility

An important benefit of an architecture is that it typically enables a measurable reduction in costs to be brought about. However, the real value of architecture is that it is an investment in management and control, which eventually leads to

document.doc of 23


better cost control measures, increased effectiveness of operations, and greater flexibility. The problem with quantifying (all) the benefits of architecture, is that the role of architecture is typically tactical, and investments in architecture, therefore are neither strategic nor operational. The diagram below shows where architecture fits within the company’s strategic-, tactical- and operational processes (the pyramid is a commonly used symbol for this, expressing that at the strategic level fewer decisions are taken than at the tactical and operational levels, but that strategic decisions guide and influence the lower levels, etc.).

Figure 5 : Positioning architecture as a tactical management tool

Above diagram uses a drawing from the Nolan Norton study. The authors argue that architecture should be used to define projects that help a company to move towards the desired situation, but also to assess projects for their contribution to the desired situation. The results of the projects can be evaluated against the principles of the architecture. If appropriate this evaluation may also lead to adjustment of the principles (van der Zee et al., 2000).

Architecture balances flexibility and controlArchitecture is to be seen as an investment in professional management, maintaining balance between freedom and control. This eventually leads to structurally better cost-control, increased effectiveness of the company, and greater agility (adaptiveness to change).

2.7 Architecture mechanisms towards the benefitsThis section discusses how the fundamental elements and concepts of architecture work in daily practice and eventually contribute to value.

2.7.1 Principles facilitate change, decisions and communication

Architecture helps to define and maintain the principles that are to be used in the design and implementation of changes in a company's business and IT operations. An example of a high-level IT-related principle could be; prescribing that a

document.doc of 23


company’s Internet infrastructure needs to be capable to cope with extensive growth in on-line customer transactions.

Structured documentation prevents the need to “re-invent the wheel”To facilitate usage, principles need to be stored in such a way that the people who are to use them or the people who are responsible for their adaptation can retrieve them easily. This also prevents earlier decisions and agreements being ignored or overruled without proper consideration (van der Zee et al., 2000). An efficient architecture is also “event-driven” (van der Zee et al., 2000), which means that principles are only added, removed or adapted if there is a reason to do so. Reasons can be, for instance, issues occurring in the business or IT operations, technological advancements or business opportunities in the industry, such as new ways of trade via the Internet.

Principles facilitate decision-making and communication:To pursue successful change, it is essential that the responsible process owners and business managers of the target operation are involved in the decision process, that the changes are clearly communicated to the people who are impacted, and that the engineers understand what they need to develop, and which guidelines they have to follow (Schekkerman, 2000a, van der Zee et al., 2000). Principles are the vehicle by which to document and communicate what needs to be changed and how. In addition, the considerations behind the principles are equally important (Tapscott, 1996). The diagram below shows in concept how principles cover all relevant domains.

Figure 6 : Principles throughout the architecture domains

In this example, the domains of the Nolan Norton study (van der Zee et al., 2000) have been copied, but the original diagram of the study showed Principles, Parameters and Models, whereas this diagram focuses on “why?”, “what?” and “how?”. For this research, Parameters and Models are not considered as being separate from Principles. Instead, Parameters are rather seen as specific2 forms of Principles, and Models are simply a way of clarifying the way in which complex Principles are presented.

2 Principles may be grouped in a tree- or network structure. Very specific (detailed) principles should be SMART (Specific, Measurable, Achievable, Relevant, Timed). An example would be a call centre in which the agents must pick up the phone after a maximum of three rings.

document.doc of 23


2.7.2 Deliberate limitation of choices reduces complexity A good Architecture deliberately limits the number of choices that do not add value (van der Zee et al., 2000). This leads to a reduction in the number of different components in a company’s business and IT operations. This reduces complexity, which is an important objective of architecture (van der Zee et al., 2000). Focusing on the functionality of a component and buying it instead of building it, may reduce the complexity even more, as it removes the need to bother about the construction.

An example of buying components instead of building them, is a situation where a company outsources its employee company-car facilities to a specialized leasing-company. The car-facilities operation may be considered as a high-level component whose functionality (and not the construction) is the primary consideration to the “buying” company and its employees. In the same example, the company may want to save costs, by limiting the employees’ choice of cars. The cost savings then need to be outweighed with the benefits. Limiting the selection of cars too much, may have an adverse effect on employee motivation.

2.7.3 Focus on functionality brings clarity and effectivenessSome architecture methods recommend distinguishing between functionality and construction in designs of products, information systems, organizations, etc. (Dietz et al., 1999, van der Zee, 2000). An explicit focus on functionality avoids unnecessary construction design detail which, if included, can overcomplicate matters. An example of this would be the driver of a car, who needs to know how to drive the car (i.e. the functionality of the car), but doesn’t need to know how the engine (the construction) works (see diagram below). The reduction of complexity also facilitates decision-making and communication.

Another advantage of focusing on the functionality is that it prompts the people, who develop and use the architecture, to put themselves in the position of the end-user of the systems that are to be implemented or adapted. The Nolan Norton study proposes the use of a product/service architecture in which the value of the customer is the central focus (van der Zee et al., 2000). This overall focus on the customer conforms with marketing theories of the past two decades, as David Ford said: “No customers, no business – no business, no job!” (Ford et al., 1998). The distinction between functionality and construction also fits Kotler’s generally accepted product-marketing concept of benefits and features (Kotler, 1984). Similar to functionality, benefits are the solutions to the customer’s problems, requirements or desires. In terms of their customer benefits, products or services are not necessarily delivered by one company alone. An example of this is a car, of which the value for its driver lies with the benefits of the physical car, augmented with the service from the dealer. The diagram below, illustrates the example.

document.doc of 23


Figure 7 : The customer pays for the functionality, not for the construction

Customers are important, but they are not the only stakeholders. Schekkerman (2000b) states that architectures need to embrace the views of the main stakeholders. This means that apart from creating a product/service view for customers, additional views may be required for the company’s key suppliers, the shareholders, the company’s corporate management, etc. Similar to the proposed product/service view, these additional views are again architectures that encourage thinking beyond the company’s borders.

2.7.4 Architecture for agility, effectiveness and cost controlThe intermediate benefits of architecture – communication, decision-making, reduction of complexity and focus on end-users -, eventually lead to improved agility, effectiveness and structural cost-savings. How this works, will be explained later in this paper (see The value of architecture - analysis & conclusion on page 14).

document.doc of 23


3 The value of architecture - analysis & conclusion

3.1 The problem of quantifying the benefits In section 2.6 (The potential benefits of architecture on page 9) it has been established that companies especially embrace architecture to reduce IT costs and to gain control over their decentral technical infrastructures. It has also been discussed that the real value of architecture is to be seen as an investment in management and control, which eventually leads to structurally better cost-control, increased effectiveness of operations, and greater flexibility (or agility). Measuring the benefits of architecture, and especially quantifying those benefits appears, however, to be difficult (van der Zee et al., 2000).

Similar to measuring the benefits of a quality management system, the discussion about the costs and benefits of architecture tends to remain rather conceptual (van der Zee et al., 2000), unless examples of (potential) architecture-usage/application3 are investigated.

3.2 Value creation - the mechanisms behind the benefits

Exploring how architecture creates value, it may be necessary to take one step back, and review how in concept architecture contributes to the three earlier mentioned categories: cost saving, agility and effectiveness (see The potential benefits of architecture on page 9). Insight in these concepts should reveal the why and how behind the value of architecture.

3.2.1.1Principles as the vehicle for decision making and changeIn the literature review, architecture has been defined as a management tool for guiding change, which makes use of a logically consistent set of principles, which are used in engineering the actual changes (see Architecture a tool for change on page 6). These principles are the vehicle by which to communicate what needs to be changed and how. Documenting the what and the how is not sufficient. It is especially the why that makes these principles valuable for decision making and adaptation (see Principles facilitate change, decisions and communication on page 10).

3.2.1.2End-user functionality enables to cross bordersThe literature review also showed that focusing on functionality rather than construction, is a technique that lends itself for the adoption of an end-user view (see Focus on functionality brings clarity and effectiveness on page 12). Again, the principles are the vehicle to ensure that such an end-user view can be shared and discussed. The product/service architecture proposed by the Nolan Norton study can be adopted to produce a customer view and reduce the potential bias from an internal company view. This corresponds with what the Nolan Norton study suggests, i.e. that the starting point for a product/service architecture should be the value for the customer and not the internal view of the customer (van der Zee et al., 2000). In an inter-company situation, the product/service architecture leads the process architecture and the organization architecture (see also Enterprise Architecture beyond company borders on page 7).

3 The initial report applied architecture to airline alliances to demonstrate value creation.

document.doc of 23


3.3 The value of architecture – main conclusionsThe research and analysis demonstrate that architecture is even more important for companies, than was assumed at the beginning of the management research study. The following are general conclusions from the analysis: Architecture is a management tool for continuous change. To obtain real value

from it, architecture needs to be practiced throughout the whole organization at all management levels. Principles are the key vehicles of architecture. Principles are formulated, justified and documented by decision-makers throughout the organization and guide the development of the company’s business and IT. The management of these principles is what architecture is about.

Architecture is to be seen as a tactical instrument, to bridge the gap between the strategy and the realization of the strategy. By the use of guiding principles and an essentially event-driven approach, architecture facilitates the implementation of strategy. Defining a bi-directional (between business- and IT) update-process within an architecture-governance model, ensures the continuous alignment between business- and IT requirements.

Architecture techniques can be used to guide the design and development of a single function – for instance, a business process or an information system –, but the real value lies in practicing architecture at the enterprise-wide level.

3.4 Positioning this paperAs mentioned before, this paper is largely based on an earlier conducted management research study, which focused on identifying how architecture could contribute to the success of airline alliances (Bosch, 2000). The application of architecture mechanisms to alliance success factors proved to be an interesting but complex area of research.

More generally, the study demonstrated that also for companies less occupied with inter-company collaboration, architecture could be a powerful instrument to set the right priorities throughout the whole organization. To institutionalise this, the Nolan Norton study recommends to link “development with architecture” to the existing planning- and control cycles within the company (van der Zee et al., 2000).

This paper shows that formulating principles, and adopting the habit and discipline to justify, document and update them consistently in the daily management practice, are essentially very simple activities but they require reflection instead of (immediate) action.

Although not pretending to be complete, the elements and mechanisms described within this paper demonstrate that these essentially very simple activities have the power to substantially contribute to a company’s ability to change, and thus to its success and survival.

document.doc of 23


Appendix A : Research methodology & process

Because architecture lacks a solid definition, it was decided to explore the various approaches towards architecture. This corresponds with a research approach known as the “Grounded theory” method (Hussey and Hussey, 1997) Grounded theory “build theory that is faithful to and which illuminates the area under investigation” to come to theory which is “likely to be intelligible to, and usable by, those in the situation being studied, and is open to comment and correction by them” (Turner, 1981 in Hussey and Hussey, 1997). The research for this study didn’t really involve the people in the situation under study but similarly to grounded theory aimed to build theory “intelligible and usable” for the wider professional group of people who practice architecture. Also the study took an “inductive/deductive approach and […] constant reference to the data which helps ground the theory.” The research process undertaken can be described as follows:

3.4.1 Initial exploration of the research area:In this phase IBM and KLM literature was consulted and Internet searches were performed, searching for “architecture” and “enterprise architecture”. The topic was also discussed with a small number of people, among which the client sponsor and IBM architects.This initial exploration revealed certain recurring themes, such as Business/IT-alignment, the move towards enterprise-wide application, and organizational boundaries.

3.4.2 Reflection on themes and producing a taxonomyReflection on the recurring themes and verification by applying the concepts with “everyday” examples, such as cars, houses, revealed that the themes could be grouped in different classes or dimensions, which led to produce a preliminary taxonomy of architecture methods. Reflection and testing with examples was repeated until the taxonomy-framework seemed robust enough to bear the examples (see Appendix B : Taxonomy of Architecture Methods).

3.4.3 Testing the taxonomy with a full “brick and mortar” case

To test the taxonomy, a zoning plan analogy was applied to all dimensions of the framework. After that two of the architecture methods under study, Nolan Norton’s (van der Zee, 2000) and IBM’s Enterprise Architecture (IBM, 1999a,b,c,d) were assessed against the taxonomy. This proved to be difficult, as the information on the methods was not necessarily complete. Worse, but inherent to the “grounded theory” method, the assessment criteria were still to be established. It was decided to leave this out of the scope, because establishing these criteria seemed not especially useful for the basic research question.

3.4.4 Exploring the mechanisms behind value contributionBased on the tested and adapted taxonomy the basic mechanisms of architecture were studied, investigating how these mechanisms led to value. This process of exploration went as follows: From the literature and unstructured interviews with architecture

practitioners, three “generic benefits” were established; agility, effectiveness and cost reduction

During search for “generic benefits”, also what could be called “mechanisms” or “intermediate benefits” were identified, such as communication and reduction of complexity.

document.doc of 23


Then it was analysed how the basic elements identified in the taxonomy supported the “mechanisms” and eventually led to the “generic benefits”.

3.4.5 Application of the architecture mechanisms In the initial study architecture characteristics were applied to the success- and fail factors of alliances, in particular airline alliances. For reasons already mentioned in the introduction, this alliance specific part was not included in this paper.

document.doc of 23


Appendix B : Taxonomy of Architecture MethodsAn approach for classification of architecture methods could be to use the following three dimensions:

Dimension 1 : System Scope:The architecture scope can vary from a single Function (or sub-system) to an Company, which is a System in which multiple Functions operate. The scope can even be wider, crossing the boundaries of the Company. In the latter case the scope is “Beyond-Company”.

Dimension 2 : Business/IT Orientation: Many architecture methods focus on Information Technology, others are especially Business oriented. Some architecture methods recognize the need to cover both IT and Business and the alignment between these domains.

Dimension 3 : Method Elements: Apart from their scope and orientation, architecture methods consist of elements, which may vary across methods. Categories of elements are the Architecture Construct (the core elements of the architecture), the Architecture Process (of developing and maintaining the architecture), the Architecture Governance (by which architecture is imbedded in the Enterprise’s processes), and the Architecture Capabilities.

The diagram below illustrates the three dimensions as separate axes for classification.

Figure 8 : Taxonomy framework for classifying architecture methods

The dimensions together can be considered as a framework against which architectures can be positioned.

document.doc of 23


Appendix C : Architecture Analogy – Zoning Plan An analogy with a zoning plan has been chosen for the following main reasons: 1. Architecture is often compared with the architecture of a building (IBM, 1999c,

Computable, 2000), but a zoning plan seems a better analogy for Enterprise Architecture (Schekkerman, 2000a).

2. To verify whether the proposed taxonomy would hold in a well established field (triangulation of disciplines/application fields)

Below for each of the three dimensions of the taxonomy, the analogy with a zoning plan has been elaborated.

Dimension 1 : System Scope – the geographic boundary

A zoning plan at a Function level addresses, for instance, the introduction of a new shopping centre or an extension of a city-wide sewerage system.

An analogy for the Company in the field of zoning plans, could be a city or a country. A zoning plan at city level needs to address the development of housing estates, shopping centres, connecting roads, electricity and television supply, a police system, etc… A country level zoning plan needs to plan for railroads, highways, airports, customs, etc…

A Beyond-Company scope would involve facilities and laws that supersede the country borders. Examples are trade agreements, international rail connections, international law, standardization committees, military collaboration and international aid. Countries give up part of their autonomy and conform to joint regulations to get advantages from acting together, in return. In the same way organizations decide to submit themselves to standards by alliance committees they form. Conformance to serve the collective and individual interest

Dimension 2 : Business/IT- orientation – function & infrastructure

An analogy for IT-orientation in the field of zoning planning, is the practice of developing, for instance, a city-infrastructure, including roads, electricity, a sewer system, etc.; all this based on an existing zoning plan.

A Business-oriented zoning plan would then focus on the functional requirements of a city, country or (international) society, such as living, working and leisure. If the zoning plan would be Business-oriented only, this would be like trying to implement functional requirements without considering the implications for the city-infrastructure in advance.

In this analogy, Business/IT-alignment would mean that the city-, country- or international functions and the underlying infrastructure are designed in a concerted manner, and that requirements and implications from function to infrastructure (and vice versa) are interchanged. Furthermore, a successful zoning plan needs to anticipate future functional requirements and infrastructural possibilities over a reasonable time-period.

Dimension 3 : Method Elements – ingredients of a living zoning plan

document.doc of 23


The Construct of a zoning plan comprises functional Principles, for instance, that the city should be a popular place to be for international tourists, and infrastructural principles, such as that parking cars should be easy for residentials as well as non-residentials. These Principles are translated into Parameters. Some parameters are given by law, such as the minimum road-width to give the fire brigade way. Parameters can also be derived from functional requirements. An example of such a parameter would be the number of parking places per resident and/or per shop, appropriate for a popular tourist centre. The Models of the zoning plan are the designs and calculations that guide construction, based on the principles and parameters. Domains within a zoning plan are among others the commercial plan, the building plan (of buildings and roads), and the infrastructure plans (for the electricity system, the sewerage system, etc.).

Note: When this taxonomy was created, Parameters and Models were also considered to be essential parts of the Architecture Construct. By the time of finishing the studies, especially the Principles were considered to be important and Parameters and Models were just seen as specific types of Principles (for details, see the discussion in the Literature Review on Architecture).

The (Architecture) Process for a zoning plan is the process along which the development of the city or country takes place

In this analogy the (Architecture) Governance is to ensure the use of the zoning plan for all substantial changes (Systems Thinking – if an element is added or removed, the system changes). Building-rules and regulations need to be accessible by the public. This can be achieved by publication of these rules in, for instance, city-guides or on the Internet, and by maintaining knowledge about these rules with the city-planning service desk of the city hall.

It will be obvious that various Capabilities are required to sensibly develop the environment within which people live and work (the target-field of zoning plans). Plans for change need to be linked to what is to be achieved. If a country wants to develop its international commercial activity, it needs people with functional knowledge about economics, business, airport-regulations, and much more. Also required are people who know how to design and construct infrastructures, such as roads, electricity supply, transportation systems etc. Last but not least architecture capabilities are required to realize new developments in a structured way (from principles to implementation).

document.doc of 23


Appendix D : References

Bemelmans, T.M.A., de Bra, P.M.E., Looijen, M., van Oortmerssen, G. (1999) ICT-zakboekje, informatie- en communicatietechnologie, Koninklijke PBNA b.v., Arnhem.

Burns, T. and Stalker, G.M. (1961) ‘The Management of Innovation’ in The Open University (1994) B751 Managing Development and Change, Unit 3, Managing and Learning.

Concise English Dictionary ; Hayward, A. (1982), Omega Books Ltd., Hertfordshire, England.

Darwin, C. (1859) The Origin Of Species, Reprinted in Penguin Classics, 1985, Clays Ltd. St Ives plc, England

Dietz, J., Mallens, P., Goedvolk, H, Rijsenbrij, D. (1999) A Conceptual Framework for the Continuous Alignment of Business and ICT, Whitepaper Technical University Delft & Cap Gemini (December 1999).

Ford, D. et al. (1998) Managing Business Relationships, John Wiley & Sons Ltd.

de Geus, A. (1997) The Living Company, Habits for survival in a turbulent environment, Longview Publishing Ltd.

Grant, R.M. (1995) Contemporary Strategy Analysis: concepts, techniques, applications, 3rd edn, Blackwell, Oxford.

Hussey J., Hussey R. (1997) Business Research, A practical guide for undergraduate and postgraduate students, MacMillan Press Ltd., London.

META Group (1999b) Enterprise Architecture Strategies, Architecting for a Business Value Discipline, Willie Appel, November 12, 1999.

META Group Practice (2000) Enterprise Architecture Strategies, Architecture Capability Assessment, Volume 4, Number 7, August 2000.

Mitleton-Kelly, E. (1997) Research Abstract: Business Process Analysis Theme: Complex Adaptive Systems in an Organisational Context, “Organisations as Co-evolving Complex Adaptive Systems”, Business Process Resource Centre, http://bprc.warwick.ac.uk/bam6.html

Schekkerman, J (2000a) Ketenintegratie em de rol van Architectuur, Cap Gemini Ernst & Young, June 29, 2000.

Schekkerman, J (2000b) Architecture Score Card, Cap Gemini Ernst & Young, August 10, 2000.

Sloan A.P. (1963) My Years with General Motors, Doubleday, New York in The Open University (1996) B820 MBA Strategy, Book 10, Corporate Strategy.

The Open University (1994a) B600 The Capable Manager, Book 9, Operations and Marketing.

The Open University (1994b) B751 Managing Development and Change, Unit 8, Charting Change.

document.doc of 23

http://bprc.warwick.ac.uk/bam6.html


The Open University (1994c) B751 Managing Development and Change, Unit 3, Managing and Learning.

The Open University (1995a) B752 Managing Resources for the Market, Block 1, Introduction: Resourcing the Manager.

The Open University (1995b) B752 Managing Resources for the Market, Block 2, Marketing I: Managing the Marketing Function.

The Open University (1995c) B752 Managing Resources for the Market, Block 7, Marketing II: Managing the Market.

The Open University (1996a) B820 MBA Strategy, Book 4, Competing with Capabilities.

The Open University (1996b) B820 MBA Strategy, Book 10, Corporate Strategy.

van der Zee, H., Laagland, P., Hafkenscheid, B. et al. (2000), Architectuur als managementinstrument, Multi Client Study, “Beheersing en besturing van complexiteit in het netwerktijdperk”, Nolan, Norton & Co., ten Hagen & Stam Uitgevers, Den Haag

Internal and/or informal publications:

ABN/AMRO (1999) CITA Explained, ABN/AMRO-internal booklet, providing an introduction to their Corporate Information Technology Architecture (CITA) project

ABN/AMRO (2000) CITA Method Explained, ABN/AMRO-internal booklet, explaining their Corporate Information Technology Architecture (CITA) method

Annual Architecture Conference (2000) Internet site announcing and facilitation the Dutch Annual Architecture Conference (“Landelijke Architectuur Congres 2000”) November 23-24, Amsterdam, http://www.architecture-forum.org

Bosch, R.A. (2000) The Value of Architecture for Airline Alliances, Management Research Project, Graduation Thesis for MBA study (BYM826) at Open University UK; study conducted for KLM Royal Dutch Airlines.

Computable (2000), Architectuur als bestemmingsplan, June 23, 2000, p41.

IBM (1999a) Enterprise Architecture, EA Method Overview and Positioning, IBM Global Services, September 1999, (Internal Foil Presentation by Carol Ann, Architecture Practice Leader, IBM EMEA Region North)

IBM (1999b) Enterprise Architecture Method Class, Enterprise Capabilities Overview, IBM Global Services, September 1999, (Internal Foil Presentation by Carol Ann, Architecture Practice Leader, IBM EMEA Region North)

IBM (1999c) IT Architecture – throwing the light on some of the confusion, Introduction to IBM internal online forum discussion, Carol Ann, March 5, 1999.

IBM (1999d) Enterprise Architecture (EA) Method Announcement, IBM internal online announcement of EA, Carol Ann, October 25, 1999.

KLM (2000) Conceptual Architecture and Technical Domain Framework, KLM Corporate Information Office, August 1, 2000 (Internal Document by Hans Zwitser and Norbert Stam).

document.doc of 23


META Group (1999a) Definition and Principles of META Group’s Enterprise-wide Technical Architecture in presentation used within KLM, June 1999.

document.doc of 23

Bekijk Paper.doc

Education

Transcript of Bekijk Paper.doc