=Paper=
{{Paper
|id=Vol-247/paper-7
|storemode=property
|title=Analyzing the Business of Software: A Modelling Technique for Software Supply Networks
|pdfUrl=https://ceur-ws.org/Vol-247/FORUM_06.pdf
|volume=Vol-247
|dblpUrl=https://dblp.org/rec/conf/caise/JansenFB07
}}
==Analyzing the Business of Software: A Modelling Technique for Software Supply Networks==
https://ceur-ws.org/Vol-247/FORUM_06.pdf
21
Analyzing the Business of Software: A Modelling
Technique for Software Supply Networks
Slinger Jansen1 Anthony Finkelstein2 Sjaak Brinkkemper1
1
Utrecht University
Information and Computing Sciences Institute
Utrecht, The Netherlands
{s.jansen, s.brinkkemper}@cs.uu.nl
2
University College London
Dept. of Computer Science
London, United Kingdom
a.finkelstein@cs.ucl.ac.uk
Abstract. One of the most significant paradigm shifts of software busi-
ness 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 tech-
nique 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.
1 Software Supply Networks
Individual businesses no longer compete as single entities but as supply chains [5].
This holds for the software industry as well, where software products and services
are no longer monolithical systems developed in-house, but consist of complex
hardware and software system federations [3] produced and sold by different
organizations. This development has lead organizations to combine their busi-
ness and components into complex software supply networks (SSNs), from which
they supply end-users with integrated products. As these SSNs grow more com-
plex, it becomes harder for the participants of SSNs to make informed decisions
on development strategy, responsibility, liability, and market placement. It also
becomes harder to manage the risk associated with these decisions [4].
A software supply network is defined as a series of linked software, hardware,
and service organizations cooperating to satisfy market demands. SSN manage-
ment 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 [1].
As SSNs grow more complex, organizations require more insight into SSNs [2].
Such insight is required by all the participants dealing with the supply network,
22
Fig. 1. SSN Model of WebERP
such as a customer trying to determine who to address when an interface does
not work, a vendor considering strategic alliances, or a judge trying to deter-
mine liability within a SSN. We present a method for modelling the complex
relationships between participants in the supply networks of composite products
and services. Such models enable participants in the SSN to evaluate risks and
architectural decisions for software products, by use of a product context model.
A result of the difference between conventional supply networks and SSNs is
that literature on collaboration in supply networks [7] does not discuss mainte-
nance and how it requires information flow through the supply chain. The same
holds for other work on SCM, such as [6], which groups horizontal ties between
firms (such as manufacturers and suppliers), but fails to recognize the impor-
tance of leveraging feedback in such networks, or Lambert and Cooper [5], who
provide a conceptual framework for SCM without maintenance.
2 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.
23
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 hard-
ware 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 mak-
ing 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 par-
ticipants (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.
Fig. 2. Software supply network model legend
24
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 manage-
ment 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 de-
veloper 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.
References
1. L. Baxter and J. Simmons. The software supply chain for manufactured products:
reassessing partnership sourcing. In International Conference on Management of
Engineering and Technology, 2001.
2. R. Colville and P. Adams. It service dependency mapping tools provide configuration
view. In Gartner Research News Analysis. Gartner, 2005.
3. C. Ghezzi and G. P. Picco. An outlook on software engineering for modern dis-
tributed systems. In Proceedings of the Monterey workshop on Radical Approaches
to Software Engineering, Venice (Italy), October 8-12, 2002.
4. S. Jansen and W. Rijsemus. Balancing total cost of ownership and cost of mainte-
nance within a software supply network. In proceedings of the IEEE International
Conference on Software Maintenance, Philadelphia, PA, USA, September, 2006.
5. D. M. Lambert and M. C. Cooper. Issues in supply chain management. In Journal
of Industrial Marketing Management, 2002.
6. S. G. Lazzarini, F. R. Chaddad, and M. L. Cook. Integrating supply chain and
network analyses: the study of netchains. In Journal on Chain and Network Science.
Wageningen Academic, 2001.
7. J. Patosalmi. Collaborative decision-making in supply chain management. In Sem-
inar in Business Strategy, 2003.