Integrated Architectural Design of Business and Information Systems 1 Integrated Architectural Design of Business and Information Systems 1 1 This paper is a result of a joint research project between the Vrije Universiteit and Cap Gemini in the field of ICT architecture. Hans Goedvolk Cap Gemini, Utrecht The Netherlands [email protected]Hans de Bruin Vrije Universiteit, Amsterdam The Netherlands [email protected]Daan Rijsenbrij Vrije Universiteit, Amsterdam The Netherlands [email protected]__________________________________________________________________________________ Abstract The current integration of information and communication technology (ICT) will profoundly change information systems and the business they support. While the current generation of information systems focuses on supporting the business of a single company. In the future, networks will integrate the information systems of companies and their customers and suppliers. The next generation information systems will support complete supply chains, not only involving companies, but also customers. As a result, customers can be treated as individuals again, catering to their needs by offering tailor-made products and services. Thus, advancements in technology lead to new business models, new products and services, and new organisations. The question now is how can we align the transformation of the business with development of information systems. Cap Gemini regards architectural design as the prime means to align business transformation with ICT development. This alignment is supported by a single framework called the Integrated Architecture Framework (IAF) in which business architecture is related to ICT architecture. The architectural design approach underlying IAF allows us to assess the impact of new business models on the information systems supporting these models, and the other way around, to assess the impact of new technologies on the business models. IAF has been applied successfully to several projects of which one is described in this paper. Introduction The impact of information and communication technology on companies is increasing rapidly. The future of companies is becoming more and more dependent on the degree to assimilate these technologies, not only within their own organisations, but also in the relations with other companies. We are now witnessing the integration of information technology (IT) with communication technology. The usual abbreviation is therefore no longer IT, but rather ICT (Information and Communication Technology). Arguably, the Internet is the catalyst for this integration. The Internet technology is not restricted to wide-area networks only. It can also be used for networks ranging from a single company to agglomerations of collaborating companies.
Transcript
Integrated Architectural Design of Business and Information Systems 1
Integrated Architectural Design of Business and Information Systems1
1 This paper is a result of a joint research project between the Vrije Universiteit and Cap Gemini in the field of
The current integration of information and communication technology (ICT) will profoundly changeinformation systems and the business they support. While the current generation of informationsystems focuses on supporting the business of a single company. In the future, networks will integratethe information systems of companies and their customers and suppliers. The next generationinformation systems will support complete supply chains, not only involving companies, but alsocustomers. As a result, customers can be treated as individuals again, catering to their needs byoffering tailor-made products and services. Thus, advancements in technology lead to new businessmodels, new products and services, and new organisations. The question now is how can we align thetransformation of the business with development of information systems. Cap Gemini regardsarchitectural design as the prime means to align business transformation with ICT development. Thisalignment is supported by a single framework called the Integrated Architecture Framework (IAF) inwhich business architecture is related to ICT architecture. The architectural design approachunderlying IAF allows us to assess the impact of new business models on the information systemssupporting these models, and the other way around, to assess the impact of new technologies on thebusiness models. IAF has been applied successfully to several projects of which one is described inthis paper.
Introduction
The impact of information and communication technology on companies is increasing rapidly. Thefuture of companies is becoming more and more dependent on the degree to assimilate thesetechnologies, not only within their own organisations, but also in the relations with other companies.We are now witnessing the integration of information technology (IT) with communicationtechnology. The usual abbreviation is therefore no longer IT, but rather ICT (Information andCommunication Technology). Arguably, the Internet is the catalyst for this integration. The Internettechnology is not restricted to wide-area networks only. It can also be used for networks ranging froma single company to agglomerations of collaborating companies.
Integrated Architectural Design of Business and Information Systems 2
Current Situation� Information Technology (IT)
� Stand-alone Systems� Data and Information� Monolithic Systems� Support of Internal Organisation� Support of Mass-Production
Future Situation� Information and Communication
Technology (ICT)� Networked Systems� Communication and Knowledge� Component-based Systems� Support of External Relations� Support of Mass-Customisation
Figure 1: From IT to ICT.
The transition from IT to ICT has a number of consequences as is depicted in Figure 1. The currentgeneration of information systems typically focus on the information supply within a single company.They usually support very specific business functions such as the financial and the employeeadministration. It is expected that these stand-alone systems will be integrated in networks supportingthe internal as well as the external communication. The latter involves both companies and clients.The net result of this development is the integral co-ordination of business processes of severalcollaborating companies and the channels to the customers. Typical applications include E-commerce,supply chain management, customer relationship management and the Web-enabled enterprise
A consequence of managing the complete supply chain is that new kinds of products and services willemerge. Currently, the emphasis lies on maximising the efficiency of mass production of products andservices. New ICT applications will treat customers as individuals by offering products tailored toindividual needs. The future seems to be an ICT enabled, customer focused enterprise, in which allforms of information and communication technology are applied to enable the business. Thisenterprise will be a network (or web) linking people, competencies, facilities and capabilities ofdifferent companies or individual workers, together as though they are one enterprise. The ICTenabled enterprise will show shifting patterns of affiliations, dynamic assembly of core competenciesand the resulting virtual supply chains can take many forms. The enterprise will quickly adapt tochanges both internally and externally by changing the patterns of co-operation within the enterprise.
These developments do not only give rise to new opportunities, but also to new questions that must beanswered to successfully integrate new business models and new technologies in a company:• The first and most important question is what kind of new business models and products are
enabled by ICT and how can ICT be used as a strategic means for business innovation.• The second question then is how can we assess the implications of ICT on the business. A derived
question is how to integrate new developments in existing I(C)T systems and organisations.• The final question is how to synchronise changes in business and information systems. In
particular, how can we define a migration and transformation path in order to reduce the inherentrisks of innovation?
The answers for these questions can be found in the tight integration of business and ICT policies. CapGemini regards architecture as the prime means to establish this integration. The key idea is to relatebusiness architecture with information system and technical infrastructure architecture in a singleframework: the Integrated Architecture Framework (IAF). In this way, the impact of new businessmodels on information systems can be evaluated quickly, and the other way around, the consequencesof technology innovations can be assessed at the business level.
In this paper, we discuss IAF. In particular, we focus on how business, information system and thetechnical infrastructure architecture areas are aligned. The use of IAF is exemplified with anelaborated example. This paper starts with a discussion on architectural principles underlying IAF.
Integrated Architectural Design of Business and Information Systems 3
Architectural Principles
Business architecture and ICT architecture are emerging disciplines. As a consequence, there is nowidely accepted definition for these kinds of architectures. The vision on architecture described in thispaper is based on the role that the architect plays in the design and realisation of artefacts includingbuildings and, of course, information systems. By observing how architects design in practice, we geta handle on the nature of architecture.
The Role of the Architect
client,users
architect developers
appearance,behaviour
construction,co-operation
architecturaldesign
visualises prescribes
requirements solutions
createsassess assess
Figure 2: The role of the architect.
An architect has the following responsibilities:• Designing artefacts, in particular the design of a business and the information systems supporting
the business.• Communicating an architectural design to the stakeholders. The following prime stakeholders can
be identified: customers, end-users, and developers, that is, they commission, use, and implementa system, respectively.
• Supervising the development process.
The goal of these activities is:• To gain insight at an early stage in the qualities of an existing system or a system to be.• To use an architectural design as a guide for planning and controlling the subsequent development
stages.• To inform the stakeholders about what is built, the way it is built, and the implications on the
current situation.
The architect has a pivotal role in the development process of a system. As is depicted in Figure 2, thearchitect acts as an intermediary between, on the one hand, customers and end-users, and on the otherhand, the developers of the system.
Integrated Architectural Design of Business and Information Systems 4
ConsultantWhat Artefact
must be realised?
ArchitectHow is the
Artefact realised?
EngineerWith What is the
Artefact realised?
The Ideal ArchitectThe Ideal Architect
Figure 3: The professional roles of an architect; an architect is more than just an architect.
An architect is responsible for a system’s architecture. In principle, an architect designs a system at ahigh abstraction level by neglecting irrelevant details. In some cases, however, the details do matter.One can think of quality attributes like performance and user friendliness, which require a moredetailed design or even a prototypical implementation to assess whether the user requirements will besatisfied or not. It should be clear that an architect should possess many competencies. The idealarchitect is more than an architect; he/she is also familiar with consulting and engineering (see Figure3). In the design of complex system, an architect would typically delegate design tasks to specialists inorder to derive at a well-balanced architecture.
Architectural Artefacts
An architect designs artefacts. The term artefact can be defined as something created by humansserving a practical purpose. It can have a static nature like a house or it can be dynamic like aninformation system or the organisation of a company. Every artefact has an architecture, which isusually identified by a particular architectural style and its accompanying style characteristics.Frequently, a comparison is made with the design of buildings. An important difference whenconsidering business and ICT architecture is that besides static aspects much attention must be paid tothe dynamical aspects of the system.
As will become apparent later on, it is useful to view an artefact from two viewpoints [Dietz96]:• External view: the black-box approach
The central concepts in the external view of an artefact are behaviour and appearance. That is,from this point of view, one is interested in what an artefact does and what external form it has.
• Internal view: the white-box approachFrom the internal point of view, the emphasis lies on the construction and operation of an artefact.The internal view describes how the components of an artefact realise its external behaviour and tosome extent its appearance.
From now on, we will use the term organisation, system or component instead of the more abstractterm artefact because the former terms are typically used in the realm of business and ICT.
Architectural Design
The concept of quality plays a central role in architecture. The key question is how can we applyarchitecture in order to assess quality attributes of an existing system or a system to be? To begin withwe must define the quality attributes that we are interested in. One can think of quality attributes likeperformance, security, usability, reusability, modifiability, and portability. A typical architecturaldesign process is to first derive an architectural design that focuses on the external appearance andbehaviour, in particular, the system’s functionality. Once we are certain that the functionality
Integrated Architectural Design of Business and Information Systems 5
requirements are met, the architecture can be transformed in order to satisfy non-functionalrequirements. This iterative design process is depicted in Figure 4 (adapted from [BM99]). Notice thatviews are developed to assess quality attributes from an appropriate viewpoint. In some cases, it mightbe necessary to add attributes to views, for instance, latencies and execution time attributes forevaluating the performance of a system by means of simulation. Frequently, alternative designs aredevised that are benchmarked. That is, they are compared with respect to a set of quality attributes.The best design is then further elaborated.
RequirementsSpecification
Initial Design(External Appearance
and Behaviour)
Business/ICTArchitecture
Constructing andAttributing Views
Assessment ofQualities
Adaptation ofArchitecture
not OK
OK
Figure 4: Iterative quality design.
The question when architectural design transcends into traditional (top-down) design is easy toanswer. A system must be recursively decomposed in sub-components until the level is reached wherethe system can be evaluated. Notice that the goal of communication with the stakeholders is satisfiedimplicitly since the stakeholders are responsible for the acceptance of the architecture. In addition, notevery architectural viewpoint needs to be elaborated to the same abstraction level. The rightabstraction level is dependent on whether we are able to assess certain quality aspects or not.
A Definition of Architecture
So far, we have discussed the role of the architect and the process of architectural design. The result ofan architect’s design activities is an architecture. We are now in the position to cast more light on thiscontroversial concept.
An architectural design results in one or more models of a system. Characteristic properties of thesemodels are that they are based on architectural styles and that they describe a system from severalviewpoints. These models are the starting points in a development process that lead to the realisationof the system. Such a system has an architecture, namely the architecture that is in conformance (inprinciple at least) with the models.
In the reference work “Software Architecture in Practice”, the following definition is given, which canbe applied to other architecture disciplines as well [BCK98]:
The software architecture of a program or computing system is the structure or structures ofthe system, which comprise software components, the externally visible properties of thosecomponents, and the relationships among them.
A few issues attract the attention. Firstly, we are only interested in the externally visible properties ofcomponents, that is, the black-box approach with which we try to deliberately ignore irrelevant details.
Integrated Architectural Design of Business and Information Systems 6
Secondly, a system can have and usually does have multiple structures, which are exposed byarchitectural views. Thirdly, the principle of abstraction is enclosed in this definition. However, thedefinition does not tell us why this principle should be applied. As discussed before, one of the centralconcepts in architecture is quality. A system’s architecture is developed to gain insight in the system’squalities typically by deriving models of the system at such a level of detail that we can actually assesscertain quality attributes. As a result, it is usually not sufficient to decompose a system in a single levelof black-boxes only. Instead we should make a recursive decomposition until the appropriateabstraction level is reached.
By taking these remarks into account, we come to the following definition of architecture:
The architecture of a system are the system’s structures, which comprises the internalconstruction and collaboration of components and sub-components as far as they influence theexternal appearance and behaviour of the system as experienced by an external actor (astakeholder or a system).
The Integrated Architecture Framework (IAF)
The Integrated Architecture Framework (IAF) forms the core of Cap Gemini’s architectural designapproach. The framework relates the deliverables and methods addressing different aspects of the ICTenabled enterprise by capturing the whole scope of architectural design.
Figure 5: The Integrated Architecture Framework (IAF).
The framework has three dimensions that relate the following aspects of integrated architecturaldesign (see Figure 5):• the four main architecture areas;• the design approach;• architectural viewpoints.
Integrated Architectural Design of Business and Information Systems 7
The Main Architecture Areas
ICTICTSystemSystem
BusinessBusinessSystemSystem Information and KnowledgeInformation and Knowledge
The four main architecture areas of IAF are based on a “holistic” view on business and ICT system ofthe ICT enabled enterprise. In this view, the business is seen as two interrelated networks (see Figure6). The Business and Environment (BE) network consists of communicating and co-operating peoplein the role of employee, and of organisational units such as teams and departments. The network isorganised as one or more supply chains of individuals, organisational units and companies workingtogether in delivering products or services to the customers. The environment of a company is seen asnetwork connecting the company with customers, suppliers and other third parties.
Information and knowledge is an important enabler of the business. The BE network is supported byan Information and Knowledge (IK) network formed by people and organisational units in specific IKsupportive roles. These may be the same people and units that already have a role in the BE network.The IK network enables the business by supporting the creation, exchange, storage and use ofinformation and knowledge. The IK network in fact acts as the collective memory of the organisation.
The ICT system that supports the business is also seen as a network system in two main layers: theinformation system(s) and the technology infrastructure. The information system(s) encompass anetwork of communicating and co-operating applications. The applications work together in deliveringcommunication and information services to the people in the ICT enabled Enterprise. These automatedservices enable the data processing, communication and control in the BE network, and the creation,exchange, storage and use of data in the IK network. The technology infrastructure is seen as anetwork of communicating and co-operating hardware devices and system software and middleware.The Technology Infrastructure (TI) delivers processing, communication and storage capabilities to theinformation systems.
Information Systems
Technology Infrastructure
technology infrastructure services
Information and Knowledge
Business and Environment
automated services
information and knowledge services
InternalOrganisation
ExternalParties
productsservices
Figure 7: The enabling relations between the architecture areas.
Integrated Architectural Design of Business and Information Systems 8
The main objective of IAF is to support an architectural design an ICT enabled enterprise as onecoherent co-operation of people, information, knowledge, applications and technology. The specificadded value and benefits of IAF are in the design and assessment of the enabling relationships (seeFigure 7), interactions, and dependencies among these architecture areas and not as much in thearchitectural design of the individual areas.
Notice that the scope of IAF is considerably wider than Zachman’s framework [Zachman87, SZ92]. InIAF, architectural considerations range from business and information to technical infrastructure andthe relationships between these, while Zachman’s framework focuses on the design of informationsystems. Furthermore, the design approach with quality assessment is missing in Zachman’sframework, which is one of the driving forces in architectural design. Finally, Zachman’s frameworkis silent about design methods. It merely offers a framework in which the results of a design processcan be placed.
The design of the enterprise architecture with those four architecture areas and their interactionsprovides the information to support coherent decisions by the enterprise about:• business aspects such as products, services, distribution channels, business processes and
organisation;• the information and knowledge needed to enable the business;• the information systems i.e. applications and electronic data to enable the business and the
information and knowledge provision;• the technology infrastructure of hardware, system software and middleware to support the other
areas.
In the end, the result of an architectural design using IAF is an ICT enabled enterprise. This means: theinternal organisation of the enterprise, its products and services and its relationship with externalparties are optimally enabled by information, knowledge, information systems and technologyinfrastructure.
The Design Approach
The second dimension of IAF concerns the design approach. The design of each architecture area goesthrough four phases (see Figure 8) which are repeated in a quality assessment iteration until the clientaccepts the design
Static and Dynamic StructuresBehaviour and Appearance,
Co-operation and Construction ofRoles (Logical Components)
Physical ComponentsPeople, Software, Hardware
Vision, Strategy, ScopeRequirements and Constraints
Integrated Architectural Design of Business and Information Systems 9
The conceptual phase answers the question: What ICT enabled enterprise (i.e. its businessorganisation, information/knowledge organisation, information systems and technology infrastructure)must be realised? The deliverables include:• The vision, strategy and policies concerning the ICT enabled enterprise.• The scope of the enterprise that must be (re)designed.• The stakeholders of the design and the viewpoints they must assess.• Requirements and constraints concerning the structures and qualities of the ICT enabled
enterprise.The logical phase answers the question: How is the ICT enabled enterprise realised? The deliverablesinclude:• A design of the behaviour and appearance of the business organisation, information/knowledge
organisation, information systems and technology infrastructure of the enterprise and the productsand/or services these organisations and systems delivers.
• A design of the co-operation and construction of components of these organisations and systemswithin the enterprise. In fact the components are roles performed by people in the business andinformation/knowledge organisation, by software components in the information systems and bysoftware and hardware components in the technology infrastructure.
• The transformation stages of the ICT enabled enterprise as base for a migration or transformationplan.
The physical phase answers the question: With what is the ICT enabled enterprise realised? Thedeliverables include prescriptions for:• The capabilities of human resources in the organisation and the software and hardware
components in the information systems and technology infrastructure.• The development and realisation methods.The Quality Assessment answers the question: How good is the ICT enabled enterprise that will berealised? The deliverables include:• Views that represent the structures and qualities of the organisation and systems for assessment by
the different stakeholders.• Reports about the assessment.• Decisions about the next iteration of the architectural design.
As discussed before, the design of organisation or system is an iterative process involving architecturetransformations in order to meet the pre-set quality requirements. The iteration stops when all qualityrequirements have been satisfied. Notice that the scope of this iterative process is not restricted to theindividual architecture areas. An important goal of IAF is to design and optimal enabling of thebusiness by information, knowledge and ICT. Figure 9depicts the relations between an enabled andenabling area in the design approach.
CommonQuality
AssessmentIteration
Enabled Area
Construction andCo-operation
Appearance andBehaviour
Components
Requirements,Constraints
Enabling Area
EnablingServices
Quality Viewsof Enabling Services and Both Areas
Construction andCo-operation
Appearance andBehaviour
Components
Requirements,Constraints
EnablingRequirementsConstraints
Figure 9: Relation between Enabled and Enabling Area.
Integrated Architectural Design of Business and Information Systems 10
The architectural design of an enabled area imposes enabling requirements on the enabling area. Forinstance the architectural design of the business and environment area imposes requirements for itsenabling by automated services on the information systems area. The enabling area uses theserequirements as input for its conceptual phase. The architectural design of the enabling area is aimedat an external appearance and behaviour that is able to deliver the required enabling services. Theassessment of the enabling is realised by a common quality view on both areas from the enabling pointof view. The design of both areas is repeated until the enabling requirements are satisfied. Theconsequence is that when an architectural design is made in one area it is necessary to perform anarchitectural design of all other areas that are enabled by the area because they contribute to therequirements of the design. For instance, the design of an information system for a department needsfor its requirements a logical design of the business and information at that department.
In order to realise an optimal ICT enabled enterprise it is necessary to perform the design and thequality assessment iteration for all main architecture areas of IAF. But an architectural design of alarge enterprise that can directly serve as input for realisation by developers will contain so muchdetail that it is impossible to assess it as a whole. By realising the design at different abstraction levelsit is possible to prevent this problem.
Essentially there are two different abstraction levels in the architectural design of an ICT enabledenterprise: the enterprise-level and the project-level.
The enterprise-level design is a high-level architectural design of the ICT enabled enterprise as awhole. The aim of the design is a high-level “zoning” plan of the future business, information supply,information systems and technology infrastructure at the level of organisational units and subsystemsthat correspond to important roles or functions in the organisations and systems. The enterprise-leveldesign also makes representations of the intermediate stages (islands of stability) that business andsystems will pass when transforming in the direction of the future ICT enabled enterprise.Stakeholders for assessment of the enterprise-level design are at strategic or tactical level.
The project-level design is the architectural design of a part of the ICT enabled enterprise that isrealised subsequently by a project. The design contains all the details that are important for realisation.Stakeholders are at tactical and operational level, mainly the people that are directly involved asemployee within that part of the organisation or user of the information system.
QualityAssessment
EnterpriseRequirements
EnterpriseStructures
Project-levelRequirements
Project-levelStructures
Subsystems
as-is to-be
Components
as-is to-be
ConceptualDesign
LogicalDesign
PhysicalDesign
QualityAssessment
QualityAssessment+ Iteration
Enterprise Level Project Level
ConstraintsRequirements
FeedbackRequirements
Figure 10: Enterprise-level and Project-level Design.
Figure 10 shows the relationship between enterprise-level design of the whole ICT enabled enterpriseand the project-level design of business and ICT subsystems within the enterprise. The enterprise-leveldesign and the different project-level designs each consist of a conceptual, logical and physical design
Integrated Architectural Design of Business and Information Systems 11
and a quality assessment iteration until the design is accepted. The enterprise-level design acts in factas one big set of requirements and constraints for the designs at project-level.
The project-level designs must realise these requirements and constraints. In the case that this is notfeasible, an adaptation of the enterprise-level may be necessary. Enterprise-level design is therefore acontinuous activity. The enterprise-level architecture is a real zoning plan: It is continually adapted onthe base of feedback from the project-level designs.
Architectural Viewpoints
The third dimension of IAF concerns specific architectural viewpoints. One of the central issues inarchitectural design is the design and assessment of certain structures and qualities of an organisationor system. We have already seen that the design of an architecture area is an iterative processcontrolled by quality considerations. Many quality attributes can be assessed comprehensively withina certain architecture area (e.g., performance and portability), but not all. The assessment of somequality attributes requires a broader scope. For instance, security cannot be addressed at the IS and TIarchitecture areas only, but requires an overall vision since measures taken in one area have an impacton the other areas. For this reason, a coherent approach to architectural design is required that spans allarchitecture areas. The architectural viewpoint dimension of IAF is intended for this purpose. Atpresent, two methods have been developed that address the following overall structure or qualityattributes:• The security of the ICT enabled enterprise. This design method is also applicable for existing
companies that want to improve the security of their organisation and systems;• Systems Management of information systems and technology infrastructure. The design includes
the systems management organisation and its processes, information and information systems.
A new development is the architectural design of the adaptability through the whole ICT enabledenterprise.
IAF Example: Facility Services
The Facility Services (FS) is a department of a multinational. It provides internal services likefinancial administration and human resource management, as well as external services for customersand organisations such as copying, cleaning and leasing. FS will be privatised in the near future, whichhas several consequences. The ICT provisions of FS must be prepared for the future. Even stronger,the management of FS regards ICT as an enabler for offering new products and services to thecustomers in a timely way.
This example shows an enterprise-level architectural design using IAF that relates the organisation ofa business with ICT in order to assess the feasibility of the strategy of FS. In particular, IAF has beenused to assess whether FS has the potential to adapt for facing new challenges in a cost-effectivemanner.
Strengths and Weaknesses
The co-ordination of complex facility services, which comprise the secondary business processes andinformation supply, is the core competence of FS. This provides FS with a competitive edge in theirbranch. In addition, FS has a vast knowledge of the ICT services offered by other players, whichallows FS to quickly interface and co-operate with new customers in the same branch. FS has noexperience as an autonomous organisation, which has to anticipate new opportunities and counteractthreats. These competencies must be acquired in the process of detaching from their umbrellaorganisation.
Integrated Architectural Design of Business and Information Systems 12
Requirements and Future Directions
The current ICT policy is based on supporting facility services with dedicated ICT solutions. The prosand cons of a “make-or-buy” solution are assessed carefully. However, less attention has been paid tothe integration of these services, resulting in ICT islands supporting very specific services. ICT is notexplicitly used to enable new forms of organisation or services.
NewServices
ExistingServices
ExistingCustomers
NewCustomers
ICT forimprovingefficiency
ICT asenabler
Growth Path
Integrated Services
Figure 11: The growth path of Facility Services.
A growth path has been defined comprised of two stages (see Figure 11):1. offer new services to the existing customers;2. offer new, integrated services to existing and new customers.
The long-term goal is to transform FS from a service provider into a co-ordinator of integrated serviceofferings. ICT is seen as the key enabler for this process by providing the means to efficiently co-ordinate services possibly offered by sub-contractors.
A flexible organisation is required to adapt swiftly for facing new challenges. Since the organisationstructures will be subjected to continuous change, it is difficult to line up the ICT organisation with thebusiness organisation. For this reason, the organisation will be organised in small business units thatplay specific roles in the organisation. These units will be supported by ICT applications, which inessence have to concentrate on a single role only. Integrated services can then be offered to customersby setting up alliances of business units. In this way, new units can be easily incorporated in theorganisation, and the provided services can be easily integrated in other services.
The customer should not be aware of this organisation for offering integrated services. An importantrequirement is therefore one face to the customer, which entails:• one account and one account manager per project per customer;• if required, one invoice per project per customer;• a service may be offered through multiple channels.
Approach
Since the organisation of the business and the ICT goes hand in hand, the consequences for purchasingfuture directions cannot be analysed in isolation. For this reason, the feasibility study has beenconducted that uses IAF to relate business issues with ICT issues.
The desired organisation, which is partly reflected in the current ICT solution, is used as a startingpoint in the assessment of the requirements. The following phases have been followed:1. envisioning the desired situation;2. devising alternative solutions;3. evaluating the alternatives from a flexibility and cost-effectiveness point of view;4. elaborating one alternative, provided that future directions can be reached.
Integrated Architectural Design of Business and Information Systems 13
Envisioning the Desired Situation
Production ServicesCustomers
CustomerServices
CustomerChannels
Co-ordinationServices
Internal Production
Units
Machine
InvoicingIden
tifi
cati
e / A
uth
enti
cati
e
Service desk
accountmngr
SLAmgmt
ExternalProduction
units
Productionmgmnt
Suppliermgmt
Sales
MarketingInt*net
Help desk
Pers. Ass.
Serv. Point
Smartcard
Call Center
Other
Figure 12: The FS organization.
The goal of this phase is to relate business processes with ICT support to obtain an overall view of thedesired situation. The following steps have been carried out:1. identifying organisational units and other actors (internal and external);2. identifying their roles and interaction in the business process;3. identifying necessary information for each role and the processes to provide this information.
This is a high-level logical design in the BE and IK-area of IAF. The result of step 1 is reflected inFigure 12.
Alternative Information Systems Solutions
The next stage is the enterprise-level design of the information systems that support the designedbusiness roles in their business processes and information exchange and storage. Four alternativeswere conceived (see Figure 13), that are primarily evaluated in relation with the Business andEnvironment (BE) and the Information and Knowledge (IK) architecture areas with respect toenabling the flexibility of the organisation and the total cost-effectiveness.
Integrated Architectural Design of Business and Information Systems 14
Marketing
ProductieRegie
LeveranciersManagement
Betaler
Besteller
Beslisser
Inkoper
Smartcard
Automaat
Call Center
Balie/kiosk
Persoon
Infozuil
Other
Identificatie
Verkoop
Servicedesk
SLA-management
Facturatie
Interne productie units
Externe productie units
Int*net
ERP
ERP
ERP
ERP
ERP
ERP
ERP
Production
Production
Marketing
ProductieRegie
LeveranciersManagement
Betaler
Besteller
Beslisser
Inkoper
Smartcard
Automaat
Call Center
Balie/kiosk
Persoon
Infozuil
Other
Identificatie
Verkoop
Servicedesk
SLA-management
Facturatie
Interne productie units
Externe productie units
Int*net
ServiceDesk
Application
SalesSystem
MarketingSystem
Inv. System
Marketing
ProductieRegie
LeveranciersManagement
Betaler
Besteller
Beslisser
Inkoper
Smartcard
Automaat
Call Center
Balie/kiosk
Persoon
Infozuil
Other
Identificatie
Verkoop
Servicedesk
SLA-management
Facturatie
Interne productie units
Externe productie units
Int*net
SalesSystem
SeviceDesk
Application
SLASystem
Prod.and
Mgmt
System
Inv.System
MarketingSystem
Marketing
ProductieRegie
LeveranciersManagement
Betaler
Besteller
Beslisser
Inkoper
Smartcard
Automaat
Call Center
Balie/kiosk
Persoon
Infozuil
Other
Identificatie
Verkoop
Servicedesk
SLA-management
Facturatie
Interne productie units
Externe productie units
Int*net
Integrated Customer- en Management
Services System
1. ERP 2. Current production systems
3. Production system perorganisational unit
4. One integrated customer andproduction management system
Figure 13: The information systems alternatives.
The four alternatives can be summarised as:1. ERP (Enterprise Resource Planning)
An ERP package is comprised of several modules that handle specific services. The emphasis lieson production system support rather than customer support.
2. Current production systemsThe current production systems will be used and where necessary they will be augmented withnew functionality.
3. Information systems per business roleInformation systems will be restricted to support the specific role of a organisational unit only.The systems communicate by means of a standardised interface mechanism.
4. One integrated customer and production management systemThis solution is like alternative 3 with the exception of the use of a single system for managementand customer services.
The pros and cons of these alternatives are shown in Table 1 (OTS stands for Of-The-Shelf, typicalOTS applications include word-processors, spreadsheets, databases, e-mail packages and financialpackages).
Alternatives Flexibility Cost-Effectiveness
1. ERP • integration is easy (+)• fixes the business
organisation (-)• unsuited for IT enabling (-)• no complete coverage (-)
• expensive implementation (-)• must be interfaced with other ICT
applications for complete coverage (-)
2. Currentproductionsystems
• can use OTS applications (+)• difficult to integrate (-)• no integrated services (-)
• buy the best, make the rest (+)• expensive integration (-)
3. Productionsystem per
• uses OTS applications (+)• required functionality is not
• buy the best, make the rest (+)• expensive integration initially (-)
Integrated Architectural Design of Business and Information Systems 15
business role guaranteed by OTSapplications (-)
• integration is relatively easy(+)
• inexpensive integration operationally(+)
4. Integratedsystem for themanagementand customerservices
• tailored to FS needs (+)• large monolithic systems may
be difficult to develop,maintain and adapt (-)
• see alternative 3• very expensive to develop (-)
Table 1: Evaluating alternatives
Elaborating Alternative 3: Production System per Organisational Unit
By taking the pros and cons into account, it was decided to elaborate the third alternative. Theconsequences for purchasing this alternative were evaluated mainly at the Information System (IS) andTechnical Infrastructure (TI) architecture areas. However, the impact of technology-driven solutionswere assessed again at the business level to assure that the business requirements set out by themanagement are satisfied. One consequence was clear from the outset, namely that the FS organisationhas to adapt to OTS applications. This is not necessarily a bad thing, the FS organisation must beprepared to adapt anyway, not only by customer forces, but also by new technologies.
The quality attributes that are of interest in the IS and TI architecture areas include flexibility, securityand performance. Notice that cost-effectiveness is a less important quality attribute since the decisionto use cost-effective OTS applications was already made at the BE and IK architectural levels.
The Information System concept can be summarised as follows:• an OTS application must support preferably a three-tier-architecture, i.e., separation of data,
business logic, and user interface (flexibility);• a message broker will be used to exchange information between (OTS) applications and to
synchronise business processes (flexibility, security, and performance);• specific OTS requirements:
• FS-Core (integrated customer and production management system): three tier architecture;• FS-Front-End (call-centre, smart-card, customer service point, help desk): WEB
technologies (XML, Java);• FS-Production Systems (very specific, single services): (de-facto) industrial standards;• General OTS office systems (word-processors, spreadsheets, and e-mail): (de-facto)
industrial standards.
By using OTS applications based on three-tier-architectures and by using de-facto industrial standardsand technologies, the requirements imposed from a business perspective (e.g., flexibility and cost-effectiveness) can be satisfied.
The requirements for TI can be summarised as a trade-off between cost-effectiveness, security,performance, and application issues. Without going into detail here, logical infrastructure alternativesconcentrating on network facilities have been devised to assess the IS concept at the TI architecturallevel. The outcome was that the IS concept can be supported.
As discussed before, the IS and TI concepts have an impact on the business organisation:• ICT will play a more prominent role, not only for increasing efficiency, but more importantly as
enabler to renew products and services.• OTS applications will determine to a large extent the organisation of business processes.
Integrated Architectural Design of Business and Information Systems 16
• An architectural concept that is developed provides the means for integrating new OTSapplications. The architectural principles must therefore be protected against erosion. Thisrequires:• a managing architect (guarding and guiding);• an ICT representative in the management team.
Concluding Remarks
IAF has been used to assess the impact of ICT on the business, and vice versa. This has been done atthe enterprise level of abstraction in this feasibility study. The next step is to elaborate the architectureareas while continuously assessing the impact of decisions in one area on the other ones. IAF provedto be a valuable tool for relating architectural issues at the appropriate level of abstraction.
Conclusions
We have argued that ICT enabled enterprises must be designed from different architecturalperspectives to relate the business with the technology that enables the business. IAF provides theframework to establish this relation. It can be regarded as a reference architecture frameworkprescribing how an architectural design should be approached. In addition, rules and guidelines can beincluded in the framework, thereby guiding and directing architectural designs. This ensures company-wide a coherent co-operation of business and ICT systems. It ensures also a common “look-and feel”of the information systems and even the business processes. We have shown in an example how IAFhas been applied successfully in practice. Although the example concentrated on high levelarchitectural design, IAF can also be used for more detailed designs in all architecture areas. In fact,this is one of the most important assets of IAF; it relates architecture areas at all abstraction levels andit provides the context with which architectural design decisions can be traced back.
References
[AWG98] Architecture Working Group. Recommended practice for architectural description.Draft IEEE Standard P1471/D4.1, IEEE, December 1998.
[BCK98] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. SEISeries in Software Engineering. Addison-Wesley, Reading, Massachusetts, 1998.
[BM99] Software Architecture Design: Evaluation and Transformation, Jan Bosch and PeterMolin. IEEE Engineering of Computer Based Systems Symposium (ECBS99),December 1999.
[BMRSS96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and MichaelStal. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley andSons, Chichester, England, 1996.
[Dietz96] Jan L.G. Dietz. Introductie tot DEMO / Een reis door Kabouterland (in Dutch).Samson, 1996. ISBN 9014 05327 4.
[SG96] Mary Shaw and David Garlan. Software Architecture: Perspectives on an EmergingDiscipline. Prentice Hall, New Jersey, 1996.
[SZ92] J.F. Sowa and J.A. Zachman. Extending and formalizing the framework forinformation systems architecture. IBM Systems Journal, 31(3):590-616, 1992.
[Zachman87] J.A. Zachman. A framework for information systems architecture. IBM SystemsJournal, 26(3):276-292, 1987.
