About Variability, Variety And Complexity

1 About Variability, Variety And Complexity

The text below has been reproduced from VARIES deliverable [D3.3] (Biot, et al., 2014), section 2.1, and has been adapted for public dissemination.

When describing the creation and management of product variants, often the terms variability, variety and complexity appear. These terms have partially overlapping meanings (Figure 1‑1).

Variability, Variety and Complexity

Figure 1‑1. Variability, Variety and Complexity

When we use these terms in a specific discipline (hardware, software or supply chain), one must realize that each of the terms (e.g. variability) may convey different meanings across these disciplines (Figure 1‑2). For this reason, this section starts with a definition of these 3 terms from the following perspectives:

  1. The Supply Chain Perspective (1.1)
  2. The Software Perspective (1.2)
  3. The Hardware Perspective (1.3)
  4. The Market Perspective (1.4)
Several Perspectives to Variability

Figure 1‑2. Several Perspectives to Variability

1.1 The Supply Chain Perspective

A supply chain consist of all parties and activities involved, directly or indirectly, in fulfilling a customer request. This means that not only the manufacturer and supplier are included, but also the transporters, warehouses, retailers and even the customers themselves

1.1.1 Variability

Supply chain management defines variability as a type of uncertainty in the market that cannot be solved through data analysis and is defined as the fact of something being likely to vary or change (Oxford Dictionary). Uncertainty is something that is not known with certainty in a company, e.g. the average demand for different product types. Variability is often caused by variable demand and supply, e.g. uncertainty in timing of customer orders and the number of machine breakdowns. In supply chain and operations language, this could for example be changes in demand (called demand variability) or changes in lead times (called time variability). A first solution is to try to reduce variability by for example introducing fixed times at which customers can order. Another solution is to introduce buffers, which can be in the form of inventory (safety stock), capacity (excess capacity) and time (safety time) (Beliën, De Boeck, & Colpaert, 2012). Five other types of variability are: arrival variability, request variability, capability variability, effort variability and subjective preference variability (Frei, 2006).

1.1.2 Variety

In supply chain management, variety, also called variance, can be generally defined as the number or range of things (products, components…) that differ in some way (character, quality, features…). The more different products offered and components used, the higher respectively the product and component variety. The Oxford Dictionary defines variety as the absence of uniformity or monotony (Oxford Dictionary), whereas Randall and Ulrich define product variety from a product perspective as the number of different versions of a product offered by a firm at a single point in time (Randall & Ulrich, 2001).

Variety, in the sense of different products, components… is in most cases an intra-company decision instead of an uncertainty. This does not mean that this decision is always taken consciously or that the company is aware of the internal and external drivers of this variety.

When using variety to refer to product variety, the concept of variants is also used. Variants with similar features are part of the same product family and all product variants together form the product portfolio.

1.1.3 Link Between Variability And Variety

In supply chain management, variety and variability are not independent of each other. The more variety in a company, the more vulnerable the company is for the effects of variability.

Product variety can cause what is called functional or goods variability. Introducing variety typically increases process variability and product lead times. However, this increase in cost might be offset by the increase in revenue thanks to more types of products offered to the market (Beliën, De Boeck, & Colpaert, 2012).

The level of uncertainty associated with a certain level of variability can differ depending on how predictable that variability is. For example, peaks in demand can be semi-predicted when the product is seasonal. Therefore the concept of uncertainty is sometimes referred to as predictable variability, which means extra information can help the company in handling the changes. Higher variety can increase demand variability and forecast errors, increasing excess inventories and shortages, buffer capacity, and workforce fluctuations.

1.2 The Software Perspective

1.2.1 Software: A Definition

Computer software, or simply software, also known as computer programs, is the non-tangible component of computers. Computer software contrasts with computer hardware, which is the physical component of computers. Computer hardware and software require each other and neither can be realistically used without the other.

Software consists of clearly-defined instructions that upon execution, instructs hardware to perform the tasks for which it is designed.

At the lowest level, executable code consists of machine language instructions specific to an individual processor – typically a central processing unit (CPU). A machine language consists of groups of binary values signifying processor instructions that change the state of the computer from its preceding state. For example, an instruction may change the value stored in a particular storage location inside the computer – an effect that is not directly observable to the user. An instruction may also (indirectly) cause something to appear on a display of the computer system – a state change which should be visible to the user. The processor carries out the instructions in the order they are provided, unless it is instructed to “jump” to a different instruction, or interrupted.

Software is usually written in high-level programming languages that are easier and more efficient for humans to use (closer to natural language) than machine language. High-level languages are compiled or interpreted into machine language object code. Software may also be written in a low-level assembly language, essentially, a vaguely mnemonic representation of a machine language using a natural language alphabet. Assembly language is converted into object code via an assembler.

1.2.2 Firmware: A Definition

In electronic systems and computing, firmware is the combination of persistent memory and program code and data stored in it.

Typical examples of devices containing firmware are embedded systems (such as traffic lights, consumer appliances, and digital watches), computers, computer peripherals, mobile phones, and digital cameras. The firmware contained in these devices provides the control program for the device. Firmware is held in non-volatile memory devices such as ROM, EPROM, or flash memory. Changing the firmware of a device may rarely or never be done during its economic lifetime; some firmware memory devices are permanently installed and cannot be changed after manufacture.

In industry, firmware often refers to the basic software layer written right above the processor, DSP, ASIC, FPGA or microcontroller, to expose its functionality to higher level software and to other digital and analogue electronic components. A synonym regularly seen in this context is a “firmware driver” which is part of a Board Support Package. Firmware is often written in low-level, chip specific assembly language.

1.2.3 Variability In Software Engineering

Within the software engineering world, the ability of creating variants is referred to as variability. Many publications on the topic exist, however it appears that a generic definition is only rarely given (most publications define variability rather implicitly). Some examples:

  • Within the well-known FODA (Feature-oriented domain analysis) variability modelling technique, variability is mentioned and refers to different uses of a certain feature (Kang, Cohen, Hess, Novak, & Spencer Peterson, 1990). Although FODA attempts to document variation in a software product, no explicit definition of variability is given.
  • Van Gurp and Bosch define Software variability as the ability of a software system or artefact to be changed, customized or configured for use in a particular context (van Gurp & Bosch, 2003).
  • The technical report of Bachmann and Clements defines variability as the ability of a system, an asset, or a development environment to support the production of a set of artefacts that differ from each other in a pre-planned fashion (Bachmann & Clements, 2005).
  • In (Pohl, Böckle, & van der Linden, 2005), Part II is devoted to explaining variability for software product lines. From the description it is clear that variability refers to the creation of product variants in a predefined way (the product line).
  • (Codenie, et al., 2009) defines product variability as the ability to offer a large number of product variants to customers.

1.2.4 Complexity

Complexity in software can refer to several things:

Programming complexity (or software complexity) is a term that encompasses numerous properties of a piece of software, all of which affect internal interactions. A distinction is to be made between the terms complex and complicated:

  • Complicated implies being difficult to understand but with time and effort, ultimately knowable.
  • Complex, on the other hand, describes the interactions between a number of entities.

As the number of entities increases, the number of interactions between them would increase exponentially, and it would get to a point where it would be impossible to know and understand all of them. Similarly, higher levels of complexity in software increase the risk of unintentionally interfering with interactions and so increases the chance of introducing defects when making changes. In more extreme cases, it can make modifying the software virtually impossible.

The idea of linking software complexity to the maintainability of the software has been explored extensively by Professor Manny Lehman, who developed his Laws of Software Evolution from his research. Together with his co-author Les Belady he explored numerous possible software metrics in their oft cited book (Lehmam & Belady, 1985), that could be used to measure the state of the software, eventually reaching the conclusion that the only practical solution would be to use one that uses deterministic complexity models.

1.3 The Hardware Perspective

1.3.1 Hardware: A Definition

In general, the term hardware refers to any physical, tangible part of a product. Examples relevant to embedded systems are mechanics, mechatronics, analogue and digital electronics, PCB assembly and their discrete components, electric wiring.

Depending on the context and history of a company, different own interpretations are given to the term hardware. Some companies don’t explicitly distinguish between aforementioned technologies, while other have a need for a more specialized taxonomy.

In some organizations, firmware is also considered as hardware. This can be explained by the fact that the first firmware was written by electronics engineers, part of the hardware development team.

1.3.2 Variants

A physical, existing product is represented by a product variant. Any product is in fact an instance of a product variant (Veen, 1992).

From a hardware perspective the concept of variants is widely used in CAD (Computer Aided Design) and PDM (Product Data Management) environments in relationship with product-options or features a customer can choose. The core of the product structure consists of the product components (items) and their interfaces (relationships). The assembly can exist of subassemblies and parts. In the context of VARIES, the following differentiation and variation concepts can be considered as product variants:

  • Alternatives: an alternative of an item is considered as a substitute for that particular item
  • Variants: a variant is another option of an item which the consumer can choose
  • Revisions: a revision indicates the change history of the item

A configurable product represents a set of different but closely related product variants. All variants of a configurable product can also be called a product family. All possible variants of a configurable product are described with a configuration model or a generic product. (Peltonen, 2000). The total of these variants is referred to as (product) variety.

1.3.3 Variety

Variety refers to the range of products the firm can produce within a particular time period in response to market demand. (Ulrich & Eppinger, 2007)

1.3.4 Complexity

Publications use numerous definitions of the term complexity. A comprehensive overview over theories and interpretations of complexity is given by (Meyer, 2007) and (Kirchhof & Specht, 2003). (Wu & Frizelle, 2007) give an overview of production engineering complexity theories.

In systems theory, complexity is defined as by the number of elements, their relations and their transformation over time. Elements consist of software, hardware, mechanics, … . Static or structural complexity arises from the system structure, whereas the dynamic or operative complexity addresses the system behaviour over time. In the context of the automotive industry, product variety is the main driver of complexity (Schuh & Schwenck, 2005).

1.3.5 Variability

In product development, the term variability is mostly used to indicate the variation in the product development process or the rate of change of requirements (Reinertsen, 2009).

1.3.6 Product Family

IEC OD 2041 defines a product family as the maximum configuration, a list of components/sub-assemblies plus a description of how the products are constructed from the maximum configuration and list (IEC/IECEE, 2007). All products which are included in the family typically have common design, construction, parts, or assemblies essential to ensure conformity with applicable requirements.

1.4 The Market Perspective

Variety at the “technical” product level does not necessarily match one-to-one with variety as presented on the market. The following basic strategies can be identified (see Figure 1‑3):

  1. Market variety reflects technical varietyIn this scenario, there is a one-to-one match between “technical” products and their identity on the market.
  2. Same product seen on the market as differentA given “technical” product variant can be sold under different names in different markets or market segments. This practice is very popular in retail stores where one company produces identical products for other, often competing, retailers under their own private label. These products often have a different packaging of product label that is applied by the B2B customer.
  3. Different products seen on the market as the sameMoreover companies can decide to hide different “technical” product variants to the market and preserve the same product identification (name, product label…). This often happens to hide technical modifications to the product which don’t substantially alter the product features. E.g., different firmware versions of an embedded platform can be hidden to the market, and may possibly only be identified by analysing the serial number.
Basic product-market variety strategies

Figure 1‑3. Basic product-market variety strategies

Companies will choose from these strategies depending on their context, market insight and needs. Sometimes a mix of these strategies is applied.

Where relevant, the distinction between technical and market variety must be clearly stated to avoid confusion.

2 The VARIES Definitions

Since the VARIES project approaches several perspectives, there was a need to disambiguate the terminology used within the VARIES results. This need has been addressed by an internal workgroup created during the September 2013 plenary meeting: the Terminology Task Force.

This Task Force started from a list of potentially confusing terminology used within the VARIES consortium and concept proposals collected during a workshop.

As baseline and main reference the ISO/IEC 26550:2013 standard was used ISO/IEC, 2013. Further input was gathered from literature and the ARTEMIS CESAR project (ARTEMIS CESAR consortium).

2.1 Variability

In the software and electronics worlds, the word ‘variability’ is used to refer to the ability for a product or parts thereof to be changed (1.2). In the supply chain world, a similar concept exists, variety, however it rather conveys the meaning of diversity in the portfolio (1.1.2) and not the ability to create this diversity. Articles and conferences in the software and electronics business mostly use variability to refer to the creation and management of variety as defined above.

It can also be observed that variability refers to two facets: the end products (product variability) and the means to create these end products (e.g. a product line, processes, development environments).

From the online dictionaries and Wikipedia it appears that variability generally means statistical variance. Variability as we use it in VARIES and in engineering is not found with that meaning in those dictionaries (including Wikipedia).

Based on the aforementioned definitions of variability, we propose the following definition of variability in the context of the VARIES project, encompassing both facets:

Variability is:
  • the ability of a product to be adapted to serve a certain purpose.

According to this definition, variants are a direct result of variability.

2.2 Variety

Variety is associated with the total amount of variants of a product. When this number becomes large it is often referred to as complexity.

Variety is:
  • the set of variants that exists at a certain point in time.

2.3 Product

A product is:
  • a physical item or service where all variability has been resolved within its product line.
  • anything that can be offered to a market that might satisfy a want or need.

Once delivered by the product line, a product instance may still be configured, or features and characteristics modified afterwards. This does not breach the proposed definition.

In practice, a product either refers to a product instance, a product line or the collection of all identical product instances of a particular product or variant.

When referring to the class of products that share exactly the same characteristics,

2.4 Variant

A variant is:
  • a version (a particular form or state) of a product that differs in some respect from other versions or from a standard.

The term “Variant” should not be used stand-alone. It should always be classified, like “Product variant”: a product having most features in common with another product, but with some different features.

Not every new product variant is visible to the market. Often the market only sees a limited number of product variants although under the hood many differences are to be found. For instance, changes that do not disrupt the functionality previously available are often concealed to the customer (market) to avoid confusion.

Based on the variability definition:

  • A variant is the result of adapting a product to serve a certain purpose.
  • A variant can have a multitude of instances.
  • A variant is part of a class of products that share exactly the same characteristics.

2.5 Product Instance

A product instance is:
  • a realization (instantiation) of a product.

Product instances are the end product of a product line.

Identical product instances are members (instances) of a class of products that share exactly the same characteristics. Typical for product instances is that they have the same product number but different serial numbers.

2.6 Product Line

A product line is:
  • a set of products that share a common, managed set of features satisfying the needs of one or more particular market segments.

Product line is a synonym for Product family where Product line is preferred.

As such, products are to be seen as segments in the product line.

2.7 Portfolio

A portfolio is:
  • a collection of elements (Products, Projects, Product lines, …)

The term portfolio should not be used stand-alone. It should always contain a qualifier like Product Portfolio, Project Portfolio, Product Line Portfolio, …

3 References

  1. ARTEMIS CESAR consortium. (n.d.). ARTEMIS CESAR project. ARTEMIS-JU. Retrieved from http://www.cesarproject.eu/
  2. Bachmann, F., & Clements, P. (2005). Variability in Software Product Lines. Tech. rep., CMU/SEI, http://www.sei.cmu.edu/library/abstracts/reports/05tr012.cfm.
  3. Beliën, J., De Boeck, L., & Colpaert, J. (2012). Managing Variability in Manufacturing and Services. Review of Business and Economic Literature, 57(03), 302-316.
  4. Biot, O., Hirvonen, H., Bollen, M., González-Deleito, N., Drissen, T., Codenie, W., . . . Vierimaa, M. (2014). VARIES Deliverable D3.3: Variability drivers.
  5. Codenie, W., González-Deleito, N., Deleu, J., Blagojevic, V., Kuvaja, P., & Similä, J. (2009). Managing Flexibility and Variability: a Road to Competitive Advantage (Vols. Chapter 12, Taylor and Francis, December 2009). (K. C. Kang, S. Vijayan, & P. Sooyong, Eds.) Taylor and Francis.
  6. Frei, F. (2006). Breaking the trade-off: Between Efficiency and Service. Harvard Business Review, November, 11.
  7. IEC/IECEE. (2007). Guide on Product Families, Family Ranges or Series of Products. Guide on Product Families, Family Ranges or Series of Products. Available from http://www.iecee.org/Operational_documents/iecee_documents/od-2041_ed.1.0.pdf.
  8. ISO/IEC. (2013, 9 1). ISO/IEC26550:2013: “Software and systems engineering — Reference model for product line engineering and management. ISO/IEC26550:2013. ISO/IEC. Retrieved from http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43075
  9. Kang, K., Cohen, S., Hess, J., Novak, W., & Spencer Peterson, A. (1990). Feature-Oriented Domain Analysis (FODA), Feasibility Study. Tech. rep., CMU/SEI, http://www.sei.cmu.edu/reports/90tr021.pdf.
  10. Kirchhof, R., & Specht, D. (2003). Ganzheitliches Komplexitätsmanagement. Grundlagen und Methodik des Umgangs mit Komplexität im Unternehmen.(1st ed.) (1st ed.). Wiesbaden: Deutscher Universitätsverlag.
  11. Lehmam, M. M., & Belady, L. A. (1985). Program Evolution – Processes of Software Change. Academic Press Professional, Inc. San Diego, CA, USA.
  12. Meyer, C. (2007). Integration des Komplexitätsmanagements in den strategischen Führungsprozess der Logistik (1st ed.). Bern: Haupt Verlag AG.
  13. Peltonen, H. (2000). Acta Polytechnica Scandinavica: Mathematics and computing series 105 (1st ed.). The Finnish Academy of Technology.
  14. Pohl, K., Böckle, G., & van der Linden, F. J. (2005). Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag.
  15. Randall, & Ulrich. (2001). Product Variety, Supply Chain Structure, and Firm Performance: Analysis of the U.S. Bicycle Industry. Management Science.
  16. Reinertsen, D. G. (2009). The Principles of Product Development Flow (1st ed.). Redondo Beach, CA: Celeritas Publishing.
  17. Schuh, G., & Schwenck, U. (2005). Produktkomplexität managen. Strategien – Methoden – Tools. (2nd ed.). München: Carl Hanser Verlag GmbH & Co. KG.
  18. Ulrich, K., & Eppinger, S. (2007). Product Design and Development (4th ed.). McGraw-Hill/Irwin.
  19. van Gurp, J., & Bosch, J. (2003). Preface of Proceedings of the 1st Workshop on Software Variability Management. Proceedings of the 1st Workshop on Software Variability Management, Software Variability Management, Groningen, the Netherlands February 13-14, 2003.
  20. Veen, E. v. (1992, January). Modelling Product Structures by Generic Bills of Material. Manufacturing Research and Technology, 13, 215.
  21. Wu, Y., & Frizelle, G. (2007). A study on the cost of operational complexity in customer-supplier systems. International Journal of Production Economics, 106, 218.