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 Hans.Goedvolk@capgemini.nl
Hans de Bruin
Vrije Universiteit, Amsterdam The Netherlands hansdb@cs.vu.nl
Daan Rijsenbrij Vrije Universiteit, Amsterdam
The Netherlands 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
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 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.
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
client,
users architect developers
appearance, behaviour
construction, co-operation architectural
design
visualises prescribes
requirements solutions
creates
assess 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 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.
Consultant What Artefact must be realised?
Architect How is the Artefact realised?
Engineer With What is the Artefact realised? The Ideal Architect
The 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 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
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 Architecture
Constructing and Attributing Views
Assessment of Qualities Adaptation of
Architecture
not OK
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.
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.
Conceptual
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;
The Main Architecture Areas
ICT
ICT
System
System
Business
Business
System
System Information and KnowledgeInformation and Knowledge
Information System(s) Information System(s)
Technology Infrastructure Technology Infrastructure Business and Environment Business and Environment
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.
Information Systems
Technology Infrastructure
technology infrastructure services
Information and Knowledge Business and Environment
automated services information and knowledge services
Internal Organisation
External Parties
products services
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
Static and Dynamic Structures
Behaviour and Appearance, Co-operation and Construction of
Roles (Logical Components)
Physical Components
People, Software, Hardware
Vision, Strategy, Scope Requirements and Constraints
Products/Services and Qualities
Conceptual Conceptual (What) (What)
Logical Logical (How) (How)
Physical
Physical
(With What)
(With What)
Quality Views
of Products/Services, Structures and Components
Quality
Quality
Assessment
Assessment
(How Good)
(How Good) Quality
Assessment Iteration
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.
Common Quality Assessment
Iteration
Enabled Area
Construction and Co-operation Appearance and
Behaviour
Components Requirements,
Constraints
Enabling Area
Enabling Services
Quality Views
of Enabling Services and Both Areas
Construction and Co-operation Appearance and
Behaviour
Components Requirements,
Constraints Enabling
Requirements Constraints
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.
Quality Assessment
Enterprise Requirements
Enterprise Structures
Project-level Requirements
Project-level Structures
Subsystems
as-is to-be
Components
as-is to-be
Conceptual Design
Logical Design
Physical Design
Quality Assessment Quality
Assessment + Iteration
Enterprise Level Project Level
Constraints Requirements
Feedback Requirements
Figure 10: Enterprise-level and Project-level 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
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.
New Services
Existing Services
Existing Customers
New Customers
ICT for improving efficiency ICT as enabler
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 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;
Envisioning the Desired Situation
Production Services
Customers Customer
Services Customer
Channels
Co-ordination Services
Internal Production
Units
Machine
Invoicing
Identificatie
/
Authenticatie
Service desk account
mngr
SLA mgmt
External Production
units Production
mgmnt
Supplier mgmt
Sales Marketing Int*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 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
Marketing
Interne productie units
Externe productie units Customer- en Management
Services System
1. ERP 2. Current production systems
3. Production system per organisational unit
4. One integrated customer and production 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 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 (+)
• fixes the business organisation (-)
• unsuited for IT enabling (-)
• no complete coverage (-)
• expensive implementation (-)
• must be interfaced with other ICT applications for complete coverage (-)
2. Current production systems
• can use OTS applications (+)
• difficult to integrate (-)
• no integrated services (-)
• buy the best, make the rest (+)
• expensive integration (-)
3. Production system per
• uses OTS applications (+)
• required functionality is not
• buy the best, make the rest (+)
business role guaranteed by OTS applications (-)
• integration is relatively easy (+)
• inexpensive integration operationally (+)
4. Integrated system for the management and customer services
• 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. 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.
By using OTS applications based on three-tier-architectures and by using de-facto industrial standards and 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 alternatives concentrating on network facilities have been devised to assess the IS concept at the TI architectural level. 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.
• An architectural concept that is developed provides the means for integrating new OTS applications. The architectural principles must therefore be protected against erosion. This requires:
• 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 at the enterprise level of abstraction in this feasibility study. The next step is to elaborate the architecture areas while continuously assessing the impact of decisions in one area on the other ones. IAF proved to 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 architectural perspectives to relate the business with the technology that enables the business. IAF provides the framework to establish this relation. It can be regarded as a reference architecture framework
prescribing how an architectural design should be approached. In addition, rules and guidelines can be included 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 IAF has been applied successfully in practice. Although the example concentrated on high level
architectural 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 and it 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. SEI Series in Software Engineering. Addison-Wesley, Reading, Massachusetts, 1998. [BM99] Software Architecture Design: Evaluation and Transformation, Jan Bosch and Peter
Molin. IEEE Engineering of Computer Based Systems Symposium (ECBS99), December 1999.
[BMRSS96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley and Sons, 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 Emerging Discipline. Prentice Hall, New Jersey, 1996.
[SZ92] J.F. Sowa and J.A. Zachman. Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3):590-616, 1992. [Zachman87] J.A. Zachman. A framework for information systems architecture. IBM Systems
