Software Architecture Decision-Making Practices and Challenges: An Industrial Case Study

Sandun Dasanayake, Jouni Markkula, Sanja Aaramaa, Markku OivoM-Group, University of Oulu29.09.2015

Software Architecture Decision-Making Practices and Challenges: An Industrial Case Study

24th Australasian Software Engineering Conference – ASWEC’15

Preprint of the Article: http://goo.gl/7Ay6nE

Contents

• Case Study in Brief• Research Questions• Results• Discussion• Conclusions• Future work

Case Study in Brief

• Supported by MERgE Project– http://www.merge-project.eu

• Conducted in 3 SMEs in Europe– Similar size– Focused on different business areas

• Interviewed 10 practitioners involved in SW architecture decision making– Titles: SW Engineers to Product Leads– Experience: 2 to 24 years– Each semi-structured Interview last 1.5h – 2h

Research Questions

• RQ1: How do the software architects make architecture decisions?

• RQ2: What are the reasons for using the current architecture decision-making approach?

• RQ3: What challenges are associated with current architecture decision-making approach?

• RQ4: Which areas can be improved in order to make better architecture decisions?

Team Level Decision Making (RQ 1)

• Not formal, but structured• All the team members are involved• Mostly consensus – If not, architect takes the final

decision• 3 main approaches to come up with a decision

Using a pre-defined criteria

By analyzing pros and cons

Selecting first satisfactory choice

Individual Decision Making (RQ 1)

Experience

Intuition

Reuse

Methods

External experts

Prototyping

Why Use Current Practices? (RQ2)

Challenges of Current Approach (RQ3)

• Missing a (possibly) better solution• Revisiting design rationale• Integrating new members• Improper documentation• Issues with customer communication• Knowledge gap between the engineers• Finding necessary resources• Lack of proper tools

Improvement Opportunities (RQ4)

• Lightweight technique or tool to guide• Improved documentation• Efficient information sharing• Keeping track of design decisions and rationale• Making decision-making agiler

Discussion (1/2)

• Team level decision-making methods resembles existing decision-making techniques.– Using a pre-defined criteria : Quality-Drive Decision Support

Method– By analyzing pros and cons: The Cost Benefit Analysis Method– Selecting the first satisfactory choice : Recognition Primed

Decision Model

• Majority of the identified challenges can be addressed by following activities that improve architecture knowledge management

[1] M. Svahnberg, C. Wohlin, L. Lundberg, and M. Mattsson, "A quality- driven decision-support method for identifying software architecture candidates," International Journal of Software Engineering and Knowledge Engineering, vol. 13, no. 5, pp. 547–573, 2003[2] R. Kazman, J. Asundi, and M. Klein, "Quantifying the costs and benefits of architectural decisions," in Proceedings of the 23rd International Conference on Software Engineering, 2001, pp. 297–306. [3] G. Klein and D. Klinger, "Naturalistic decision making," Gateway, vol. 2, no. 1, pp. 16–19, 1991.

Discussion (2/2)Identified KM activities mapped in to SECI model

[4] I. Nonaka and H. Takeuchi, The Knowledge-Creating Company, 1st ed. Oxford University Press, 1995.

E

xplic

it

from

Taci

t

Tacit to Explicit

Pair designDesign reviewsSwapping tasksCustomer interactionsInformal discussions

MeetingsBrainstormingRetrospectives

Prototyping Design documentsWiki/ intranetInternal doc servers

Conclusions• Team decision-making – informal but structured• Individual decision-making – heavily based on

personal characteristics• Several challenges are recognized Regardless, practitioners satisfied• Knowledge Management is recognized as a key improvement area

Researcher

Software Practitioners

Future Work

• A similar study is already been conducted in a large enterprise

• Investigate possible solutions to overcome identified challenges

THANK YOU!More information:

sandun.dasanayake@oulu.fi