#  DevOps Adoption: Eight Emergent Perspectives

Mauro Lourenço Pedra
Graduate Program in Informatics
Federal University of Rio de Janeiro (UFRJ)
Rio de Janeiro, Brazil
<EMAIL_ADDRESS>
Mônica Ferreira da Silva
Graduate Program in Informatics
Federal University of Rio de Janeiro (UFRJ)
Rio de Janeiro, Brazil
<EMAIL_ADDRESS>
Leonardo Guerreiro Azevedo
IBM Research
Rio de Janeiro, Brazil
<EMAIL_ADDRESS>

###### Abstract

DevOps is an approach based on lean and agile principles in which business,
development, operations, and quality teams cooperate to deliver software
continuously aiming at reducing time to market, and receiving constant
feedback from customers. However, implementing DevOps can be a complex and
challenging mission due it requires significant paradigm shift. Consequently,
many failures and misconceptions can occur about DevOps adoption by
organizations, despite its numerous benefits.

This work identifies, describes, and compares different perspectives related
to DevOps adoption in academy and industry. The perspectives can be understood
as factors or variables that influence or help to understand the DevOps
journey.

We employed a sequential multi-method research approach, including Systematic
Literature Review (SLR) and Case Study. As a result, eight perspectives were
found: concepts, models, principles, practices, difficulties, challenges,
benefits, and strategies. More specifically, the SLR produced 390 items, which
can be understood as occurrences of a perspective. The conducted case study
confirmed 75 items, corroborating the SLR findings, while another 29 items
emerged. This global view on DevOps adoption may guide beginners, both
theorists, and practitioners, to make the necessary organizational
transformation less painful.

_Keywords_ Software Engineering, Agile, DevOps Adoption, DevOps
implementation, DevOps Dimensions

##  1 Introduction

Several organizations that develop and use information systems split their
software teams structurally into departments. A standard approach is a
separation in software development and system operation departments. This
division has been debated, and combining those teams is argued in the concept
of DevOps. DevOps is about fast, flexible development and provisioning
business processes. It efficiently integrates development, delivery, and
operations, thus facilitating a lean, fluid connection of these traditionally
separated silos Ebert et al. (2016).

Usually, the Development team is responsible for answering market change needs
and delivering new assets in production as quickly as possible. On the other
hand, the Operation team is responsible for providing stable, trustful, and
secure IT services to clients, ensuring that changes that may compromise the
services are not deployed in production Kim et al. (2016). Therefore,
Development and Operation teams have conflicting stimuli and goals due to the
choice between agility and stability. So, the industry has adopted DevOps in
an attempt to deal with this disparate of concerns Fitzgerald and Stol (2017).

Although DevOps has been an essential movement in industry for more than a
decade, it has not received much attention from the academic community until
recently Wiedemann et al. (2019). Still, the interest is increasing from both
practitioners and researchers. Among the main reasons are results such as
increased productivity and quality of IT products and services and reduced
development cycle time, and, consequently, faster response to market needs
Dingsøyr and Lassenius (2016). Although many organizations have achieved great
success with technology transformations, there is still much work to be done —
both in the broader industry and within individual organizations Humble and
Kim (2018).

DevOps adoption is not an easy or direct task. It may require requires complex
changes in an organization, corporate process, and workflows Bucena and
Kirikova (2017). As a software process improvement initiative, the route for a
successful DevOps adoption is exclusive and typical of each organization.
However, it is possible to learn from empirical knowledge to plan future
DevOps adoption initiatives Smeds et al. (2015). Research on DevOps is
fragmented, making it challenging to identify and understand its scope,
covered topics and challenges already addressed as well as those not yet
addressed Erich et al. (2014).

Organizational and cultural changes and adoption of technologies (mainly
frameworks) are required to overcome the detachment of Development and
Operation teams Wettinger et al. (2014). In addition, given that DevOps
practitioner literature is still emerging, and reliable academic research on
the phenomenon is sparse, IT organizations lack concrete guidance on how to
approach the DevOps paradigm in practice Nielsen et al. (2017) .

The goal of this work is to identify, describe, and compare different
perspectives related to DevOps adoption in academy and industry. These
perspectives refer to possible dimensions or ways to interpret or visualize
the phenomenon of DevOps adoption. In other words, the perspectives can be
understood as factors or variables that influence or help to understand the
DevOps journey. We provide a holistic view of these perspectives without
delving into any specific characteristics.

This work employed a sequential multi-method research approach, including
Systematic Literature Review (SLR) and Case Study. Figure 1 shows a holistic
scheme of the applied multi-method research. The SLR aimed to identify,
describe and deepen the knowledge about DevOps adoption in the academy and
identify the main related perspectives. The case study was conducted with two
software development organizations and empirically explored how is going
DevOps adoption in industry and compared with the SLR results. The research
was exploratory, descriptive, and deductive since it seeks new insights and
aims at generating and validating ideas and hypotheses for future work.
Deductively, according to Runeson et al. (2012), this can lead to confirmed or
rejected theories. More specifically, the SLR produced 390 items, which can be
understood as occurrences of a perspective, found in the 28 selected primary
studies and classified according to our interpretative scheme. The conducted
case study confirmed 75 items, corroborating the SLR findings, while another
29 items emerged, expanding what was found in the literature regarding DevOps
adoption. This global view on DevOps adoption may guide beginners, both
theorists, and practitioners, to make the necessary organizational
transformation less painful.

Figure 1: Holistic Research Scheme

##  2 Systematic Literature Review

To achieve research objectives, SRL was used as one of the research
strategies. This section presents a brief description of the adopted protocol,
including selection criteria and discovered limitations, in addition to
achieved results.

###  2.1 Preliminary Bibliographic Research

Initially, it was necessary to conduct preliminary bibliographic research of
the literature through snowballing method Wohlin (2014), i.e., follow
references of the most relevant works in the DevOps theme to deepen the
understanding and construction of a more robust search string.

During this phase, it became evident the difficulty of defining the most
common English-speaking terms related to DevOps. For ensuring more accuracy in
the search string’s construction, we performed a generic search for the word
DevOps in the search engines ACM Guide to Computing Literature, IEEExplore,
DBLP, and Scopus. Three hundred forty-one papers were obtained, excluding
duplicate results, unavailable publications, and papers written in languages
other than English. After that, a file containing all the titles, abstracts,
and keywords of the selected publications was generated and submitted to the
Corpus linguistic processor111Available at
http://linguistica.insite.com.br/corpus.php., from Insite Linguistics Group,
to identify the words with the highest occurrence in the publications. The
generated report counted more than 7,000 words. Three stages were used to deal
with these words:

  * •

Exclusion of irrelevant or generic words such as pronouns, conjunctions,
adverbs, and connectives;

  * •

Combination of words with similar radicals;

  * •

Elimination of words with less than 100 occurrences.

As an example, Figure 2 displays the 15 more relevant words found in the
selected publications. We considered the more fitting words to the research
objectives to construct the search string, which not necessarily are the more
cited ones.

Figure 2: Top 15 of the most relevant words found in DevOps publications

###  2.2 Execution

The following search string was assembled from the preliminary bibliographic
research:

( DevOps ) AND ( model OR framework OR method OR platform OR solution ) AND (
adoption OR implementation OR introduction )

Table 1 relates the number of quotes from the words that make up the search
string.

Table 1: Number of Word Citations for Search String Word | Number of Citations
---|---
DevOps | 1344
model | 242
framework | 101
method | 109
platform | 100
solution | 100
adoption | 143
implementation | 163
introduction | 77

We chose the following scientific bases among the main ones in Computer
Science to combine comprehensive search engines with other more specific
bases. This combination aims to achieve greater plurality and coverage of
scientific events and journals in the investigated area.

  * •

Scopus \- www.scopus.com \- Search Engine

  * •

IEEE Xplore \- ieeexplore.ieee.com \- Bibliographic basis

  * •

Science Direct \- www.sciencedirect.com \- Bibliographic basis

  * •

Springer \- link.springer.com \- Bibliographic basis

  * •

ACM Digital Library \- dl.acm.org \- Hybrid

The Mendeley222Available at https://www.mendeley.com/, and licensed by UFRJ,
the institution of some of the authors. software was used as a support tool to
manage the documents extracted from the scientific bases, generate
bibliographies, and add markings in the texts.

In this stage of the SLR, the inclusion and exclusion criteria were applied to
increase selected studies’ relevance, as follows in Figure 3.

The Snowballing search was applied to the twenty primary studies initially
selected, which added eight new studies, resulting in twenty-eight documents
in total. This step was performed to avoid missing relevant works.

Figure 3: Application of Inclusion and Exclusion Criteria

###  2.3 Analysis and Results

This section will detail the extraction and organization of information, using
spreadsheets, thematic analysis, and mind mapping to present the results.
Eight perspectives were generated, i.e., , concepts, models, principles,
practices, difficulties, challenges, benefits, and strategies.

####  2.3.1 Concepts

To obtain the author’s view on DevOps concepts, we extracted a term definition
from each of the 28 studies.

A word cloud was created to provide a more comprehensive view of the various
concepts extracted, as shown in Figure 4. The greater the number of words
present, the larger the size or highlight shown. Stop words such as pronouns,
conjunctions, adverbs, and connectives were not considered. The site
WordClouds.com333Available at https://www.wordclouds.com/. was used to create
the word cloud.

This word cloud reinforces some terms related to DevOps, such as
collaboration, culture, software, practices, quality, delivery, automation,
operations, processes, and teams, which shows excellent adherence and
convergence to the broad concept DevOps represents. Moreover, although there
are different interpretations in DevOps literature, this word cloud helps to
visualize a connection and many similarities between the various authors
considered in this study.

Figure 4: Cloud of Words

####  2.3.2 Distribution of Primary Studies by Locality

As an additional result from the SLR, in Figure 5, it is possible to
visualize, through the illustrated world map, the distribution of the primary
studies selected in this phase of the research by country of publication.
There is a high concentration in the European and North American continent
countries and relevant research in India. From this, it is possible to deduce
that there is a scarcity of qualified studies, specialized events, or research
focus in the least developed countries, probably due to a low degree of
maturity or interest in DevOps’ adoption. Future research on this topic may be
helpful.

Figure 5: Distribution of Primary Studies Around the World

####  2.3.3 DevOps-related Models and Frameworks

Table 2 presents a consolidated view of the models and frameworks found in the
28 studies selected in the SLR, as well as their type, focus, and quantity.

Table 2: DevOps-related Models and Frameworks - Consolidated Type | Focus | Quantity
---|---|---
Model |  DevOps Adoption | 4
DevOps Maturity | 2
Technology Acceptance | 1
Framework |  DevOps Adoption | 2
DevOps Maturity | 2
Knowledge Sharing | 1
Communication | 1

####  2.3.4 Thematic Analysis and Mind Mapping

Although the kind of results obtained by content analysis techniques cannot be
taken as irrefutable proof, it constitutes an illustration that allows
corroborating, at least partially, the presuppositions in question BARDlN
(1977).

Carrying out a thematic analysis consists of discovering the “nuclei of
meaning” that make up the communication and whose presence, or frequency of
appearance, can mean something for the chosen analytical objective. The theme
is generally used as a recording unit to study motivations for opinions,
attitudes, values, beliefs, and trends. In this sense, it is possible to
consider that the mind mapping technique can be seen as a type of content
analysis, even more, a kind of thematic analysis.

Mind maps were chosen because they can represent ideas linked to a central
theme. There are a lot of rules for creating mind maps in which the main one
is to bring the brain in and use the imagination Crowe and Sheppard (2012).
Creating mind maps is an easy and natural organization method and visualizing
complex data, both as survey methods and as interactions between data. In
addition, mind maps can also help people learn concepts better than linear
formats and annotations.

Given the large number of occurrences associated with each perspective, it was
necessary to adopt a classification scheme using graduated weights. This
scheme considers an importance degree (or weight) for each item present in
each perspective, from the association of a star that can have three colors
(or three weights): red represents the highest degree, with value three;
yellow has value two; and, finally, blue represents the lowest degree, with
value one. This degree is determined by the number of times the item is cited,
considering one citation if the item appears one or more times in the same
primary study. On each picture that represents a perspective’s mind map, there
is a legend that explains this particular color scheme. The number of
citations present in this color scheme may vary according to each perspective,
never exceeding the limit of 28 citations, which is the total number of
primary studies considered.

In addition, given the possibilities and complexities inherent in the mind
map’s construction, it was necessary to create a type called aggregator branch
(expressed by a noun). This aggregator refers to a branch that explains,
details, or exemplifies the branch or avoids repetition of similar terms,
improving semantics. An image of a green check sign represents the aggregator,
and a legend is associated with it.

An additional feature of the classification scheme was still necessary to
better express the mind maps’ semantics in scenarios of greater complexity and
number of items. This scheme was applied in the mind maps of the Difficulties,
Challenges, Benefits, and Strategies perspectives. To represent the degree of
importance of a mind map branch, the sum of the weights attributed to all the
branch twigs and leaves, and sub-leaves was considered. This number was
represented below the box that represents the topic itself. The number that
appears next to the topic is the sum of the number of subordinate items. It is
important to remember that the values assigned to the weights always vary from
1 to 3, with an increasing degree of importance. The criterion for framing an
item to a given weight is specified in the legend of each mind map. It may
vary from perspective to perspective, according to the free criterion adopted
by the authors.

To facilitate the visualization and understanding of this internal
classification scheme of mind maps, a structural meta-model was created,
represented in Figure 6, in which:

  * •

Root Node = Perspective

  * •

Branch = Correlated Item or Aspect

  * •

Twigs and Leaves = Items or Aspects’ aggregations or extensions

Figure 6: Structural Meta-Model of Mind Maps

Given the possible options in drawing a mind map, some clarifications about
construction rules are in order. A simple branch directly represents an item
or aspect related to the perspective. At most, it can have a few associated
branches, only at 1 level of depth, to explain it or correlate similar items
or aspects.

On the other hand, the aggregator branch or aggregator topic, present in
several perspectives, represents a set of correlated items or aspects. It can
contain another branch, a twig, leaf, or sub-leaf. Its existence allows for
greater freedom in drawing the mind map, unifying or simplifying several items
correlated by some characteristic to improve the semantics and contain any
reasonable explanation found in primary studies. It can be considered a
complex branch that represents high-density structures with several branches.
The main item or aspect, which represents something related to the perspective
and which must be considered in the accounting, in any branch, will always
have an associated colored star.

The XMind ZEN444https://www.xmind.net/ software tool was used to support the
creation of mind maps. Due to the extensive size of mind maps, we provided a
Web page555https://github.com/leogazevedo/devops-adoption-perspectives with
them.

####  2.3.5 Principles

We found fifteen principles related to DevOps. Among the five most cited
principles are only two of those present in the acronym CALMS, they are:
Culture and Automation. Among the most cited are the principles of
Communication, Collaboration and Agility. The other principles present in the
acronym CALMS (Lean, Measurement and Sharing) also appear, but with fewer
citations in the selected studies, thus configuring themselves with less
relevance in this research.

In Table 3, there is a description of each principle found in the 28 selected
studies, as well as its relevance. This relevance was calculated considering
the number of citations, as described below:

  * •

High = Over 19 occurrences

  * •

Medium = Among 10 and 19 occurrences

  * •

Low = Under 10 occurrences

Table 3: Principles ID | Principle | Relevance
---|---|---
| P1
---
| Collaboration
---
| High
---
| P2
---
| Automation
---
| High
---
| P3
---
| Culture
---
| High
---
| P4
---
Communication |  | High
---
| P5
---
| Agility
---
| High
---
| P6
---
Sharing |  | Medium
---
| P7
---
Measurement | Medium
| P8
---
| Trust
---
| Medium
---
| P9
---
| Lean
---
| Medium
---
| P10
---
| Alignment of
---
Responsabilities
| Medium
---
| P11
---
| Respect
---
| Low
---
| P12
---
| Transparency
---
| Low
---
| P13
---
| Resilience
---
| Low
---
| P14
---
| Standardization
---
| Low
---
| P15
---
| Collective Property
---
| Low
---

####  2.3.6 Practices

Eleven direct practices were found represented by simple branches, two
indirect practices represented by hybrid branches, and ten aggregator branches
were created to facilitate the organization and visualization, as they were
considered to represent correlated practices. Aggregator branches represent
the number of practices that are grouped, making a subtotal of 60 practices.
That is, in total, adding the direct practices (11), plus the indirect
practices (2) with the practices present in the aggregator branches (60), 73
practices related to DevOps were found. Practices related to Monitoring,
Development, Testing, and Continuous Deployment stand out among the most
cited. As a demonstration, the DevOps Practices mind map was represented in 4
parts, for ease of viewing, due to its length, as we can see in the figures 7,
8, 9 and 10. The most cited practices with great relevance (red star) to the
DevOps concept are:

  * •

Automated Build

  * •

Continuous Deployment

  * •

Continuous Integration

  * •

Continuous Delivery

  * •

Cloud Computing

  * •

Source Code Version Control

  * •

Automated and Continuous Feedback

  * •

Infrastructure as Code

Figure 7: Mind Map of DevOps Practices - Part 1 Figure 8: Mind Map of DevOps
Practices - Part 2 Figure 9: Mind Map of DevOps Practices - Part 3 Figure 10:
Mind Map of DevOps Practices - Part 4

####  2.3.7 Difficulties

Forty difficulties were encountered, represented by five aggregator branches.
These were created to better semantically represent difficulties related to
Tools (4), Client (2), Teams (14), Management (8), and Process (12). The
weights of the classification scheme highlight difficulties or problems
related to the Team and Process aspects during the adoption of DevOps.

####  2.3.8 Challenges

Fifty-two challenges were found, represented by four aggregator branches.
These were created to better semantically represent challenges related to
Tools (4), Teams (11), Management (22), and Process (15). Applying the weights
of the classification scheme, challenges or risks related to the Management
and Process aspects during the adoption of DevOps are highlighted.

####  2.3.9 Benefits

Seventy benefits were found, represented by six aggregator branches. These
were created to better semantically represent benefits related to
Product/Service (9), Customer (8), Teams (19), Market (1), Organization (10),
and Process (23). The weights of the classification scheme highlight benefits
related to the aspects of the Process and Teams during the adoption of DevOps.

####  2.3.10 Strategies

Ninety-nine strategies were found, represented by four aggregator branches.
These were created to better semantically represent strategies related to
Organization (14), Teams (27), Management (18), and Process (40). The weights
of the classification scheme highlight strategies related to the aspects of
the Process and Teams during the adoption of DevOps.

####  2.3.11 Summary of Perspectives

To facilitate the comparison between perspectives and consolidate the results
achieved, the tables 4 and 5 were created. These tables present four
perspectives and the analyzed branches or dimensions. The difference between
the tables occurs regarding the use or not of the weights of the
classification scheme. The use of weights did not change the order or degree
of importance either of the perspectives, comparative scope, or branches or
dimensions when viewed in isolation and compared to each other. So, using
weights helps reinforce the validity and assertiveness of using the mind
mapping technique to encode information extracted from selected studies.

For the Principles and Practices perspectives, there was no need to use
specific branches or dimensions due to the ease to analyze and condense the
results because of the small number of extracted items, the direct mentions,
or good correlation to the perspectives in the analyzed primary studies. For
these reasons, these 2 perspectives do not appear in the tables 4 and 5.

Table 4: Summary of Perspectives - Weightless | Difficul. | Challen. | Benef. | Strateg. | Total
---|---|---|---|---|---
Tools | 4 | 4 | N/A | N/A | 8
Manag. | 8 | 22 | N/A | 18 | 48
Teams | 14 | 11 | 19 | 27 | 71
Process | 12 | 15 | 23 | 40 | 90
Client | 2 | N/A | 8 | N/A | 10
Organiz. | N/A | N/A | 10 | 14 | 24
Product | N/A | N/A | 9 | N/A | 9
Market | N/A | N/A | 1 | N/A | 1
Total | 40 | 52 | 70 | 99 |
Table 5: Summary of Perspectives - Weighted | Difficul. | Challen | Benef. | Strateg. | Total
---|---|---|---|---|---
Tools | 6 | 10 | N/A | N/A | 16
Manag. | 16 | 31 | N/A | 50 | 97
Teams | 24 | 24 | 32 | 63 | 143
Process | 18 | 24 | 31 | 83 | 156
Client | 2 | N/A | 11 | N/A | 13
Organiz. | N/A | N/A | 14 | 37 | 51
Product | N/A | N/A | 15 | N/A | 15
Market | N/A | N/A | 3 | N/A | 3
Total | 66 | 89 | 106 | 233 |

##  3 Case Study

This section presents the case study which was conducted following Runeson et
al. protocol Runeson et al. (2012) as follows:

  * •

Case study type: Exploratory, descriptive, multiple, and holistic.

  * •

Goal: Analyze the state of the practice comparing with state of the art (i.e.,
considering SLR results), aiming at bringing new visions, contexts,
perspectives, and interpretations enhancing the theory.

  * •

The case: Professional experts in DevOps of organizations that handle Software
Engineering problems.

  * •

Selection strategy: Enterprises that are adopting or are mature in DevOps,
even partially, and utilize agile or hybrid methodologies for software
development in at least one year.

  * •

Data collection: through semi-structure, remote interviews, preferably with
audio and video recording consented by the interviewees.

  * •

Quantity of interviewees: Four experts were selected considering experience,
knowledge, and human factors (relationship).

  * •

Validation (pre-test): with a member of HumânITas research group666Research
group of Graduate Program in Informatics of UFRJ (PPGI-UFRJ) which is composed
of Ph.D., masters, and students. The group focus is research on human factors
about development, adoption, and use of IT. More information available at
http://dgp.cnpq.br/dgp/espelhogrupo/635926.

  * •

Interview duration: About 120 minutes on average.

First, a semi-structured interview questionnaire with open and closed
questions was created based on SLR results777Available at
https://github.com/leogazevedo/devops-adoption-perspectives. The questionnaire
was enhanced considering the feedback of HumânITas research group, and it was
composed of three parts:

  * •

Social-demographic questions: Questions to characterize the individuals and
organization with a focus on the case;

  * •

Technical questions: technical questions about DevOps centered on this
research goal.

  * •

Practices knowledge form: a set of practices and resources found in the
literature to validate their representativeness and importance in a practical
environment.

Four interviews were conducted by Skype888https://www.skype.com/ with four
software engineering professions of two distinct organizations. The same set
of questions were applied to all interviewees, and other spontaneous questions
were made when necessary. The interviewees received disclosure information,
and they were asked to present genuine and detailed responses. All interview
audios were recorded for data collection with the consent of all interviewees.

Table 6 presents interview details. The four interviewees are anonimized with
I1, I2, I3, and I4 codes.

Table 6: Interviews Conduction ID | Organization | Date | Duration
---|---|---|---
I1 | A | May 30th, 2020 | 72 minutes
I2 | A | May 30th, 2020 | 125 minutes
I3 | B | June 22nd, 2020 | 133 minutes
I4 | B | June 22nd, 2020 | 97 minutes

Table 7 and Table 8 present the demographic data of the interviewees in a
personal and organizational context, respectively. Table 9 presents the
context of the enterprises considering the case study goal.

Table 7: Interviewee Demographics - Personal Context ID | Gender | Age (years) | Qualification
---|---|---|---
I1 | Female | 19 to 29 | Incomplete undergrad.
I2 | Male | 19 to 29 | Incomplete undergrad.
I3 | Male | 30 to 39 | Complete undergrad.
I4 | Male | 40 to 49 | Complete graduation
Table 8: Interviewee Demographics - Organizational Context ID | Function |  | Org.
---
Size
| IT
---
Experience
| DevOps
---
Experience
I1 |  | Product
---
Owner
Small | 2 years | 1 year
I2 |  | Project
---
Director
Small |  | 3 years
---
and a half
6 months
I3 |  | Business
---
Architect
Big | 12 years | 9 years
I4 |  | Construction
---
Solution
Leader
Big | 20 years | 3 years
Table 9: Company Description | Company A | Company B
---|---|---
| Business
---
Branch
| Provision of
---
IT Services
| Energy
---
Industry
| Number of
---
Employees
| Between
---
30 and 40
| Between
---
48 and 50 thousand
| Locality /
---
Coverage
| Rio de Janeiro /
---
Regional
| Brazil /
---
National
| Organizational
---
Structure
Projected |  | Functional
---
(matrix efforts)
| IT
---
infrastructure
| On-premise
---
(VPS)
| On-premise
---
(Datacenters)
| Strategic Position
---
IT
Core Business |  | Executive
---
Management
| DevOps
---
Adoption Stage
Initial | In progress

###  3.1 Results and Analysis

This section presents the results and analysis of the interviews. We preformed
a thematic analysis and compared with SLR results, through the following
steps, depicted in Figure 11:  (i) Transcription;  (ii) Organization;  (iii)
Reading;  (iv) Codification;  (v) Theme identification;  (vi) Theme meaning
interpretation.

Figure 11: Thematic Analysis Stages

All interview audio-recorded data were transcribed in a spreadsheet with
specific tabs for each interview script stage. The interviewee responses were
transcribed in sentences connected to the question goal, and redundant and
irrelevant terms were removed. We assigned a unique identification to avoid
shuffle and facilitate data analysis. We exhaustively read the transcriptions
to be familiarized and have a clear comprehension of the data. The codes in
each transcription were assigned, analyzing each one manually. The identified
codes were classified into themes according to the perspectives identified in
the SLR and their topics. The frequency and relevance of a code were the main
criteria to consider. In this work, we defined frequency as answers from more
than one interviewee and relevancy as the importance for the literature and
this research.

####  3.1.1 Concepts

For individuals I1 and I2, from the same company, the focus is on gaining time
and productivity. Therefore, in this company, DevOps is related to the ideas
of agility and Lean applied to infrastructure activities. For individuals I3
and I4, from the same organization, it is possible to infer a significant
focus on collaboration and delivering value to the customer as motivators of
the DevOps initiative.

####  3.1.2 Models and Frameworks

Only I3 reported the existence of a model focused on organizational topology
questions tailored for development and operation team999Available at
https://web.devopstopologies.com/.

However, in general, interviewees stated that there is no single model or
framework recognized and widely used as a reference. It is a journey where
each organization must seek its path without following something strictly
predetermined since each company has its strategic objectives, maturity, and
sizes.

They also mentioned that the multidisciplinary working groups are a good
choice for DevOps adoption.

Besides, I4 suggested the DevOps adoption through an incremental and on-demand
approach using a customized model. That way, the journey is more adaptable to
the different business requirements of each client and technology.

####  3.1.3 Principles

The two interviewees from company A cited specific DevOps practices. Thus,
from the items mentioned earlier, it was possible to infer that the adoption
of DevOps in this company had a strong foundation in the automation of
infrastructure activities, focusing on implementing and improving the software
delivery pipeline. For these two interviewees, the principles of Automation,
in the first place, and Culture, in the second, present themselves as the most
important ones related to the adoption of DevOps.

For the second company, despite the two respondents having different technical
expertise, there was a convergence on the most relevant principles considered
during the adoption of DevOps, which can be seen as a positive aspect. The
Culture and Automation principles are also listed as the most relevant in the
view of these interviewees.

Therefore, although the two companies and their employees have very different
expertise, the principles of Automation and Culture are considered the most
relevant in the adoption of DevOps. We observe that these principles have a
more tangible and visible character since automation brings several changes
and practical improvements to the flow and form of work. In addition, Culture
is a principle related to people and has a fundamental role when transforming
processes and routines in a way that is as significant as DevOps proposes.
However, interviewee I3, depicted that the adoption of DevOps requires
considering all the principles since they are necessary and complementary.
Adopting part of them can bring difficulties and, of course, internal
resistance to the changes that come about.

####  3.1.4 Practices

Interviewee cited eleven DevOps in total. I3 cited two new practices:
InnerSource and Skunkworks. InnerSource allows software developers to
contribute to other teams’ efforts, promoting transparency and openness to
other people’s contributions. This practice embodies a philosophy of human
relations, an approach for rewards and motivations, and a flexible and
adaptable set of tools and practices. Skunkworks project is one developed by a
relatively small and loosely structured group of people who research and
develop a project primarily for the sake of radical innovation. Additionally,
Blue Green Deployment was mentioned by I1.

The Continuous Integration practice was the only one cited and recognized by
all the interviewees. Continuous Deployment and Continuous Integration were
practices cited by three of the four interviewees.

Regarding the companies, Company A focuses on automation practices, while
Company B concentrates on automation and is planning to use Cloud Computing.
Seven of the eleven cited practices are related to automation. This fact
reinforces that, in industry, the DevOps adoption is strongly related to
activities of automation practices.

####  3.1.5 Difficulties

I1 and I2 reported difficulties in writing tests, choosing proper tools,
adopting this practice broadly in the organization.

I4 highlighted the complexity concerning task automation securely and the
human factor, mainly related to convincing and getting team confidence in the
new way of working.

####  3.1.6 Challenges

The interviewees of Company A point out learning and knowledge propagation as
a big challenge, which is a fundamental issue for DevOps adoption. One of its
basic principles, as RSL confirmed.

I3 highlighted Cloud Computing as a prerequisite for DevOps adoption, and the
convincing of high management about DevOps adoption may be pretty costly and
comprising.

I4 points out the challenge already taken but not yet overcome about unique
open-source tool adoption for code versioning and the internal challenge about
resistance to change.

####  3.1.7 Benefits

Company A has the increase in delivery speed and improvement of company image
in the market as the benefits.

I3 reported delivery speed as a benefit resulted from the DevOps adoption.

Concerning agility increase and workflow simplification, I4 highlighted that
process automation reduced the need to take different teams to answer the
company requests registered in task control systems.

####  3.1.8 Strategies

I1 and I2 pointed out the requirement to set up a plan for DevOps adoption, as
well as knowledge acquisition and dissemination in an integrated way for the
whole organization. So, there is a concern and focus on stimulating the
collaborative culture in the company, which is one of the biggest motivations
to put forward the DevOps initiative.

I3 highlighted the risks related to DevOps adoption and suggested strategies
to overcome them. For him, a very close plan should be taken, presenting a
history of broad DevOps use in the organization. Only sell the idea that
DevOps solve all the organization areas does not work. On the other hand, the
effective approach should present that the whole organization is already
adopting DevOps, there are already organization teams with experience in
DevOps, and there is evidence that many problems in projects were solved using
DevOps. He also considered that DevOps might be difficult and risky to adopt,
requiring a high level of adaptation.

I4 reported the strategy employed by his organization in DevOps adoption. He
said DevOps adoption resulted from a natural and spontaneous need of the
development team. There was a significant organization initiative for DevOps
adoption which concluded in the last year when a multidisciplinary working
group was created to handle many problems that should be solved with DevOps
adoption. There were sparse initiatives in some teams, but the main idea was
to turn it into a corporate endeavor. The working group’s goal was to make the
DevOps initiative officially in the company. An effective plan was devised,
which resulted in DevOps adoption in a bottom-up way.

##  4 Discussion

This section presents an analysis of the interviewee’s definitions related to
the ones found in the SLR, highlighting differences and similarities.

We generated a word cloud from the definitions gathered from the 28 documents
selected in the SLR depicted in Figure 4. The most relevant concepts resulting
from the interviews were: agility, collaboration, continuous delivery,
practices, process, improvements, and culture. These concepts and their
variations have high frequency when compared with the word cloud, which
demonstrates, in a general view, that literature and industry converge. On the
other hand, some items were mentioned a lot in the SLR but were not pointed
out by the interviewees, such as software, quality, automation, teams, change,
tools, principles, and approach.

The SLR brought 13 models or frameworks from which six are focused on DevOps
adoption, while the interviewees did not mention anyone with this focus. It
shows that the SLR finds are not commonly used on a large scale, or there is
no recognition of its applicability in practice.

The interviewees highlight the way for DevOps is particular to each
organization. However, we argue that a model or framework should be used since
they are defined from various previous experiences and industry reports.

Culture and automation principles are the most cited principles in SLR and by
the interviewees. However, several other principles are very relevant when
considering the SLR but were not mentioned by the interviewees, such as
Collaboration, Communication, and Agility.

Six practices were cited by the interviewees and found in the SLR: Continuous
Deployment, Continuous Improvement, Continuous Testing and Automation,
Automating Building, Infrastructure-as-Code, and Cloud Computing.

The majority of items reported by the interviewees were in the Difficulties
perspective, which may be an obstacle for the advance of DevOps adoption in
organizations.

Table 10 presents a comparison between the number of items found in SLR and
the Case Study for the eight identified perspectives. Table 11 presents a
comparison of the reinforced items (i.e., appeared in SLR and Case Study) and
new items (i.e., emerged from the Case Study).

Since the SLR and Case Study are subjective processes, the presented numbers
may have significant variance. The results represent a snapshot in time, and
they are not deterministic, i.e., they are tight to the nature of an
interpretative process. So, we only compared and verified if there were
convergence considering the findings of both methods application. In this
case, from the analysis presented in Table 10 and Table 11, we may deduct that
there is a majority convergence among SLR and Case Study findings because
there was empirical evidence of common elements.

Table 10: Comparative SLR and Case Study | SLR |  | Case
---
Study
Concepts | 28 | 4
Models | 13 | 1
Principles | 15 | 2
Practices | 73 | 11
Difficulties | 40 | 31
Challenges | 52 | 13
Benefits | 70 | 21
Strategies | 99 | 21
Total | 390 | 104
Table 11: Case Study Items |  | Reinforced
---
Items
| New
---
Items
Concepts | 0 | 4
Models | 0 | 1
Principles | 2 | 0
Practices | 8 | 3
Difficulties | 24 | 7
Challenges | 11 | 2
Benefits | 16 | 5
Strategies | 14 | 7
Total | 75 | 29

##  5 Conclusions

This research aimed to elucidate the phenomenon of DevOps adoption in
Brazilian organizations that develop and holistically maintain the software.
For this, a multimethod approach was carried out with two methodological
research techniques. Firstly, a Systematic Literature Review to understand the
phenomenon, find the gaps and thus bring the main perspectives in their
nuances associated with the theme, thus bringing the academy’s view. In a
second step, a Case Study was carried out with 2 Brazilian companies, one
large and one small, to observe and empirically verify how the phenomenon of
DevOps adoption presented itself, thus allowing comparison and complementation
to what was found in the literature.

With the development of this research, it was possible to understand and
visualize the DevOps phenomenon from the following perspectives found in the
literature and sequentially applied in the industry: its most relevant
principles, the varied concepts and interpretations involved, the associated
practices, the problems faced, the current challenges, the benefits identified
and the strategies used. This research result brought a wide range of
characteristics and views, both in the literature and in the industry, on
DevOps manifestation in organizations.

The SLR brought 390 items, artifacts, or characteristics related to the
adoption of DevOps were identified. The case study reinforced or validated 75
items and revealed 29 new items, expanding the literature findings.

Literature reports that the DevOps initiative must be something top-down, with
support and sponsorship from top management to be successful in its adoption
Bucena and Kirikova (2017) Colomo-Palacios et al. (2018) Elberzhager et al.
(2017). However, in the case study, it was identified that the bottom-up
initiative proved to be fundamental for the successful DevOps adoption in one
of the companies. While confronting what was recommended in SLR, this fact
converges with the idea that DevOps came from the practical community and has
proven itself over time as something beneficial and transformative for
software engineering.

In short, it is possible to conclude that DevOps manifests itself in many
different ways and perspectives in organizations that develop software because
its adoption is something transformative for the entire company, involving
people, processes, and tools. Besides, it brings a robust cultural change, the
need for new skills, greater collaboration, and organizational restructuring.
It is not trivial, as DevOps adoption requires a series of requirements and a
very well-designed and structured plan to occur without trauma or at a high
cost. This is mainly due to the involved human factor because without people
being convinced, the journey can go wrong at all hierarchical levels.

Because it is a relatively new topic and comes from practice, associations
need to mature the idea well, discussing it internally before deciding on
DevOps adoption. There is no magic guide or formula ready for doing it, a very
particular journey for each company. It is pretty challenging to find the
ideal path that can connect people, adjust processes and adopt tools combined
and not necessarily in that order. In other words, it is a new way of working,
requiring a lot of collaboration between teams, support from top management,
motivation from both the company and employees, clarity about the objectives,
a well-structured plan, with phases, and participatory adoption of ideal tools
in the assembly of the pipeline, well-structured documents and processes and
continuous review for improvements.

Below is a list of possible future works to be considered from this research:

  * •

Use the Multivocal Literature Review methodology, according to the study of
Garousi et al. (2019), to systematically aggregate publications related to
Grey Literature, thus taking a stronger view of the industry and practical
community;

  * •

Seek generalization of results using a quantitative research approach, such as
a Survey to validate the perspectives raised in other development
environments;

  * •

Conduct new case studies, in organizations from different branches of
industry, in different countries, to seek and aggregate more cultural and
organizational contexts;

  * •

Apply new research focused on how the manifestations of the principles
influence DevOps adoption, with emphasis on culture and collaboration. There
is relevant research on the topic developed that can be used as a reference,
as Humble and Kim (2018);

  * •

Adapt or build a model or framework of best practices for adopting DevOps, in
addition to testing it in organizations, based on the results of this
research.

## References

  * Ebert et al. [2016] Christof Ebert, Gorka Gallardo, Josune Hernantes, and Nicolas Serrano.  Devops.  _Ieee Software_ , 33(3):94–100, 2016.
  * Kim et al. [2016] Gene Kim, Jez Humble, Patrick Debois, and John Willis.  The devops handbook: How to create world-class agility.  _Reliability, and Security in Technology Organizations_ , 2016.
  * Fitzgerald and Stol [2017] Brian Fitzgerald and Klaas-Jan Stol.  Continuous software engineering: A roadmap and agenda.  _Journal of Systems and Software_ , 123:176–189, 2017.
  * Wiedemann et al. [2019] Anna Wiedemann, Nicole Forsgren, Manuel Wiesche, Heiko Gewald, and Helmut Krcmar.  The devops phenomenon: An executive crash course.  _Queue_ , 17(2):93–112, 2019.
  * Dingsøyr and Lassenius [2016] Torgeir Dingsøyr and Casper Lassenius.  Emerging themes in agile software development: Introduction to the special section on continuous value delivery.  _Information and Software Technology_ , 77:56–60, 2016\.
  * Humble and Kim [2018] Jez Humble and Gene Kim.  _Accelerate: The science of lean software and devops: Building and scaling high performing technology organizations_.  IT Revolution, 2018.
  * Bucena and Kirikova [2017] Ineta Bucena and Marite Kirikova.  Simplifying the devops adoption process.  In _BIR Workshops_ , pages 1–15, 2017.
  * Smeds et al. [2015] Jens Smeds, Kristian Nybom, and Ivan Porres.  Devops: a definition and perceived adoption impediments.  In _International conference on agile software development_ , pages 166–177. Springer, 2015.
  * Erich et al. [2014] Floris Erich, Chintan Amrit, and Maya Daneva.  Cooperation between software development and operations: a literature review.  In _The 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ACM, Torino_ , 2014.
  * Wettinger et al. [2014] Johannes Wettinger, Uwe Breitenbücher, and Frank Leymann.  Devopslang–bridging the gap between development and operations.  In _European Conference on Service-Oriented and Cloud Computing_ , pages 108–122. Springer, 2014.
  * Nielsen et al. [2017] Pia Arentoft Nielsen, Till J Winkler, and Jacob Nørbjerg.  Closing the it development-operations gap: The devops knowledge sharing framework.  In _BIR Workshops_ , 2017.
  * Runeson et al. [2012] Per Runeson, Martin Host, Austen Rainer, and Bjorn Regnell.  _Case study research in software engineering: Guidelines and examples_.  John Wiley & Sons, 2012.
  * Wohlin [2014] Claes Wohlin.  Guidelines for snowballing in systematic literature studies and a replication in software engineering.  In _Proceedings of the 18th international conference on evaluation and assessment in software engineering_ , pages 1–10, 2014.
  * BARDlN [1977] Lawrence BARDlN.  Análise de conteúdo.  _Lisboa: edições_ , 70:225, 1977.
  * Crowe and Sheppard [2012] Michael Crowe and Lorraine Sheppard.  Mind mapping research methods.  _Quality & Quantity_, 46(5):1493–1504, 2012\.
  * Colomo-Palacios et al. [2018] Ricardo Colomo-Palacios, Eduardo Fernandes, Pedro Soto-Acosta, and Xabier Larrucea.  A case analysis of enabling continuous software deployment through knowledge management.  _International Journal of Information Management_ , 40:186–189, 2018.
  * Elberzhager et al. [2017] Frank Elberzhager, Taslim Arif, Matthias Naab, Inge Süß, and Sener Koban.  From agile development to devops: going towards faster releases at high quality–experiences from an industrial context.  In _International conference on software quality_ , pages 33–44. Springer, 2017.
  * Garousi et al. [2019] Vahid Garousi, Michael Felderer, and Mika V Mäntylä.  Guidelines for including grey literature and conducting multivocal literature reviews in software engineering.  _Information and Software Technology_ , 106:101–121, 2019\.


# Simultaneous observation of forward-backward attosecond photoelectron
holography

Hongchuan<EMAIL_ADDRESS>Hongmei Wu1, Huiqiao Wang2, Shengjun
Yue1,and Bitao<EMAIL_ADDRESS>1School of Nuclear Science and
Technology, Lanzhou University, Lanzhou 730000, China
2Institute of Modern Physics, Chinese Academy of Sciences, Lanzhou 730000,
China

###### Abstract

Photoelectron angular momentum distribution of $He^{+}$ driven by a few-cycle
laser is investigated numerically. We simultaneously observe two dominant
interference patterns with one shot of lasers by solving the 3D time-dependent
Schrodinger equation (TDSE). The analysis of a semiclassical model identifies
these two interference patterns as two kinds of photoelectron holography. The
interference pattern with $P_{z}>0$ is a kind of forward rescattering
holography, which comes from the interference between direct (reference) and
rescattered (signal) forward electrons ionized in the same quarter-cycle. The
interference pattern with $P_{z}<0$ is a kind of backward rescattering
holography, which comes from the interference between direct electron ionized
in the third quarter-cycle and rescattered backward electron ionized in the
first quarter-cycle. Moreover, we propose a method to distinguish this
backward rescattering holography and intracycle interference patterns of
direct electrons. This is an important step for dynamic imaging of molecular
structure and detecting electron in molecules on attosecond time scale by the
backward rescattering attosecond photonelectron holography.

###### pacs:

32.80.Wr, 33.60.+q, 61.05.jp

††preprint: APS/123-QED

In 1947, Gabor invented the holography [1] in which a coherent beam of light
or electron is split into a signal beam and a reference beam. The signal beam
scatters off the target and encodes its structure. When it recombines with the
reference beam, an interference pattern storing the spatial information of the
target is formed. Then the objects can be reconstructed by the interference
pattern. Recently, Huismans _et al._ applied the concept of holography to
strong-field laser ionization to record temporal and spatial information on
the atomic and molecular scale [2], in which a “forklike” structure is found
and recognized as a kind of forward rescattering holography. So far, the
backward rescattering holography has not been reported experimentally due to
small atomic scattering cross sections. It has been well known that the
backward rescattering holography can be used for dynamic imaging of molecular
structure [3, 4] and detecting electron motion in molecules or atoms on
attosecond time scale [5]. So it is very necessary for observing the backward
rescattering holography in experiment. Due to molecular ions with larger
rescattering cross sections, Bian $et$ $al.$ theoretically predicted that the
backward rescattering holography can be observed by using ${H}_{2}^{+}$[6].
Moreover, they also found that two kinds of forward and backward holography
patterns can be simultaneously observed by using the polar molecular ion
$HeH^{2+}$ with parallel orientation because of the preferential enhanced
ionization from one direction of the molecular axis [7]. Unfortunately, it is
still difficult to prepare the target of the molecular ions with perfect
orientation in current experimental conditions. Besides, the ground-state
$1s\sigma$ of the $HeH^{2+}$ is repulsive and unstable [8, 9]. These limit the
use of their scheme. In addition, the interference pattern (as shown in Fig.
5(d)) between the direct electron ionized in the third quarter-cycle and the
rescattered backward electron ionized in the first quarter-cycle is similar to
the intracycle interference patterns of direct electrons (as shown in Fig.
5(b)). Therefore, the interference pattern asserted as the back holography
pattern may come from the intracycle interference patterns of direct
electrons. To our best knowledge, how to distinguish these two kinds of
interference structures is still an open question.

In this work, we investigate the photoelectron angular momentum distribution
of $He^{+}$ driven by a few-cycle laser by solving the TDSE and semiclassical
model. It is found that two dominant holography patterns can be observed
simultaneously with one shot of lasers. By means of the semiclassical model,
we identified the interference pattern with $P_{z}<0$ as a kind of backward
rescattering holography, which comes from the interference between the direct
electron ionized in the third quarter-cycle and the rescattered backward
electron ionized in the first quarter-cycle.

In order to investigate the photoelectron angular momentum distribution, we
numerically solve the three-dimensional (3D) time-dependent Schrodinger
equation (TDSE) describing the interaction between the linearly polarized
laser field and the $He^{+}$ ion. The corresponding TDSE in atomic units
(a.u.) is written as

$\displaystyle i\frac{\partial}{\partial
t}\psi(\textbf{r},t)=[-\frac{\nabla^{2}}{2}-\frac{2}{r}+W(\textbf{r},t)]\psi(\textbf{r},t),$
(1)

where the interaction term in velocity gauge is defined as
$W(r,t)=-i\textbf{A}(t)\cdot\bigtriangledown$. Here, A(t) is the corresponding
vector potential of the laser pulse. The time-dependent wave function can be
obtained by solving the Eq. (1) in the spherical coordinate system using the
Crank-Nicolson method [10]. An absorbing potential is employed to avoid wave
function reflection on the grid edge [11, 12].

Figure 1: (Color online) Photoelectron angular momentum distribution of
$He^{+}$ calculated by the TDSE (a) and semiclassical model [(b) and (c)]. (b)
represents the interference where the reference electron is generated in the
same quarter-cycle, which (c) represents the interference where the reference
electron is generated in the third quarter-cycle.

Since a long-wavelength laser field isn’t a necessary condition to attosecond
photoelectron holography [14], we adopt a 532-nm laser pulse to reduce the
spread of the electron wavefunction in our simulation. The laser intensity is
chosen as $1.5\times 10^{15}W/cm^{2}$. The vector potential of the laser pulse
is given by $A(t)=E_{0}/\omega_{0}\sin^{2}(\pi t/\tau)\sin(\omega_{0}t)$, and
the laser polarization direction is along the $z$ direction. $\tau$ is the
total duration of the laser pulse, and is set as $5T_{0}$ ($T_{0}$ is the
optical cycle of the laser pulse). Figure 1(a) presents the photoelectron
angular momentum distribution of $He^{+}$ calculated by projecting the final
wavefunction onto plane waves at a time later than the end of the laser pulse.
One can clearly see that the photoelectron angular momentum distributions with
$P_{z}>0$ and $P_{z}<0$ are quite different since a few-cycle laser pulse is
used. In the region of $P_{z}>0$, the interference pattern resembles a “fork”,
which is similar to the results in Refs [2, 15]. In their works, the “fork”
structure is identified as a kind of forward rescattering photoelectron
holography. However, in the region of $P_{z}<0$, the interference pattern is a
semiring structure (downward curvature). Moreover, the width of the stripes
and the space between the stripes become larger as the momentum $P_{z}$
decreases from -0.5 to -1.5a.u.. For the sake of checking the accuracy of our
results, we also calculate the photoelectron angular momentum distribution by
projecting the numerical solution of the TDSE onto the

Figure 2: (Color online) Photoelectron angular momentum distribution of
$He^{+}$ calculated by projecting the numerical solution of the TDSE onto the
incoming Coulomb waves at the end time of the laser pulse.

incoming Coulomb waves at the end time of the laser pulse, which is shown in
Fig. 2. In the calculation, we use a grid with a maximum radius of
$r_{max}=2800a.u.$ in the radial direction and maximum number of partial waves
$L_{max}=35$. The grid space is 0.02a.u., and the time step is 0.015a.u.. It
is found that there is a good agreement between the two methods by comparing
with those results in Fig. 1(a). This implies that the results shown in Fig.
1(a) don’t come from the calcultaion error. In order to illustrate the
physical mechanism of these two kinds of interference patterns, we use the
semiclassical recollision model [15, 16], which has been proven to be
successful in interpreting forward rescattering photoelectron holography [2,
15]. In the calculation, we used the few-cycle laser pulse. The photoelectron
angular momentum distributions calculated by the semiclassical model are
presented in Figs. 1(b) and 1(c). Fig. 1(b) shows the interference pattern for
the case in Fig. 3(a), where both the signal (A) and reference (B) electrons
are generated in the same quarter-cycle. In this case, the signal electron (A)
is firstly ionized in the negative z direction, and is then turned around by
the laser field. So the velocity of the signal electron (A) is positive before
being rescattered. After being forward rescattered, the signal electron (A)
has a positive velocity. Finally, the signal (A) and reference (B) electrons
with the same final momentum will interfere with each other and form the
interference pattern shown in Fig. 1(b). From this figure, one can clearly see
the “forklike” interference pattern, which is in good agreement with the
pattern with $P_{z}>0$ shown in Fig. 1(a). Therefore, the “forklike”
interference pattern with $P_{z}>0$ in Fig. 1(a) comes from the interference
between direct (reference) and rescattered (signal) forward photoelectrons
ionized in the same quarter-cycle as shown in Fig. 3(a). Fig. 1(c) presents
the interference pattern for the case in Fig. 3(b), where the signal electron
(A) is ionized in the first quarter-cycle, and the reference electron (B) is
ionized in third quarter-cycle. In this case, the signal electron (A) is
firstly ionized in the negative $z$ direction, and is then turned around by
the laser field. So the velocity of the signal electron (A) is positive before
being rescattered. After being backward rescattered, the signal electron (A)
has a negative velocity. Finally, the signal (A) and reference (B) electrons
with the same final momentum will interfere with each other and form the
interference pattern shown in Fig. 1(c). It can be seen from the Fig. 1(c)
that the number of interference stripes with $P_{z}\in[-1.5,-0.5]a.u.$
predicted by the semiclassical model is 7. Moreover, the width of the stripes
and the space between the stripes calculated by the semiclassical model become
larger as the momentum $P_{z}$ decreases from $-0.5$ to $-1.5a.u.$. These
agree well with the TDSE results in Fig. 1(a). However, we can’t ensure that
the interference pattern with $P_{z}<0$ in Fig. 1(a) is caused by the
interference in Fig. 1(c) because the intracycle interference pattern of
direct electrons has also a similar structure [17, 18]. So far, it is still an
open question to distinguish these two kinds of structures.

Figure 3: (Color online) Schematic illustration of interference trajectories.
A is the rescattering channel, and B is the direct ionization channel.

As well known, the rescattering process is closely related to the Coulomb
potential of parent ion, so the interference patterns will be significantly
changed when a short-range potential is used if they are caused by the
rescattering process. However, for the interference of direct electrons, the
interference pattern is less sensitive to the Coulomb potential of parent ion.
Thus we investigate the Coulomb-tail effects to the photoelectron angular
momentum distribution in order to confirm that the interference patterns with
$P_{z}<0$ in Fig. 1(a) come from the interference in Fig. 3(b). In the
calculation, the potential function V(r) is instead with a short-range
potential $V_{s}(r)$. We choose

$\displaystyle V_{s}(r)=-(b+\frac{2.0}{r})exp(-r^{2}/s^{2}),$ (2)

where $s=1.6$ and $b=0.57$ to keep the ground-state energy unchanged.

Figure 4:  (Color online) Photoelectron angular momentum distribution with
$P_{z}>0$ of $He^{+}$ calculated by the (a) TDSE with a short-range potential
$V_{s}(r)$, (c) the full TDSE, and semiclassical model [(b) and (d)]. (b)
represents the interference between direct electrons generated in first and
second quarter-cycle. (d) represents the interference where the reference
electron is generated in the same quarter-cycle.

In order to confirm above conclusion, we firstly compare the photoelectron
angular momentum distribution with $P_{z}>0$ of $He^{+}$ calculated using the
following theoretical models: (a) solving the TDSE with a short-range
potential, (b) using a semiclassical model which describes the interference
between direct electrons generated in first and second quarter-cycle as shown
in Fig. 3(c), (c) solving the TDSE with the actual potential, (d) using a
semiclassical model which describes the interference where the reference
electron is generated in the same quarter-cycle as shown in Fig. 3(a). It is
clear that there are obvious differences in the photoelectron angular momentum
distributions in Figs. 4(a) and 4(c). In Fig. 4(c), one can see a “fork”
structure, which has been identified as a kind of forward rescattering
photoelectron holography as shown in Fig. 4(d). When the short-range potential
is used, as shown in Fig. 4(a), the “fork” structure washes out, and a
semiring structure (upward curvature) appears. Fig. 4(b) presents the
interference pattern of the direct electrons ionized in first and second
quarter-cycle as shown in Fig. 3(c). It is seen that the number of
interference stripes with $P_{z}\in[-1.5,-0.5]a.u.$ predicted by the
semiclassical model is 8, which is in good agreement with those in Fig. 4(a).
Hence, we conclude that the semiring structure (upward curvature) in Fig. 4(a)
comes from the intracycle inference of direct electrons in Fig. 3(c).

Figure 5: (Color online) Photoelectron angular momentum distribution with
$P_{z}<0$ of $He^{+}$ calculated by the (a) TDSE with with a short-range
potential $V_{s}(r)$, (c) the full TDSE, and semiclassical model [(b) and
(d)]. (b) represents the interference between direct electrons generated in
third and fourth quarter-cycle. (d) represents the case where the reference
electron is generated in the third quarter-cycle.

Next, we investigate the Coulomb-tail effects to the interference pattern with
$P_{z}<0$ in Fig. 1(a). Likewise, we compare the photoelectron angular
momentum distribution with $P_{z}<0$ of $He^{+}$ calculated using the
following theoretical models: (a) solving the TDSE with a short-range
potential, (b) using a semiclassical model which describes the interference
between direct electrons generated in third and fourth quarter-cycle as shown
in Fig. 3(d), (c) solving the TDSE with the actual potential, (d) using a
semiclassical model which describes the interference where the reference
electron is generated in the third quarter-cycle as shown in Fig. 3(b). At
first glance, the photoelectron angular momentum distributions in Figs. 5(a)
and 5(c) appear to be fairly similar. Both of them show a semiring structure
(downward curvature). Moreover, the width of the stripes and the space between
the stripes become larger as the momentum $P_{z}$ decreases from $-0.5$ to
$-1.5a.u.$. However, a closer look reveals that the number and location of
stripes are quite different in the two pictures. In Fig. 5(a), the number of
interference stripes with $P_{z}\in[-1.5,-0.5]a.u.$ is 8, which is in good
agreement with the results predicted by the semiclassical model in Fig. 5(b),
in which the interference pattern is produced by the direct electrons ionized
in third and fourth quarter-cycle as shown in Fig. 3(d). However, in Fig.
5(c), the number of interference stripes with $P_{z}\in[-1.5,-0.5]a.u.$ is 7
which is in good agreement with the results predicted by semiclassical model
in Fig. 5(d), which describes the interference where the reference electron is
generated in the third quarter-cycle as shown in Fig. 3(b). Moreover, it is
also noted that the curvature of the semiring structure in Fig. 5(c) is larger
than that in Fig. 5(a), which is also observed in Figs. 5(b) and 5(d). In
addition, it is worth mentioning that the intracycle interference patterns of
direct electrons can be shifted by the Coulomb tail. Fortunately, the number
of the interference stripes becomes sparse when the Coulomb tail is cut off as
shown in Fig. 5 of Ref. [18], which is opposite with our results. Therefore,
we conclude that the semiring structure (downward curvature) in Fig. 1(a)
comes from the interference between direct electron ionized in the third
quarter-cycle and rescattered backward electron ionized in the first quarter-
cycle as shown in Fig. 3(b).

In summary, we propose a way of simultaneously observing two kinds of
photoelectron holography. The forward rescattering holography comes from the
interference between direct and rescattered forward photoelectrons ionized in
the same quarter-cycle, which appears in the region of $P_{z}>0$. The backward
rescattering holography comes from the interference between direct
photoelectron ionized in the third quarter-cycle and rescattered backward
photoelectron ionized in the first quarter-cycle, which appears in the region
of $P_{z}<0$. Moreover, we also propose a method to distinguish the backward
rescatterring holography and the intracycle interference pattern of direct
electrons. The laser parameters in this work are experimentally accessible
currently. It is predicted that the backward rescattering photoelectron
holography can be observed in experiment by in the near future. Finally, we
would like to remind that this kind of backward rescattering holography
pattern must be carefully confirmed before it is used to dynamic imaging of
molecular structure and detecting electron in molecules on attosecond time
scale.

## Acknowledgement

This work was supported by the National Natural Science Foundation of China
(Grants Nos. 11404153, No. 11135002, No. 11175076, No. 11475076, and No.
11405077).

## References

  * (1) D. Gabor, Nature (London) 161, 777 (1948).
  * (2) Y. Huismans A. Rouz$\acute{e}$e, A. Gijsbertsen, J. H. Jungmann, A. S. Smolkowska, P. S. W. M. Logman, F. L$\acute{e}$pine, C. Cauchy, S. Zamith, T. Marchenko, J. M. Bakker, G. Berden, B. Redlich, A. F. G. van der Meer, H. G. Muller, W. Vermin, K. J. Schafer, M. Spanner, M. Yu. Ivanov, O. Smirnova, D. Bauer, S. V. Popruzhenko, M. J. J. Vrakking, Science 331, 61 (2010).
  * (3) T. Zuo, A. D. Bandrauk, and P. B. Corkum, Chem. Phys. Lett. 259, 313 (1996).
  * (4) A. D. Bandrauk and M. Ivanov, Quantum Dynamic Imaging (Springer, New York, 2011).
  * (5) H. C. Shao and A. F. Starace, Phys. Rev. Lett. 105, 263201 (2010).
  * (6) X.-B. Bian and A. D. Bandrauk, Phys. Rev. Lett. 108, 263003 (2012).
  * (7) X.-B. Bian and A. D. Bandrauk, Phys. Rev. A 89, 033423 (2014).
  * (8) G. Lagmago Kamta and A. D. Bandrauk, Phys. Rev. A 76, 053409 (2007)
  * (9) I. Ben-Itzhak, I. Gertner, O. Heber, and B. Rosner, Phys. Rev. Lett. 71, 1347 (1993).
  * (10) J. Crank and P. Nicolson, Proc. Cambridge Philos. Soc. 43, 50 (1947).
  * (11) T. Gonzale-Lezana, E. J. Rackham, and D. E. Manolopoulos, J. Chem. Phys. 120, 2247 (2004).
  * (12) D. E. Manolopoulos, J. Chem. Phys. 117, 9552 (2002).
  * (13) T. Marchenko, Y. Huismans, K. J. Schafer, and M. J. J. Vrakking, Phys. Rev. A 84, 053427 (2011).
  * (14) X.-B. Bian, Y. Huismans, O. Smirnova, K.-J Yuan, M. J. J. Vrakking, and A. D. Bandrauk, Phys. Rev. A 84, 043420 (2011).
  * (15) P. B. Corkum, Phys. Rev. Lett. 71, 1994 (1993).
  * (16) X. Xie, S. Roither, D. Kartashov, E. Persson, D. G. Arbo, L. Zhang, S. Grafe, M. S. Schoffler, J. Burgdorfer, A. Baltuska, and M. Kitzler, Phys. Rev. Lett. 108, 193004 (2012).
  * (17) D. G. Arbo, K. L. Ishikawa, K. Schiessl, E. Persson, and J. Burgdorfer, Phys. Rev. A 81, 021403 (2010).