Keywords

1 Introduction

Software sector plays a very relevant role in current world economy as a means to face several of societal challenges [1]. However, being typically constituted by SMEs (Small and Medium sized Enterprises), most of them use to have many problems to be sustainable in the increasing competitive, globalized and innovation-driven market [2].

In the software sector, SOA has introduced a new outlook on system design, implementation and integration, and has been increasingly adopted (as services-based applications) by software developers and customers in general [3]. In SOA, all system’s features are regarded as independent and self-contained software modules – called software services or just services – that jointly form a virtual single logical unit to create products and processes [4].

However, SOA projects are complex, risky and costly, and its adoption impacts both customers and providers at many techno and non-techno dimensions [3].

Software innovation is a key factor to increase SMEs competitiveness nowadays [5]. This paper exploits the premise that SOA providers SMEs can mitigate the mentioned barriers if they innovate together, collaboratively, towards developing a SOA-based solution/“product”, although mostly in the form of prototypes. This has the potential to endow them to develop novel software solutions or gathering existing services and solutions from other companies to more effectively and flexibly attend to new and larger demands and wider markets. Such SMEs are here seen as software services providers (SSP), i.e. independent organization that owns and provides software services’ implementations and descriptions as well as the respective technical and business support throughout a given SOA solution’s life cycle [4, 6].

In a previous work, authors have proposed an innovation model for SOA providers [7]. However, after further evaluations by some IT companies, it was realized that it could not support at all the required flexibility in the development path as each SOA product, as an innovation project, is unique and there is not a single model to follow.

A sort of innovation models has been presented in the literature. However, it was not found out anyone devoted to SOA/software sector and that consider software services’ providers as autonomous SMEs that can participate in all phases of the innovation process, flexibly, collaboratively, as a network. This is also important as a SOA/software “product” is different than manufacturing, in terms of e.g. development stages and methodologies, supporting constructs, physical deployment, SLA treatment, software/services quality, and product contracting, access and usage [6]. This paper presents a newer model so as to cope with these requirements.

This work has been conducted as an essentially action-research, qualitative, deductive and applied research, strongly grounded on literature revision.

The paper is organized as follows. Section 1 has introduced the problem and research goals. Section 2 presents a brief review of the main basic foundations used in the proposed model. Section 3 presents an analysis of related works. Section 4 presents the proposed innovation model. Section 5 presents some results of a preliminary assessment of the model. Finally, Sect. 6 presents final consideration about the research done so far and next steps.

2 Basic Concepts

Innovation Models.

Literature presents several definitions of innovation. In this work we have considered it as “the implementation of a new or significantly improved product (good or service), or process, a new marketing method, or a new organizational method in business practices, workplace organization or external relations” [8].

An innovation model can be defined as the general conceptual construct that helps organizations to set up the innovation framework, to develop the innovation itself and to manage its progress and results (adapted from [9]). In general, it basically describes the main phases and processes necessary to carry out an innovation throughout (and typically via) a so-called funnel. These processes often comprise: generation and ideas selection; concept development; concept evaluation/selection; concept design and specification; implementation; and exploitation (adapted from [10]).

Innovation models have evolved from linear to open and network models, and can go back and forth through each stage. Evaluation actions (through gates) are normally added between each stage in way to restrict process’ continuation. Processes can be executed sequentially or in parallel. Different types of actors can be involved along the innovation process with variable roles, being intra-organizational members or external partners, like ad-hoc business partners, supporting institutions and customers [11].

Regarding this paper’s goal, two innovation models are relevant. Open innovation model is based on a more ample collaborative environment where ideas both from the company and third parties are taken into account in some parts of the innovation process to add value to what has been conceived [12]. The Network model considers an environment that is composed of a set of complementary and independent organizations that work on a given innovative idea regarding their core expertize [13].

Collaborative Networks (CN).

CN has arisen as a prominent paradigm to underpin strategic alliances that are focused on a more intense and fluid collaboration among autonomous organizations. Its vision relies on allowing organizations to keep focused on their skills and aggregating competencies and sharing resources with other organizations in order to meet businesses in a better way [14]. In order to support a higher agility in the formation of an innovation network, the concepts of two types of CN are used. A Virtual Organization (VO) can be characterized as a temporary alliance formed by autonomous and heterogeneous organizations that join their complementary core-competences and resources to better attend to a given demand, dismantling itself after all its legal obligations have been accomplished. VOs are originated from long-term alliances, the Virtual organization Breeding Environment (VBE). A VBE can be defined as a long-term association of organizations (companies, etc.) which have the willingness, enough preparedness and trust, and that share common principles to collaborate. It is assumed in this work that SSPs are members of a VBE-like alliance.

A collaborative innovation network is defined as “a long-term or temporary cluster of disparate and autonomous organizations with the willingness to collaborate towards exploiting together an individual or collective business vision by sharing ideas, knowledge, work, computing and services assets, as well as costs, risks and benefits, supported by ICT, and grounded on trust, preparedness, governance and IPR” [15].

Service Oriented Architecture (SOA).

A SOA “product” typically comprises services of several natures, like business services, infrastructure, security, interoperability, orchestration, wrapped legacy systems’ functionalities, etc., deployed and provided under different models [4]. Web services are one of the most currently implementing technologies in SOA [4].

Likewise traditional software engineering methodologies, SOA also has a lifecycle, covering a number of developing phases [4], spanning from the analysis to delivery and management. However, these phases have to be dealt with in a different way as: (i) the final result of a development process within an innovation initiative is usually a prototype, proof of concepts, etc., and where some existing software/services from SSPs can also be reused for the given purpose; i.e. it is a not a bundled product; (ii) likewise typical SOA development processes, collaborative innovation involves disparate SSPs, having different practices, working cultures and sometimes non-common objectives in terms of exploitation plans, (iii) SOA is not a mere technological paradigm. Instead, it is an approach to help companies to better achieve its strategic goals. The model should provide means to bring the business perspective into the software innovation process; (iv) besides supporting the provision of the services themselves, a SOA solution should look after its life cycle as a product as well as the general non-software services required to support its life cycle (e.g. local integration, ESB configuration, training, maintenance, etc.), i.e. the set of respective business models. In other words, SOA deeply involves management too, at several levels [16].

3 State of the Art Review

A literature review was carried out mainly via the SLR methodology, looking for articles that essentially tackled SOA, innovation, SMEs and networks. The search also comprised the CORDIS EU’s research projects database. None works were found out that covered that at all. However, five papers and seven projects presented some similarities and have provided some useful insights for the proposed innovation model.

In terms of papers, in a resumed way: in [10] an innovation model for manufacturing products and related services have been devised, identifying the most important innovation processes, but without considering software services and a high dynamics in the network formation. In [18] a supporting language to express the value delivery and services chain for the general area of services was proposed. In [19] authors stressed the obstacles for SMEs to collaborate towards jointly handling e-business transactions. In [20] authors proposed a framework and typology to understand the services innovation (but not of software) as a wider and multidimensional evolutionary process. In [21] a model-driven collaborative development platform for SOA-based e-business systems was proposed, but without considering innovation processes and networks of companies.

In terms of EU funded projects [22], BIVEE, ComVantage, IMAGINE, CoVES, Laboranova, PLENT and GloNet have tackled innovation at different perspectives and levels, but devoted to the manufacturing and general services sectors. Some of them consider open innovation, some don’t. GloNet is the only one that has specifically applied the network innovation model using the virtual organization concept. None of these projects are devoted to software innovation or SOA areas though.

4 Proposed Innovation Model

The innovation process can be triggered on customer request or prospectively (by one or more partners) with the aim to attend foreseen new businesses or to improve a previous SOA products. Innovation outcomes can evolve and be exploited according to what was set up in the governance model. Cycles of developments, prototyping, etc. can be necessary until a result can be considered as ready for representing the initially envisaged SOA product. During the development partners can reuse their existing software services assets and also share them with other members [23].

A set of premises are adopted to frame the envisaged innovation scenario: selected members may participate along the entire innovation process and associated software development cycle; this participation, stage of that, and decision power should respect the respective VO governance model; companies can/should enter to, operate in, and exit from the collaborative innovation network in different moments and number of times, both in the normal operation of the network and when problems, changes or severe conflicts take place; the innovation process involves creativity and some unpredictability [24]. These premises were adapted to the envisaged collaborative innovation, flexible, and SME- and SOA-oriented scenario.

In order to cope with the desired flexibility, we brought inspiration from the Design Thinking method [25] and of its three innovation “spaces” (immersion, idealization and prototyping) and innovation stages. This was complemented and adapted (including processes’ terminology) with the six classical processes suggested in [11] regarding the specificities of the envisaged scenario. Besides considering the SOA development requirements along the whole innovation processes and spaces, one of the processes is devoted to software development itself. For that, we have adopted and adapted the processes proposed in [4, 16]. Governance issues were regarded mainly considering the works of [17, 26, 27]. Regarding the intrinsic nature of software development process, there is no simple progression, being often necessary to go back to earlier stages in order to overcome problems and need for revisions, in non-linear cycles. In other words, each innovation is treated as a unique initiative with no predefined paths.

The collaboration within a VO is carried out along four phases/life cycle: Creation (starting phase, when it is created, partners are selected and the network is configured for the business); Operation (when the VO effectively runs, executing and managing the required activities and partners towards reaching its goals); Evolution (performed when problems take place during the Operation phase and that can hazard the VO success); and Dissolution (ending phase, where the VO finishes its activities) [14].

4.1 The Innovation Model

The proposed innovation model is to support the development of the SOA product, from the initial ideas exchange to its final delivery/deployment (Fig. 1). There are three spaces through which all the actions are carried out.

Fig. 1.
figure 1

The proposed innovation model. Source: authors.

Full size image

The execution path within each space is flexible, i.e. each innovation initiative has particular requirements that determine its flow. Because of that, each process is seen as a kind of decoupled building block, which is linked with others to define the given innovation’s path and the set of activities that have to be executed. This also means that a given space (and so some of its processes) can be revisited in cycles, or that some of the processes may not be performed. The whole team of companies, also considering the governance model associated to the given innovation initiative, is the responsible to set up the path on-the-fly and to make the necessary changes when needed. That is why there are no arrows in the model as the flow, cycles and sequence can vary from project to project. Briefly, the spaces and processes are as follows, and they have not to be understood as sequential steps.

  • Idea Analysis: one or more companies from the VBE-like alliance can propose a joint innovation to the alliance’s committee (or a kind of board if any), which will firstly evaluate the idea’s potential. At this moment the idea is just generally presented.

  • Briefing: the idea is detailed presented, describing the necessary technologies, potential partnerships, estimated ROI, foreseen market, etc.

  • Consulting Alliance Board: process triggered in the case the innovation team needs some advisory about given issues. Although it can depend on how the governance model had been set up when the alliance was founded, the board usually does not have the power to cancel an initiative. It is usually formed by some selected members and can also involve external actors. The main goal here is to try to anticipate problems or to identify major issues and possible solutions before keeping going on.

  • VO Configuration: formation of the VO that will develop the innovation. It usually includes subprocesses, like partners’ search and selection, negotiations of several matters, the VO governance model setting up, the agreement on revenue mode, and IPR contracts signature. VO members may have different decision powers and internal top level committees can be created. This can also comprise the definition of performance indicators and metrics upon partners and the innovation process itself.

  • Presentation: a more complete project plan and ICT technological analysis are conceived and the initially devised business model (if any) is refined. This is done by the involved companies’ managers and can also be helped by some external expert actors, depending on the VO governance model specification. This process also includes discussions on issues like IPR and ownership, technology transfer, accounting, and knowledge gaps in the VO and in the alliance.

  • Software-Service Conceptualization: idealization and macro specification of the SOA solution, the required services to be composed, the expected end-to-end QoS, implementation technologies and access modes, SOA governance requirements, etc.

  • SOA Solution Development: it is equivalent to the software-service conceptualization process, but at a very detailed level. This includes services coding, integration among services and with their presentation and persistency layers, QoS testing and launching. It actually covers the SOA/services life cycle, including the particularities when the SOA project is to be developed by a group of companies [6] (see also Sect. 2).

  • Consulting VO Board: process triggered in the case the innovation team needs some advisory about given issues, for example, when there are relevant changes in the project course and budget, the need for new members, etc. This VO board can be composed of a predefined group of partners (and even external actors) or be settled following the VO governance model.

  • SOA Solution Commercial Preparation: this last process makes the idealized innovation outcomes available for “use”. In this process the VO members make agreements and sign legal contracts, which can comprise commercial support for future products and services, IPR, commercialization model, price policy, etc.

  • Local Infrastructure Provisioning: preparation and hiring of the required infrastructure for the SOA solution at the customer, third part, some specific member, or at the alliance’s site regarding the agreed business model, contracts and QoS requirements.

  • Local Deployment: making the physical deployment of the SOA solution at the customer’s site once the infrastructure is ready.

  • External Deployment: making the deployment (e.g. in a cloud) of the SOA solution. The third space may be not executed depending on the development results and even on the initiative’s goals. For example, partners might only be interested in developing a mockup to better evaluate some concepts even though some potential customers might be invited to assess it. On the other hand, this space can be partially visited when e.g. such prototypes require some deployment in external clouds to evaluate end-to-end QoS.

In general terms, a more human-driven approach tends to prevail in the first space, and a process-driven approach in the second and third ones as software development and delivery processes are usually much more structured. As such, in each space, there are different notions of: budget, time and human resources allocations; the need for research and even the involvement of research institutions; and the involvement of customers, experts and other supporting institutions (like IPR offices).

The nature of discussions, type of involved and required knowledge, information flow, type of responsibilities, etc., are different in each process and space. Regarding that, the innovation initiative behaves more like as the network type inside the first space and more like as the open innovation type in the second and third spaces. In terms of governance model, while the all-ring no-core and buyer-driven models [26] are likely to prevail in the first space, this tends to be more core-ring with coordination firm and information-driven [27] in the second and third spaces. Likewise in the traditional funnel-based models, where gates are used to decide about the continuation of the innovation project, the proposed model also has this equivalent concept. Actually, the innovation initiative can be interrupted, radically changed or just stored (for further usages) anytime in any of the spaces/processes. Performance indicators can be used to support this decision [28], following the governance model. All processes can be audited and authorized knowledge can be stored, also following the governance model.

4.2 Functional Guidelines

Functional guidelines (FG) are supporting and reference constructs of the model. Members of the innovation initiative require methods, techniques and tools to help them executing processes’ activities along the collaborative innovation regarding that SMEs’ managers are often not much aware of which issues are more likely to be taken into account in each process. The model does not offer the concrete methods themselves. Instead, they should be chosen by each alliance or VO regarding existing practices, available financial resources, prepared people, etc. For example, if VO members realize that they indeed need some support in terms of (the FG) Project Management in a given process (or space), they can select the PMBOK methodology and the MS Project as the specific software tool after an analysis by the members.

FGs are actually associated – as an abstract reference – to each model’s processes. For example, thanks to the FGs, partners can become aware that (FGs) actors’ roles and network operation governance issues are important to have in mind in the VO configuration process.

There are ten main FGs. They were identified and categorized via an inductive method over a number of papers on innovation, [2, 29] in more particular:

Business level: FGs more related to the business and strategic aspects:

  • Business Model Management: foundations to help partners checking if innovation results are aligned with the defined business model and innovation goals.

  • Legal Management: help partners checking if the innovation follows the required legal frameworks, contracts, IPRs and services ownerships.

Operational level: support to the daily operation of innovation developments:

  • Actors’ roles: help partners checking if partners’ rights, duties and roles settled in the alliances and VO’s governance models are been followed.

  • Network Operation: it is also related to the governance model, helping the observation of the power and structural elements of decision-making along the innovation process.

  • Project/Resources Management: supports the issues related to manage the innovation process as a project, including associated e.g. financial, material and human resources.

  • Incentive Systems: checking if the collaboration incentives are being correct applied to partners, also regarding general performance and adherence to the project’s goals.

  • Performance Indicators: selection and application of adequate indicators to measure and manage the performance of the innovation projects and partners.

Policies level: FGs related to general relations among the VO, the VO with other actors (internal or external to the alliance), and with customers:

  • Governance: rules to set up how the innovation will be managed, including partners’ roles, responsibilities, boundaries of actions and actors autonomy.

  • Software Process Improvement: models, standards, specifications and methodologies to guarantee the use of more proper practices of software and services development.

  • Knowledge Sharing: to guarantee that the necessary information and knowledge to support the innovation are properly organized and shared, that lessons are learned, etc.

These FGs and their placement along the innovation process should however be seen as a reference. Regarding the particularities of the given innovation initiative in terms of e.g. existing culture, type of customers, current business models, and regional/national/international accounting and legal frameworks’ requirements, FGs can support processes at different levels and can have different degrees of importance. Besides that, other FGs can be added to the model if needed by the particular case.

5 Preliminary Evaluation

This model was preliminary evaluated by a group of experts on SOA from a cluster of ICT/SOA providers placed in the South of Brazil. Actually, such users have been participating since the early stages of the model development, helping in the identification of requirements. A survey was prepared using the GQM method [30] and the method was presented and a set of typical business cases were exemplified. In this first stage the questions of the survey focused on the processes and basic assumptions of the innovation model. The questions were made using the Likert scale and free-response questions. For all the experts, all processes were considered as necessary. For most of them the most critical processes are the Ideas Analysis and the VO Configuration, and the general SOA delivery space due to commercialization aspects as they are particular to customers and there can be several providers involved in. The experts called the attention to the governance issue and the complexity it can have, at the alliance, VO and SOA levels.

About if software services providers in the near future tend to provide joint solutions in order to reduce costs and risks and increase the chances of better addressing the market, around 75 % agreed on that. About if more and more ICT companies can become part of larger IT ecosystems in the near future to take advantage of complementarities and additional scale, around 85 % agreed on that.

6 Final Considerations

This paper has presented current results of a research which aims at conceiving an innovation model devoted to support collaborative innovation among SMEs of software/services providers related to SOA products. Collaborative innovation has the potential to leverage new degrees of sustainability for software and SOA SMEs. The proposed model has been developed in the light of Collaborative Networks foundations, enabling SMEs to work as a network, sharing assets, resources, costs, risks and benefits. A Virtual Organization (VO) represents the group of SMEs that jointly develop an innovation. This work has also identified the most important supporting constructs to consider throughout the innovation process and VO life cycle. Such constructs, called as functional guidelines, help companies to allocate resources and to be aware of the different levels of complexities along the collaborative innovation life cycle. It could be noticed that dealing with the envisaged scenario which combines collaborative innovation between disparate and independent SMEs, SOA and software sector particularities, flexibility in the processes, etc., is complex. Regarding it was not found in the literature an innovation model for this scenario, the proposed model should be taken as an initial contribution, even because it was not truly validated yet. As the model was conceived based on more generic and reference innovation models, we believed it may be also used in the traditional software sector. However, some activities inside of some processes should be adapted, in more particular the SOA solution development process and the software delivery.

Next short-terms steps of this research include new rounds of assessment and practical evaluation of the model towards its validation.