On the Adoption of Federated Machine Learning:

Roles, Activities and Process Life Cycle

Tobias M

uller

1,2 a

, Milena Zahn

1,2

and Florian Matthes

Technical University of Munich, TUM School of Computation, Information and Technology,

Department of Computer Science, Boltzmannstrasse 3, Garching bei M

unchen, Germany

SAP SE, Dietmar-Hopp-Allee 16, Walldorf, Germany

Keywords:

Federated Machine Learning (FedML), Software Engineering, Machine Learning Operations (MLOps).

Abstract:

Federated Machine Learning is a promising approach for training machine learning models on decentralized

data without the need for data centralization. Through a model-to-data approach, Federated Machine Learn-

ing yields huge potential from privacy by design to heavily reducing communication costs and ofﬂine usage.

However, the implementation and management of Federated Machine Learning projects can be challenging,

as it involves coordinating multiple parties across different stages of the project life cycle. We observed that

Federated Machine Learning is missing clarity over the individual involved roles including their activities, in-

teractions, dependencies, and responsibilities which are needed to establish governance and help practitioners

operationalize Federated Machine Learning projects. We argue that a process model, which is closely aligned

with established MLOps principles can provide this clariﬁcation. In this position paper, we make a case for the

necessity of a role model to structure distinct roles, an activity model to understand the involvement and opera-

tions of each role, and an artifact model to demonstrate how artifacts are used and structured. Additionally, we

argue, that a process model is needed to capture the dependencies and interactions between the roles, activities,

and artifacts across the different stages of the life cycle. Furthermore, we describe our research approach and

the current status of our ongoing research toward this goal. We believe that our proposed process model will

provide a foundation for the governance of Federated Machine Learning projects, and enable practitioners to

leverage the beneﬁts of decentralized data computation.

1 INTRODUCTION

The increasing reliance on data-driven decision-

making has led to an expansion of machine learning

(ML) applications in various industries. However, the

use of ML often requires large amounts of data, which

is often collected from various sources including per-

sonal devices with sensors such as tablets, phones or

other IoT devices. While this data could be valuable

for training ML models to power intelligent services,

it also contains sensitive personal information which

must be protected. In traditional ML approaches, data

is often centralized in a single data lake, which can be

a privacy risk as it requires data transfer and allows a

potential misuse or breach of sensitive information.

To tackle these issues McMahan et al. (2016)

introduced Federated Machine Learning (FedML), a

novel decentralized ML paradigm. The proposed al-

gorithm follows a model-to-data approach, which en-

https://orcid.org/0000-0002-9088-5054

ables training a common ML model on distributed

data while the data remains on the user’s devices and

therefore implements data privacy by design. The

FedML process is described in more detail in chapter

2. This approach yields a multitude of beneﬁts in ad-

dition to data privacy. For example, the model can be

used ofﬂine without the need of communicating with

a server and the communication load is heavily re-

duced since only update gradients are shared between

the parties. Despite these potential advantages, there

are currently only a few production-level applications

and most work on FedML still comprises prototypes

or simulations (Lo et al., 2021).

Integrating ML systems into production-level ap-

plications requires the operationalization and incorpo-

ration of software development practices of ML sys-

tems. This is a highly challenging task since the ad-

dition of ML capabilities adds further complexity to

the system design and implementation process (Ser-

ban et al., 2020; Kreuzberger et al., 2022; Wan et al.,

Müller, T., Zahn, M. and Matthes, F.

On the Adoption of Federated Machine Learning: Roles, Activities and Process Life Cycle.

DOI: 10.5220/0011954500003467

In Proceedings of the 25th International Conference on Enterprise Information Systems (ICEIS 2023) - Volume 1, pages 525-531

ISBN: 978-989-758-648-4; ISSN: 2184-4992

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

525

2021). Especially the data collection, data prepara-

tion, training, monitoring as well as the deployment

process of a typical ML life cycle require novel soft-

ware engineering practices in comparison to tradi-

tional software engineering (Sculley et al., 2015; Ser-

ban et al., 2020). There is a persisting discrepancy

between the engineering of ML-capable systems and

the engineering of traditional software (Giray, 2021).

To bridge this gap, the traditional software engineer-

ing ways of implementing code need to be revisited

due to the uniqueness of non-deterministic ML sys-

tems.

To address these issues, a two-day long discus-

sion of 160 practitioners and researchers on the chal-

lenges and implications of engineering ML systems

at the First Symposium on Software Engineering for

Machine Learning Applications (SEMLA) (Khomh

et al., 2018) spawned two key questions:

• ”How should software development teams inte-

grate the AI model life cycle (training, testing, de-

ploying, evolving, and so on) into their software

process?”

• ”What new roles, artifacts, and activities come

into play, and how do they tie into existing agile

or DevOps processes?”

According to SEMLA, researching these two key

questions is essential to link software engineering and

ML development processes. Currently, a growing cor-

pus of academic literature is concerned with these

problems. Chandrasekaran et al. (2021), for exam-

ple, propose in their work on ML governance that

an operational life cycle consists of data preparation,

model development, and a model deployment phase.

Accordingly, they deﬁned principals, the involvement

and interaction of these principals, and the life cycle

management of ML systems (Chandrasekaran et al.,

2021). Furthermore, Ritz et al. (2022) deﬁned a com-

prehensive process model for ML systems to capture

the dependencies between the artifacts and activities

in a ML life cycle in order to bridge the gap be-

tween existing software engineering process models

and ML-speciﬁc procedures (Ritz et al., 2022). Also,

there has been a growing interest in deﬁning princi-

ples, components, roles, and architectures in the con-

text of operationalizing MLOps workﬂows (Ruf et al.,

2021; Subramanya et al., 2022; Kreuzberger et al.,

2022).

Even though the key questions posed by SEMLA

have been addressed by the academic literature,

FedML introduces new processes and requirements

due to its decentral model-to-data approach. Due to

the decentralization and local training/usage proce-

dure, additional roles, activities, artifacts, and life cy-

cle stages need to be introduced. Before FedML can

be broadly operationalized, we argue that these spe-

ciﬁc questions posed by SEMLA need to be answered

as well.

IEEE published a Guide for Architectural Frame-

work and Application of Federated Machine Learn-

ing (IEEE, 2021), which deﬁnes a standard for the

FedML reference architecture including user role de-

scriptions of the FedML process. According to this

IEEE standard, a participant could play the role of

a data owner, model user, coordinator, and/or audi-

tor. These roles are presented with their accompany-

ing actions in the FedML process. This reference ar-

chitecture provides generalized information as a tem-

plate solution for the implementation of FedML pro-

cesses including structures and respective elements

with their relation. The reference architecture can

be used as a basic foundation for the governance of

FedML projects. However, according to this refer-

ence architecture, a single role is responsible for mul-

tiple steps of a typical MLOps life cycle. For instance,

the activities of a coordinator comprise the aggrega-

tion step, model management, data management, de-

ployment, and capabilities coordination.

We argue that the separation of roles and activities

should be closely aligned with established MLOps

stages and principles, such that the FedML speciﬁcs

can be easily integrated into known MLOps work-

ﬂows. Hence, a more structured breakdown of the

activities and roles in relation to the different stages

of an End-to-End FedML life cycle is needed to fully

capture the dependencies and interactions between

these roles. Furthermore, deﬁning the set of actors,

their roles and activities not only provides a clearer

understanding of the project’s setup, but also plays a

crucial part in the governance of the project (de Man

and Luvison, 2019; Kujala et al., 2021; Carid

a et al.,

2018). To accomplish this, we aim to identify the dif-

ferences between MLOps and FedML-speciﬁcs to ﬁ-

nally derive a formal process model for a full End-

to-End FedML life cycle. Through a holistic process

model, we hope to enable practitioners to set up and

provide a foundation for the governance of FedML

projects.

In summary, the planned ﬁnal contributions of our

ongoing research would comprise:

• Role Model: To structure the individual roles in-

cluding their corresponding capabilities and re-

sponsibilities.

• Activity Model: To understand the involvement,

operations, and activities of each role.

• Artifact Model: To show how artifacts are used

and structured in the process ﬂow.

• Process Model: To capture the different life cy-

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

526

cle stages including the interactions and depen-

dencies between the activities, roles, and artifacts.

To achieve this goal, we follow the Design Science

Research (DSR) conceptual framework by Hevner et

al. (2004) through an incorporated DSR Methodol-

ogy (DSRM) by Peffers et al. (2007) . The prob-

lem identiﬁcation and objective description have been

conducted through a focus group with three different

product teams and a total of ten participants. The rel-

evance and objectives have been conﬁrmed through

ﬁve semi-structured expert interviews. The knowl-

edge base was built through a literature review. In

an iterative manner, we developed the ﬁrst versions

of our models and evaluated the artifacts with a focus

group every four weeks. A more detailed description

of the conducted research methodology will be pro-

vided in the report of the ﬁnal results.

In the following, we present our current state of re-

search. In section 2, we will give a short introduction

to the FedML process. This is followed by section

3 with a high-level overview of our state of research.

This section comprises our current separation of roles

including a description of the corresponding activi-

ties and the life cycle of a FedML project. Finally, we

conclude with a discussion.

2 PRELIMINARIES

FedML is a novel ML paradigm that is concerned

with training a joint ML model on distributed datasets

over multiple iterations. In traditional ML settings,

data is usually assembled on a central data lake,

where the ML model is trained. Hence, data owners

are obliged to share their data with a central server

and therefore lose data sovereignty, which potentially

poses a privacy risk. Introduced by McMahan et

al. (2016), FedML counteracts this need of sharing

datasets. Through a model-to-data approach, FedML

enables K data owners to train a joint model M

FED

iteratively without the need of disclosing their dis-

joint datasets {D

i=1

}. A simpliﬁed illustration of the

FedML process can be seen in Figure 1.

More speciﬁcally, the FedML protocol can be di-

vided into four distinct steps:

1. The server chooses an initial global model M

suitable for the use case and underlying data struc-

ture. The global model M can be initially trained

on the dataset of the server.

2. The server distributes the global model M

amongst all clients.

3. Each client k trains the global model on its

own dataset and stores the update gradient g

Server

Client 2Client 1 Client n

Train global model

Server

Client 2Client 1 Client n

Distribute model

Server

Client 2Client 1 Client n

Train model locally

Server

Client 2Client 1 Client n

Upload and average gradients

Legend

Step

Data Flow

Database

Training

ML Model

Figure 1: One iteration of the FedML process.

∇F

). After the training process, each client

k owns its individually adapted ML model M

based on its dataset D

4. The clients send the individually computed update

gradients back to the server. The gradients are ag-

gregated based on a pre-deﬁned protocol and used

to update the global model.

This process can be repeated over several iterations

until the global model reaches a certain accuracy level

or the accuracy converges. In the original FedAVG

implementation (McMahan et al., 2016), the model

is learned through stochastic gradient descent (SGD)

and the aggregation scheme is as follows:

t+1

← w

−

∑

k=1

t+1

← w

− ηg

, ∀k

(1)

FedML commonly uses a client-server architec-

ture consisting of a central orchestrating server and

multiple clients. However, completely decentral-

ized alternatives have been proposed, which estab-

lish a peer-to-peer network to exchange model up-

dates without a central server (Roy et al., 2019). In

this work, we solely focus on traditional client-server

FedML, since fully decentral architectures are rarely

used.

The distribution of features and samples across

datasets may not be homogeneous. If all datasets con-

tain different samples but share the same feature space

we refer to horizontal federated learning (HFL). If the

same samples are present in all datasets but the fea-

ture spaces are disjoint, we refer to vertical federated

learning (VFL) (Yin et al., 2021).

The collaborative nature of FedML implies a more

sophisticated training and usage process compared to

On the Adoption of Federated Machine Learning: Roles, Activities and Process Life Cycle

527

traditional, centralized ML. This may result in new

roles, activities, artifacts, and processes, which need

to be investigated and addressed.

3 STRUCTURING FEDERATED

MACHINE LEARNING

PROJECTS

To provide a clearer understanding of the process

structure, we ﬁrst need to analyze the different ac-

tivities which are needed to implement and execute

the FedML processes as well as the MLOps work-

ﬂows. These activities can be grouped and assigned

to different role deﬁnitions. Through examining the

resulting artifacts, interactions and dependencies, the

descriptions of the individual roles can be comple-

mented with their corresponding capabilities and re-

sponsibilities. With regard to the process model, it is

ﬁrst needed to structure the project ﬂow into different

life cycle stages. By combining the roles, activities,

artifacts, interactions and life cycle we can ﬁnally de-

rive a holistic process model. By this, we aim to en-

able practitioners to set up FedML projects as well as

provide a foundation for its governance.

The following presents our current proposal of

the involved roles with their corresponding activities

(section 3.1) and the different stages of the project

(section 3.2). It is important to note, that the following

descriptions are a high-level overview of our current

state of work and may differ from the ﬁnal results.

3.1 Participating Roles and Activities

Apart from the high-level descriptions of the IEEE

standard (IEEE, 2021), no ﬁxed roles for participants

within FedML projects have been uniformly deﬁned

yet. We reviewed academic literature on ML Gover-

nance as well as reference architectures and identiﬁed

different role deﬁnitions of a traditional ML life cycle.

Furthermore, we performed a thorough analysis of a

FedML project ﬂow and derived critical roles from

the technology speciﬁcs. Finally, we aggregated and

combined our ﬁndings which resulted in a set of par-

ticipating roles of the FedML process. The following

describes the identiﬁed roles including their responsi-

bilities and capabilities. It is essential to distinguish

between participant and role. One participant can take

on several roles, and one role can be assigned to sev-

eral participants.

• Model Manager: The model manager has the

business need of a problem to be solved with ML

and represents the initiator. He takes responsibil-

ity for the context and requirements speciﬁcation.

The customer requirements are communicated to

the model owner and deployment details to the

model deployer. The primary capability is domain

and business knowledge.

• Model Owner: The model owner holds owner-

ship of the global ML model and is authorized

to decide on technical requirements. He gets

customer requirements from the model manager

and communicates technical requirements to the

model builder.

• Model Builder: The model builder deﬁnes the

ML model architecture and is responsible for

technical and system speciﬁcations. He acts as a

mediator between the model owner, data owner,

and model deployer. The primary capability is

FedML expertise. He speciﬁes and coordinates

the training procedure, trains the initial model,

distributes the model, aggregates gradients, evalu-

ates the model, and provides the trained model to

the model deployer.

• Model Deployer: The model deployer serves the

ML model according to the deployment details

deﬁned by the model manager. The primary capa-

bility is deployment knowledge and infrastructure

to serve the ML model.

• Data Owner: The data owner collects data,

cleans, transforms, trains the model, and sends

gradient updates to the model builder. The pri-

mary capability is a sufﬁcient database with qual-

itative data to train the ML model and facilitate

the FedML infrastructure.

• End User: The end user consumes the deployed

ML model to solve a particular problem.

• Auditor: The auditor veriﬁes the deployment of

the ML model, adheres to technical standards, and

adheres to compliance obligations.

• Adversary: The adversary is an entity trying to

disrupt, intercept, or cause harm to the system.

The roles can be grouped according to their tasks

in the FedML procedure. The Model Manager and the

Model Owner are mainly responsible for the manage-

ment and administration of the project. The Model

Builder and the Model Deployer are carrying out

the implementation and deployment of the FedML

model. The Data Owner undertakes the task of data

collection and local training of the model. The End

User, the Auditor, and the Adversary assume a role

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

528

End User

Model Owner

n >= 1

MANAGEMENT

ADMINISTRATION

IMPLEMENTATION

&

DEPLOYMENT

DATA COLLECTION

&

LOCAL TRAINING

Auditor

Adversary

ADDITIONAL ROLES

Information Exchange

Legend

Data Exchange

Role Grouping

Model Deployer Model Builder

Data Owner

n > 1

Model Manager

Figure 2: Overview of the roles involved in the FedML process.

that is not directly posted in the FedML training pro-

cess. Figure 2 visualizes the grouping and interac-

tions between the different roles on a high level ab-

straction.

3.2 Life Cycle of a Federated Machine

Learning Project

To capture the involvement, interactions, and activi-

ties of each role as well as the arising dependencies,

it is necessary to provide a clearly structured project

process ﬁrst. The decentral nature of the FedML

training process allows for collaborations of different

data owners. Hence, if we want to propose a holis-

tic life cycle we need to allow and depict collabora-

tive settings as well. According to Diirr and Cappelli

(2019) collaborative projects can be divided into ﬁve

main stages, from the creation of the collaboration,

operational execution, and evaluation leading to evo-

lution or dissolution. To adjust it to the FedML tech-

nology, we merged stages and included steps of op-

erational ML activities, as well as FedML-speciﬁcs.

Note, that the collaboration formation step is optional

and only has to be considered in collaborative set-

tings.

Fig. 3 shows an overview of the derived inter-

organizational FedML life cycle. The illustration un-

derlies simpliﬁcations to ease the readability of the

visualized process. The ﬁrst stage, the collabora-

tion creation, comprises four sub-steps: identiﬁca-

tion, formation, viability, and planning (Diirr and

Cappelli, 2019). First, the business need and the re-

sulting collaborative business opportunity are identi-

ﬁed and characterized. In addition, the strategy for

inter-organizational collaboration of the participants

should be determined. Next, the formation of the

network of organizations starts by identifying, eval-

uating, and selecting participants. After that, the vi-

ability of the FedML project must be assessed with

the selected participants in terms of technical and le-

gal aspects, e.g., GDPR and antitrust. Subsequently,

the business project can be speciﬁed in the planning,

and the collaboration can be institutionalized and con-

tracts negotiated. During this stage, iteration loops

may arise, or the project may be cancelled, e.g., if the

feasibility study fails.

The FedML development is the second stage and

includes the iterative process of the FedML setup,

training process, and testing and evaluation of the

model. The setup compromises the installation of

the infrastructure with all participants to execute the

iterative FedML steps, which are performed during

the training process (see Fig.1). Once the aggregated

FedML model has been successfully tested and eval-

uated with deﬁned quality speciﬁcations, it moves to

the next stage.

The stage FedML operation describes the de-

ployment, monitoring, and operation of the global

FedML model. The model is served to the end cus-

tomer by deploying the model into a speciﬁed envi-

ronment and putting it into production to be used for

its purpose. The monitoring includes monitoring the

FedML model’s performance, selecting feedback, and

detecting problems as soon as possible. The operation

comprises the application of processes to maintain the

models in production environments.

The next stage, evaluation, assesses the FedML

model and the collaboration itself to decide how to

proceed with the project. The evaluation based on

evaluation criteria should lead to decisions on how to

proceed. In case of a retirement, the collaboration

will be closed, and it must be decided whether the

resulting FedML models remain to be distributed or

recalled. In the other case, an evolution means either

improvement or changes in the FedML development

or adaptation of the collaboration of the organizations.

The simpliﬁed life cycle does not represent all it-

erative possibilities and provides a rough guideline for

FedML projects.

On the Adoption of Federated Machine Learning: Roles, Activities and Process Life Cycle

529

CollaborationCreation

Formation

FedML Development

Setup

Training

Process

Testing and

Evaluation

FedML Operation

Deployment

Monitor and

Maintenance

Evaluation

Evolution

Evaluation

Operation

Viability Planning

Adjust Participants

Adjust FedML

Training

Legend

Stage

High-level Activity

XOR Gate

Start/End Point

Identiﬁcation Retirement

Figure 3: High-Level Overview of a FedML life cycle with exemplary iterative loops.

4 DISCUSSION

Despite the potentially large beneﬁts of breaking up

data silos, implementing privacy by design, and heav-

ily reducing the communication costs of ML appli-

cations, FedML only has seen a few production-level

applications and seems to be mainly in a prototype

stage. We observed that FedML is missing a struc-

tured process model which gives the involved parties

clarity over the structure, interactions, and responsi-

bilities of the full FedML life cycle process. We ar-

gue that this process model should be closely aligned

with established MLOps stages and principles such

that the FedML speciﬁcs can be easily integrated into

known workﬂows and therefore ease the operational-

ization. To provide this guidance, it is important to

deﬁne role descriptions including their activities, ca-

pabilities, and responsibilities. Furthermore, the re-

sulting artifacts throughout the life cycle need to be

derived. By combining the interactions and depen-

dencies between the roles, activities, and artifacts we

can provide a formal process model of an end-to-

end FedML life cycle. We argue that such a process

model is needed to provide a blueprint for practition-

ers to establish governance and integrate FedML into

their products. This position paper represents our cur-

rent state of research towards a process model, which

clearly structures the FedML life cycle with regard to

established MLOps practices. As a ﬁrst step towards

this goal, we proposed an initial structuring of roles

and activities which are involved in the FedML train-

ing process as well as a high-level project life cycle.

Our current work focuses on capturing the artifacts,

interactions, and dependencies while iteratively inte-

grating our ﬁndings into the role and activity mod-

els. We ﬁnally aim to derive a holistic FedML process

model over the full project life cycle.

ACKNOWLEDGEMENTS

The authors would like to thank SAP SE for support-

ing this work.

REFERENCES

Carid

a, A., Colurcio, M., and Melia, M. (2018). Design-

ing a collaborative business model for smes. Sinergie

Italian Journal of Management, pages 233–253.

Chandrasekaran, V., Jia, H., Thudi, A., Travers, A., Yaghini,

M., and Papernot, N. (2021). Sok: Machine learning

governance. ArXiv, abs/2109.10870.

de Man, A.-P. and Luvison, D. (2019). Collaborative busi-

ness models: Aligning and operationalizing alliances.

Business Horizons, 62(4):473–482.

Diirr, B. and Cappelli, C. (2019). A systematic litera-

ture review to understand cross-organizational rela-

tionship management and collaboration. In Anais do

XV Simp

osio Brasileiro de Sistemas Colaborativos,

pages 118–119, Porto Alegre, RS, Brasil. SBC.

Giray, G. (2021). A software engineering perspective on

engineering machine learning systems: State of the

art and challenges. Journal of Systems and Software,

180:111031.

Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004).

Design science in information systems research. MIS

Quarterly, 28(1):75–105.

IEEE (2021). Ieee guide for architectural framework and

application of federated machine learning. IEEE Std

3652.1-2020, pages 1–69.

Khomh, F., Adams, B., Cheng, J., Fokaefs, M., and Anto-

niol, G. (2018). Software engineering for machine-

learning applications: The road ahead. IEEE Soft-

ware, 35(5):81–84.

Kreuzberger, D., K

uhl, N., and Hirschl, S. (2022). Ma-

chine learning operations (mlops): Overview, deﬁni-

tion, and architecture.

Kujala, J., Aaltonen, K., Gotcheva, N., and Lahdenper

a, P.

(2021). Dimensions of governance in interorganiza-

tional project networks. International Journal of Man-

aging Projects in Business, 14(3):625–651. Funding

Information: This paper extends on previous research

that has been presented in European Academy of

Management (EURAM) conference, 1-4 June 2016,

Paris, France. Publisher 2020, Emerald Publishing

Limited.

Lo, S. K., Lu, Q., Wang, C., Paik, H.-Y., and Zhu, L. (2021).

A systematic literature review on federated machine

learning: From a software engineering perspective.

ACM Comput. Surv., 54(5).

McMahan, H. B., Moore, E., Ramage, D., and y Arcas,

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

530

B. A. (2016). Federated learning of deep networks

using model averaging. CoRR, abs/1602.05629.

Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chat-

terjee, S. (2007). A design science research method-

ology for information systems research. Journal of

Management Information Systems, 24(3):45–77.

Ritz, F., Phan, T., Sedlmeier, A., Altmann, P., Wieghardt,

J., Schmid, R., Sauer, H., Klein, C., Linnhoff-Popien,

C., and Gabor, T. (2022). Capturing dependencies

within machine learning via a formal process model.

In Margaria, T. and Steffen, B., editors, Leveraging

Applications of Formal Methods, Veriﬁcation and Val-

idation. Adaptation and Learning, pages 249–265,

Cham. Springer Nature Switzerland.

Roy, A. G., Siddiqui, S., P

olsterl, S., Navab, N., and

Wachinger, C. (2019). Braintorrent: A peer-to-peer

environment for decentralized federated learning.

Ruf, P., Madan, M., Reich, C., and Ould-Abdeslam, D.

(2021). Demystifying mlops and presenting a recipe

for the selection of open-source tools. Applied Sci-

ences, 11(19).

Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips,

T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-

F., and Dennison, D. (2015). Hidden technical debt in

machine learning systems. In Cortes, C., Lawrence,

N., Lee, D., Sugiyama, M., and Garnett, R., editors,

Advances in Neural Information Processing Systems,

volume 28. Curran Associates, Inc.

Serban, A., van der Blom, K., Hoos, H., and Visser, J.

(2020). Adoption and effects of software engineer-

ing best practices in machine learning. In Proceed-

ings of the 14th ACM / IEEE International Symposium

on Empirical Software Engineering and Measurement

(ESEM), ESEM ’20, New York, NY, USA. Associa-

tion for Computing Machinery.

Subramanya, R., Sierla, S., and Vyatkin, V. (2022). From

devops to mlops: Overview and application to elec-

tricity market forecasting. Applied Sciences, 12(19).

Wan, Z., Xia, X., Lo, D., and Murphy, G. C. (2021). How

does machine learning change software development

practices? IEEE Transactions on Software Engineer-

ing, 47(9):1857–1871.

Yin, X., Zhu, Y., and Hu, J. (2021). A comprehensive sur-

vey of privacy-preserving federated learning: A tax-

onomy, review, and future directions. ACM Comput.

Surv., 54(6).

On the Adoption of Federated Machine Learning: Roles, Activities and Process Life Cycle

531