Business Architecture: A New Paradigm To Relate Business .
Inf Syst Front (2006) 8:91–102DOI 10.1007/s10796-006-7973-zBusiness architecture: A new paradigm to relate businessstrategy to ICTGerrit Versteeg · Harry BouwmanC Springer Science Business Media, LLC 2006 Abstract In this paper we address the concept of business architecture. We explain the concept and, based on a case study,discuss its relevance, operation, relationship with strategyand business models, and value for an organization. We alsoshortly discuss the approach that was taken to create the business architecture; how it was based on and derived from thebusiness strategy. Business architectures contribute to clarify the complexity within an organization and form a usefulstarting point from which to develop subsequent functional,information, process and application architectures. We clarify these relationships through an architecture linkage model.Having an explicit business architecture also helps to structure the responsibilities within an organization, and to shapeoutsourcing activities, within the primary process as well aswith regard to ICT-support. Business architectures contributeto an adequate ICT-governance in order to orchestrate theresources for critical business activities and how to managethe development and support for e-business efficiently.Keywords Business architecture . e-business . Informationsystems . Shared service centers . Architecture linkagemodel . Architecture framework . Demand organization .Outsourcing . Business strategyG. Versteeg ( )FourPoints Intelligence, Planetenbaan 114, 3606 AK Maarssen,The Netherlandse-mail: Gerrit.Versteeg@FourPoints.nlH. BouwmanInformation and Communication Technology,Faculty of Technology, Policy, and Management,Delft University of Technology,PO Box 5015, 2600 GA Delft, The Netherlandse-mail: harryb@tbm.tudelft.nl1. IntroductionOrganizations are hampered in their response to changes inthe environment due to the existence of organizational stovepipes and legacy systems. There are many reasons why thetendency to think in terms of architectures showed a markedincrease in the period when the Internet emerged as a disruptive technology. The Internet makes a number of new business models possible (Timmers, 1999; Bouwman and Vanden Ham, 2003). The limited life span of these models implicates that organization, information and IT have to be flexiblein order to respond quickly to changing circumstances andto adapt the business model if necessary. Business strategiesthat utilize the possibilities offered by Internet and ICT tothe fullest are hard to implement however. A critical assessment of the internal processes in many organizations showsa substantial level of redundancy and rigidity, while businessprocesses are usually organized in (often product-oriented)stove-pipes (Van Diepen, 2000). Due to this rigid organization, companies are unable to meet customer demands,coordinate processes and offer the painfully needed transparency. This leads to the redesign of processes (Hammer andChampy, 1993). Due to the failing connection between thenew customer-oriented business processes and informationand the existing rigid product-oriented processes and information, companies find it extremely difficult or impossibleto implement Customer Relationship Management (CRM).In combination with path dependencies, current (legacy)information systems often make it hard to realize changesin the business processes. Companies are limited in their response to changing market circumstances caused by a lackof flexibility and adaptability. It is often a slow and difficultprocess to translate adaptations in the strategy to the ICTdomain (Maes et al., 2000). Strategic considerations therefore force us to break open information systems and reduceSpringer
92Inf Syst Front (2006) 8:91–102their complexity, using a more modular approach. However,such an approach affects the way these modules (for instanceweb services) are defined, combined and/or reused, as wellas their scalability and the extent to which they can be used ina distributed environment (Turban, McLean and Wetherbe,2002). We believe that business architectures are importanttools in dealing with the issues above.In recent years there is an increasing interest in business, information and technical architectures, albeit withouta common and clear definition of the architecture-concept.Business architecture receives the least attention, which inour view is unjustified as it can play a significant role intranslating the business strategy to the ICT-domain as wellas to the design of the organization. We often see that whenarchitectures are considered attention is mainly focused onthe information and technical architecture, while hardly anyattempt is made to establish a connection between businessand ICT-architectures. Therefore, the central questions in thispaper are: (1) what is meant by the concept of business architecture, (2) what are the required elements of a businessarchitecture model, (3) what are the advantages and the practical use of such a model, and (4) how can a model for abusiness architecture be developed in a concrete case.To answer these questions we will start by discussing theconcept in more detail, elaborate on insights provided bytheory and present our model. Next we will analyze the modelin a case study focusing on the usability of the model, and endby reflecting on the proposed model and the case. This articlepresents our view on the concept of business architecture andpositions it in relation to other architectures. Although we dopresent a case description to illustrate the use of the concept,it is not possible to present the case-study in every detail, dueto confidentiality and size limitations.2. The concept of business architectureAlthough the term “Business Architecture” is used in numerous publications, the concept is not defined unambiguously.The concept is used within modeling approaches (IEEE1471, ISO 15704, Rensburg, 1997), in classification frameworks (Zachman, 1987; Mathora, 1996), or used by softwaresuppliers or consultancy organizations (IBM, Cap GeminiErnst and Young, see also Arbab et al., 2002). It is morecommon in many organizations to go straight to the technical specifications of information or technical architecturesinstead of using some form of business architecture. Differences between approaches can be found in the degreeof specification as well as the layers (business, information, technology) and approaches (logical, physical) that arebeing distinguished. Research into-business architecture isscarce. There are a few case studies of Enterprise Architecture available (Besson et al., 2002; Chandra and Kumar,Springer2001; Richardson, Jackson and Pages, 1990; Veasey, 2001;Wolfenden and Welch, 2000). The application of business architecture is not limited to organizations, it is also possible toanalyze supply chain integration using an architecture pointof view (Chandra and Kumar, 2001). Many of these studiesemphasize the conceptual level (Zachman, 1987; Malthora,1996; McDavid, 1999) or the modeling aspects (Bernes andNemes, 1996; Arbab et al., 2002).The link between business and IT, strategy and operations,is also made in strategic alignment approaches (Hendersonand Vankatraman, 1993). More, and increasingly large scale,studies have been conducted in this domain (Cragg, Kingand Hussin, 2002) shifting from case studies towards moreencompassing surveys (Teo and Ang, 1999). In addition toa link to strategic alignment there is also a link to businessmodel literature. According to Hedman and Kalling (2003)the business model concept and strategy are increasingly interchangeable. Instead of formulating a strategy, companiesare designing a business model. Rensburg (1997) sees business models as building blocks for architecture: “Good business architecture consists of business models which allowthe modeling of any organizational entity together with itsmulti-dimensional organizational views”. In our view, business strategy as well as generic or specifically used business models, are important inputs for business architecture.Wolfenden and Welch (2000) also use “business architecture” as the connecting link between strategies on the onehand, and business processes, roles, behavior and information on the other. Others (Veasey, 2001) adopt a more holisticapproach to realize changes in strategy and the redesign ofthe organization.We use the concept of “Business Architecture” to structurethe responsibility over business activities prior to any furthereffort to structure individual aspects (processes, data, functions, organization, etc.). The business architecture arrangesthe responsibilities around the most important business activities (for instance production, distribution, marketing, etcetera) and/or economic activities (for instance manufacturing, assembly, transport, wholesale, et cetera) into domains.We distinguish the concept of Business Architecture fromthe concept of Enterprise Architecture. We look at enterprisearchitectures as any “architecture at the enterprise level” (McGovern et al., 2004), where “enterprise” is used to indicatethe scope of the architecture being enterprise-wide. BusinessArchitecture in contrast is an architecture that is specificallymeant to structure responsibility over economic activities bymultiple organizations (supply chain level), by one organization (enterprise level) or by part of an organization (businessunit level).Main elements of the Business Architecture are what wecall “business domains”. They can best be looked at as “areas of accountability”. Within the business architecture a highlevel description is provided of how the business processes
Inf Syst Front (2006) 8:91–102are dealt with by these domains and which domain is responsible for specified business functions or objects. Thus:the main elements of a business architecture are “businessdomains”, which are clusters of coherent business functionsand objects (concepts), over which meaningful responsibilitycan be taken in business processes. So we look at business architecture as: “the grouping of business functions and relatedbusiness objects into clusters (business domains) over whichmeaningful accountability can be taken as depicted in thehigh level description of the related business processes”. Notethat these domains are consciously decoupled from the organizational graph itself and therefore decoupled from currentmanagerial position and interests. Assigning the business domains to specific directors and business units is a subsequentactivity (i.e. after the creation and acceptance of the businessarchitecture). In our view the business architecture contains:– A lay-out of business domains (including their occurrences on various levels) and their assigned business activities and added value (“business case”).– Business functions and business concepts (high-leveldata descriptions), that these business domains need (andare responsible for) to perform their assigned businessactivity.– High level business processes, which show how thesedomains work together to achieve the organizationalgoals and strategies.Such a business architecture shows higher level management how their strategy will be implemented in their organization. Business architecture is directly based on businessstrategy (see Fig. 1). This business architecture is the foundation for subsequent architectures (strategy embedding),93where it is detailed into its various aspects and disciplines.The business strategy can consist of elements like strategystatements, organizational goals and objectives, generic business models and/or applied business models (business cases),etc. Statements formulated by top management (or its strategic planning department) can be strategic, tactical and sometimes even operational in nature and may include a number ofapplied business models. Often the strategic statements alsoinclude the description of the “business case,” i.e. the specific application of a business model. ICT-innovations openup new possibilities for the industry, organization or business unit. In our model, new possibilities offered by ICTinnovations are required to be specifically included in thestrategy statements, where they (if operationalized correctly)lead to the most effective usage. Note that this differs fromusing them directly when setting up ICT-architectures.Looking at the creation of a business architecture we depart from this business strategy (Fig. 1: (1) Strategy formulation). The strategic statements are analyzed and arranged hierarchically, through techniques like qualitative hierarchicalcluster analysis (Miles and Hubermann, 1984). The top levelstatements that are the most inclusive (e.g. for an enterpriselevel business architecture: company-wide scope, industrypositioning) are placed at the top of the hierarchy. These toplevel statements are often mission-like in nature or based onindustry-wide agreements. Lower level statements are morelimited in scope and have less far-reaching consequences.They are specific in nature and are often based on (or implicitly stated in) higher level statements. Based on this strategyhierarchy and starting from the top the business architecture is drawn-up, using general organizational structuringmethods and business administration theories. Examples areFig. 1 Relation betweenbusiness strategy, businessarchitecture and subsequentarchitecturesSpringer
94Inf Syst Front (2006) 8:91–102theories on assets and resources (Kay, 1993; Quinn, 1992;Prahalad, 1990 and others) and theories on structuring economic activity (Chandler, 1990; Powell, 1990; Child andFaulkner, 1998; Best, 1990 and others). Although architectures are mainly the realm of the ICT-organization (or at leastoften initiated by ICT), the business architecture can betterbe created by more business oriented architects (e.g. with aMBA-background). The business architecture should also beowned and maintained by the business rather then ICT. Oftenit is heard in larger organizations that the ICT-department isnot backed up by a poorly involved business. Amongst othersthis is caused by the technical character of ICT-architectures.The creation of the business architecture by the business itself gives the business a (non-technical and therefore understandable) tool to influence the subsequent ICT-architecture,whilst ICT is helped with a involved business that has formulated and structured their business requirements. Having abusiness architecture benefits both parties, business as well asICT.Setting up the business architecture, the company gainsinsight into the consequences of the individual statements aswell as the way they are related to one another. Supportedby interaction with relevant management and by applyinglower strategy statements, the business architecture will getmore and more detail, levels will be introduced, occurrencesof business domains will be determined and specified. During the process the strategy and its consequences willbecome increasingly clear. The end result is a better understanding of the strategy itself and the consequences ofthe interference between various statements as well as theconsequences for the implementation of that strategy in theorganization.During the creation of the business architecture all designdecision are clearly stated and directly related to strategy elements and/or general business construction principles. Thismakes the business architecture more than “yet another picture”. It helps people using the architecture to steer change tounderstand why it is important to maintain the business domains and the depicted clustering of business functions, dataand processes. The fact that the business architecture clustersactivities into sensible units of accountability (business domains) is a strong facilitator towards future implementationof the subsequent organization, processes and IT. Managersnow have specific areas that they can take control over in either the demand organization or the supply organization (tobe addressed later on in this section).Based on the business architecture the construction of theorganization can now take shape (Fig. 1: (2) strategy embedding). Due to the fact that during strategy formulationand the creation of the business architecture the businessstrategy gets better formulated and understood as well asmade more internally consistent, the business architectureforms a far better basis for subsequent architectures than theSpringerindividual statements themselves. This business architecturealso forms a common basis for each of the subsequent architecture, which adds to the internal consistency of thesearchitectures.The business architecture gives direction to organizationalaspects, such as the organizational structuring (in whichthe responsibilities of the business domains are assigned toindividuals and/or business units in the organization chartor where a fresh organization chart is drawn) and the administrative organization (describing for instance the financial reconciliation mechanisms between business domains).Assigning the various business domains to their owners (directors) also helps the further development of other architectures, because now the managers or directors of thesedomains can be involved in their part with a specific assigned responsibility. The specific assignment will increasethe involvement of top-level management in a structured way,where all directors are well aware of their role. It is also possible to draw up subsequent architectures for specific businessdomains first, based on the effort and support of the domainowners involved. This is also why we believe that the businessarchitecture is a very helpful pre-structuring device for thedevelopment, acceptance and implementation of subsequentarchitectures.Next to the organizational aspects, the organization is setup from various points of view. These perspectives have beenused in the thinking on architecture for years: information architecture, technical architecture, process architecture, organizational structure (Zachman, 1987). In this paper we focuson process, information and application architecture. Thevarious parts (functions, data and processes) of the businessarchitecture function as an compulsory starting point for thedifferent subsequent architectures, it in fact pre-structuresthe other architectures. It is a new approach to use businessarchitecture in a pre-structuring way towards the other architectures.The division and use of the coarse business processes thatare described in the business architecture forms the startingpoint for the more detailed process architecture, in whichthe relevant processes are further decomposed, specified andanalyzed. The business architecture also pre-structures thetop-level business functions and business objects. Both provide the same guidance to the data decomposition and thefunctional decomposition, which make up the informationarchitecture.In the basic architecture linkage model (Fig. 2), we showthe pre-structuring function of the business architecture towards other aspect architectures as well as the relationshipsbetween the various architectures. Starting with the coarsestructuring of business functions and objects in the businessarchitecture, the further functional decomposition leads toan information architecture that includes the following elements:
Inf Syst Front (2006) 8:91–10295Fig. 2 Basic architecture linkage modelr IT-functions (functional modeling), such as registeringran order, handling a customer contact, generate a lead,determine sales-targets for a channel, register a customeror an agreement, andData, objects (data modeling), like agreements, customers,orders and credit risk.IT-functions and data can be grouped at an intermediarylevel into ICT-supply domains. Because the functional decomposition is started, based on the business domains, thisalso aligns the ICT-supply domains better to the businessrequirements. We now have the means
Business architecture is directly based on business strategy (see Fig. 1). This business architecture is the foun-dation for subsequent architectures (strategy embedding), where it is detailed .
Visual Paradigm for UML Quick Start Page 5 of 30 Starting Visual Paradigm for UML You can start Visual Paradigm for UML by selecting Start Menu Visual Paradigm Visual Paradigm for UML 7.1 Enterprise Edition. Importing license key 1. After you enter VP-UML, you will be asked to provide license key in License Key Manager.
Dec 01, 2014 · dies in the field. Aim: The purpose of this paper is a review of the nursing paradigm. Method: This review was undertaken by library studies using databases such as CINHAL, MEDLINE, Web of Sciences by key words Paradigm, Mono paradigm, Multi Paradigm, Nursing, Nursing Sciences, separatel
CARESOURCE'S BUSINESS ARCHITECTURE PRACTICE ¡CareSource's Business Architecture practice is part of the Enterprise Architecture team ¡EA team uses Orbus iServer as our primary architecture tool ¡In 2020, launched a reset / maturing focus on the business architecture practices: ¡ Existing capability model rebuilt leveraging Business Architecture Guild's industry reference models
What is Computer Architecture? “Computer Architecture is the science and art of selecting and interconnecting hardware components to create computers that meet functional, performance and cost goals.” - WWW Computer Architecture Page An analogy to architecture of File Size: 1MBPage Count: 12Explore further(PDF) Lecture Notes on Computer Architecturewww.researchgate.netComputer Architecture - an overview ScienceDirect Topicswww.sciencedirect.comWhat is Computer Architecture? - Definition from Techopediawww.techopedia.com1. An Introduction to Computer Architecture - Designing .www.oreilly.comWhat is Computer Architecture? - University of Washingtoncourses.cs.washington.eduRecommended to you b
Quantum Mechanics and Paradigm Shifts Abstract It has been argued that the transition from classical to quantum mechanics is an example of a Kuhnian scientific revolution, in which there is a shift from the simple, intuitive, straightforward classical paradigm, to the quantum, convoluted, counterintuitive, amazing new quantum paradigm.
Series Owners Manual REFERENCE COLLECTION. Paradigm DOES NOT supply hardware for mounting Paradigm Prestige 25S speakers to the wall. Always use screws appropriate for wall type and . PARADIGM, PARADIGM REFERENCE COLLECTION, PRESTIGE and all associated proprietary and
An extra Paradigm infusion set and Paradigm reservoir Dressing and adhesive Extra AAA Alkaline and A23 batteries (Energizer recommended) Paradigm Quick Reference Card Glucagon Emergency Kit Inform a family member, co-worker, and/or friend where this emergency kit is kept. Please refer to Chapter 10, User Safety for more information on
Programming paradigm A programming paradigm is a style, or w, ay of programming. Paradigm can also be termed as method to solve some problem or do some task. Programming paradigm is an approach to solve problem using some programming language or also we can say it is a meth
