One of the most significant paradigm shifts of software business management is that individual organizations no longer compete as single entities but as complex dynamic supply networks of interrelated participants. Understanding these intricate software supply networks is a difficult task for decision makers. This paper outlines a modelling technique for representing and reasoning about software supply networks. Modelling software supply networks allows managers to visualize liability and responsibilities and identify new business opportunities in a software supply network.
Individual businesses no longer compete as single entities but as supply chains [
A software supply network is defined as a series of linked software, hardware,
and service organizations cooperating to satisfy market demands. SSN
management is different from physical goods supply chain management (SCM) in two
ways. First, software is adaptible after release and delivery, giving rise to the
need for extensive maintenance. Secondly, products delivered to end-users in
SSNs are tolerated with much lower quality levels than physical products [
A result of the difference between conventional supply networks and SSNs is
that literature on collaboration in supply networks [
Software Supply Network Models The model for SSNs consists of two parts, the software product context and the supply network. The product context describes the context in which a software service operates, and the software products, hardware products, and software services that are required to provide the software service. A supply network displays all participants in a SSN, the connections between these participants, and the flows describing the type of product that flows down these connections. The two diagrams are related in that the product context shows all products that are traded in their different forms in the supply network.
A software service is the provision of one or more functions by a system of interest to an end-user or another software service. A system is a combination of independent but interrelated software services, software components, and hardware components that provides one or more services. There are three types of entities in the software product context, being (1) white-box services and their systems, (2) black box services, and (3) software and hardware components making up systems. Dependencies are modelled by drawing the required component under the first component. At the bottom of all software components will be the hardware and services that are required to create a system that provides a service.
With respect to the supply network, there are seven different types of participants (represented as entities). Between these entities different products and services are distributed (represented as labels on arcs between entities). When looking at all participants, seven categories of organizations arise that participate in the value chain of software products and software services. 2.1
An Example: WebERP In figure 1 the example SSN model is presented for a customer requiring a Web Enterprise Resource Planning (ERP) service. To supply this service internally, the customer has a partner implementer organization who implements a product WebERP on a newly purchased local database server and a local web server. The software product context displays that to supply Sys.6, P.6 is required. To run P.6 a server is required that supplies WebERP through a web server application, in this case Microsoft IIS. On the other side a database server (Sys.5) is required that manages all the data for WebERP. Both servers, supplied by Dell, run a different operating system. To provide the WebERP service, a high speed internet connection is required, such that people working outside of the organization can access WebERP. As products transition from source code to product to system, they generally retain the same number, such as for WebERP; Des.6, As.6, P.6, and Sys.6 are all instances of the same product.
With all services and products laid out, the supply network can be created. The customer requires Sys.6 from the implementer. The implementer purchases two servers from Dell, one with RedHat installed, the Oracle database management system, WebERP, and Microsoft Windows and IIS for the web server. The implementer combines all components into a new system Sys.6 that is delivered to the customer.
WebERP, the application, is designed by an external ERP product designer. Their design is the blueprint for WebERP, which is developed by WebERP developer and sent to the WebERP publisher. The WebERP publisher compiles the components and productizes the WebERP components, explaining the color change of the flows and the transition from component assembly to product. Finally, the internet service provider (ISP) provides Ser.7, which is black box because it is not relevant how this service is provided.
With this example some applications of SSN models can be demonstrated. In figure 1 the implementer could decide to provide the service Ser.6 itself directly to the customer. Furthermore, the Oracle could decide to deliver ready to run systems by installing their product onto a server Sys.5 and sell them as black boxes to the implementer. These two examples, however, provide a small portion of the myriad of applications of SSN models.
This paper has presented the concept of a SSN model, and its two parts, the product context and the supply network. Part of our future work is to find out whether the SSN models can be used to establish economic viability of a business model.