Integrated Architectural Design of Business and Information Systems

  1 Integrated Architectural Design of Business and Information Systems

  Hans Goedvolk Hans de Bruin Daan Rijsenbrij Cap Gemini, Utrecht Vrije Universiteit, Amsterdam Vrije Universiteit, Amsterdam

  The Netherlands The Netherlands The Netherlands

  Hans.Goedvolk@capgemini.nl hansdb@cs.vu.nl daan@cs.vu.nl

  __________________________________________________________________________________

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.

  Current Situation Future Situation

Ÿ Ÿ Information and Communication

  Information Technology (IT) Technology (ICT) Ÿ Stand-alone Systems Ÿ Networked Systems

  Data and Information

Ÿ Ÿ Communication and Knowledge

Ÿ Monolithic Systems Ÿ Component-based Systems Ÿ Support of Internal Organisation Ÿ Support of External Relations

Ÿ Support of Mass-Production Ÿ 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 current generation 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 employee administration. It is expected that these stand-alone systems will be integrated in networks supporting the 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 several collaborating 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 will emerge. Currently, the emphasis lies on maximising the efficiency of mass production of products and services. New ICT applications will treat customers as individuals by offering products tailored to individual needs. The future seems to be an ICT enabled, customer focused enterprise, in which all forms of information and communication technology are applied to enable the business. This enterprise will be a network (or web) linking people, competencies, facilities and capabilities of different companies or individual workers, together as though they are one enterprise. The ICT enabled enterprise will show shifting patterns of affiliations, dynamic assembly of core competencies and the resulting virtual supply chains can take many forms. The enterprise will quickly adapt to changes 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 be answered 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 inherent risks of innovation? The answers for these questions can be found in the tight integration of business and ICT policies. Cap Gemini regards architecture as the prime means to establish this integration. The key idea is to relate business architecture with information system and technical infrastructure architecture in a single framework: the Integrated Architecture Framework (IAF). In this way, the impact of new business models on information systems can be evaluated quickly, and the other way around, the consequences of 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 the technical infrastructure architecture areas are aligned. The use of IAF is exemplified with an elaborated example. This paper starts with a discussion on architectural principles underlying IAF.

Architectural Principles

  Business architecture and ICT architecture are emerging disciplines. As a consequence, there is no widely accepted definition for these kinds of architectures. The vision on architecture described in this paper is based on the role that the architect plays in the design and realisation of artefacts including buildings and, of course, information systems. By observing how architects design in practice, we get a handle on the nature of architecture.

The Role of the Architect

  

requirements solutions

client,

architect

developers users

creates

assess assess prescribes visualises appearance, architectural construction, behaviour design co-operation

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 implement a 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, the architect acts as an intermediary between, on the one hand, customers and end-users, and on the other hand, the developers of the system.

  

The Ideal Architect

The Ideal Architect

  

Consultant Architect Engineer

What Artefact How is the With What is the

must be realised? Artefact realised? Artefact realised?

  

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 a high 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 more detailed design or even a prototypical implementation to assess whether the user requirements will be satisfied or not. It should be clear that an architect should possess many competencies. The ideal architect is more than an architect; he/she is also familiar with consulting and engineering (see Figure 3). In the design of complex system, an architect would typically delegate design tasks to specialists in order to derive at a well-balanced architecture.

Architectural Artefacts

  An architect designs artefacts. The term artefact can be defined as something created by humans serving a practical purpose. It can have a static nature like a house or it can be dynamic like an information system or the organisation of a company. Every artefact has an architecture, which is usually identified by a particular architectural style and its accompanying style characteristics. Frequently, a comparison is made with the design of buildings. An important difference when considering business and ICT architecture is that besides static aspects much attention must be paid to the 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 approach From 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 to some extent its appearance.

  From now on, we will use the term organisation, system or component instead of the more abstract term 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 apply architecture in order to assess quality attributes of an existing system or a system to be? To begin with we must define the quality attributes that we are interested in. One can think of quality attributes like performance, security, usability, reusability, modifiability, and portability. A typical architectural design process is to first derive an architectural design that focuses on the external appearance and behaviour, in particular, the system’s functionality. Once we are certain that the functionality requirements are met, the architecture can be transformed in order to satisfy non-functional requirements. This iterative design process is depicted in Figure 4 (adapted from [BM99]). Notice that views are developed to assess quality attributes from an appropriate viewpoint. In some cases, it might be necessary to add attributes to views, for instance, latencies and execution time attributes for evaluating the performance of a system by means of simulation. Frequently, alternative designs are devised that are benchmarked. That is, they are compared with respect to a set of quality attributes. The best design is then further elaborated.

  Requirements Specification Initial Design (External Appearance and Behaviour) Business/ICT Adaptation of Architecture Architecture Constructing and Attributing Views not OK Assessment of Qualities OK

Figure 4: Iterative quality design.

  The question when architectural design transcends into traditional (top-down) design is easy to answer. A system must be recursively decomposed in sub-components until the level is reached where the system can be evaluated. Notice that the goal of communication with the stakeholders is satisfied implicitly since the stakeholders are responsible for the acceptance of the architecture. In addition, not every architectural viewpoint needs to be elaborated to the same abstraction level. The right abstraction 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 of an architect’s design activities is an architecture. We are now in the position to cast more light on this controversial concept. An architectural design results in one or more models of a system. Characteristic properties of these models are that they are based on architectural styles and that they describe a system from several viewpoints. These models are the starting points in a development process that lead to the realisation of the system. Such a system has an architecture, namely the architecture that is in conformance (in principle at least) with the models. In the reference work “Software Architecture in Practice”, the following definition is given, which can be applied to other architecture disciplines as well [BCK98]:

  The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. A few issues attract the attention. Firstly, we are only interested in the externally visible properties of components, that is, the black-box approach with which we try to deliberately ignore irrelevant details. Secondly, a system can have and usually does have multiple structures, which are exposed by architectural views. Thirdly, the principle of abstraction is enclosed in this definition. However, the definition does not tell us why this principle should be applied. As discussed before, one of the central concepts in architecture is quality. A system’s architecture is developed to gain insight in the system’s qualities typically by deriving models of the system at such a level of detail that we can actually assess certain quality attributes. As a result, it is usually not sufficient to decompose a system in a single level of black-boxes only. Instead we should make a recursive decomposition until the appropriate abstraction 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 internal construction and collaboration of components and sub-components as far as they influence the external appearance and behaviour of the system as experienced by an external actor (a stakeholder or a system).

The Integrated Architecture Framework (IAF)

  The Integrated Architecture Framework (IAF) forms the core of Cap Gemini’s architectural design approach. The framework relates the deliverables and methods addressing different aspects of the ICT

  enabled enterprise by capturing the whole scope of architectural design. _{Approach Approach Design Design Viewpoints Viewpoints Architectural Architectural} Conceptual Conceptual _{Logical Logical (What) (What) (How) (How) Business & Business & Information & Information & Information Information Technology Technology BE BE IK}

_IK

_{IS IS TI TI (With What) Assessment (With What) Assessment (How Good) (How Good) Physical Physical Quality Quality} Environment Knowledge Systems Infrastructure _{Environment Knowledge Systems Infrastructure Main Architecture Areas} Main Architecture Areas

Figure 5: The Integrated Architecture Framework (IAF).

  The framework has three dimensions that relate the following aspects of integrated architectural design (see Figure 5):

• the four main architecture areas;
• the design approach; • architectural viewpoints.

  The Main Architecture Areas _{System System Business Business}

_{Information and Knowledge Information and Knowledge}

_{Business and Environment Business and Environment}

_{ICT ICT System System Technology Infrastructure Technology Infrastructure}

Information System(s) Information System(s)

Figure 6: The view on the ICT enabled enterprise.

  The four main architecture areas of IAF are based on a “holistic” view on business and ICT system of the ICT enabled enterprise. In this view, the business is seen as two interrelated networks (see Figure 6). The Business and Environment (BE) network consists of communicating and co-operating people in the role of employee, and of organisational units such as teams and departments. The network is organised as one or more supply chains of individuals, organisational units and companies working together in delivering products or services to the customers. The environment of a company is seen as network 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 by an Information and Knowledge (IK) network formed by people and organisational units in specific IK supportive 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 of information 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: the information system(s) and the technology infrastructure. The information system(s) encompass a network of communicating and co-operating applications. The applications work together in delivering communication and information services to the people in the ICT enabled Enterprise. These automated services 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 a network of communicating and co-operating hardware devices and system software and middleware. The Technology Infrastructure (TI) delivers processing, communication and storage capabilities to the information systems.

  

Business and Environment

Internal products External

Organisation services Parties

information and knowledge services

  

Information and Knowledge automated services Information Systems technology infrastructure services Technology Infrastructure

Figure 7: The enabling relations between the architecture areas. The main objective of IAF is to support an architectural design an ICT enabled enterprise as one

  coherent co-operation of people, information, knowledge, applications and technology. The specific

  added value and benefits of IAF are in the design and assessment of the enabling relationships (see Figure 7), interactions, and dependencies among these architecture areas and not as much in the architectural design of the individual areas.

  Notice that the scope of IAF is considerably wider than Zachman’s framework [Zachman87, SZ92]. In

  IAF, architectural considerations range from business and information to technical infrastructure and the relationships between these, while Zachman’s framework focuses on the design of information systems. Furthermore, the design approach with quality assessment is missing in Zachman’s framework, which is one of the driving forces in architectural design. Finally, Zachman’s framework is silent about design methods. It merely offers a framework in which the results of a design process can be placed.

  The design of the enterprise architecture with those four architecture areas and their interactions provides 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: the internal organisation of the enterprise, its products and services and its relationship with external parties are optimally enabled by information, knowledge, information systems and technology infrastructure.

  The Design Approach

  The second dimension of IAF concerns the design approach. The design of each architecture area goes through four phases (see Figure 8) which are repeated in a quality assessment iteration until the client accepts the design _{Conceptual Conceptual} Vision, Strategy, Scope _{(What) (What)} Requirements and Constraints

  Products/Services and Qualities _{Logical Logical} Static and Dynamic Structures Behaviour and Appearance, Quality (How) (How) Co-operation and Construction of Assessment Roles (Logical Components) Iteration _{(With What) (With What) Physical Physical Physical Components Assessment Assessment Quality Quality Quality Views} People, Software, Hardware _{(How Good) (How Good)} of Products/Services, Structures and Components

  

Figure 8: The design approach. The conceptual phase answers the question: What ICT enabled enterprise (i.e. its business organisation, 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 deliverables include:

• A design of the behaviour and appearance of the business organisation, information/knowledge

  organisation, information systems and technology infrastructure of the enterprise and the products and/or services these organisations and systems delivers.

• • A design of the co-operation and construction of components of these organisations and systems

  within the enterprise. In fact the components are roles performed by people in the business and information/knowledge organisation, by software components in the information systems and by software and hardware components in the technology infrastructure.

• • The transformation stages of the ICT enabled enterprise as base for a migration or transformation

  plan.

  The physical phase answers the question: With what is the ICT enabled enterprise realised? The deliverables 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 be realised? 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 architecture transformations in order to meet the pre-set quality requirements. The iteration stops when all quality requirements have been satisfied. Notice that the scope of this iterative process is not restricted to the individual architecture areas. An important goal of IAF is to design and optimal enabling of the business by information, knowledge and ICT. Figure 9depicts the relations between an enabled and enabling area in the design approach.

  Enabled Area Enabling Area Requirements, Requirements, Enabling Constraints Constraints Requirements Common Constraints Appearance and Appearance and Quality Behaviour Behaviour Assessment Iteration Construction and Construction and Enabling Co-operation Co-operation Services Components Components Quality Views of Enabling Services and Both Areas

Figure 9: Relation between Enabled and Enabling Area. The architectural design of an enabled area imposes enabling requirements on the enabling area. For instance the architectural design of the business and environment area imposes requirements for its enabling by automated services on the information systems area. The enabling area uses these requirements as input for its conceptual phase. The architectural design of the enabling area is aimed at an external appearance and behaviour that is able to deliver the required enabling services. The assessment of the enabling is realised by a common quality view on both areas from the enabling point of view. The design of both areas is repeated until the enabling requirements are satisfied. The consequence is that when an architectural design is made in one area it is necessary to perform an architectural design of all other areas that are enabled by the area because they contribute to the requirements of the design. For instance, the design of an information system for a department needs for 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 the quality assessment iteration for all main architecture areas of IAF. But an architectural design of a large enterprise that can directly serve as input for realisation by developers will contain so much detail that it is impossible to assess it as a whole. By realising the design at different abstraction levels it is possible to prevent this problem. Essentially there are two different abstraction levels in the architectural design of an ICT enabled enterprise: the enterprise-level and the project-level.

  The enterprise-level design is a high-level architectural design of the ICT enabled enterprise as a whole. 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 subsystems that correspond to important roles or functions in the organisations and systems. The enterprise-level design also makes representations of the intermediate stages (islands of stability) that business and systems 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 is realised 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 as employee within that part of the organisation or user of the information system.

  Enterprise Level _{Conceptual Design Requirements Requirements Enterprise Project-level Enterprise Project-level Requirements Constraints} Project Level _Physical Logical _{Design Design as-is to-be as-is to-be Subsystems Components Structures Structures Assessment + Iteration} Quality _{Assessment Assessment Quality Quality Requirements Feedback}

Figure 10: Enterprise-level and Project-level Design.

  Figure 10 shows the relationship between enterprise-level design of the whole ICT enabled enterprise and the project-level design of business and ICT subsystems within the enterprise. The enterprise-level design and the different project-level designs each consist of a conceptual, logical and physical design and a quality assessment iteration until the design is accepted. The enterprise-level design acts in fact as 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 not feasible, an adaptation of the enterprise-level may be necessary. Enterprise-level design is therefore a continuous activity. The enterprise-level architecture is a real zoning plan: It is continually adapted on the base of feedback from the project-level designs.

  Architectural Viewpoints

  The third dimension of IAF concerns specific architectural viewpoints. One of the central issues in architectural design is the design and assessment of certain structures and qualities of an organisation or system. We have already seen that the design of an architecture area is an iterative process controlled by quality considerations. Many quality attributes can be assessed comprehensively within a certain architecture area (e.g., performance and portability), but not all. The assessment of some quality attributes requires a broader scope. For instance, security cannot be addressed at the IS and TI architecture areas only, but requires an overall vision since measures taken in one area have an impact on the other areas. For this reason, a coherent approach to architectural design is required that spans all architecture areas. The architectural viewpoint dimension of IAF is intended for this purpose. At present, two methods have been developed that address the following overall structure or quality attributes:

• 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 enabled enterprise.

IAF Example: Facility Services

  The Facility Services (FS) is a department of a multinational. It provides internal services like financial administration and human resource management, as well as external services for customers and organisations such as copying, cleaning and leasing. FS will be privatised in the near future, which has 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 the customers in a timely way.

  This example shows an enterprise-level architectural design using IAF that relates the organisation of a business with ICT in order to assess the feasibility of the strategy of FS. In particular, IAF has been used to assess whether FS has the potential to adapt for facing new challenges in a cost-effective manner.

Strengths and Weaknesses

  The co-ordination of complex facility services, which comprise the secondary business processes and information supply, is the core competence of FS. This provides FS with a competitive edge in their branch. In addition, FS has a vast knowledge of the ICT services offered by other players, which allows FS to quickly interface and co-operate with new customers in the same branch. FS has no experience as an autonomous organisation, which has to anticipate new opportunities and counteract threats. These competencies must be acquired in the process of detaching from their umbrella organisation.

Requirements and Future Directions

  The current ICT policy is based on supporting facility services with dedicated ICT solutions. The pros and cons of a “make-or-buy” solution are assessed carefully. However, less attention has been paid to the integration of these services, resulting in ICT islands supporting very specific services. ICT is not explicitly used to enable new forms of organisation or services.

  ICT as New enabler Services Growth Path

  ICT for Existing improving Integrated Services Services efficiency

Existing New

Customers Customers

  

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 service offerings. 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 organisation structures will be subjected to continuous change, it is difficult to line up the ICT organisation with the business organisation. For this reason, the organisation will be organised in small business units that play specific roles in the organisation. These units will be supported by ICT applications, which in essence have to concentrate on a single role only. Integrated services can then be offered to customers by setting up alliances of business units. In this way, new units can be easily incorporated in the organisation, 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 important requirement 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 purchasing future directions cannot be analysed in isolation. For this reason, the feasibility study has been conducted 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 starting point 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.

  Envisioning the Desired Situation Customer Customer Co-ordination Production Customers Channels Services Services Services _{Machine Int*net Marketing mgmt SLA Production Internal Serv. Point Authenticatie Sales Smartcard Pers. Ass.} Help desk Units _{/ account Production mngr Supplier mgmnt mgmt External Call Center Other Identificatie Service desk Invoicing} Production _units

Figure 12: The FS organization.

  The goal of this phase is to relate business processes with ICT support to obtain an overall view of the desired 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 in Figure 12.

  Alternative Information Systems Solutions

  The next stage is the enterprise-level design of the information systems that support the designed business roles in their business processes and information exchange and storage. Four alternatives were conceived (see Figure 13), that are primarily evaluated in relation with the Business and Environment (BE) and the Information and Knowledge (IK) architecture areas with respect to enabling the flexibility of the organisation and the total cost-effectiveness.

  _{Beslisser Infozuil Betaler Int*net Betaler Int*net Besteller ERP Balie/kiosk} Automaat _{Persoon Identificatie ERP ERP Marketing Marketing SLA-management System Verkoop System ERP Productie Management Leveranciers Regie Identificatie ERP Production Interne productie units Sales Interne productie units Beslisser Infozuil Besteller Balie/kiosk} ^Automaat _{Persoon Marketing SLA-management Verkoop Management Leveranciers Productie Regie Inkoper Smartcard ERP Call Center ERP Production Inv. System Other Servicedesk Inkoper Application Facturatie Externe productie units Call Center} Smartcard _{Other Service Desk Servicedesk Facturatie Externe productie units}

  2. Current production systems _{Betaler Int*net Betaler Int*net Balie/kiosk Automaat Marketing System}

  _{Sales Besteller Marketing SLA-management Marketing SLA-management System Prod. SLA Interne productie units Interne productie units Balie/kiosk Automaat Beslisser Infozuil Beslisser Inkoper} Besteller _{Call Center Persoon Mgmt Productie Smartcard Sevice Other Identificatie Application System Desk Servicedesk Verkoop and System System Leveranciers Management Services System Facturatie Externe productie units Inv. Regie Inkoper Call Center Smartcard Persoon Integrated Infozuil Other Identificatie Customer- en Management Servicedesk} ^Verkoop _{Leveranciers Management Productie Facturatie Externe productie units Regie}

  4. One integrated customer and

  3. Production system per production management system organisational unit

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 lies on production system support rather than customer support.

  2. Current production systems The current production systems will be used and where necessary they will be augmented with new functionality.

  3. Information systems per business role Information 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 system This solution is like alternative 3 with the exception of the use of a single system for management and customer services.

  The pros and cons of these alternatives are shown in Table 1 (OTS stands for Of-The-Shelf, typical OTS applications include word-processors, spreadsheets, databases, e-mail packages and financial packages).

  Alternatives Flexibility Cost-Effectiveness

  1. ERP integration is easy (+) expensive implementation (-)

• fixes the business must be interfaced with other ICT

  organisation (-) applications for complete coverage (-)

• unsuited for IT enabling (-)
• no complete coverage (-)

  2. Current can use OTS applications (+) buy the best, make the rest (+)

  production difficult to integrate (-) expensive integration (-)

• systems no integrated services (-)

  3. Production uses OTS applications (+) buy the best, make the rest (+)

• system per required functionality is not expensive integration initially (-)

• business role guaranteed by OTS inexpensive integration operationally applications (-)
• integration is relatively easy

  (+)

  4. Integrated tailored to FS needs (+) see alternative 3

• • • system for the large monolithic systems may very expensive to develop (-)

  management be difficult to develop, and customer maintain and adapt (-) services

  

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. The consequences for purchasing this alternative were evaluated mainly at the Information System (IS) and Technical Infrastructure (TI) architecture areas. However, the impact of technology-driven solutions were assessed again at the business level to assure that the business requirements set out by the management are satisfied. One consequence was clear from the outset, namely that the FS organisation has to adapt to OTS applications. This is not necessarily a bad thing, the FS organisation must be prepared 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, security and performance. Notice that cost-effectiveness is a less important quality attribute since the decision to 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.