PaperlayerView exact revision on arXiv

Source-linked AI summary

Collaboration Challenges in Building ML-Enabled Systems: Communication, Documentation, Engineering, and Process

Nadia Nahar, Shurui Zhou, Grace Lewis, Christian Kästner

arXiv:2110.10234v4cs.SEcs.LG

TL;DR

This paper examines collaboration challenges in building ML-enabled systems, focusing on requirements, training data, and product-model integration. Based on interviews with 45 practitioners, it identifies recurring organizational patterns and challenges and offers recommendations for improving collaboration practices.

  • Problem

    Moving ML systems from prototypes to production requires additional expertise and creates collaboration challenges beyond those of traditional software projects.

  • Method

    The authors interviewed 45 practitioners from 28 organizations and triangulated the findings with a literature review.

  • Results

    Three central collaboration points emerged: requirements and project planning, training data, and product-model integration.

  • Takeaways & Limitations

    Organizations should deliberate more deliberately about structures and practices at key collaboration points and develop integrated process life cycles for ML-enabled systems.

  • Takeaways & Limitations

    Generalizations beyond the sampled participant distribution should be made with care because the study included few managers, no dedicated data experts, and no clients.

Abstract

from arXiv · show

The introduction of machine learning (ML) components in software projects has created the need for software engineers to collaborate with data scientists and other specialists. While collaboration can always be challenging, ML introduces additional challenges with its exploratory model development process, additional skills and knowledge needed, difficulties testing ML systems, need for continuous evolution and monitoring, and non-traditional quality requirements such as fairness and explainability. Through interviews with 45 practitioners from 28 organizations, we identified key collaboration challenges that teams face when building and deploying ML systems into production. We report on common collaboration points in the development of production ML systems for requirements, data, and integration, as well as corresponding team patterns and challenges. We find that most of these challenges center around communication, documentation, engineering, and process and collect recommendations to address these challenges.

1 INTRODUCTION

ML-enabled systems add collaboration demands beyond traditional software development, yet systematic understanding of how data scientists and software engineers coordinate remains limited. This study examines those challenges across production-oriented organizations and identifies requirements, data, and integration as central collaboration points.

  • Motivation: ML development adds expertise and collaboration demands to already complex software projects, making the transition from prototypes to production difficult.The introduction of ML also brings exploratory development, testing, monitoring, and non-traditional quality requirements.
  • Research gap: Prior research emphasizes technical ML concerns, while human factors such as coordinating data science and software engineering work have received less attention.The paper also notes that prior work often focuses on models rather than complete products containing ML and non-ML components.
  • Approach: The study investigates collaboration challenges through interviews with 45 practitioners from 28 organizations developing ML-enabled systems for production use.Participants included data scientists, software engineers, and managers from startups through large technology companies.
  • Findings: Three collaboration points are especially challenging: identifying and decomposing requirements, negotiating training-data quality and quantity, and integrating data science with software engineering.Organizational structure, team composition, power dynamics, and responsibilities vary substantially, with recurring patterns at specific collaboration points.
  • Recommendations: The paper organizes its recommendations around interdisciplinary teamwork, documented responsibilities and interfaces, engineering contributions, and process planning.These themes address communication, documentation, engineering, and process challenges identified across the study.
  • Contributions: The paper contributes identified collaboration points and challenges, organizational patterns, and recommendations for improving collaboration practices.It combines practitioner interviews with a literature review to develop these contributions.

3 RESEARCH DESIGN

The study uses a qualitative, interview-centered design to explore collaboration points and challenges in production ML-enabled systems. Interviews were analyzed through organizational mappings, literature triangulation, and participant validation, with qualitative generalization limits acknowledged.

  • Research strategy: The researchers adopted a qualitative strategy because research on collaboration in ML-enabled systems is limited.The design comprised interview preparation, interviews, literature triangulation, and validation with interview participants.
  • Research strategy: The interview guide was scoped through an opportunistic review of 15 papers on collaboration problems involving different skills or educational backgrounds.The literature review informed the topics addressed during interviews.
  • Interviews: 45 participants from 28 organizations completed 30- to 60-minute semi-structured interviews about professional ML projects already deployed or planned for production.The sample covered projects using ML rather than pure analytics or early prototypes.
  • Sampling: Purposeful maximum-variation sampling sought diversity in participant roles, company types, and countries, with recruitment adapted until saturation.Researchers also sought multiple perspectives within organizations where possible.
  • Analysis: Interview analysis mapped reported challenges onto visualizations of organizational structures and responsibilities to examine associations with organizational forms.The visualizations represented teams, responsibilities, and collaboration points; two examples appear in Figure 1.
  • Validation: Findings were triangulated with literature and checked by returning a summary and full draft to interviewees for feedback on correctness, fit, and applicability.The validation process invited participants to identify agreement, disagreement, and insights from others’ experiences.
  • Validity: Generalization is constrained by the sample, including few managers, no dedicated data experts or clients, one-sided organizational perspectives, and underrepresented domains and regions.The authors also acknowledge self-selection and possible researcher-introduced coding and memoing biases.

4 DIVERSITY OF ORG. STRUCTURES

Organizations differ widely in team structures, responsibilities, and collaboration forms, but recurring patterns emerge around requirements and product-model coordination. These patterns shape how teams negotiate capabilities, constraints, and integration responsibilities.

  • Organizational diversity: Teams vary widely in composition, responsibilities, power dynamics, and collaboration form, with members responsible for models, pipelines, data, inference, or the final product.A single team may hold multiple responsibilities and interfaces with other teams at several collaboration points.
  • Organizational diversity: Organization 3 uses one 8-person team that develops the model first, distributes software and data-science work internally, and gives groups roughly equal negotiation power.The team builds a product around an initially trained model.
  • Organizational diversity: Organization 7 separates product and model teams across company boundaries, with the model team deploying an inference API and the product team controlling negotiations.The product team provides confidential training data and revises model requirements with the external model team.
  • Organizational diversity: No clear global organizational pattern emerged, although recurring patterns appeared when the analysis focused on specific collaboration aspects.This motivates examining collaboration points rather than treating organizational structure as uniform.
  • Development trajectories: 13 of 28 organizations followed a model-first trajectory, 13 followed a product-first trajectory, and 2 worked on models and products in parallel.Model-first projects shaped product requirements around model capabilities, whereas product-first projects derived model requirements from existing product needs.
  • Requirements: Product and model requirements remain in tension because product requirements govern the whole system while model requirements specify goals such as accuracy, latency, domain, and available data.Requirements frequently focus on accuracy, while latency, scalability, model size, fairness, and explainability are less often specified.
  • Requirements: Product requirements often require model-team input, because product teams may otherwise miss needed data or commit to unrealistic capabilities.Model teams can also overlook product concerns such as usability when requirements elicitation is left primarily to them.
  • Requirements: Model teams commonly receive sparse or unclear requirements and must understand the broader product context to determine intended domains and in-scope data.Requirements given to model teams primarily concern accuracy, with data security and privacy also common.

6 COLLABORATION POINT: TRAINING DATA

Training-data collaboration is difficult because teams often lack influence, shared understanding, stable documentation, and access to domain expertise. These problems can produce inadequate or unrepresentative data and require explicit contracts, validation, and monitoring.

  • Organizational patterns: Data access and negotiation depend on organizational arrangements, with product-provided, public, external, and internal sources giving model teams different levels of influence.Internal access is often constrained by priorities, politics, permissions, and security.
  • Challenges: Training-data disagreements were the most common collaboration challenge, with data scientists frequently dissatisfied with the quality and quantity they received.This pattern appeared in almost every project interviewed.
  • Data quality: Provided and public data are often inadequate, requiring substantial cleaning and creating training-serving skew when training data differs from production data.The skew is linked to inadequate training data and insufficient information about production data.
  • Data understanding: Poor documentation and limited communication make data understanding and domain-expert access bottlenecks, while continuously changing sources can invalidate undocumented assumptions.Changes may involve schemas, distributions, or semantics and can occur without announcement.
  • Documentation: Teams often communicate data expectations verbally, leaving data collectors without sufficient project context and model teams without clear quality or quantity requirements.Formal contracts are especially useful when teams have distant relationships or limited negotiation power.
  • Recommendations: Planning should budget for data collection and domain expertise, formalize expectations where needed, and add automated validation and monitoring as data evolves.Suggested checks include detecting schema violations and distribution shifts.

7 COLLABORATION POINT: PRODUCT-MODEL INTEGRATION

Product-model integration is challenging because teams differ in responsibilities, capabilities, terminology, development practices, and quality-assurance processes. The paper recommends clearer boundaries, documented interfaces, engineering support, and planned monitoring across teams.

  • Integration challenges: Integrating ML and non-ML components produces conflicts when processes, responsibilities, practices, and expectations are unclear.Deployment often requires reproducible pipelines, API design, and cloud infrastructure.
  • Responsibility patterns: 18 out of 28 organizations assigned model development and deployment to the model team, making substantial engineering capability part of that team’s role.Other organizations used dedicated deployment teams or separated research and engineering responsibilities.
  • Capability mismatches: Responsibility assignments often mismatch team capabilities and preferences, leaving data scientists with unwanted infrastructure work or software engineers without sufficient model and domain understanding.Both arrangements create integration difficulties when support or context is missing.
  • Communication: Siloed data science work and differing technical terminology create weak requirements, ambiguity, misunderstandings, and inconsistent assumptions during integration.Terms such as performance can mean prediction accuracy to data scientists and response time to software engineers.
  • Engineering practices: Differences in code quality, documentation, and versioning expectations generate conflicts during integration and deployment.These disagreements reflect different development practices across data science and software engineering.
  • Recommendations: Better teams define responsibilities and boundaries carefully, document APIs, recruit deployment support, and foster mutual understanding across disciplines.Established processes are more common in big technology organizations than in smaller organizations and startups.
  • Quality assurance: Limited evaluation transparency reduces other teams’ confidence, while product and operations teams may lack the data-science knowledge needed to provide meaningful feedback.Explicit planning and coordination are needed to identify quality measures and build monitoring infrastructure.
  • Quality assurance: Only 11 out of 28 organizations collected any telemetry, and responsibilities for online evaluation were often not assigned upfront.Most organizations did not perform monitoring or online testing, while retraining decisions were often manual or intuitive.

8 DISCUSSION AND CONCLUSIONS

The discussion identifies three central collaboration points in production ML systems and highlights four broader areas needing attention: communication, documentation, engineering, and process.

  • Requirements and project planning, training data, and product-model integration are the three central collaboration points with substantial challenges.
  • Organizations vary in structure and practice, but many do not deliberately consider available choices or their tradeoffs.
  • Communication: Communication problems reflect differing backgrounds, motivating ML literacy for software engineers and managers and software-engineering awareness for data scientists.
  • Documentation: Teams should document model requirements, data expectations, and assured model qualities in forms understandable across disciplines.
  • Engineering: Organizations often underestimate the engineering needed to operate and maintain ML products, including data checks, deployment automation, and production testing.
  • Process: ML's science-like development process challenges traditional software life cycles, making integrated process models and early data-science involvement important considerations.

SUPPLEMENT A: INTERVIEW PARTICIPANTS

The supplement presents the interview sample through company-location, participant-role, and company-type distributions, plus detailed participant, company, and product information.

  • The supplement includes a table and figure describing the distribution of company locations.
  • It includes a table and figure describing the distribution of participant roles.
  • It includes a table and figure describing the distribution of company types.
  • Table 5 provides details about interviewed participants, companies, and products.
  • The interview protocol addressed study purpose, confidentiality, aggregation of findings, recording, transcription, and destruction of audio recordings.

Interview Questions

The interview questions examined participants, teams, planning, process, data, operations, integration, testing, and interdisciplinary challenges in ML-enabled systems.

  • Participants were asked about their roles, backgrounds, ML projects, team composition, responsibilities, communication, and component ownership.
  • Planning and process questions covered estimation, dependencies, development order, process models, replanning, and change management.
  • System questions addressed ML pipelines, interactions with non-ML components, architecture, decomposition, module boundaries, and correctness goals.
  • Data questions examined quality, quantity, ownership, documentation, schema semantics, drift, change notification, and monitoring.
  • Additional questions covered explainability, fairness, privacy, versioning, provenance, reproducibility, maintainability, deployment, and model integration.
  • Participants were asked about ML versus non-ML projects, development challenges, and whether different professional backgrounds made collaboration difficult.

1. Understanding System Requirements

System requirements define the overall product behavior and environment interactions, but ML-enabled systems may establish them either around an ML module or before modeling. This creates coordination challenges when model-focused work diverges from system goals or stakeholders struggle to scope and quantify targets.

  • System requirements address overall system behavior and environmental interactions, extending beyond the requirements of individual ML components.
  • Requirements may follow initial ML design when the model is central, or constrain modeling when ML features are incorporated into an already defined system.
  • ML design decisions can shape the entire system, whereas broad system requirements can constrain data scientists during modeling.
  • Effective requirements work involves system-level requirements, feedback loops, and non-functional requirements, producing documented requirements and environment-interaction analysis.
  • Collaboration is difficult because data scientists may focus on the model rather than the overall system, while stakeholders struggle to scope ML projects and set reasonable targets.

2. Project Planning, Process and Interdisciplinary Collaboration

Project planning in ML-enabled systems covers process selection, estimation, risk mitigation, and communication across disciplines. Exploratory ML work makes timing and coordination harder because ML components follow different structures and time requirements than traditional software components.

  • Project planning defines the process model, estimates time, mitigates risks, and synchronizes plans among stakeholders.
  • Interdisciplinary communication is part of planning because the whole team must coordinate project processes and general planning.
  • ML projects may begin with requirements or with extended data exploration, so planning practices must accommodate different starting points.
  • Planning outputs can range from informal plans to formal process documents, team structures, and adopted teamwork practices.
  • Time estimation is difficult because ML applications are exploratory and their components have structures and time requirements unlike traditional software.

3. System Decomposition, Local Checking and System Evaluation

ML-enabled systems require explicit decomposition into ML and non-ML components, component and system-level evaluation, coordinated data and quality practices, maintainable implementation, and post-deployment operations. These activities involve different specialists and require collaboration across boundaries.

  • System Decomposition, Local Checking and System Evaluation: System decomposition establishes module boundaries and interface contracts between ML and non-ML components, followed by composition and system-level quality assurance.
  • System Decomposition, Local Checking and System Evaluation: The architecture distinguishes traditional software, pipeline, inference, and monitoring components.
  • System Decomposition, Local Checking and System Evaluation: Evaluation combines local component checks with integration, system, and acceptance testing against system specifications.
  • System Decomposition, Local Checking and System Evaluation: System-level quality may include fairness, privacy, explainability, and provenance, requiring negotiated component responsibilities and corresponding system tests.
  • System Decomposition, Local Checking and System Evaluation: Data collaboration covers data quality and quantity, schemas, integrity, privacy, monitoring, and drift, with accuracy changes serving as one indicator of data needs.
  • System Decomposition, Local Checking and System Evaluation: Coding conventions and documentation must support shared understanding, integration, reuse, reproducibility, maintainability, and consistent system-wide implementation.
  • System Decomposition, Local Checking and System Evaluation: Deployment is not the final development stage because systems require monitoring, updates, continuous experimentation, bug fixes, and version changes.
  • System Decomposition, Local Checking and System Evaluation: User interaction and telemetry collection make usability and UI design additional concerns in ML-enabled systems.

Complete Set of Papers (61)

The cited literature covers software engineering challenges for ML systems, collaboration with software engineers, requirements, fairness, lifecycle processes, responsible ML, and human-AI interaction. The references therefore span technical, organizational, and human-centered concerns.

  • Several cited studies examine collaboration between data scientists and software engineers and the development processes of ML systems.
  • The bibliography includes research on requirements engineering, fairness needs, privacy, security, and responsible machine learning.
  • The references also cover computational notebooks, model performance analysis, interactive ML, and human-AI interaction.
  • The references include work on software engineering challenges, ML pipelines, production readiness, lifecycle models, and engineering AI-enabled systems.
Loading 2110.10234v4…