On the Relation between Business, Business Model, Soft-ware, and ICT Platform Architectures

J.C. Wortmann¹, D.K. Hammer², J.B.M. Goossenaerts¹, A.T.M. Aerts²¹ Eindhoven University of Technology, Information and Technology Division, P.O.Box

513, Paviljoen, 5600 MB Eindhoven, The Netherlands² Eindhoven University of Technology, Department of Mathematics and Computing

Science, P.O.Box 513, 5600 MB Eindhoven, The Netherlands

Abstract. This paper will focus on the investigation of the enables and the drives rela-tions in the inter-domain context of business, business model, software, and ICT platform architecture. The historical development of these architectures and their mutual depend-encies is summarised. On the basis of these observations, architectural issues such as complexity, flexibility versus performance, and leveraging and enabling, are discussed.

1. Introduction

The mutual relationship between enterprise development and ICT (Information and Communication Technology) development is one of symbiosis: the development of ICT architectures enables the development of business architectures; and vice versa, en-terprise applications will leverage or drive the development of new ICT systems or their features. We show that this mutual influence can be observed in the past, and it is likely to continue in the future.

The definition of four domains of architecture: business architecture, business model architecture, software architecture and ICT platform architecture allow us to make a conceptualisation of the historical developments in the application of ICT in enter-prises. A further goal of this paper is to focus on a number of properties of these archi-tectures, which can be observed in multiple domains, and to illustrate them on the basis of the historical developments. By doing so we hope to discover ways to manage and ac-celerate the symbiosis of enterprise development and ICT development.

Definitions and scope of the paperBusiness architecture (also called enterprise architecture) and ICT architecture be-

long to different engineering domains (see also Wortmann et al., 1999). Business archi-tecture belongs to the domain of industrial engineering and management science, whereas ICT architecture belongs to the domain of computer systems engineering. Each profes-sional discipline is characterized by its own culture, its own approach to knowledge, its own way of thinking and solving relevant problems. Each professional discipline uses also its own set of modeling techniques. Usually a model will be a description of the structure, the relations and the interactions of real world objects or processes. Many dif-ferent models may be needed, depending on the purpose. Related issues are how to make sure that different models are consistent, how models can be compared, and how one model can be derived from another one.

Analytic and synthetic techniques within engineering domains are well under-stood and reported about in scientific and engineering publications, but the same cannot

be said about the relationships between different engineering domains. This relationship must, however, be carefully "managed" in industrial companies. Such companies make value propositions to a market, by "tacitly" merging advances and technologies from mul-tiple engineering domains.

Architecture is a generic concept, which is cutting through engineering disciplines and domains. It is a promising starting point to better understand the symbiosis of ICT and enterprise development. This symbiotic development is, according to us, understood insufficiently in both the business engineering and ICT engineering domains, causing a significant waste of effort in research and technology development. This paper will focus on the investigation of the enables and the drives relations in the inter-domain context of business architecture, business model architecture, software architecture and ICT plat-form architecture. These four architecture domains are defined as follows:1. The business architecture specifies the business processes that must be supported by

the underlying ICT system in terms of, e.g., business processes, business rules, busi-ness units, and important business resources. In this domain the business is decom-posed into smaller units and their relations.

2. The business model architecture details the model of the business processes in terms of, e.g., a conceptual data model, a business model (business object models, business object interaction and workflow models) or a product model.

3. The software architecture details the application components and their interaction.4. ICT platform architecture is the architecture of the generic resource layer, which de-

scribes the machines, networks, peripherals, operating systems, data base manage-ment systems, UI frameworks, system services, and other resources that will be used as a platform for the construction of the ICT system for the enterprise.

Each architecture domain defines the requirements for the following domains and verifies the feasibility of the preceding ones (in so far as applicable). The first domain specifies the business system, the other three the ICT system.

Intra-domain issues that matter for any architecture, such as intuitiveness, adapt-ability, ease-of-use, simplicity, distribution, scalability, inter-operability, portability, reusability, maintainability, and embedding of new technologies, will not be covered in detail in this paper. Exceptions are the issues that have a strong inter-domain context like complexity and performance.

From Business architecture to ICT platform architectureWith the historical development of the application of information and communic-

ation technology in the enterprise, the need for architecture has been propagating from the enterprise itself, over the business model architecture, software architecture to include also the ICT platform architecture. The need for architecture in a certain domain stems mainly from the growth of complexity. In their initial applications, computers were con-sidered as tools to solve isolated problems, without a need for business model, software, or ICT platform architecture. The data entry burden naturally lead to a need for data stor-age with access defined, and this made business model architecture necessary. The do-main of information and communication technology has developed dramatically in line with the technology it covers, from manual index-sequential files to the World Wide Web. Technology has taken over an increasing range of activities from the human

2

worker. With this increase, the need for architecture has become evident in the domains of business model, software, and ICT platform. This development can be described in ref-erence to three domain architectures, the business model architecture, the software archi-tecture, and the (IC) technology architecture.

OverviewIn the historical development of enterprise organisation and information techno-

logy, six development phases can be distinguished: 1. The functional hierarchy. 2. The functional hierarchy with function oriented automation. 3. The functional hierarchy with shared database on mainframes. 4. The process oriented enterprise.5. The supply chain oriented enterprise.6. The web-enabled agile enterprise.

In chapter 2, the different phases are presented sequentially, abstracting from a possible overlap in time. For each development level, we describe the aspects that must be covered in four domain architectures, and how they are mutually connected.

In chapter 3 we summarise some aspects of the four domain architectures for the current development level 6. These aspects are structure, interaction, distribution, stake-holders, concerns and performance measures.

Finally, three issues that are relevant for architectures in the inter-domain context will be described. These issues are complexity, flexibility versus performance, and the leveraging and enabling relationship between domains.

2. Historical development

Before the industrial revolution, manufacturing was based on craft. Products were usually unique (one of a kind, but not always ordered by customers). Moreover, the flow of one-of-a-kind goods was rather accidental, being pushed by producers or traders to markets, rather than pulled by customer orders. Therefore, the flow of goods was slow, and many resources were wasted in quality control of these goods. Ordering was always a local process. Trade required many links, was not predictable, often not based on money, and not included in ordering.

The history of modern organisations is rooted in two evolutionary lines (Hammer & Champy, 1993):

the principle of the division of labour, as described by Adam Smith in The Wealth of Nations (1776), and later improved by Ford and Sloan who applied the prin-ciple to the assembly of the automobile (1909)

the invention of the business bureaucracy by railroad companies (1820): in or-der to prevent collisions on single-track lines that carried trains in both directions, rail -road companies invented formalised operating procedures and the organisational struc-ture and mechanisms to carry them out (command-and-control structure)

2.1. The functional hierarchy without automation: the 50ies.Business architecture: The dominant model of the organisation after the industrial re-

volution is the functional hierarchy and the only information system is the general

3

ledger. The organisation is engineered over a long period of time for operation in a stable environment. Until the middle of this century, the enterprise structure has been dominated by the machine bureaucracy, which comprises organisational units each specialised for one function such as Sales, Marketing, Ordering, Ship-ping, Warehousing, Manufacturing, Purchasing, Finance, and HRM. These func-tional units are largely self-contained and tend to focus more on the management of their resources than on the management of business processes which cross the boundaries of these units. Products are mass-produced, and their distribution is supported by a transportation and banking infrastructure. Usually organisations have a local geographical scope (in Europe: independent organisations per coun-try).

Business Model architecture: The business model architecture is implicit in the work-routines and file systems of the organisation. Communication is achieved by passing documents between functions.

Software architecture: There is no software architecture as software applications are not available yet. There is a (manual) database (a set of index-sequential files) for each function. Calculation and data storage functions are performed by people with the assistance of mechanical calculators and manual file systems.

ICT platform architecture: There is no ICT platform yet as the technology base of the in-formation processing and communication is very limited. Communication re-quires humans to exchange documents or messages between these functions, or between enterprises, mostly on paper via mail, or via telephone and telex.

The enabling role of the implicit model architecture for the enterprise is in the

area of speed (of access to data, allowing mass production), predictability, correctness, repeatability, and accountability.

2.2. The functional hierarchy with function oriented automation: the 60ies.Business architecture: As the first computation and data storage applications become

available, the business architecture remains pretty much the same through the six-ties as it was in the fifties, showing a hierarchy composed of self contained func-tional units under central control. Smooth communication within organisations in such a structure is mainly vertical. Horizontal communication, as required by cross-functional business processes, is not really organised, and tends to be slow. Moreover, much energy is lost in quality control of data, which passes the bound-aries of functional units.

Business Model architecture: The business model architecture remains largely unchanged and implicit, but information and data structure is made explicit on a function by function basis, by declaring record formats for punch cards or magnetic tapes.

Software architecture: Software applications are introduced for calculations and data storage. For each function there is a database (a set of index-sequential files) plus self-contained applications. Computer technology supports computing and data storage, but communications are not affected much: messages are (manually) ex-changed between these functions in the form of paper listings or magnetic tapes.

4

ICT platform architecture: The hardware consists of a mainframe accessed by terminals. Processing, storage and usage is done centrally in a computing centre, often under the control of the financial department.

As the computer is added to the technology base the enabling role of the ICT for the enterprise is expanded: the speed and reliability of all data related activities and calcu-lations is improved dramatically.

2.3. The functional hierarchy with shared data base on mainframe: the 70ies.Business architecture: The 70ies show a small change in the organisational structure for

enterprises in manufacturing and distribution of physical goods, because speed becomes more important, and therefore logistics. Special co-ordinators become responsible for order promising and goods flow control. The geographical scope is enlarged, but not fundamentally changed. Although the co-ordination of the flow of materials is improved, the functional hierarchy is still in place. Similar developments can be observed in other sectors, such as banking or healthcare. For the primary business processes, speed and quality become important. This leads to ad-hoc adaptations in the organisation, but not to a fundamental change in the functional hierarchy.

Business Model architecture: The model architecture becomes explicit and is built-up around one data architecture, at least for applications involved with the primary action. External schema's which support functions are mapped on a single (con-ceptual) schema, which in turn is mapped on a storage structure definition (ANSI/SPARC DBMS Model (1975), see for instance Date, 1986). Integration of information from different applications in many cases is changed from manual to automatic. Schema's and mappings can be described in the relational model (Codd, 1970).

Software architecture: The application software becomes more integrated between busi-nesses and therefore less transparent. Integration is mainly ad-hoc, and mirrors the functional structure of the business. However, a clear distinction between the data-layer and the application layer becomes visible. Mainframe (i.e., hierarchical and network) database management systems now allow efficient and controlled sharing of the data by different applications.

ICT platform architecture: The hardware architecture is still mainframe-oriented. Pro-cessing no longer is exclusively central, with minicomputers supplying local sup-port for functions that control their own databases. Communication between these local systems, which have become known as “automation islands” is still manual.

The architecture of the database system becomes dominant between the business domain and the information technology domain. It offers solutions in the model domain, the software domain and their interface to mainframe and mass storage devices. In a sense one could state that the automation problem of the functional hierarchy was solved. Information modeling and data sharing solutions in the information technology domain all contribute to the emergence of business process re-engineering.

5

2.4. The process oriented enterprise: the 80ies. Business architecture: The 80ies show a change in the business world towards business

units. Business process re-engineering appears. It means that logistics (or in gen-eral the value-adding process) becomes the principle of organising the business, rather than the functional hierarchy. However, there is still a local geographic scope in organisations.

Business Model architecture: The ICT-solution changes to client-server systems. The model architecture is now built on the data-architecture of a single conceptual data model. The emergence of the object-oriented approach to structuring systems provides an alternate way to organize data and functions. Each object has its own state (data-members) and methods (function-members) to manipulate this state. In this approach the application architecture is specified in terms of an object-ori-ented architecture, as opposed to the prevalent combination of data and function architecture.

Software architecture: Simple client-server enterprise applications appear. The advent of relational database systems allows the separation of storage and manipulation of data. The first ideas on User Interfaces (UI) come to stage, triggered by the graph-ical capabilities of the workstations, which allow the presentation of much more information on the client system. The systematic design and generation of UI is supported by the introduction of UIMS (User Interface Management Systems), which enable the separation of presentation aspects from the business logic in ap-plications. Together with the earlier separation of data and application a three-tier, software architecture emerges. GUI (graphical user interface) systems are the first widespread application of object oriented technologies. Standard ERP-software delivers standard integration between functions.

ICT platform architecture: Smaller hardware systems (Workstations and PC’s with their own processing power, connected to the more powerful departmental systems and each other by fast local area networks) come to the stage. The hardware architec-ture becomes open (network-based). The computing workload is partially shifted to the smaller systems resulting in a two-tier, client/server hardware architecture. Processing is done at the server-side, while usage has now become distributed over the clients.

The process-oriented enterprise shows a sharing of functions and a de-specializa-tion when compared to the "modular" functional hierarchy. IT-supported multi-site oper-ations become feasible or are expanded by using client/server architectures. DBMS have developed towards sub-systems with stable interfaces, implemented at the servers. The client/server architecture is a multi-domain architecture, affecting the model, software and ICT architectures.

2.5. The supply chain process oriented enterprise: the 90ies. Business architecture: The early nineties enlarged the scope of the business units from

local to regional. Several warehouses, factories and distribution centres are in-cluded in these business units, as well as different legal and financial enterprise units. Supply chain processes are the focus of bilateral commercial process reen-gineering efforts: an internal integration into a process oriented enterprise, is fol-

6

lowed by an "external" supply chain integration, linking together the "functions" of the supply chain members.

Business Model architecture: The previous pattern of standardised, local integration be-comes more and more difficult in the case of multi-site systems and supply chains. The approach widens from expanding or integrating applications based on a single, homogeneous information model to the integration of applications based on different, heterogeneous information models. The federated model architec-ture, with semantic mapping interfaces between the different information models emerges.

Software architecture: Enterprise-level client-server applications, i.e. client based pro-cessing accessing multiple local servers, mature. Also here, the previous pattern of standardised, local integration becomes more and more difficult in the case of multi-site systems. The approach now widens from expanding or integrating ap-plications based on a single, homogeneous software architecture (based on syn-chronous communication) in order to support distributed functions, to the integra-tion of applications based on different architectures. Communication between these components is necessarily asynchronous (message-based). The focus shifts from integration of applications on a one by one basis to a standardisation ap-proach. The infrastructure (often called middle-ware or glue) enables integration into a common environment based on the CORBA or DCOM object models. In this framework both processing and usage of information have become distrib-uted. The UI paradigm shifts from the GUI paradigm, providing (just) graphical presentation, to an OOUI paradigm supporting as well the direct manipulation (such as drag-and-drop) of objects on the screen.

ICT platform architecture: Wide area networks, such as Internet, have gained enough critical mass to enable global access. The ICT solution incorporates in its data-structure and application the so-called multi-site aspects. Either clusters of organ-isational units are physically placed on one DB-server, or these are based on sep-arate local servers. In both cases, integration has to be built. The hardware archi-tecture evolves from a two-tier architecture via a three-tier architecture (compris-ing the client, an application and a data server on as many machines) to an n-tier architecture where applications and data have been partitioned over several serv-ers (distributed application, distributed data). Very little (a PC running a Web server and a link to an Internet provider) is needed to start a global company.

Current enterprises require better ways to make systems work together (Enterprise Application Integration, or EAI) across the supply chain, and more difficult, in multi-in-dustry supply chains. Current challenges are related to a highly diverse population of leg-acy systems, the wish to protect investments, and the slow acceptance of new standards. Simultaneously, agile enterprises, i.e., lean enterprises with a fast, efficient response to change, have to secure their ability to innovate and respond swiftly to market opportunit-ies.

2.6. Web-enabled agile process-oriented enterprise: Next.Business architecture: At the turn of the century, organisations expand their scope to

really global, and differentiate their patterns of co-operation to encompass also

7

collaborative activities. Multi-site and multi-enterprise problems permeate every aspect of the enterprise, such as product development, marketing, sales, contract-ing, ordering, invoicing, and servicing. Each aspect differentiates dynamically between local and global responsibilities. We will call this “scope”. We are on the verge of a re-engineering of engineering and commercial processes (e-com-merce) and market infrastructure. One example is the enactment of multiple sales channels for heterogeneous markets. New applications include (IMTR-TEI, 1999): multi-enterprise estimating and resource planning simulations for joint bid-ding; multi-tiered planning and scheduling that progressively firms up schedule commitments based on decreasing range of scheduling horizons; collaborative planning and collaborative forecasting and replenishment that include automatic negotiation processes. Many such applications are infeasible without the con-nectivity and low cost communication facilities provided by Internet and the World Wide Web.

Business Model architecture: Increasing effort is spent in coping with heterogeneity at all levels. Application based integration becomes virtually impossible, as it cannot provide the flexibility needed to quickly respond to change. The UI paradigm be-comes based on task modelling which allows full separation between content (data) and processing (form). The definition of data-structures will rely on in-stance mark-up, in preference to any schema external to it. All data becomes self-describing. It carries its own meta-data, including mappings to common stand-ards. This separation of presentation and content is driven by the emergence of all kinds of new peripheral devices. Processing and data-structure will be selected (from multiple servers) or defined on the client-side in order to specify the exact behaviour required. Model–based execution of business processes becomes the dominant mode providing the necessary flexibility needed to cope with or create changes in the business environment. Processing flow and procedural or condi-tional logic will be stored in models, in absolute preference to implementing any such in executable code. These models will be self-describing as well and to-gether with the data they will be uniquely parsed on every occasion within the context receiving them. Any application session is generated based on a specific scope. There is an extensible model-repository providing the multi-site structures in various aspect systems (See Perry (1999) for a presentation of some of these is-sues as pure XML designs).

Software architecture: The software architecture of web-based enterprise applications is highly distributed, consisting of interoperable components. The mapping of these components and their persistent counterparts on the ICT-infrastructure is flexible, and is explicitly described in an ICT-implementation repository. The paradigm for communication and collaboration between components changes from message-based to the deployment of intelligent agents that find their way through the ICT-infrastructure. These mobile agents provide a dynamic form of application parti-tioning. They use the model-repository to find a logical component instance and the implementation repository to find the corresponding physical component in-stance and data. Generic services, such as model execution and broker services, are required components to provide the necessary execution platform.

8

ICT platform architecture: besides powerful personal computers, a multitude of new peri-pheral devices, such as palmtops, and mobile phones give rise to new demands on presentation services. High bandwidth networks, low cost communications enable the application of new communication and collaboration paradigms, based on ubi-quitous computing.

Time spanDomain

50ies 60ies 70ies 80ies 90ies Next

Business Architec-ture

Func-tional Hierarchy

Functional Hierarchy

Distribution Logistics

Business process

Supply Chain

Web-en-abled

Business Model Ar-chitecture

implicit implicit Data mod-els

Client / Server

Federa-tions

Model based

Software Architec-ture

no Function oriented

DBMS RDBMS3-tier GUI

Enterprise applica-tions

Generic compon-entsOOUI

ICT Archi-tecture

limited mainframe information islands

networks multi-site,n-tier

ubiquitous computing

Table 1. The historical development of the business and ICT domains

Architectures supporting reflectivity may provide the proper response to the busi-ness need for flexibility and agility. Such architectures will coexist with the more tradi-tional architectures, which will provide less flexibility, but more performance in more stable environments. In the previous paragraph two technologies supporting such archi-tectures have been mentioned: XML and mobile agents. Whether these technologies will turn out to be the true enablers, or even whether our description of phase 6 will turn out to be the correct one, remains to be seen, of course.

3. Aspects of the Domain Architectures

In the discussion above, we have distinguished various aspects of the business, business model, software and ICT architecture. In the different development levels of en-terprises and supporting ICT systems, these domains have had different relevance and had to meet different requirements. Both the business requirements and the technological components and their enabling role have dramatically changed. The need for architecture as a tool for managing complexity has expanded from the business domain, over the model domain and the software domain, towards the ICT domain. The ICT system that supports an enterprise has grown into a complex entity that includes hardware and soft-ware for data-storage, computation and communication, as well as data and information models.

The tables below contain a more complete list of aspects of the four domain archi-tectures as they matter in the current development of enterprise organisation and informa-tion technology. These tables present, however, more an illustrative than an exhaustive overview.

9

AspectDomain archi-tecture

Structure Interaction Distribution

Business StoresFactoriesTransportationProducts

Business processesBusiness transac-tionsMaterial flow

Enterprise topology: Multi-site Scope Functional Partition

Business Model Meta models Data models Ontologies Process models

Workflows Data topologyProcess topology Objects Relations Interactions

Software Applications Module Interac-tionsDependencies

Instance topology

ICT platform MachinesDBMS’sDatabases / StoresGeneric servicesORB’sUI frameworksNetworksPeripherals

Call patternsProtocolsData streams

Resource topology

Table 2. Structure, interaction and distribution of domain architectures.

Tables 2 and 3 illustrate the large number of concerns that are important at the be-ginning of phase six. In the course of the six phases that we have described in chapter 2, this list has developed from one that was virtually empty. Tables 2 and 3 also illustrate the close interconnection between enterprise organisation and ICT (see, e.g., the stake-holders in table 3.) that has developed during the past decades. Tables 2 and 3 explicate the areas that will be affected when the requirements imposed on the system will change. We will not explain the entries of the tables in detail here. In section 4 we will, however, discuss a number of issues involving more than one domain.

4. Inter-domain Architecting

This chapter illustrates a number of issues of inter-domain architecting by means of business and ICT cases. Each principle is introduced first, followed by some refer-ences to the enterprise and ICT development, and possibly some open questions. The first issue is that of the complexity of innovative architectures affecting several domains. The second issue is the balance that has to be found between flexibility and performance. The third issue is the leveraging and enabling relationships that exist between several do-mains.

10

AspectDomain architec-ture

Stakeholders Concerns Performance measures

Business ManagerCustomer

Goal orientationCustomer orienta-tionEffectivenessEconomy

Lead-timesProductivityThroughputQualityProfitabilityReturn on Investment

Business Model Information of-ficer

CompletenessExtensibility

Compliance with std’sStability of interfacesSimplicityConsistency

Software UsersDevelopers

Function Structure Behavior Timing Reliability

Transaction /userPerformanceResponse time

ICT platform OperatorsAdministrators

SpeedConnectivityEfficiency

Execution performance Bandwidth/throughput Latency ReliabilitySecurity

Table 3. Stakeholders, concerns and performance measures of domain architectures

4.1 Complexity in inter-domain developmentThe complexity of design is to a large extent determined by the availability of ap-

propriate objects together with effective composition and decomposition strategies to find the right combinations of primitive objects. The following classification of design has been proposed (Brown and Chandrasekaran, 1989):

Class 1: radical innovation. This class involves innovative design leading to a major invention or completely new systems. It is characterized by the fact that goals are ill specified, no storehouse of effective decompositions exists and no precompiled partial design solutions are available.

Class 2: modular innovation. This type of design activity is characterized by the existence of powerful problem decompositions. The structure of the system, together with the general interfaces of the main subsystems has been fixed for quite a long time. Class 2 design often reuses existing modules as the linkages between modules remain un-changed.

Class 3: relatively routine design. This class of design is similar to incremental in-novation, where effective problem compositions and compiled design plans for the com-ponent problems are known. Class 3 systems are often designed to the installation site while retaining the same structure and general properties.

11

The development of businesses (or enterprises), business model architecture, soft-ware and ICT platform clearly shows cases of all three classes of design. Development levels of enterprise and information technology have been raised by innovative type de-signs (Class 1) such as the development of database management systems, the three-schema architecture, and the client-server architecture.

Currently a new Class 1 leap is being wrought which involves web-based e-com-merce and a further re-engineering of the supply-chain processes based on Internet tech-nology. Companies can offer customers the possibility to configure their products (e.g., their PC) and deliver the product in a few days time, at all major markets. Traditional products such as books are becoming major items in web-based services, such as discus-sion groups and alert services. By means of hyper links, embedded in advertisements or produced by Web search services, potential customers are lead to commercial Web sites. There they can inspect on-line product catalogues and enter orders. Commercial Web sites often also support after-sales contact in cooperation with local service providers. Global companies, with a world wide visibility, are enabled by these web-based-ICT ser-vices. A low threshold environment has been created which allows micro companies to operate in global markets: according to a recent IDC research report over 4 million small businesses are expected to be present on the Web.

We can observe that innovative type designs, such as database systems, client/server systems and the World Wide Web span multiple domains. For example, the three-schema architecture of database systems relates the model, software and ICT platform domains by its separation of the conceptual (semantic), external (user-related) and physi-cal (storage related) models. Within each of the four domains of enterprise architecture class 2 and class 3 type of development are common place.

4.2 Flexibility versus optimisation Flexibility is defined here as the possibility to support new use-cases by changing

existent components or adding of new components, but without changing the architec-ture. Understood this way, flexibility must be determined from the enterprise side (it must be driven by "value propositions"), not from the technology side.

An enterprise is not a static entity. In fact, enterprises can nowadays only survive when they can effectively cope with changes in their environment or even cause these changes. Being the first to introduce a particular product or service may provide a decis-ive advantage over the competition. This means that enterprise processes are constantly undergoing change.

The same is true for the ICT systems supporting these processes. New product and process models have to be supported. In addition, there are regular upgrades of com-ponent software, DBMS, operating systems, computers, and networks. Also the alloca-tion of components to a site becomes a dynamic one. Components may disappear from the system, enter it, or they may change location. Consider, e.g., a mobile agent, which moves through the system: it has no fixed location.

The need for flexibility and changeability implies an important role for modular-ity. Erens (1996) contrasts modularity with integration. Modularity on the one hand, is an effective mechanism to upgrade and reuse existing functions, modules and technologies, thus reducing initial costs in system development, at the expense of higher operational

12

costs. Integration of functions, modules and technology, on the other hand, trades stabil-ity and optimised operations, against higher initial costs and reduced flexibility. Integra-tion implies the application of encompassing architectural principles. It requires the definition of shared resources, common models and common interfaces between compon-ents or systems. The consequence of integration is that one has to give up all kinds of local specialisation and optimisation in favour of uniform and efficient solutions.

The following architecting principles are important for achieving flexibility:

Modularity and componentization: a system that consists of moderately complex compo-nents with maximum cohesion, minimal coupling, and well-defined interfaces re-stricts the impact of changes to a few components.

Composability: the characteristic of a system to function not only stand-alone, but also as part of a larger system or in combination with new components.

Extraction of application models: the separation of development and maintenance of ap-plication specific and generic software.

The first principle is illustrated in object-oriented environments that support in-

heritance and encapsulation. The former allows for reuse of proven components, thus shortening development time. A developer only has to provide enterprise specific func-tionality. The latter allows for separation of interface and implementation, which allows one to replace one implementation, e.g. a legacy system, with another one, using better technology.

The second principle is illustrated by the emergence of open interfaces through which systems can access each other’s functionality when needed. Examples of open in-terfaces supporting of this kind of collaboration are JNI, CORBA and DCOM. Open in-terfaces allow generic software such as Web browsers to accommodate new types of doc-uments, by loading the necessary module (plug-in) to process document instances. CORBA allows client systems to access distributed services on the basis of functionality, availability and price. In order to achieve composability, also unwanted inference between the components must be avoided. This can be done by making all implicit com-ponent interactions (via shared resources) explicit at the interface (see Hammer and Chaudron (2000)).

The third principle is exemplified in generic software systems. Typical examples are the separation between a database and the database management system, between a (business) rule base and the inference engine and between a (business) model and a gen-eric model execution mechanism. For example, a workflow system can be made opera-tional by providing a workflow management system with a workflow specification. Changes in the workflow can easily be accommodated by adaptation of the workflow specification. By making the application model explicit, one reinstalls the stakeholders, i.e., the users of the system, into their original rights by giving them control over and re-sponsibility for their own process.

13

From these three principles we can conclude that modularity is an intra-domain matter, as long as proper interfaces between domains have been defined. Abstract inter-faces shield off heterogeneity and non-modularity. Both the business and the ICT archi-tectures have to support flexibility within their domain. By a suitable choice of inter-ar-chitecture boundaries one can prevent the propagation of internal changes to another ar-chitectural domain. After all, the replacement of one module in the platform architecture domain, e.g., a DBMS or a processor, should not propagate into the business architecture domain and affect the logic of the business processes.

On the other hand, integration is only effective when it is performed for multiple or even all domains; all domains should be in tune. For instance, the extension of a com-pany with an additional factory or distribution centre should be reflected in the ICT plat-form architecture. One can state that a domain architecture has a high quality and shows more stability, if it takes into consideration the enabling and leveraging influences of other domain-architectures. An enterprise can not easily align to new business goals, when the supporting system does not support of the required changes of the business pro-cesses. Innovative (class 1) architecture changes are thus integral changes that span sev-eral domains.

Figure 1: The business and ICT domains as layered system.

Note that from the point of view of modularity, the four domains can also be viewed as a layer system. Each domain refines the next higher one by adding domain spe-cific implementation details. Abstract interfaces ensure the decoupling between the dif-ferent layers. At the other hand, optimisation by integration breaks this layer structure and thus also the modularity. These relationships are shown in Figure 1.

Ulrich and Tung (1991) state that most architectures evolve from being modular to being integrated. In later stages of the system life-cycle, when the interactions between different aspects are better understood, the architectures in the different domains should enable function, module or technology sharing in order to make the design more efficient.

14

4.3 Leveraging and enablingA class 1 innovative architecture should take into consideration the enabling or

leveraging influences of other domain-architectures. The business domain leverages the developments in the other three domains, in the sense that it derives needs for lower-level services from its goals, such as customer orientation, effectiveness, efficiency, and sus-tained competitiveness. The growing enabling power of ICT systems on the other hand is a result of the increase of functionality that can be supported by new technology. The business model domain enables the business by offering consistency and correctness of information and procedures. The software domain adds increased functionality, repetit-iveness and variability. The ICT platform domain adds speed of computation, connectiv-ity (space and time independence), and additional variability.

Summarizing, we can state that the application of ICT systems has caused pro-found transformations of the business architecture: the possibility to share data has al-lowed organizations to become flat and process oriented. Communication technology has made it possible to integrate the operations of supply chains. This symbiotic development is continued in the web-enabled agile enterprise.

5. Conclusions

We have described the historical development of enterprises, with a focus on the symbiosis between the development of the business and the enabling ICT. From this ex-ercise, we derived the following relationships between the different architecture domains: Class 1 innovative architectures, such as database systems, client/server systems and

the World Wide Web, span multiple domains. A class 1 innovative architecture should take into consideration the enabling or lever-

aging influences of other domain-architectures. Modularity is an intra-domain matter, as long as proper interfaces between domains

have been defined. Integration and optimisation is only effective when it is performed for multiple or

even all domains; all domains should be in tune.

We have especially looked at breakthroughs (radical innovations of class 1) in the inter-domain context of business development and ICT development. Striking examples of innovations in these domains, such as the discovery of the functional hierarchy, the database three-schema architecture and the client-server architecture, all require inter-do-main solutions. Likewise, the current development level of business and ICT will demand an inter-domain architecture, which gives due attention to the requirements that are typ-ical for each of the domains.

Looking at the phases of enterprise development and ICT deployment, it seems that ICT has considerably contributed to firstly integrating the "modular" functional en-terprise, and secondly, the supply chain. This integration has often been accompanied by an inability to respond to changes, or a lock-in in obsolete technologies. In this respect the agile enterprise appears to be a change of paradigm. Its inherent genericity and flexib-ility seems to be able to overcome the stiffening effects of integration and performance optimisation.

15

In this paper, we have only discussed general trends and relationships. We have shown examples of ICT developments enabling enterprise development, and, vice versa, of enterprise developments leveraging the ICT development. In order to derive general principles, supported by solid evidence, much more research is needed, however.

6. References

Brown D.C. and Chandrasekaran, B. (1989) Design Problem Solving, Knowledge Structures and Control Strategies, Pitman Publishing,1989.

Browne, J., Sackett, P.J., and Wortmann, J.C. (1995) Future manufacturing systems - towards the extended enterprise. Computers in Industry, 25(): 235--254, 1995.

Codd, E.F. (1970) A Relational Model of Data for Large Shared Data Banks, CACM 13(6).Date, C.J. (1986) An introduction to Database Systems, Vol 1, 4th edition, Addison Wesley Pub-

lishing.Erens, F.J. (1996) The synthesis of variety - Developing product families, Doctoral dissertation,

Eindhoven University of Technology, Faculty of Technology Management.Hammer, M. and Champy, J. (1993) Reengineering the Corporation. Harper Collins Publishers,

Inc., New York, 1993.Hammer, D.K. and Chaudron, M., (2000) Resource Constraint Software Architectures: On the

conditions for Composability, 7th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS), Edinburgh, UK, April 2000.

IMTR-TEI (1999) Integrated Manufacturing Technology Roadmapping Project, Technologies for Enterprise Integration. (http://imtr.ornl.gov)

Perry, W.E. (1999) Conference Editorial: What is True XML Processing, XML Development 1999 Conference, http://www.gca.org/conf/xmldev99/perry.htm .

Scheer, A.-W. (1989) Enterprise-Wide Data Modelling - Information Systems in Industry. Springer-Verlag, Berlin - Heidelberg.

Scheer, A.-W. (1994) Business Process Engineering -- Reference Models for Industrial Enter-prises. Springer Verlag, Berlin, 1994.

Y.-P. Shan, R.H. Earle “Enterprise Computing with Objects”, Addison-Wesley Longman, Object Technology Series, 1998.

Ulrich, K.T. and Tung K. (1991) Fundamentals of Product Modularity, DE-Vol. 39, Issues in Design Manufacture Integration, ASME.

Wortmann, J.C., Hegge, H.M.H., Goossenaerts, J.B.M (1999) Understanding Enterprise Model-ing from Product Modeling; Proceedings of International Enterprise Modeling Confer-ence, Verdal, Norway, June, 1999.

16