Investigating Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects

Slides for the talk on "Investigating Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects" at the International Conference on Evaluation and Assessment in Software Engineering (EASE) conference 2023.

https://conf.researchr.org/details/ease-2023/ease-2023-research/2/Investigating-Software-Engineering-Artifacts-in-DevOps-Through-the-Lens-of-Boundary-O

Christoph Matthies, Robert Heinrich, and Rebekka Wohlrab. 2023. "Investigating Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects". In Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering (EASE '23). Association for Computing Machinery, New York, NY, USA, 12–21. https://doi.org/10.1145/3593434.3593441

Transcript

1. Hasso Plattner Institute, University of Potsdam, Germany christoph.matthies@hpi.de @chrisma0 Investigating Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects Christoph Matthies, Robert Heinrich, Rebekka Wohlrab June 2023 Oulu https://conf.researchr.org/home/ease-2023
2. Boundary Objects 2 A theory from sociology applied to engineering organizations “ [...] have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translation [SG89] ” [SG89] S. L. Star & J. R. Griesemer. 1989. Institutional Ecology, “Translations and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology”, 1907-39. Social Studies of Science 19, 3 (aug 1989), 387–420
3. Boundary Objects 3 A real-world example (also used to explain in interviews)
4. Methodology ▪ Exploratory multiple case study [Eas+08] □ 9 study sites, 12 interviews with industry practitioners □ Median 9.5 years of work experience 4 [Eas+08] S. Easterbrook, J. Singer, M.-A. Storey & D. Damian. 2008. “Selecting empirical methods for software engineering research”. In Guide to advanced empirical software engineering. 285–311. 1. Collaboration practices, coordination of dev and ops roles, significance of engineering artifacts 2. Introduction of Boundary Object concept 3. Reflection on concept in daily work ▪ Semi-Structured Interviews
5. Boundary Objects 5 A real-world example (also used to explain in interviews)
6. Research Questions RQ1 Categories of artifacts employed as Boundary Objects? 6 Areas of inquiry within the research paper RQ2 Which stakeholders are involved? RQ3 Where do practitioners see concerns? RQ4 What attributes influence Boundary Object relevance?
7. Research Questions RQ1 Categories of artifacts employed as Boundary Objects? 7 Presented in this talk RQ4 What attributes influence Boundary Object relevance?
8. DevOps Boundary Objects 8 Categories of Boundary Objects identified by study participants Dev. Ops.
9. DevOps Boundary Objects 9 Examples of Boundary Objects identified by study participants Dev. Ops. ▪ Sprint Backlog Entry ▪ Pseudo-Code ▪ Metrics Dashboard ▪ Software Log File ▪ Wiki Page ▪ Code Review Comment ▪ Checklists with steps ▪ Operations Runbooks
10. Attributes of Boundary Objects 10 Seven attributes that influenced perceptions of relevance DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level of Automation Structured- ness Lifespan Number of Stakeholders
11. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 11 Relative to other objects in a given context, how frequent are updates? DevOps Boundary Objects Frequency of Change ▪ Notifications on updates ▪ Obtained info outdated quickly ▪ “a map might be a good Boundary Object because its speed of change is manageable” [Interview K]
12. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 12 How many connections to other engineering artifacts are there? DevOps Boundary Objects Connected- ness ▪ Higher degree of detail without duplication ▪ Higher effort to fully explore knowledge ▪ Maintenance of links
13. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 13 To what degree will the performance degrade if the object is unavailable? DevOps Boundary Objects Criticality ▪ Described by “how many people can’t work” ▪ Consequences of inadequate/missing quality (legal reqs): “They will literally send you to jail” [Interview K]
14. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 14 How much repeated manual effort is required to update the object? ▪ Automate as much as possible (in theory, less in practice) ▪ “If communication is ad-hoc, it is slow, get rid of it and automate” [Interview F] ▪ Monitoring and alerting of stakeholders DevOps Boundary Objects Level of Automation
15. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 15 To what degree does the object follow set standards? ▪ Highly dependent on context ▪ Reports via email vs. Jira task management ▪ Structure enables faster understanding DevOps Boundary Objects Structured- ness
16. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 16 When is the object created and for how long is it relevant? ▪ May be used only for a specific development phase ▪ Archived or set as read-only ▪ May require data only available later, e.g. metrics dashboards DevOps Boundary Objects Lifespan
17. DevOps Boundary Objects Frequency of Change Connected- ness Criticality Level of Automation Structured- ness Lifespan Number of Stakeholders Attributes of Boundary Objects 17 How many stakeholders derive value from the object during its lifespan? ▪ Includes non-technical roles e.g. Product Management ▪ “If a microservice is to be monetized, the marketing team must interact” [Interview E] DevOps Boundary Objects Number of Stakeholders
18. Conclusion 18 ▪ Previously identified Boundary Objects present in DevOps contexts □ E.g. checklists in medicine or software security [Gil+03] □ No single central coordination objects ▪ Starting points for collaboration and connecting stakeholders [Gil+03] D.P. Gilliam, T.L. Wolfe, J.S. Sherif, and M. Bishop. 2003. “Software Security Checklist for the Software Life Cycle”. In Twelfth IEEE International Workshops on Enabling Technologies (WET 2003). 243–248.
19. Conclusion 19 ▪ Object attributes inform knowledge management □ E.g. Object with two stakeholders, low criticality, and lacking automation → might not be worth maintenance overhead ▪ “management of the data generated by the [DevOps] toolchain is still undervalued” [Col+21] in practice [Col+21] A. Colantoni, A. Garmendia, L. Berardinelli, M. Wimmer, and J. Brauer. 2021. “Leveraging Model-Driven Technologies for JSON Artefacts”. In 24th Int. Conference on Model Driven Engineering Languages and Systems. 250–260.
20. Conclusion 20 “the more an agile team operates according to DevOps, the more it benefits from its artifacts [Fors+20] ” [Fors+20] M. Forsberg Lie, M. Sánchez-Gordón, and R. Colomo-Palacios. 2020. “DevOps in an ISO 13485 Regulated Environment”. In 14th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. 1–11. but the more it needs to consciously manage the Boundary Objects that facilitate collaboration
21. Summary 21
22. Image Sources 22 In order of appearance ▪ area by Nithinan Tatah from Noun Project (CCBY3.0) ▪ Document by Liberus from Noun Project (CCBY3.0) ▪ Document by DinosoftLab from Noun Project (CCBY3.0) ▪ Definition by Eko Purnomo from Noun Project (CCBY3.0) ▪ explain by Iconographer from Noun Project (CCBY3.0) ▪ Hiking Map (hiking-map_926245) by sclance.com ▪ interview by Mutualism from Noun Project (CCBY3.0) ▪ Architectural Design software diagram by heinzhafner.de ▪ Question by Alzam from Noun Project (CCBY3.0) ▪ conclusion by WEBTECHOPS LLP from Noun Project (CCBY3.0)