Open Innovation: Assessing the Socio-Economic Factors of Global Software Development

Introduction

Open innovation is an emerging paradigm which exposes organisations to external or networked resources to avail of newfound service capabilities (Chesbrough, 2003). While open innovation continues to receive more attention, it also highlights the importance of assessing the socio-economic contributory efforts of software teams developing software architecture. Nowadays, organisations are tasked with uncovering “what is out there” to combine external capabilities with internal innovation resources. Thus, over the past decade we witnessed two important key service developments: 1) increase in technology capability and accessibility, and 2) the emergence of new business models. Similar to the growth in information technology (IT) throughout the 1990’s, these developments opened up new opportunities to apply technological capabilities to address business needs. This is particularly evident within the field of software engineering (for example, Šmite et al. 2010) especially in global software development (GSD). Thus, uncovering what stabilises a GSD team is a critical element within the software system since it defines the structures and relations between them to develop software architecture. Software architecture is defined as “the fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution” (IEEE, 2000). The relational properties are of significant interest as this chapter focuses on the need to understand how GSD can facilitate communication and interaction patterns to reuse software components for software architecture in an open innovation environment. This allows us to understand ‘the system’, organise its development process and plan for methods to reuse software components and support its evolution. At a most basic level, the software architecture will be specified using diagrams which have modelled subsystems, interfaces between them, components diagrams, classes, diverse descriptions, and the basic group of use cases. The architecture it typically validated by clients and developers to achieve the desired functionality of a service. A service may be defined as “a change in the condition of a person or a good belonging to some economic entity brought about as a result of the activity of some other economic entity, with the approval of the first person, or economic entity” (Carroll, 2012). For the purpose of this chapter, the author is primarily interested in uncovering the socio-economic dynamics which contribute to the evolution of a GSD team. It examines how the relationship between stakeholders and decision-making influence the socio-economic dynamics of software development. This chapter offers a discussion on the need to apply social and economic considerations to software architectural development and decision-making tasks.