of an Extended Enterprise composed of an airplane booking company, a car rental company, and the hotel chain. At the Strategic ICT level of the hotel chain it is ...
Structuring the Development of Inter-organizational Systems Frank G. Goethals, Jacques Vandenbulcke, Wilfried Lemahieu, and Monique Snoeck F.E.T.E.W. – K.U.Leuven – Naamsestraat 69, B-3000 Leuven, Belgium {Frank.Goethals, Jacques.Vandenbulcke, Wilfried.Lemahieu, Monique.Snoeck}@econ.kuleuven.be Tel. +32 16 326880 Fax. +32 16 326732 SAP-leerstoel Extended Enterprise Infrastructures
Abstract. In this paper we argue that there are two basic types of Business-toBusiness integration (B2Bi), each of which requires a different information systems development approach. A framework is set up to structure the development of intra and inter- organizational systems. The framework has three dimensions, the first one showing business and ICT (Information and Communication Technology), the second one showing strategic, tactical and operational management levels, and the third one showing different levels of systems integration: Enterprise Application Integration, Extended Enterprise Integration, and Market B2Bi. The meaning of the so-created cells and their relationships are investigated.
1 Introduction Enterprises and the Web services they are offering and using are constantly changing. Changing an enterprise from the current AS-IS state to a desired TO-BE state is a complex task. A company cannot be seen as an entity that can easily be transformed as an integrated, harmonious unit from the current architecture into a new desired architecture. In this paper we want to stress the fact that individual projects, such as Web services development projects, should be seen as a part of a bigger whole. This paper deliberately gives a high-level view on B2Bi (Business-to-Business integration) approaches, so as not to obscure the image with details. We believe such a high-level view is interesting for both practitioners and researchers who live in the middle of a complex reality. The paper at hand shows that there exist different types of B2Bi, and that different development approaches can and need to be used to deal with each. In what follows, we first discuss two basic types of B2Bi, namely Extended Enterprise integration and Market B2Bi. Next, in Section 3, we add two other dimensions to the discussion of realizing B2B systems. These are (1) the classic problem of Business-ICT alignment, and (2) the alignment and the integration of short term project plans with long term enterprise-wide plans. The three-dimensional structure that is formed by combining these issues structures the architecture problem companies are currently confronted with. The structure makes it possible for practitioners and researchers to pinpoint the problems they are dealing with.
X. Zhou et al. (Eds.): WISE 2004, LNCS 3306, pp. 454–465, 2004. © Springer-Verlag Berlin Heidelberg 2004
Structuring the Development of Inter-organizational Systems
455
2 Three Basic Types of Systems Integration From the theory on the network form of organizations (see e.g. [1, 2]), it is clear that companies may be involved in three basic types of organizational integration: - at the level of the individual enterprise the different departments have to be integrated, - at the level of the Extended Enterprise the companies that make up the Extended Enterprise have to be integrated. An Extended Enterprise (EE) is a collection of legal entities (N ≥ 2) that pursue repeated, enduring exchange relations with one another [11]. - at the level of the market a very loose coupling is established with companies in the environment (other than those within the Extended Enterprise). In contrast with the Extended Enterprise situation, no long term relationship is envisioned with these companies. Contingency theory reveals that there should be a fit between an organization's structure, its technology, and the requirements of its environment (see e.g. [4]). Hence, companies are confronted with three basic types of information systems integration (see [2] for a detailed motivation). First, companies have to deal with the integration of their internal systems (the so-called Enterprise Application Integration, or EAI for short). Secondly, there is an integration with the systems of partnering companies within the Extended Enterprise. This is called EEi (Extended Enterprise integration). Thirdly, companies may want to integrate their systems with those belonging to other companies than close partners. This practice is called Market B2Bi. While the existence of these three types of systems integration has been recognized earlier (see [2]), it is interesting for the purpose of this paper to dig further into the meaning of each type of B2Bi. Transaction cost economics shows that an Extended Enterprise is usually set up for transactions that are more likely to involve uncertainty about their outcome and that require transaction-specific investments [5]. Web services may be developed for use by one specific partner, and fairly complex choreographies of Web services may be built. In the case of the Extended Enterprise the development of new Web services requires coordination, and the physical distance between user and developer – which is usually large in a Web services context – will be lowered artificially. This can result in the implementation of radically new business practices in ICT systems. While standards are the only option for Market B2Bi, bilateral agreements (even at technology level) may be used in the Extended Enterprise. For example, while SOAP is becoming the way to communicate with systems of other companies, partnering companies do not have to use SOAP. In Market B2Bi, network effects play. Network effects are based on the concept of positive feedback, i.e., the situation in which success generates more success. The value of connecting to a network depends on the number of other people already connected to it (i.e., you can connect to). Market B2B transactions are in essence isolated events; there is no fixed counterparty in such transactions. ICT can then only be used if it allows for the flexible replacement of one counterparty in an automated transaction by another one. With a ‘flexible replacement’ we mean that the necessary adaptations should be easily manageable, and should not be expensive nor timeconsuming. Therefore, Market B2Bi Web services are generic, standard services that can be used by, and are being offered by many counterparties. Companies will not
456
F.G. Goethals et al.
coordinate or negotiate the development of Market B2Bi Web services, but will use (preferably vendor-neutral) standards. Clearly, developing Web services for close partners does more resemble the development of classic systems than Market B2Bi Web services development does. Moreover, although an Extended Enterprise is usually not a real enterprise from a legal (financial) point of view, it is noticeable that an Extended Enterprise conceptually forms a new enterprise. After all, the organizations share and redesign processes, data, etcetera. This new enterprise has a starting point and an endpoint (in time) and can be architected. Hence ideas from the Enterprise Architecture discipline can be applied [3]. During the life of an Extended Enterprise, Web services may be designed, implemented, used, and decommissioned1. Consequently, the Extended Enterprise Web services lifecycle is encompassed by the lifecycle of the Extended Enterprise (which is in turn usually encompassed by the lifecycles of the Extended Enterprise’s constituting companies). This is not the case for Market B2Bi Web services, which are standardized services that have been designed for use by a generic combination of companies. The Market B2Bi Web services lifecycle encompasses the duration of the relationship between parties in Market B2Bi. This is illustrated in Figure 1.
Life Constituting Companies Life Extended Enterprise Life EE Web Service
Life Market B2Bi Web Service Duration Market B2B Transaction
Fig. 1. Life cycle comparisons
Of course, services developed for use by one specific partner may, after some time, be generalized and be made available for use to all companies in the marketplace. Furthermore, novel Web services developed in creative Extended Enterprises may be copied, and practices that once seemed innovative may thus become de facto standard practices, or even formalized standards.
3 Structuring the Architecture Problem in a Framework Enterprises are constantly changing. Changing an enterprise basically means moving it from the current AS-IS state to a desired TO-BE state (see e.g. [6] for a discussion on this from the Enterprise Architecture discipline). This is illustrated in Figure 2.
AS-IS situation
Transformation
Desired TO-BE situation
Fig. 2. Moving from the AS-IS situation to a desired TO-BE situation 1
The lifecycle of entities in general and of enterprises in specific has been discussed in the GERAM (the Generalised Enterprise Reference Architecture and Methodology) [7].
Structuring the Development of Inter-organizational Systems
457
This picture is a tremendous simplification of the reality if the enterprise under consideration is a ‘modern’ enterprise (i.e., an enterprise that pursues B2Bi). In what follows, we argue that changing an enterprise concerns changing many different issues that should be aligned and integrated. We present three types of ‘concerns’ which we place on three axes of a cube. One of these axes shows the three types of systems integration mentioned above. This axis is added to the discussion last (i.e., in Section 3.3) because it is by coupling this axis to the two other axes that new insights are developed. The two other axes show two issues that have been discussed extensively in literature in the context of traditional isolated enterprises. Considering these two axes has proved important for traditional enterprises, and now we argue these dimensions are also present and important at a B2B level. 3.1
First Axis: Business Versus ICT
Most companies are using ICT to support their business. Clearly, the business side and the ICT side of a company should evolve in harmony. As the business (departments) should be integrated, the ICT systems they are using should be integrated as well [4]. Alignment between business and ICT is not an easy task and has been the topic of major discussions (see e.g. [8]). 3.2
Second Axis: Planning Horizon
We notice that people may be involved 1) in the execution of operations, and 2) in the management of operations. In this paper we mainly focus on the latter because this is where the engineering happens. Typically three levels of management are discerned, namely strategic, tactical and operational (see e.g. [9]). At strategic level the desired future of the enterprise is puzzled out. Decisions made at strategic level typically cover a long time horizon of about five years. The mission, the vision, important principles, etcetera are defined. Clearly decisions at this level are not detailed at all, they are vague by nature. At the tactical level a planning is made to structure the different projects that will be executed during the following year. It is important to note that these projects are placed and fitted within the total enterprise architecture. That is, an enterprise-wide viewpoint is taken to define the projects. Hence, this level is fundamental for companies to achieve an integrated enterprise. At operational level a detailed planning is made to execute the projects that were foreseen. At this level the focus is on a single project, not on the entire enterprise. Next the project is executed, i.e., the software is programmed, people are trained, etcetera. We notice the presence of the three management levels both at the business side and at the ICT side of a company; hereby indicating that the Business-ICT axis is orthogonal to the planning horizon axis. Obviously, Business-ICT alignment requires the intertwined management of business and ICT. Business and ICT should be coevolving. For example, it is clear that the ICT strategy and the Business strategy should fit. If the Business strategy is to automate public processes (i.e., processes in which the company interacts with partners), the ICT vision should not be directed to the use of proprietary protocols, but to the use of open standards such as SOAP.
458
F.G. Goethals et al.
Market: Market B2Bi Extended Enterprise: EEi Individual Enterprise: EAI Strategic Level Tactical Level Operational Level Business side
ICT side
Fig. 3. A three-dimensional classification of architecture issues
3.3
Third Axis: The Three Types of Systems Integration
The third axis represents the three types of systems integration described in Section 2. First, there is the integration of the systems within the firewall. Secondly, the systems of the companies that make up the Extended Enterprise may need to be integrated. Thirdly, companies may want to integrate their systems with those belonging to other parties than close partners (Market B2Bi). 3.4
The Three Axes Together
If we bring the three axes together, we get Figure 3. The ‘Individual Enterprise’ cross-section of the cube is not that new2. Still, it should be noted that the Tactical ICT cell has been neglected in the past, resulting in disintegrated information systems. That is, while ICT systems used to be developed for use by one specific user group (often one department), it has been admitted (especially in the Enterprise Architecture discipline; e.g. [10]) that an enterprise-wide point of view is needed to get different computer systems to share data and logic. At the level of the Extended Enterprise operational, tactical and strategic decisions can be made that relate to the collection of companies that make up the Extended Enterprise. Companies may define new concepts and processes which do only exist at the level of the Extended Enterprise, and not at the level of an individual enterprise. Imagine two collaborating companies: an airplane booking company and a hotel chain. They may decide to offer a Web service which allows customers to make a reservation for both an airplane seat and a hotel room in one transaction. This service (which does only exist at the level of the Extended Enterprise, not at the level of the individual enterprises) may produce data such as ‘the number of trips booked that 2
Actually, it fits with the ideas of Maes [11] concerning the vertical extension of the Strategic Alignment Model of Henderson and Venkatraman [8]. While Henderson and Venkatraman focuss on the strategy and the operations, Maes stresses the importance of a ‘structure’ level (in addition to the strategic and operational levels), which we call “tactical” level.
Structuring the Development of Inter-organizational Systems
459
include an airplane seat and a hotel room’3. Tactical decisions made at the level of the Extended Enterprise are meant to ensure that an integrated Extended Enterprise is created. Different B2B processes may share logic and data. Hence, structuring all processes and data within the picture of the total Extended Enterprise is important. Strategic plans at the level of the Extended Enterprise may have far-reaching consequences. They may ask for a total restructuring of the individual enterprises. A number of practices may be abandoned so as to let every company focus on its core competences, delocalization may be needed, etcetera (see e.g. [12, 13]). In extreme cases the Extended Enterprise may almost behave as a single enterprise. Still, the cases are rare where companies delete data and logic that are redundant at the level of the Extended Enterprise. That is, in the above example both the airplane booking company and the hotel chain are likely to have data on the customer, rather than just storing this data in a database possessed by one of them. At the level of Market B2Bi, companies have (per definition) a short term relationship with each other, and they do not sit together around the table to make plans. Actually, these plans are likely to be made by standardization organizations or the legislator. The operational plans are existing (horizontal or vertical) standards, such as individual RosettaNet PIPs. Tactical plans show how the standardization organizations see those operational plans coming together (e.g., linking standards such as WSDL, BPEL4WS, WS-coordination, and WS-security). Of course, these standardization organizations have a strategy as well, a vision (e.g., the ‘semantic web’ is for the most part still a vision). At the level of Market B2Bi, standardized processes and standardized vocabularies may be available (ontologies) which can be used by all companies within some sector for example. Enterprises could then map their proprietary terminology to the standardized vocabulary. Furthermore, for all three types of integration, business and ICT are expected to be aligned. Doing B2Bi is not just about ‘playing’ with new ICT standards; it is about developing Web services that are useful for future service-consumers [14] (i.e., ICT departments should become consumer-oriented just like business departments). Alignment is thus also needed across company borders. Interestingly, also at the Market B2Bi level there is a business side and an ICT side to the picture. Some standards are being developed that purely arrange business practices (e.g., CPFR, Collaborative Planning, Forecasting, and Replenishment [15]), while others purely concern ICT matters (e.g., SOAP). Clearly, both types of standards alone will not break any bricks; complementary and explicitly linked standards are needed. Standards can be very useful, and ease the job of integrating systems, but they can only be used to the extent that they fit with the specific situation of a company. Of course, not everything is being standardized. When it comes to technology, it is only where interoperability is important that standards are developed. Features that cause customer dissatisfaction or hinder industry growth4 evolve into standards, while features on which differentiation is valuable to the customer do not tend to evolve into standards. Furthermore, the demand for standards usually comes from the users and 3
4
The Web service would then use two smaller Web services provided by the individual companies. While the choreography of the Web services is something that is negotiated at the B2B level, the internal functioning of the two smaller Web services is something that is realized at the level of the individual enterprises (see the example in Section 3.5). This may also be the ‘software industry’ of course. COTS (Commercial Of The Shelf) software is in this sense standardized software.
460
F.G. Goethals et al.
customers of the technology who experience the confusion caused by the lack of standards [16]. As stated earlier it may become interesting for businesses to use Web services that were initially developed for use by one specific partner, for integration with other counterparties as well. The users then experience the importance of having a standard way to realize this B2B process, and the B2B process may be standardized so as to make it a Market B2B practice. In this context it is also interesting to have a look at COTS software (such as the SAP software packages, for example). In the past, COTS packages were focused on the inside of the company. Now COTS packages are starting to incorporate standard B2Bi practices as well. B2B processes could be entirely realized by individual participants in the business process. That is, the individual participants could implement the Web services internally, and the execution of a choreography of Web services could arise naturally from sending messages from one company to the other (and back), without intervention of a central choreography engine. Standard Web services and standard Web services choreographies could be implemented in COTS software. Furthermore, if some central component is needed, this could be offered by COTS vendors, or standardization organizations. An example of this is the public UDDI registry (which is aimed at Market B2Bi). This registry is offered by companies such as Microsoft, IBM and SAP and can be used to publish and to search Web services. Note that the Web services concept may seem understandable to business people, but that a business person’s perception of a Web service is different from an ICT person’s perception. By an ICT person a Web service can be seen as ‘a component that is callable by anyone in a loosely coupled style over the Internet using XML and SOAP’ [17]. As such, Web services may exist that do not offer ‘business functionality’ [14]. Furthermore, for business people, the fact that some functionality is offered by a software component is not relevant; they are only interested in the service that is offered (i.e., in the functionality). In fact, one software component may offer several operations that are accessible via SOAP. However, for a business person this is transparent; he sees several services (i.e., functionalities that are offered). Also, the other way around, functionality demanded by business people is not restricted by the borders of existing software systems.
3.5
Discussion and Example
The cube presented in Figure 3 places the development of B2Bi systems within the larger context of ‘changing enterprises’. Enterprises may consist of a formal and an informal part. The informal part is usually given shape by things like ‘culture’. The formal part concerns the issues that are being actively managed. It should be noticed that ICT systems are deterministic (i.e., their behaviour needs to be specified entirely before they can function). Therefore, ICT systems can only be used to support formal (aspects of) business processes. If personnel wants freedom, and wants to behave in an unpredictable and creative way, it cannot expect information systems to fully support their practices. The only things that can be supported are the deterministic, stable (subparts of) processes. At the moment a process becomes too unstable (i.e., unmanageable), it does not make any sense anymore to formalize the process and to restrict employees that way.
Structuring the Development of Inter-organizational Systems
461
Informal practices bring along uncertainty. For as long as abstraction can be made of the uncertainty (i.e., you only need to know what will be done, not how it will be done), uncertainty causes no problems. However, in a B2B process companies have to agree on how the public process will execute. Companies participate in a shared process (they share the how), and uncertainty cannot be abstracted and must be avoided. This – together with the fact that businesses were not concerned about designing B2B processes – is why at a B2B level practices have been stable for many years. Now, to automate B2B processes, the B2B processes need to be formalized, and explicit agreement on the desired TO-BE situation is desirable. In an Extended Enterprise setting, companies may sit together around the table to develop a new B2B process. For Market B2Bi only standardized B2B processes can be used, at least for as long as no software agents do exist that can validate, negotiate, and steer choreographies of Web services. It is needless to say that the development of such agents will take many years, and that such agents require many standards. Software agents that offer such functionality are still a vision (i.e., this concept is still situated at the Market B2Bi Strategic ICT level, where it is linked to the vision of the semantic web) and the infrastructure for such B2Bi practices needs to be developed (i.e., the Market B2Bi Tactical ICT level needs to be planned, and systems and standards need to be put into operation). The formal part of an entity may or may not be made explicit in ‘architectural descriptions’. These architectural descriptions could model the AS-IS situation, or a desired TO-BE situation which needs to be realized. In the Extended Enterprise, we expect the application of “Extended Enterprise Architecture” to gain momentum. Especially now companies are developing more and more Web services, and their B2Bi practices become complex, it becomes important to keep things manageable by having good documentation. For Market B2Bi standardization organizations build generic models, and these can be instantiated by companies for use. Please note that some argue that in the future it will become possible to automatically generate ICT systems from models (see e.g. [18]). As an illustration, the ARIS tool that will be part of the next version of the SAP NetWeaver platform is said to enable business people to change business processes and the underlying ICT systems by dragging and dropping boxes in a graphical user interface. The MDA (Model Driven Architecture) also fits with this vision [14]. While architectural descriptions always have been handy for supporting communication among people and to maintain systems, they would now become directly useful for generating the system. Making the architecture explicit would then not only prove useful in the long term any more, but also in the short term. Of course, when working with standards code generation becomes less of an issue because standard mappings can be made available. Models such as RosettaNet PIPs could for example (partly) be made executable by creating standard mappings to software platforms (e.g., to Microsoft’s Biztalk Accelerator). The theory presented in this paper can be illustrated with a (simplified) hypothetical example of the development of a Web service by an Extended Enterprise. While the text that follows pays attention to the decisions that are made within the cells of the framework, Figure 4 shows the communication between cells. Clearly this image is not complete; much more arrows could be added to the picture (e.g., arrows going back up so as to change unrealistic project plans).
462
F.G. Goethals et al. Extended Enterprise
Operational
Tactical
Strategic
Individual Enterprise
Business
ICT
Business
ICT
Fig. 4. Example of Extended Enterprise integration
We consider the situation of a hotel chain (the ‘Individual Enterprise’) which is part of an Extended Enterprise composed of an airplane booking company, a car rental company, and the hotel chain. At the Strategic ICT level of the hotel chain it is discussed that the ICT department needs to make itself ‘useful’ to the company. A discussion is started with the people at the Strategic Business level of the company to show that new B2Bi technologies make it possible to cut costs and to create new opportunities. Æ A new Business Strategy is developed for the Individual Enterprise: to use ICT to cut costs and to seize opportunities at a B2B level. Æ Negotiation with the partners within the Extended Enterprise results in a new Extended Enterprise Business Strategy: to offer services to customers by using ICT. Æ A first test Web service is planned at Tactical Business level of the Extended Enterprise. This service should allow customers to book hotel rooms, airplane seats, and cars in one automated transaction via the Internet. Æ This service is further detailed at the Operational Business level of the Extended Enterprise. First, the current phone-and-fax way of working is adapted to the new computerized way of working: While the customer used to be able to go to the party of his choice first (the hotel booking company, the airplane booking company or the car rental company) automated requests of the customer will automatically be sent to the airplane booking company first. It is decided that this company has to be contacted first because the timing of the flights will determine the moment a car can be picked up, and the moment a hotel room is needed (a transcontinental flight may take 20 hours or more, making an extra night in the hotel necessary or unnecessary). Once one or more airplane seats have been put into reservation state for one or more flights, the car rental company and the hotel chain can be contacted to make reservations. Next, a number of proposals (all-in arrangements) are sent to the customer. Once an answer is received from the customer, or 36 hours have past by without any notice from the customer, the reservations are cancelled or confirmed. Finally, an invoice is sent to the customer.
Structuring the Development of Inter-organizational Systems
463
Æ At the Strategic ICT level of the Extended Enterprise it is decided that open standards will be used such as SOAP. It is also decided that a standard vocabulary will be created that defines important terms. Æ At the Tactical ICT level of the Extended Enterprise the ‘BookAirplaneHotelAndCar’ service is planned. It is decided that the initial Web service call needs to be directed to the systems of the Airplane booking company, and that this company will start up the choreography (of smaller Web services). The reason for this is that – for security reasons - the Airplane booking company does not want any other companies to make reservations in her systems. Also, it was decided at Business level that first the airplane booking company has to check for possible flights, so sending the initial call to the airplane booking company could also be justified by performance considerations. Concerning the creation of the standard vocabulary it is decided that terms can be proposed and defined at the level of individual projects (i.e., at operational level), but that the terms can only be used once they have been accepted by the central ‘data architecture group’. Æ The ‘BookAirplaneHotelAndCar’ service is further detailed at the Operational ICT level of the Extended Enterprise. The Web service could be realized in many different ways. The partnering companies choose for the following approach (a motivation for this ‘serialized’ way of working can be found in [3]). As was decided at Tactical ICT level, the initial Web services call goes to the airplane booking company. This company makes a number of reservations, and sends a request to the car rental company to book both cars and hotel rooms. The car rental company makes a reservation (or sends a rejection to the airplane booking company) and sends a request to the hotel chain for hotel rooms. Once the hotel chain has made reservations it sends a number of proposals to the customer. The customer replies to the hotel chain, which confirms and cancels the necessary rooms, and communicates the confirmation to the car rental company (which also makes the necessary confirmations and cancellations) which in turn communicates the decision to the airplane booking company. Once the necessary airplane seats have been confirmed, an invoice is sent to the customer. A standard vocabulary is defined for parameters that will be used. It may for example be necessary to define what is meant with the tag ‘departure date’. For the airplane booking company this may for example be the day the client leaves his home, while for a hotel chain a ‘departure date’ would typically be the day the client leaves the hotel. Clearly, a standard vocabulary needs to be defined. At the level of the Individual Enterprise (the hotel chain) the following is noticed: Æ At Tactical Business level it is believed that this project has no ‘restructuring’ consequences (e.g., no people will need to be moved from one department to another). Æ At Operational Business level the old operational process of renting rooms will remain valid. Still, the people responsible for making reservations will now also have to check ‘alerts’ fired by the system concerning special requests of customers who try to book a room via the Internet automatically. Æ At Tactical ICT level it is decided that the company needs to develop a generic RoomRental service. This service should be generic in that it can handle requests that come from the customer directly, requests that come from the partnering car rental company (in which case airplane seats may have been booked already) and requests that come from the partnering airplane booking company (in which case airplane seats will already have been reserved, but no car is needed). It is noticed that this Web service can use functionality from the existing integrated ‘room booking system’.
464
F.G. Goethals et al.
Æ At Operational ICT level, the Web service itself is realized. A SOAP wrapper is created for the existing ‘room booking system’, and an ‘alert mechanism’ is created that allows the people in the lobby to check and to handle special requests. The above example is (of course) a simplification of reality, but it illustrates the roles of the cells in the framework.
4 Conclusions The contribution of this paper is that it brings two classic topics (Business-ICT alignment, and the different management levels) together in one framework with a new (third) dimension to take B2B practices into consideration. Putting the three axes together brings structure to the B2B domain and shows a number of basic viewpoints on integration practices. The framework is high-level in that it talks about ‘business’ and ‘ICT’ rather than about specific roles within these categories (such as CIO, business analysts, programmers, configuration managers, etcetera). Also, we did not further dig into the six aspects identified by Zachman [10] that need to be architected in an enterprise. (Basically, the data, processes, locations, persons, timing and motivation should be architected in each cell of Figure 3.) This may be seen as a negative point. However, including these ideas was expected to obscure the total picture this paper wants to draw. We have shown that changing a modern enterprise actually boils down to changing a number of different issues harmoniously. Communication between cells in the framework is necessary to realize required changes. We believe it would be very interesting to research the relationship between the performance of a company and (1) the effort put in each cell (as stated the tactical ICT level of individual companies has been neglected for years, resulting in EAI projects now), (2) the information that is communicated across cells (which is necessary to achieve alignment and integration), and (3) the absence or presence of models explicitly showing formal issues (as having models of something from different points of view makes it easier to manage and to communicate that something, and to automatically generate systems). We believe that identifying the concerns of different people in an integration effort is important. Architectural descriptions made from different viewpoints (i.e., that make different abstractions of the reality) should be linked to each other. Concepts such as ‘private processes’, ‘public processes’, ‘Web services choreographies’, ‘Web services orchestration’, ‘executable processes’, and ‘abstract processes’ actually all relate to viewpoints (and to the concerns of someone looking from that point of view). Also, ICT standards such as WSDL, BPEL4WS, BPML, and business standards such as CPFR can be related to viewpoints. A clear definition of all concepts needed to do B2Bi is only possible once the necessary viewpoints have been identified. Clearly, with BPEL4WS a Web services process can be described, but this gives only a description from one point of view. Several points of view are needed to develop an entire enterprise (and its relationships with the outer world). Also, to generate programming code different viewpoints on the system and the relationships between those viewpoints should be documented. This paper has structured the domain of B2Bi, offering a number of basic viewpoints on B2Bi.
Structuring the Development of Inter-organizational Systems
465
Acknowledgements. This paper has been written as part of the ‘SAP-leerstoel’project on ‘Extended Enterprise Infrastructures’ sponsored by SAP Belgium.
References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Podolny, J., Page, K.: Network forms of organization. ARS 24 (1998): 57-76. Goethals, F., Vandenbulcke, J., Lemahieu, W., Snoeck, M., Cumps, B.: Two Basic Types of Business-to-Business Integration. International Journal of E-Business Research, Forthcoming (2005). Goethals, F., Vandenbulcke, J., Lemahieu, W., Snoeck, M., De Backer, M., and Haesen, R.: Communication and Enterprise Architecture in Extended Enterprise Integration. ICEIS 2004 conference proceedings, Volume 3, 332-337. Borgatti, S.: Organizational Theory: Determinants of structure. Retrieved from http://www.analytictech.com/mb021/orgtheory.htm on March 4, 2003 (2001). Picot, A., Ripperger, T., Wolff, B.: The Fading Boundaries of the Firm: The Role of Information and Communication Technology. JITE (1996), 152(1), 65-79. CIO Council: A Practical Guide to Federal Enterprise Architecture. Retrieved from http://www.cio.gov/archive/bpeaguide.pdf on June 9, 2004 (2001). Bernus, P., Nemes, L., Schmidt, G: Handbook on Enterprise Architecture, SpringerVerlag, 778 (2003). Henderson, J., Venkatraman, N.: Strategic Alignment: Leveraging Information Technology for Transforming Organizations. IBM Systems Journal (1993) Vol 32, no 1, 416. Proper, H., Bosma, H., Hoppenbrouwers, S., Janssen, R.: An Alignment Perspective on Architecture-driven Information Systems Engineering. Proceedings of the Second National Architecture Congres, Amsterdam, The Netherlands (2001) 11. Zachman, J.: A framework for information systems architecture. IBM Systems Journal (1987) Vol. 26, No.3, 276-292. Maes, R.: A Generic Framework for Information Management. PrimaVera Working Paper (1999) 99-03, 22. Bowersox, D., Closs, D., Stank, T.: How to Master Cross-enterprise collaboration. Supply Chain Management Review (July/August 2003) 18-27. Liedtka, J.: Collaborating across lines of business for competitive advantage. Academy of Management Executive (1996) 10(2), 20-34. Frankel, D., Parodi, J.: Using Model-Driven Architecture to Develop Web Services. Retrieved from http://www.omg.org/ on January 29, 2003 (2002). The Collaborative Planning, Forecasting and Replenishment Committee: VICS CPFR model. Retrieved from http://www.cpfr.org/ on June 14, 2004. Cook, M.: Building Enterprise Information Architectures. Prentice-Hall (1996) 179. van der Lans, R.: SAI-workshop, Webservices - Hét nieuwe webparadigma (2002). Smith, H., Fingar, P.: A New Path To Business Process Management. Optimize (October 2002) 55-61.
