The importance of the relationship between customers and suppliers of goods and services has been recognized for many centuries. Indeed, issues of significance to the ancient spice and silk traders, such as trust, payment, and delivery, remain equally relevant today. The management of customer/supplier relationships encompasses all the activities associated with the flow of goods and services from suppliers to end users [6]. These activities relate to the flow of associated coordinating information as well as to the movement of the goods or services themselves. A number of organizations may be involved in such supply chains and the relationships established between partner organizations play a vital role in the success of a particular supply chain.
Traditionally, supply chain management takes the supply chain as a given and aims to optimize information and material flow based on historical data. However, in many domains, we now have highly dynamic and agile organizations with constant product innovation, short product cycles, volatile global demand, and customization based on evolving customer preferences [9]. In this emergent world, historical data is of little use. If software systems are to meet the demands of such organizations they, too, must be dynamic and agile. Of course, advances in IT and communications enable software materials and information to flow electronically, offering the potential to dynamically reconfigure or redesign software supply chains. So, at least in theory, software supply chains could be changed every time they are used.
This article looks at the characteristics of software supply chains across a range of development/procurement paradigms, focusing primarily on the nature of the relationship between software customers and software suppliers, with insights into the changing role of the customer.
The procurement paradigms addressed here include:
- Commercial off-the-shelf (COTS) products where a software customer is likely to have close relationships with a small number of suppliers;
- Component-based software engineering (CBSE) where many suppliers are involved in providing parts from which a system is built. Component selection (and, hence, some aspects of the customer/supplier relationship) may be automated;
- Software service engineering (SSE) where systems are composed from Web services; customers enter into negotiation with a large number of global suppliers and selection and integration may be automated.
Clearly, as the number of potential suppliers increases, so does the need for a greater level of automation in establishing and maintaining the customer/supplier relationship.
Clearly, as the number of potential suppliers increases, so does the need for a greater level of automation in establishing and maintaining the customer/supplier relationship.
COTS Products
The COTS products approach to software procurement essentially involves the selection—usually from a small set of options—of one substantial product (or software suite) that can be tailored to provide specific and substantial system functionality [5]. Such software suites often provide cross-functional capabilities within an organization and include ERP systems, management information systems, and supply chain management systems. The customer of the software in this case is the end user organization.
A number of research groups have developed and promoted processes for selecting COTS products and, hence, for establishing relationships between COTS products suppliers, and organizations seeking COTS products. Two such processes successfully applied are PORE [10] and the PECA process [5]. In addition, the more general approaches to the evaluation of software tools can also be applied to COTS products [8].
A generic COTS products evaluation process (depicted in Figure 1) involves the following four steps:
- Select evaluation method; for example, this might be a feature analysis, a formal experiment or an in-house case study;
- Plan the evaluation, including activities such as selection of tasks to be carried out, selection of subjects, design of data gathering, and analysis activities;
- Carry out evaluation and collect data; and
- Analyze the data and make a recommendation.
The customer/supplier relationship. Partnership is at the heart of the relationship between suppliers and customers of COTS products. Essentially, customers see suppliers as long-term partners as opposed to subcontractors—a view more typically held by procurers of bespoke systems [1]. Clearly, for any partnership to succeed it must be built on mutual respect and a willingness to share information. In addition, partnerships are more likely to thrive if established over a substantial period and (at least) extend throughout the lifetime of the product or products involved.
As in the case of bespoke procurement, the customer needs to maintain expertise and processes for technology watch and evaluation to be able to identify and assess alternative or additional future partners. Although suppliers of COTS products tend to be large, powerful organizations, customers must ensure they do not drive their suppliers out of business. There are many mechanisms that can be used to cement the customer/supplier partnership. For example, suppliers and customers can meet face-to-face rather than relying on electronic information exchange. Moreover, customers might choose to discuss their future requirements and dependencies with suppliers; and problem-resolution processes can be developed across the partnership rather than confined to either the supplier or the customer organization.
The limitations of this approach to software procurement arise from the balance of power between the parties concerned, the size of the organizations involved, and the level of human involvement.
One of the limitations relating to the balance of power is the supplier of a large system may impose an organizational process or way of working on the customer. In addition to embodying processes in the product, the supplier may also control product evolution with the result it becomes very difficult for the customer to move to another supplier.
A COTS products approach also favors large and powerful customer organizations able to wield a strong and potentially undue influence on their suppliers. Such customers are also able to support the high level of human involvement necessary to carry out activities such as participating in users groups, attending product demonstrations and face-to-face meetings with suppliers.
This approach basically favors large organizations, whether they are customers or suppliers, and as a consequence small to medium-size enterprises (SMEs) have difficulty establishing themselves as either suppliers of COTS products or as customers of such products.
Component-based Software Engineering
CBSE refers to the development of software systems from pre-existing parts [7]. Much effort has been devoted to defining and describing the concepts involved in CBSE and, in particular, in describing what constitutes a component [3]. For the purposes of this article, software components can be considered units of independent production, acquisition, and deployment that interact to form a functional system [11].
CBSE processes typically involve three types of actors (see Figure 2): Component suppliers who develop components for use in component-based systems; systems integrators/designers who select and acquire components in order to build component-based systems (that is, the customers); and component brokers who act as intermediaries, providing an automated marketplace for component suppliers and customers to meet.
These actors may operate within a particular organization, with the broker effectively providing a catalog of available components. On a wider, commercial scale, the broker may bring together many suppliers and customers providing added value through third-party certification, pricing/licensing information, and so on.
The customer/supplier relationship. Relationships between customers and suppliers are typically established through brokers providing a number of facilities to support both parties (www.componentsource.com). Suppliers register their components with a broker and thus make information about their products available to potential customers. Customers are supported by the broker in making trade-offs between their own requirements and the offerings of suppliers. Tools to support this process may include those for ranking and selecting of candidate components, visualization of components and of their closeness of fit with requirements, and automated support for certification. Information held by the broker (about components offered by suppliers) will include functionality, some non-functional characteristics (such as performance), and business information such as cost and supplier details.
The relationship between supplier and customer is established in a semi-automated way at the time of system design. The customer in the relationship is the systems integrator/designer as opposed to the end-user organization.
Many of the limitations of CBSE stem from the risks associated with the marketplace. The conditions necessary for such a marketplace to succeed have been highlighted by a survey of practitioners and academics working in the field [12]. For example, it is necessary for customers to be able to find and assess the value of the components they need and the specifications of components have to be standardized. Because the relationship between customer and supplier is not as strong as for COTS products the risk to customers is higher since they may not be able to find a replacement if a component ceases to be available or if a supplier goes out of business. In general, customers will not have access to the source code for the components they acquire, although they may, at least partially, protect themselves from defaulting suppliers through the use of escrow services.
Of course, the price for automating some supply chain activities is that trust between suppliers and customers will be reduced and other mechanisms, such as certification and electronic users’ groups, may be needed to enhance customer confidence. Another possibility is for a broker to collect opinions from customers about the components they have used. However, making these opinions available to other potential customers is likely to raise significant legal and ethical questions.
Another limitation, which we have found from our evaluations of prototype component brokers, is that characterizing and registering a component with a broker is a very time consuming and difficult task [4]. In the future, better tools and a higher degree of automation may make this task less onerous.
Software Service Engineering
The idea of providing software functionality as a service over the Web is not new. Application service providers have offered supply-led services to customers for several years. Such services are negotiated in advance and are essentially software procurement by outsourcing. Two obvious advances in the way in which services can be provided are through demand-led just-in-time selection and contract negotiation and through the composition (or configuration) of new services from pre-existing (sub) services.
Combining these two enhancements with the concept of application service provision leads to a vision of software service engineering—the dynamic engineering of Web services as needed—configured, executed, and paid for on demand [2].
As for CBSE, we have three actors at the base level: the customer (in this case, the end-user organization) of the software service; the intermediary (service registry) that provides a cataloging facility; and the service supplier.
This model involves three operations: registration, by a supplier, of offered services; discovery, by a customer, of a service that meets its needs; and utilization, by a customer, of selected services. Customers and suppliers connect dynamically and services are used as needed. A number of technologies are currently available and can be combined to support this basic model of software as a service (for example, .NET, Globus, and Websphere).
An enhanced model, combining the basic model with just-in-time service selection and contract negotiation and with the capability to compose new services from pre-existing ones is illustrated in Figure 3. Here, the distinction is made between service design time, when the customer is the designer, and service utilization time, when the customer is the end user of a service. At design time, a designer uses a composite service design environment to develop a composite service description or template. This is a human-intensive activity and involves, as part of the design process, the selection and invocation of subservices for evaluation purposes. The composite service description produced includes descriptions of the composite service architecture, the component services, and the acceptable operational quality of service constraints.
When the end user needs a software function he or she uses a dynamic service delivery engine to invoke the appropriate composite service template and perform the necessary selection of component services, the negotiation of contracts with the service suppliers, and the invocation of the contracted component services.
The customer/supplier relationship. Again, connections between suppliers of services and customers of services are made through intermediaries. However, in this case, there are opportunities for many different types of intermediary (such as registry services, payment management services, contract negotiation services, and quality of service monitors). A registry service, for example, will need to provide the same sort of functions as the broker in CBSE; however, this functionality is required at software service utilization time as well as at design time thereby enabling dynamic, runtime supply chain redesign.
As stated earlier, supply chain management involves not only the movement of goods (or services) but also the flow of associated coordinating information. In SSE, the flow of associated information, for example, relating to contract negotiation, payments, notification of delivery, and so on, can also be automated. So, within the constraints set by a service designer, relationships between end-user customers and many suppliers of subservices can be established and terminated dynamically as and when they are needed.
The major limitations of this approach to acquiring software functionality stem from automation of the processes associated with supplier selection. Such a level of automation will mean the trust and confidence between the parties involved may be lower than for COTS products and CBSE leading to a greater chance of failure. The risks may be higher but the opportunities arising from a more open, global market may make such risks worth taking. Other limitations stem from the high costs of automating activities such as supplier selection, contract negotiation, respecification of requirements and monitoring of service quality.
Conclusion
This article outlines some of the current models of software procurement and discusses the consequent customer/supplier relationship. It also notes the customer role varies across the paradigms presented. For COTS products, the customer is the end user organization, while for CBSE the customer is the systems integrator or designer. For SSE, we see that both of these actors are customers at some time during the lifetime of a software service.
The limitations of each of the approaches in terms of the customer/supplier relationship have also been discussed and fall into the three categories shown in the accompanying table.
Of course, each approach has strengths and weaknesses, however, in looking to the future we conclude the SSE vision of dynamic supply chain redesign offers a number of potential benefits, including the independent deployment of small component services enabling rapid evolution of composite services and a thriving global marketplace for software services. Also, SMEs will find it easier to enter the global services market; and rules of engagement between suppliers and customers will be formalized and codified.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment