AN EMPIRICAL STUDY ON COLLABORATIVE ARCHITECTURE DECISION

MAKING IN SOFTWARE TEAMS

Sandun Dasanayake, Jouni Markkula, Sanja Aaramaa, Markku OivoM3S – Empirical Software Engineering Research Group, university of Oulu, Finland

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

RESEARCH QUESTIONS

• RQ1. How do software teams make architecture decisions?

• RQ2. What are the challenges in architecture decision making in software teams?

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.

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

ARCH. DECISION MAKING – COMPANY LEVEL

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

DECISION MAKING – TEAM LEVEL (2/2)

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

CHALLENGESCategory Challenge Impact on Architecture DMOrganisational 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 collaborateProcess Inadequate preparation time Low quality decisions Dynamic requirements Short term decisions Requirement ambiguity Unclear decision goals Improper documentation Missing design rationaleHuman Clash of personalities Lengthy decision sessions / deadlocks Passive participation Limited view points

“… 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

“… but our company moved away from that direction quite a long time. So we have been intentionally trying to break the architect idea ...”

“… 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 …”

“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”

dasanayake.com - @sandundasa