Keywords

1 Introduction

To classify items human beings create mental boundaries for distinguishing items, including adopting different terms: this is a classical approach for benchmarking purposes. For example, in the Automobile market SUVs or Crossovers are recognized as distinct car segments by adopting a number of criteria, for instance their length and main characteristics. Again, in the Telecom market smartphones, tablets or ‘phablets’ are now recognized as distinct kinds of products mainly according to their size etc. However, when classification rules become too strict we may risk losing the ‘big picture’.

This can also be observed through the division of three main groups of processes (development, operation, maintenance) of a system throughout its lifetime. Here the first and the third group are often associated with the Software domain, while the second is associated with the Service domain. In this context CMMI-DEV [1] or ISO 15504-2 [2] now in the ISO 33000 series) are examples of process improvement models for the Software domain, while, ITIL [3], MOF[4], CMMI-SVC [5] or eTOM [6] are examples for the Service domain. Yet, a mix of ‘components’ from models of those two ‘separated domains’ is rarely observed. However, when analyzing the existing models/frameworks both at the process level and product level, the differences are not as sharp. For instance on the process level 16 out of the 22 processes within CMMI-DEV and CMMI-SVC are about the same, with very slight differences, mostly in the glossary adapted to the specific tasks to be performed [31].

Looking at the product level, the quality model for a software product in the ISO 25010 standard [7], if the term ‘software product’ was substituted by ‘service’, the list of categories and sub-categories could still be a good fit for a pure service, with such a service not being necessarily an ICT-related service (e.g. a service should be designed to be maintainable, reusable, usable, reliable, etc.). A question that arises is: are software and services different or not? And, if not, how to preserve the best aspects from any existing model/framework/classification currently available within both communities?

Furthermore, how to lower the Total Cost of Ownership (TCO) for the management of a project? And could Knowledge Management (KM) be part of such a solution? In this respect, this paper attempts to answer these questions by introducing an improvement approach based on merging elements from different frameworks and models, having in mind one final goal: to reinforce the organization’s Business Process Model (BPM) respecting, instead of upsetting, its architecture (Fig. 2).

This paper is structured as follows: Sect. 2 describes the main differences and commonalities as they are perceived by both communities of interest (software and service). Section 3 discusses how to merge best practices from other models as improvements to be integrated into an existing organizational BPM using the LEGO (Living EnGineering process) approach [8]. Section 4 presents an example using a typical ICT management case. Section 5 presents some conclusions and suggestions for improvements.

2 Software vs Service? Friends or Foes?

This section describes briefly the main differences and commonalities between products and services. According to ITIL and ISO 20000-1 [9]) ‘a service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks’. ISO 20000-1 adds a note that ‘service is generally intangible’.

2.1 Differences

A typical difference between product and service is the level of tangibility of a deliverable. A product (such as a table) is more tangible than a service that is typically intangible (e.g., the value perceived from whatever experience and therefore perishable, with the need to reproduce the same level of quality each time (QoS – Quality of Service)). Whereas a product – once produced – may be used many times and typically exhibiting the same level of quality (QoP – Quality of ProductFootnote 1).

In the early 90’s, ISO published two similar but distinct standards for managing quality at the organizational level: ISO 9001 for the products and ISO 9002 for the services, whatever the application domain. Later, the so-called ‘Vision 2000’ project reconciled the two standards into a single one: ISO 9001:2000 indicated that while the formal term adopted in the document was ‘product’ it was intended as a ‘product/service’, with the ultimate aim being to achieve customer satisfaction. In particular, the ICS (International Classification for Standards) code distinguished the working sector for an organization to be auditedFootnote 2: EA33 is the code for those organizations managing software, while EA35 is the code for organizations managing services.

In relation to services for developing software ISO has published the ISO 20000 series, based upon ITIL (IT Infrastructure Library), the UK standard of best practices for the IT Service Management (ITSM) community. While some concepts are differentiated (e.g. service catalogue, risk register, capacity management), other elements (such as the process improvement approach based on the Deming’s PDCA cycle) are the same in both standards. ITIL details the ‘7-Step Improvement process’ stressing the role of a proper Knowledge Management (KM) process for a more effective continuous improvement.

2.2 Commonalities

There are different types of service. For instance, maintenance is a service; operation is a service, in addition to both developing and managing software also being a service. In order to understand how the ‘boundaries’ of both standards overlap, evidence from one set of standards can be mapped to evidence from the other one (e.g. taking ISO 20000-1 [9] requirement and applying them to a software development project or, alternatively, taking ISO 9001 requirements [10] and applying them to a pure service). Their differences seem to be mostly in the terminology adopted rather than the actual contents.

A ‘service catalogue’ is a library of services: applying the same concept to any type of asset library, it works well using libraries with software code for reuse. Furthermore, the ITIL definition in the Definitive Media Library (DML) where software and related documentation and licenses are stored makes use of the same configuration management process. Some specifications (‘Service Asset and Configuration Management’) do not change the inner content of the process but extend the common concept from software code to any kind of organizational asset (including HR-asset) needed as ‘components’ of a service, that is - conceptually speaking - wider than the software itself.

2.3 The Challenge – Possible Benefits

The commonalities appear to out-number the differences. Could this therefore indicate that an organization could be made more successful through using more knowledge from models/frameworks typically developed and adopted by each of the two communities? Here it follows a list of candidate drivers for stimulating a positive and effective change and possible benefits from the joint usage and vision of software + services as a whole within the ‘project’ umbrella:

  • Unique, Continuous Lifecycle and Process Flow: what the final customer is asking for is a not a product itself, but the value that such a product (software or system) can provide to his users by its usage. Thus, the whole project can be split into a series of sub-projects (or iterations-sprints with several deliverables, outputs (e.g. software or a user manual) plus outcomes (e.g. training, positive perception after the usage), as in Fig. 1. Organizations often tend to have a group for the development part and another one for the maintenance part, creating possible logical breaks in terms of service continuity and value provided, while a customer would expect such continuity defined as ‘availability’ as stated in the agreed service levels to be as high as possible.

  • Glossary: a Change Request (CR) is exactly the same as a Request for Change (RfC) or a Modification Request (MR): these are different terms for the same concept. This happens also for other terms: for instance, the internal ‘capacity’ of a service team can be associated to the ‘productivity’ levels needed to do a project estimate, etc. However, frequently words can create barriers that may be difficult to overcome and they may reduce the initial effectiveness when people with different professional paths work together. A common, shared glossary – including a list of most used acronyms – could help in speeding the communication among people within a team.

  • Knowledge Management (KM): the input for improving anything is to know and, better, to know how to do better things. Most of the software process models assume that such knowledge is already part of a team, while often it is not. Thus, an organization stimulating creativity and knowledge sharing (e.g. the SECI model [14]) could have a greater probability to be effective on the market than its competitors.

  • Product/Service: the more tangible product is the means for providing a service to the final users. In that sense, the management of a project should be more service-oriented because the focus in the mid-long term should be in measuring not only the ROI (Return on Investment) but also the VOI (Value on Investment). This includes also what is generated by intangibles.

Fig. 1.
figure 1

Mixing CMMI constellations (DEV + SVC) into a unique ‘project scope’

Full size image
Fig. 2.
figure 2

ISO 25010:2011 quality model [7] – also for service?

Full size image

2.4 A Short Example – Software + Service Together

A further example comes from project ‘lifecycles’. The Agile approach was born in the mid ‘90 s for managing Telco projects with unstable requirements and short lead times for delivering the ‘products’. When looking at an Agile Project Management (APM) method such as Scrum [11], it is possible to adapt it to a pure service using, for example, a revised version of user stories, US2 (2nd generation of User Stories (US)) [12]. This is illustrated in Fig. 3: a US2 card adds: (a) sizing FUR and NFR by functional and non-functional sizing units (fsu/nfsu) or – as in typical US cards – directly assigning the effort in person/days (or person/hours); (b) specifying a priority (after the INVEST grid evaluation [13], see below) according to the well-known ‘MoSCoW’ (Must or Should, Could or Would) criteria from BABOK [30] and Project Management guides; (c) the formal writing also of the non-functional side of a story, which is far from obvious in a typical US card.

Fig. 3.
figure 3

US2-Type2, including both FURs and NFRs

Full size image

There is also the possibility to have only NFR (including in this definition for sake of simplicity also the project-related tasks, as quality assurance, measurement, project planning and monitoring & control, etc.), in what we call a Type1 US2 card (Fig. 4).

Fig. 4.
figure 4

US2-Type1, including only NFRs

Full size image

After the customer and provider create the single US2 cards, as achieved in an agile context, their analysis and evaluation can be done through applying a grid based on criteria such as independent, negotiable, valuable, estimable, small and testable (INVEST) Grid. The process is fully defined in [13] and uses Table 1 as the basic template to use between a customer and a provider. The six attributes have been described using a four-point ordinal scale (0–3), as in the ISO 14598-x standards, where ‘0’ means ‘poor/absent’, ‘1’ means ‘fair’, ‘2’ means ‘good’ and ‘3’ ‘excellent’. Each cell contains a description that proposes a rating for that attribute at that level.

Table 1. The INVEST Grid [13]
Full size table

In a service management context the main goal is to release ‘value’ to a customer. This is a summary of ‘utility’ (fit for purpose) and ‘warranty’ (fit for use), where the first one covers functional user requirements (FURFootnote 3) and the second one for non-functional requirements (NFRFootnote 4) (see Fig. 5).

Fig. 5.
figure 5

Functional User Requirements (FUR) vs Non-Functional Requirements (NFR)

Full size image

There are two factors: (1) the ISO 25010 quality model for a software product can also be applied to a service for describing and managing the ‘warranty’; (2) a service project could plan for each iteration (‘sprint’ in the Scrum glossary) to release firstly the ‘core + enabling’ services (in software this could be the ‘development’ part) and the following ones typically ‘enhancing’ services (in software this could be a series of enhancements).

3 Methodology

Our objective in this paper is to introduce a discussion and try to demonstrate that only one side of the story (software or service) may not deliver all the benefits an organization could achieve from a joint adoption. For instance, in two out of the three CMMI constellations, DEV and SVC, 16 out of 22 processes are the same [37, 38]: in this case would an organization run two separated process improvement initiatives or a single one by evaluating commonalities for a unique improvement plan? This corresponds to what BSI (British Standards Institution) called a ‘publicly available specification’ for an integrated management system (‘PAS 99’) [32]. For such an integration, our proposal is based on the LEGO (Living EnGineering prOcess) approach [8] proposed for stimulating organizations to improve their own processes: it suggests to take pieces (as LEGO bricks) from multiple candidate information sources and integrate them to form a unique, reinforced picture for a particular process or set of processes. It allows organizations to avoid searching conformity to ‘external’ models, when a model itself is an abstraction for trying to catch several instances at a timeFootnote 5. Again, any model/framework can represent only a part of the observed reality, not all of its possible views, since it needs to represent a single viewpoint at a time. In that way, enlarging the scope of potential useful elements for improving the organizational BPM, there could be more chances for success. LEGO has four main elements (Fig. 6):

Fig. 6.
figure 6

The four elements of the LEGO approach

Full size image
  1. 1.

    a ‘Maturity & Capability Models’ (MCM) repository (www.gqs.ufsc.br/mcm), from which relevant processes (i.e., MCMs) can be identified;

  2. 2.

    knowledge about the process architecture of each model, for understanding how to transform the desired elements from a certain model into the target format, especially when considering that the source models may have different architectures that need to be integrated into a single model;

  3. 3.

    mapping(s) & comparisons between relevant models, in order to understand the real differences or the deeper level of detail from ‘model A’ to import into ‘model B’;

  4. 4.

    a process appraisal method (PAM) to be applied on the target organization’s BPM (Business Process Model).

The LEGO approach follows a four step process:

  1. 1.

    Identify informative/business goals: clearly identify your needs from the current BPM version and content.

  2. 2.

    Query the MCM repository: browse the MCM repository, setting up the proper filters in order to obtain the desired elements (processes; practices; etc.) to be inserted into the target BPM.

  3. 3.

    Include the selected element(s) into the target BPM: include the new element(s) in the proper position in the target BPM (e.g. process group, maturity level, etc.).

  4. 4.

    Adapt & Adopt the selected element(s): according to the process architecture of both process models (the target and the source one), the selected elements may need to be adapted, tailoring such elements as needed.

Such an approach has been applied to several contexts and processes (e.g. requirement management [15], risk management [16], etc.), and it could be applied also to an improved BPM where some elements could have been missing.

4 Unification of Software + Service

This section presents an example on how to use jointly software and service models (what ISO calls a Process Reference Models (PRM)), picking up those information and best practices that one model eventually could not have yet foreseen, and to strengthen them. As already mentioned, an organization has to manage a project that could be often composed by pure software development and maintenance and pure services (e.g. incident management). Thus one of its goals will be how to lower the Total Cost of Ownership (TCO). Are really software and services so different or not? And if not, how keep the best from any model/framework/classification currently available from both communities? Can Knowledge Management (KM) be part of such solution? A real application should be done on your own BPM processes. Here, for sake of simplicity, ISO 15504-2 is selected as the target BPM to be reinforced and a series of Software and Service PRM as the sources to be investigated for picking up some interesting additional ‘bricks’ to be added, in case. Now a new application can be done considering the SPICE Knowledge Management process (RIN.3). KM was chosen because it is important to stress and discuss how to create and generate value for an organization. Having a proper KM process in place would help as a support process for many initiatives, and it is not yet part of CMMI-DEV/SVC but of another SEI-based model (People CMM): thus it can be proposed as an example, together with CMMI, as a target model for the positioning of ‘missing pieces’. Table 2 presents a list of KM-related models/frameworks explored for finding Elements of Interest (EoI) to be inserted for reinforcing RIN.3.

Table 2. Some KM-related models/frameworks
Full size table

The following preconditions, process and main results from the application of the LEGO process to the KM domain are proposed for a better process that may be applied in an organization:

  1. 1.

    Identify informative/business goals: improve the capability of the organization to collect, share, reuse and improve its knowledge by its employees and partners.

  2. 2.

    Query the MCM repository: Table 3 proposes the list of potential elements of interest (EoI) to consider for improving ISO 15504 KM process.

    Table 3. KM MCM: Elements of Interest (EoI)
    Full size table
  3. 3.

    Include the selected element(s) into the target BPM: looking at the analysis of potential EoI (Elements of Interest) in Table 3. Table 4 shows how our suggestions were introduced in the current RIN.3 process, describing a new possible improved process that may be mapped against your own QMS internal process(es) covering that subject.

    Table 4. KM process - suggestions for improvements.
    Full size table
  4. 4.

    Adapt & Adopt the selected element(s): after adapting the original RIN.3 process considering the proposed suggestions for improvement (see Table 4), the improved RIN.3 process should be mapped now against the related QMS internal process covering that subject. Since many organizations adopt an ISO management system (e.g. ISO 9001), a cross-check for validating potential improvements from the design phase could be achieved through re-applying the related mapping document to their own internal process (e.g. using the N/P/L/F – Not/Partially/Largely/Fully achieved ordinal scale from CMMI or ISO 15504). Moving from ISO 15504, it could be used also the Mutafeljia & Stromberg’s mapping [26] and/or the one by Peldzius and Ragaisis taking CMMI-DEV and ISO 15504 [29] as a basis. In this paper, our focus was limited to only the design phase. However, a case study with the application of hybrid-RIN processes will be included in a future paper.

The EoI presented in Table 3, as well as the included elements, respect the BPs of the RIN.3 process provided in Table 4 are not to be considered exhaustive: to the contrary, these two tables are to be considered as a starting point for the application of the LEGO approach in practice.

What can be easily observed reading the ‘EoI’ column is that any model can propose a series of elements and good practices, but just a single ‘model’ cannot include in one possible viewpoint every possible EoI, simply because they all were originated from different assumptions and rationales.

In particular this short example from ISO 15504 RIN.3 process stressed the need:

  • to reinforce the list of work products/deliverables defined at the end of the ISO PRM with few more elements, not currently defined;

  • to provide suggestions about the communication area, because – as in the SECIFootnote 6 model [14]– you can also have a great idea but being limited to few applications, while the larger the diffusion, the higher the probability to create/generate new joint ideas from the initial one, being refined little by little after an initial application;

  • a list of stakeholders to be periodically contacted (e.g. panels) for providing opinions/ideas on new products-services or revision for current services provided to the market.

5 Conclusions and Next Steps

Software and Service are two sides of the same coin within an ICT project. Too often they are viewed as separated issues to be managed and improved by specific models and frameworks. After reviewing the main differences and commonalities, it could be valuable to an organization to start looking at them as friends and not as foes. A list of common items valid both from the software and service sides has been discussed (e.g. the way to manage requirements by User Stories), depicting the main challenges to properly manage them together as a whole.

The LEGO (Living EnGineering prOcess) approach has been presented as an effective way to take into account several information sources from the MCM (Maturity & Capability Models) belonging to the desired area/domain to be improved. LEGO has been applied in different ways over the past years to specific process areas (PA) to be improved as a ‘vertical’ improvement, while in this paper it was applied in a ‘horizontal’ way, trying to give continuity to a continuous flow (from the development of a software system till its maintenance) within the unique ICT project frame. The RIN.3 Knowledge Management process from the ISO 15504 PRM (Process Reference Model) has been considered as a small application example, considering models from both domains (software; service & governance) for picking up potential Elements of Interest (EoI) to be suggested for strengthening RIN.3.

An organization needs more and more to ‘pick up’ pieces from several frameworks and models in order to reinforce its own unique Business Process Model (BPM), while too often organizations search for compliance to ‘external’ models (e.g. one or more CMMI constellations) thinking such models could be the target instead of being simply suggestions for an internal improvement. But a model is and remains simply a model. Each model can have its way to look at a phenomenon but cannot capture all the potential interpretations and ‘nuances’ of a certain process/domain. Therefore the need to know more sources of information and try to summarize them in the best possible way but respecting the organization’s BPM process architecture, that is the real target to improve. The papers about LEGO applications (e.g. [8, 15, 16, 39]) can be a starting point to learn and try to replicate the approach on ‘your’ own BPM and processes. The most challenging item can be how to filter the EoI (Elements of Interest) useful for being incorporated into your own BMP (target). This is why the issue dealt with in this paper was Knowledge Management and the way organizations typically deal with that process (or not). Too often such process seems to be too implicit in many medium-large organizations and could be confused with solely training.

LEGO represents a different way to improve processes from multi-source models than done in EnterpriseSPICE [27] or FAA iCMM [28] or other approaches (e.g. [33–35]) since LEGO stresses a dynamic perspective about how to find room for improvement in your own BPM, rather than considering a meta-model.

Next steps will be about the analysis of other points of contacts between the software and the service side of ICT projects, such as the measurability issue, where the knowledge coming from the software community could bring some useful tips for reinforcing the Service Level Management (SLM) process as well as how paradigms, such as DevOps [36], can help improving better and faster software and services by a more focused collaboration and communication about stakeholders. Again, a mapping of crossed terms and the way there are differently mentioned in the respective communities (e.g. a ‘Change Request’ is on software side the same concept and working item that a ‘Request for Change’ in the service side) will be created in order to facilitate such logical merging.