An Empirical Study on Collaborative Architecture Decision Making in Software Teams - ECSA 2016
European Conference on Software Architecture 2016 - Architecture decision making is considered one of the most challenging cognitive tasks in software development. The objective of this study is to explore the state of the practice of architecture decision making in software teams, including the role of the architect and the associated challenges. An exploratory case study was conducted in a large software company in Europe and fifteen software architects were interviewed as the primary method of data collection. The results reveal that the majority of software teams make architecture decisions collaboratively. Especially, the consultative decisionmaking style is preferred as it helps to make decisions efficiently while taking the opinions of the team members into consideration. It is observed that most of the software architects maintain a close relationship with the software teams. Several organisational, process and human related challenges and their impact on architecture decision-making are also identified.
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (16)
Similaire à An Empirical Study on Collaborative Architecture Decision Making in Software Teams - ECSA 2016
Similaire à An Empirical Study on Collaborative Architecture Decision Making in Software Teams - ECSA 2016 (20)
Dernier
Dernier (20)
An Empirical Study on Collaborative Architecture Decision Making in Software Teams - ECSA 2016
- 1. AN EMPIRICAL STUDY ON COLLABORATIVE ARCHITECTURE DECISION MAKING IN SOFTWARE TEAMS Sandun Dasanayake, Jouni Markkula, Sanja Aaramaa, Markku Oivo M3S – Empirical Software Engineering Research Group, university of Oulu, Finland
- 2. MOTIVATION • Rapid changes in SW development –Lean and agile principles –Global software development teams –Startup culture • Need of more empirical studies • Use knowledge from other areas
- 3. RESEARCH QUESTIONS • RQ1. How do software teams make architecture decisions? • RQ2. What are the challenges in architecture decision making in software teams?
- 4. THE CASE The case company provides software products and services to the consumer market, enterprise customers and third- party service providers. The company has around 1000 employees and has been in the business for several decades. It operates in a dynamic business domain, and its business history shows that it is keen on embracing new technologies.
- 5. DATA COLLECTION • 15 interviewees • Act as architects in their teams • Belong to 5 different units • Team size: 4 – 8 • Distributed in 3 sites • Each interview 1.5 hours
- 6. ARCH. DECISION MAKING – COMPANY LEVEL
- 7. DECISION MAKING – TEAM LEVEL (1/2) Decision Style Decision Maker Solution Origin Participation SW Team Architect Authoritative Architect Architect Passive Active Persuasive Architect Architect Active Active Consultative Architect Shared Active Active Consensus Shared Shared Active Active Delegative SW Team SW Team Active Passive
- 8. DECISION MAKING – TEAM LEVEL (2/2)
- 9. KEY TAKEAWAYS • There is no “one type fits all” • Teams prefers to reach consensus, but have to avoid deadlocks • Consultative decision making balances both aspects • It also provides decision ownership / responsibility • Majority view architecture steering groups as useful, but their view on technology unit is negative
- 10. CHALLENGES Category Challenge Impact on Architecture DM Organisational Inter team dependencies Increased complexity Change of personnel Loss of architecture knowledge Imposed technical constraints Limit potential solutions Globally distributed teams Lack of involvement Lack of a common tool chain Difficult to collaborate Process Inadequate preparation time Low quality decisions Dynamic requirements Short term decisions Requirement ambiguity Unclear decision goals Improper documentation Missing design rationale Human Clash of personalities Lengthy decision sessions / deadlocks Passive participation Limited view points
- 11. “… we have been doing these architecture decisions in several different ways in the past. We used to have this really strict architect guy who was just writing specifications and not actually doing anything …” ROLE OF THE ARCHITECT
- 12. “… but our company moved away from that direction quite a long time. So we have been intentionally trying to break the architect idea ...”
- 13. “… Then, about a year ago we slightly reversed on that decision. We’re again moving towards the direction where there are architects because someone then realized that hey, somebody still has to decide stuff …”
- 14. “But I don’t think it’s kind of the same kind of hard architect position as it was before, it’s more like a soft thing where they are kind of supposed to be more mediators where they don’t really decide, they just facilitate other people deciding”