Abstract . This paper will focus on the investigation of the ...
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.
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 paper
Business 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
multiple 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 architecture
With 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 work-
er. 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 refer-
ence to three domain architectures, the business model architecture, the software architec-
ture, and the (IC) technology architecture.
In 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 principle 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 direc-
tions, railroad companies invented formalised operating procedures and the or-
ganisational structure and mechanisms to carry them out (command-and-con-
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
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-
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.
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
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 inform-
ation from different applications in many cases is changed from manual to auto-
matic. Schema's and mappings can be described in the relational model (Codd,
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.
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-orient-
ed architecture, as opposed to the prevalent combination of data and function ar-
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-
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
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-
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
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 togeth-
er 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 vari-
ous aspect systems (See Perry (1999) for a presentation of some of these issues 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.
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-
Time span 50ies 60ies 70ies 80ies 90ies Next
Business Function- Functional Distribution Business Supply Web-en-
Architec- al Hier- Hierarchy Logistics process Chain abled
Business implicit implicit Data mod- Client / Federa- Model
Model Ar- els Server tions based
Software no Function DBMS RDBMS Enterprise Generic
Architec- oriented 3-tier applica- compon-
ture GUI tions ents
ICT Archi- limited mainframe information networks multi-site, ubiquitous
tecture islands n-tier 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
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
Aspect Structure Interaction Distribution
Business Stores Business processes Enterprise topology:
Factories Business transac- Multi-site
Transportation tions Scope
Products Material flow Functional Partition
Business Model Meta models Workflows Data topology
Data models Process topology
Process models Relations
Software Applications Module Interac- Instance topology
ICT platform Machines Call patterns Resource topology
Databases / Stores Data streams
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-
Aspect Stakeholders Concerns Performance measures
Business Manager Goal orientation Lead-times
Customer Customer orienta- Productivity
Return on Investment
Business Model Information of- Completeness Compliance with std’s
ficer Extensibility Stability of interfaces
Software Users Function Transaction /user
Developers Structure Performance
Behavior Response time
ICT platform Operators Speed Execution performance
Administrators Connectivity Bandwidth/throughput
Table 3. Stakeholders, concerns and performance measures of domain architectures
4.1 Complexity in inter-domain development
The 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-
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.
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 plat-
form domains by its separation of the conceptual (semantic), external (user-related) and
physical (storage related) models. Within each of the four domains of enterprise architec-
ture 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
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
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 loc-
al 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
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
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.
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 oth-
er 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 processes.
Innovative (class 1) architecture changes are thus integral changes that span several do-
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.
4.3 Leveraging and enabling
A 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.
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 typic-
al 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
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.
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-
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.