Network Layouts of the IT Sector and Propensity of Emergence of Dominant Designs by de facto Standardization

5Computing technologies are based on technical and functional features linked to processes of interaction and intercommunication (von Neumann, 1948). The quantitative and qualitative expansion of computing technologies extended interacting and network layouts to shape main areas of the “hardware/software paradigm” (Katz, Shapiro, 1994). This structural tendency to emphasize network layouts was amplified in a contemporary context. In particular with the dynamic waves related to the advent of the Internet and “the new economy” that led to the digital age, where meshing organizations and network devices structured the different facets of the sector: technical, economic and industrial (Lundgren, 1995).

6With this density-raising of IT network layouts, a growing parallel interest about the economic notion of network effects developed (Shapiro, Varian, 1999). One included key effect, increasing returns (Arthur, 1996), correlates the level of adoption of a technological design in a network to its attractive power compared to rival solutions. This network auto-reinforcing dynamic is strongly associated with the emergence of dominant designs (Suaréz, Utterback, 1995) as result of de facto standardization (Katz, Shapiro, 1986; Besen, Farrell, 1994; Blind, Mangelsdorf, 2016). A dominant design characterizes a singular technological architecture and design that emerged from the competitive process to prevail in its market (Wurster et al., 2014; Suaréz, 2004; Utterback, 1996; Suaréz, Utterback, 1995). Contextually, to play a relevant role in the market, the economic actors involved have to rally to the established dominant design (Utterback, 1996). The emergence of dominant designs by de facto standardization builds on a complex combination of economic and industrial factors (Suaréz, 2004; Utterback, 1996). Related to the IT sector, these factors include the quality of technological architecture and design, the industrial reputation of the organization behind the dominant design, the costs involved (Besen, Farell, 1994), the market context (Blind, 2004), the possibility of an industrial partnership (Shapiro, Varian, 1999), the dynamics of innovation (Teece, 1986, 1997), and the potential development of complementary and interfaced components in relation to the technological interrelationship (Benezech, 1996).

Closed Dominant Designs and Industrial Blocking Risks

7According to the potential combinations of factors and mainly unpredictable micro-decisions from the market stakeholders, de facto processes don’t involve a spontaneous efficiency of dominant designs and can lead to blocking risks and limitations of innovation. Thus, when industrial players confine the intellectual property of the technological architectures of dominant designs with a strict and closed control of the related specifications, they consequently have roles of full-power leaders in the market. Thus, they can determine their evolution, in particular to maintain or reinforce their roles, for example selling one’s own computing products in a biased market for potential competitors. Such strict barriers around technological architectures and designs also restrain the possibility of a free range of innovations and external developments. Furthermore, in the highly meshed IT sector, technological interactions relative to APIs [4] have a major role in the development of complementary components and products. Indeed, APIs define sets of specifications that include protocols, routines, classes, intercommunication methods and development components. So, when APIs are included in the technological architectures of dominant designs, and when the related specifications are closed by their owners, there are potential blocking risks of technological lock-in, guaranteed income, and switching costs that lead to a restraint of the dynamics of non-biased competition. De facto standardization generated a recurrence of such closed dominant designs in the IT sector. To go beyond such closed architectures of dominant designs, organizations involved in the IT sector could benefit from a consensual production of de jure standards. Nevertheless, Simcoe (2012) analyzed that the contemporary high dynamics of evolution in the IT sector do not necessarily suit the rigidity of the main traditional SSOs as ISO [5]. Furthermore, Bekkers et al. (2011) showed the average long period of time of de jure standardization’s cycles carried out by traditional SSOs in the IT sector.

8Thus, this situation increases the potential interest about a vector of digital standardization that can overcome these potential blocking risks and structural limits. As will be shown within the case study, this is a model of digital standardization based on open and agile dynamics. To begin with, in the next part, the characteristics of an agile paradigm building on historical industrial agile movements will be shown and synthesized.

Lean Production: A Pioneer Agile Industrial Movement

11Lean Production is a pioneer industrial agile-oriented framework. It builds on methods of management used in the automobile sector by the Japanese firm Toyota under the name of Toyota Production System (TPS). The engineering development of TPS, in the second half of the 20^th century, was prior to Lean Production’s terminology and theorization that started within the MIT International Motor Vehicle Program (IMVP), in particular with the publication of the academic paper “Triumph of the Lean Production System” (Krafcik, 1988) and the book “The Machine that Changed the World: The Story of Lean Production—Toyota’s Secret Weapon in the Global Car Wars that is Now Revolutionizing World Industry” (Womack et al., 1990). The theory explains the success of Japanese production as a new economic-industrial step, overtaking the Fordist organization. Indeed, Fordism, which emerged at the beginning of the 20^th century, builds on a standardized manufacturing process around an assembly line and a high scale of production. To absorb the production, Fordism expected a correlated demand of mass consumption. In contrast, Lean Production is adaptable to market demand, in particular to avoid overproduction. For this purpose, Lean Production removes elements considered as waste, under the Japanese word Muda. In addition to overproduction, these elements concern stock, over-processing, waiting, avoidable movement and transport, misuse of collaborators (trust, autonomy and easy communication are emphasized), and manufacturing defect (Lean Production includes a systematic detection of errors). In parallel, cost reductions are prioritized. Another one of Lean Production’s great principles is Just-in-Time (JIT) production, a management method aimed at constantly meeting demand, minimizing stocks, and avoiding overproduction and waiting. An additional Lean Production’s characteristic, Heijunka, is also a demand-oriented principle, leveling volume and product. Furthermore, Lean Production emphasizes process standardization and a permanent quest for innovation under the name of Kaizen. We codified the characteristics of Lean Production in the following table:

Agile Manufacturing: Emphasizing an Adaptation to Market Demand

12Agile Manufacturing, industrially analyzed by Sheridan (1993), and Robertson and Jones (1999) as a development of Lean Production (“Agile manufacturing, a strategy developed from lean production methods, is aimed at providing companies with the capabilities to succeed in the twenty first century, serving ever more sophisticated customer demand”, Robertson, Jones, 1999) was initiated in 1991 by the Agile Manufacturing Enterprise Forum (AMEF) at Lehigh University, Pennsylvania. The model particularly suits market demand and customer wishes. Like Lean Production, a vector is related to cost reductions, but product driven. Another singularity of Agile Manufacturing concerns its modular design. Lean Production can concern a large number of collaborators. In contrast, Agile Manufacturing suits smaller organizations and manufacturers. Agile Manufacturing emphasizes the possibility of process reconfiguration. The model builds on a pertinent communication flow between stakeholders and the creation of a database of organizational knowledge. This database aims to boost business improvement and innovation. The life-cycle of products is compressed to be adapted to dynamic market demand and to minimize obsolescence effects (Shewchuck, 1998). As a corollary, the time to market is also reduced. In addition, the model emphasizes mass customization to allow the development of differentiated products with the aim of high adaptation to a multiple demand.

Agile Software Development: A Search for Agility in Software Development in Contrast with Classical Models

13The interest for an agile organization in the field of software development finds its roots in the lack of flexibility of classical models of development. Indeed, the first software development method, the waterfall model, created in the 1970s (Bell, Thayer, 1976), builds on the chronological steps of requirements, specifications, design, implementation, verification and maintenance: a step has to be completed to start the next one. Thus, this model is characterized by full linearity and rigidity. An extension of the waterfall model was launched in the 1980s with the V-model. The main innovation concerns the integration of a testing process at the end of the development steps. The next method, the spiral model, was created in 1986 with the aim of extending the V-model by implementation of successive versions of the main project or prototypes of it (Boehm, 1986). The last classical method, the iterative model, builds on successive steps of specifications, development, validation and testing, and a loop process to update the project. The cycle ends when the software is considered to be ready for delivery.

14Thus, classical waterfall-based models build on partitioned development cycles and are characterized by a lack of flexibility. In addition, the cumulative complexity of source codes tends to generate a “heaviness” to reread, maintain, support and update large development projects. It is a factor in potential functioning errors and reliability failure, frequent issues in software developed within classical methods. Because of that, significant documentation is needed with the aim of mastering the issued complexity. Furthermore, the classical development methods mainly require full consideration, or at least an advanced consideration, of the design of the final software that has to be delivered, the demand prospective has to be defined ex ante within planning that requires an anticipation of market evolution. As a consequence, it is a difficult to integrate elements that are not originally planned. Such rigid elements are not optimized to suit an appropriateness that is up-to-date in a fast-changing industry such as the contemporary IT sector.

Agility Transposed into Software Development as an Answer to the Rapid Evolution of the IT Sector

15Thus, the need for agility in the IT sector emerged in contrast to the rigid and planned organization of classical methods related to compartmentalized steps and tasks. In parallel, the evolution of digital technologies (related to networks, hardware, software, communication and programming tools) concomitant to the boom of the IT industry in the 1990s extended the possibility of the flexibility and industrial development of projects by smaller and more reactive teams of developers compared with the previous economic-industrial age of computing massive projects (Erickson et al., 2005).

Characteristics of Agile Software Development

16Agile Software Development appeared in this context, building on a flexible integration of innovation and technical change (Abrahamsson et al., 2002) to be in sync with market evolution. To unify the practices, in 2001 a group of 17 experts established a set of values and principles in the reference document “The Manifesto for Agile Software Development”. The four values of Agile Software Development can be analogically differentiated with the characteristics of classical waterfall-based software development:

17The promoted principles of Agile Software Development ensue from these four values. As for Lean Production and Agile Manufacturing, these theoretical elements to generate potential testable premises will be synthesized and codified, following Yin’s methodology (2014):

RE within the Scope of Software Engineering

18Works, theories and books of practitioners and researchers related to RE focus on the requirements in the setting-up processes for software engineering, the engineering field of software development. Definitions of the sector converge to emphasize the notion of development, implementation and the production of software. For Bauer, instigator of the terminology, the goal of the sector is: “to economically obtain software that is reliable and works efficiently on real machines” (Mahoney, 1990). For Sommerville (2015), that is the discipline “concerned with all aspects of software production”. ISO, IEC and IEEE in their common norm [6] also emphasize the notion of implementation: “the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software”. Within this definition, RE is the part of the process related to the sequence of design.

19From the economic angle, the sector is related to organizations that produce software, notably software houses, IT consulting and outsourcing companies in charge of software development for client organizations, and RE emphasizes the cooperation between the development crew of the organization that produces software and the customers of the client organization. RE’s objective is the development of a software product that suits the client organization’s expectations, co-defined by customers and developers.

20In this perspective, RE is integrated into software engineering development models. In traditional waterfall-based models, requirements are established jointly with customers and developers at the beginning of projects (Royce, 1970): client’s needs are key elements in the conception of requirements and are discussed with the development crew in relation to their feasibility within technical limits. Traditional RE attaches high importance to documentation to compile requirements information and communication between customers and developers (Bray, 2002). As we will see, a specific sector of RE focuses on an agile model. But as a preliminary we will analyze in detail the dichotomy between RE and digital standardization.

RE and Digital Standardization Singularities

21RE and digital standardization differ on several points: As we indicated, digital standardization is mainly coordinated by SSOs and involves partners that can be organizations or countries (represented by their national SSOs as within ISO) to stimulate the large cooperative co-creation of the specification of a technological architecture, design or format with a normative value and a related industrial wish for multi-implementation by several organizations. While software RE is mainly related to a contract between a software engineering development company and a client organization to develop a single software product: usually only the development company and the customers are involved to redact a closed specification without normative value: most of the time, the specification has to be implemented only once, into the software delivered to the client organization. We have drawn up the following table to detail these singularities.

Agile RE as a Part of an Agile Paradigm

22If, as we analyzed, there are singularities between RE and digital standardization, our work and case study will, however, fully take Agile RE into consideration as a part of an agile paradigm. Indeed, as there is a traditional RE field (related to waterfall-based development models) studied by practitioners of computing management, there is an Agile RE field related to Agile models. Within the Agile RE academic research, Cao and Ramesh (2008) collected data from 16 organizations using Agile models or related approaches in a large and multiple case study. Significant Agile RE characteristic practices were emphasized. First, Agile RE builds on a high level of, and continual communication between, customers and developers to adapt and update requirements, instead of an extensive documentation characteristic of traditional RE. In parallel, high interaction and trust between customers and developers are emphasized: “Customers can steer the project in unanticipated directions, especially when their requirements evolve owing to changes in the environment or their own understanding of the software solution.” Thus, Agile RE requirements are generated during the development instead of being pre-established because of the current volatility of pre-established requirements, and to improve intercommunication between customers and developers: “At the start of each cycle, the customer meets with the development team to provide detailed information on a set of features that must be implemented.” “First, it creates a more satisfactory relationship with the customer.” “Second, requirements are clearer and more understandable because of the immediate access to customers and their involvement in the project when needed.” Agile RE requirements are prioritized at each step of the development cycle instead of being emphasized once at the start of development: “Because customers are very involved in the development process, they can provide business reasons for each requirement at any development cycle. Such a clear understanding of the customer’s priorities helps the development team to better meet customer needs.”

23Agile RE is also characterized by a high possibility of requirements refinements during the development phase, building on intensive interactions between developers and customers: “Accommodating requirements changes during development is a way of tuning the system to better satisfy customer needs.” “Customers provide feedback and can request major changes if their expectations aren’t met.” To update Agile RE requirements, prototypes can be delivered to customers before the final delivered software product: “instead of incurring the overhead involved in creating formal requirements documents, several organizations use prototyping to communicate with their customers to validate and refine requirements.” A test-driven development (TDD) improves Agile RE requirements throughout software production through cooperation between customers and developers: “TDD requires a thorough understanding of the requirements and extensive collaboration between the developer and the customer, because it involves refining low-level specifications iteratively.” In addition, Agile RE builds on a frequent customers - developers’ review meeting to validate requirements: “During the meeting, the developers demonstrate the delivered features, and the customers and QA people ask questions and provide feedback.” Paetsch et al. (2003) also emphasize the role of customers to check the validity of the functionalities: “Customers can use the software, experience how the system works” and transmit their feedback to the development organization in Agile RE.

24In contrast with the planned, early established and document-driven traditional RE, Agile RE, with its continuous requirements refinement within feedback and communication from the customer organization to the development organization, allows an adapted management of uncertainty in requirements (Sillitti et al., 2005) and design for the unexpected (Valckenaers, van Brussel, 2015).

25Heikkilä et al. (2015) produced a large-scale mapping review study about Agile RE, reviewing the essential published papers (28 articles on the topic). In their conclusion, they suggest the next definition of Agile RE: “Based on the synthesis of the included articles, we propose the following definition: In Agile RE, the requirements are elicited, analyzed and specified in an ongoing and close collaboration with a customer or customer representative in order to achieve high reactivity to changes in the requirements and in the environment. Continuous requirements re-evaluation is vital for the success of the solution system, and the close collaboration with the customer or customer representative is the essential method of requirements and system validation.” Again, and as analyzed in the differentiation of RE vs. digital standardization, there is a key importance of the relationship between customers and developers in the requirements process. Beyond this differentiation, the systematic literature review on Agile RE leads one to add characteristics that can be codified into premises to expand the agile paradigm and test the premises within the case study of the next section.

Research Design and Collected Data

26Related to the academic research on standardization, scholars use case studies as a privileged method, as Simcoe (2008) indicates: “Most of the empirical evidence on the committee standard setting process is based on case studies.” That guided our choice to undertake an in-depth case study in its real environment, following Yin (2014): “Compared to other methods, the strength of the case study method is its ability to examine, in-depth, a ‘case’ within its ‘real-life’ context.”

27In addition to Yin, we set up the research design from the methodological scholar references of Eisenhardt (1989), Stake (1995), Strauss and Corbin (1997), and David (2000). Intentionally, we built on an inclusive integration of different methodological elements and approaches of these authors.

28Still in an inclusive perspective, Strauss and Corbin (1997) argue for the possibility to combine deductive, inductive and abductive principles. We synthesized and schematized these reasoning models within a case study:

Figure 1

Schema of potential reasoning types in a case study

Schema of potential reasoning types in a case study

29Because of the nature and context of this case study, we combined deductive and inductive reasoning. For the deductive side, we followed Yin (2014), who emphasizes the “prior development of theoretical propositions to guide data collection and analysis”. Yin also recommends categorizing elements as premises. As we indicated, that is why, in the previous sections, we generated categories of potential premises, building on the dynamics of an agile paradigm that includes the recognized agile management movements of Lean Production, Agile Manufacturing, Agile Software Development, and Agile Requirements Engineering. Deductive reasoning was used to test these premises. In addition, inductive reasoning led to our systematic analysis of collected data that highlighted singular agile practices within the case, triangulated by several of our data sources as we detailed in the final findings board.

30We analyzed a combination of primary and secondary data, and qualitative and quantitative elements, still following the perspective of Yin (2014): “regardless of whether one favors qualitative or quantitative research, there is a strong and essential common ground between the two”, where both can be used to improve lines of evidence and proceed to triangulation.

31Primary data include 11 open-ended interviews of platforms’ stakeholders within the consortium. Interviews were carried out by email in relation to the international character of the study. Secondary data builds on the full and high quantity of current and archived elements of the consortium’s processes related to each of the 16 platforms of the sample. Each platform covers a singular specification. Secondary data accumulate internal files and documents about the operative procedures, including cooperation and exchanges between stakeholders, involved industrial organizations, and IT business specialized press. Furthermore, in relation to the technical committees of the platforms, we conducted a systematic analysis of the published reports, issue lists and internal comments. In addition, we made a full study of the technical documents and mailing archives of the assembly technical committees.

32The findings board shows the obtained results and answers to the case study’s research question in a detailed way. This research question previously mentioned in the introduction is, overcoming the limits of traditional standardization, how can agile dynamics be a driver in the co-production of digital standards?

33The findings board indicates how these were done specifically. When several methods are indicated (Secondary data, Primary data: Interviews, Questionnaire, Deduction, Induction) there was systematically a triangulation between these lines of evidence. In parallel, we proceeded to internal triangulations, such as cross checking of secondary data.

34In addition to the definition of the general unit of analysis (the consortium), Yin (2014) recommends defining the potential sub-units of analysis. The case study includes a large sample of 16 sub-units as standardization platforms of singular digital standards within the consortium. Following Yin’s terminology, this corresponds to an embedded case study. The study of the 16 platforms, in particular associated to a questionnaire to stakeholders of these platforms, allowed us to make an extra triangulation because of the singularities of each of these platforms.

35The questionnaire gives us data on the next items.

36The questionnaire was sent to 184 collaborators of the different platforms with 38 answers. We did not need to use a leveling extra statistical method because of the high correlation of the answers. These results confirmed the prior analysis of the other sources of data in relation to these items. The combination of these multiple sources of data and the cohesion of the results dismissed bias from the respondents to the questionnaire part, in addition to the non-profit and neutral character of the consortium. The scores of the different items of the questionnaire appear in the findings board.

Case Study Development and Findings

37As mentioned in the introduction, OASIS is a non-profit international consortium [7] that coordinates the co-production of open digital standards. Any organization involved in the related IT sector can join: corporate, institutional, academic, private, public, profit or non-profit actor. The rules exclude any corporate discrimination or market bias.

38A large number of the organizations involved in the IT sector are members of the consortium, including computing-centered firms such as IBM, Microsoft, Google and Intel, firms in other sectors using digital infrastructures such as Boeing and Bank of America, universities including the MIT, governmental bodies such as the European Parliament and the California Office of Legislative Counsel. The covered specifications are regularly extended to suit the evolution of the IT industry. The initial field was related to digital formats based on XML [8], as OpenDocument Format for office suites [9]. The consortium includes two complementary elected colleges: technical (technical advisory board) and executive (board of directors). Each platform related to a singular specification has its own technical committee.

39Internal processes are fully transparent. Because the involved technologies aim to establish industrial standards, this transparency favors industrial trust. Furthermore, it contrasts with major traditional standards bodies, where internal elements are closed to non-members. The benefit related to the open character of the consortium was emphasized in an interview section.

40

Itw: “It is very open, all documents and meeting minutes are available for all to see. This is a contrast with some other organizations, where the activities are only visible to the people participating in the standards process. ISO/IEC is an example of a very ‘closed’ organization.”

41The non-profit character of the consortium emphasizes low fees for membership. Annual fees are gradual with maximum fees of 54 000 US dollars in 2018 for foundational sponsor companies employing more than 500 people. Some members particularly benefit from the opportunity of low fees including non-profit and open source organizations, such as the Linux distribution Debian and TheDocumentFoundation that develops LibreOffice, the most used open source office suite. Consequently, any category of organizations is encouraged to bring its own contribution to improve digital standards.

42

Itw: “The easy involvement of industry players and of other players (academics, open source participants) makes OASIS attractive and does help with take-up. Other standards venues have restricted access or substantial fees to participate.”

43In the direction in favor of open source, the consortium promotes open source implementations of its standards.

44

Itw: “For any standard that deals with APIs, protocols and data structures, it is important for the development of the standard to have a parallel open source project which has implementations of the APIs, protocols and data structures, and ideally test suites that can validate any future implementation of the standard. The openness of OASIS makes it easy for the open source project to follow the development of the standard and easy for the open source project to give feedback to the standard.”

45Like Agile Software Development, the consortium combines elements of coordination and self-organization. Issued characteristics are notably related to a high interaction between members, a large use of distant cooperative tools, a continuous evolution of projects, short feedback, an adaptability to new technical and market contexts, a search for the availability of testable implementations, and an instant publication of issued elements to show the evolution of work in progress.

46Concerning the elements of self-organization, interviews emphasized opportunities for full-time social networking and distant contacts between members as a very flexible way to co-produce specifications beyond the usual boundaries, unlike traditional standards bodies that have mainly formal protocols, more “rigidity”, such as more early pre-scheduled meetings.

47

Itw: “The ability to have issue lists (useful tools) and have people bring forward proposals that address specific issues is good. By contrast, cooperation in say ISO/IEC is less easy, it is more formal, slower and does not encourage consensus and problem solving. The existence of open email lists is good in OASIS, and it is possible to create additional email lists for specific topics. Such facilities are not available in all other standards bodies. So OASIS allows for open communication and debate. Indeed most of the SCA [10] work was done by email and by conference calls with relatively few face-to-face meetings. I note that this is not the case in other standards bodies where the travel implies costs in time and money that can discourage people from taking part.”

48Within OASIS, all decisions, works, communications are electronically recorded in a Just-in-Time way and digital tracks are archived. Thus, it is possible to have access to all chronological events from the start to the end of a cycle of co-production. Automatic digital tools and less formalism than in classical development methods allow one not to have to devote human resources to archival activity such as Agile Software Development and Agile Manufacturing platforms, which can potentially build on a reduced number of collaborators. Furthermore, the possibility offered for each platform to develop testable implementation early in the process allows for stakeholders to have recurrent feedback, experimental gain, to benefit from learning by doing, and to induce incremental and continuous improvement. Such beta-tests generate continuous adjustment and adaptation.

49The findings board of the case study shows the complete and final classification of the results, following the methodology recommended by Eisenhardt (1989) and Yin (2014). Within the prior theoretical background of Sections 3 and 4, we coded the characteristics of the combination of Lean Production, Agile Manufacturing, Agile Software Development, and Agile Requirements Engineering. Because of the gap in application fields, some of these characteristics are inoperative within the sector of digital standardization: [PROD_LEVEL] (Leveling volume and production), [DISTINCT] (Distinction human/machines), [WASTEFUL_WARN] (Wasteful warning), [COST_REDU] (Cost reductions) of Lean Production, [MODULAR] (Modular design), [CUSTOM] (High potential of customization of the production), [SH_CYCLES] (Short life-cycles), [SH_TTMARK] (Short time to market) of Agile Manufacturing, and [SUST_DEV] (Sustainable development) of Agile Software Development. As we mentioned, the other coded characteristics set up premises that are testable within the case study according to deductive reasoning (Yin, 2014). The findings board also shows the dynamics found by inductive reasoning related to the systematic field study. Triangulations are notified by the presence of several lines of evidence under an item.