SPM10 SPM and Software Architecture

Software Product Management Software Architecture

Lecture 10

Garm Lucassen

Sjaak Brinkkemper

24 September 2014

Relationship agenda

• Software Architecture definition & motivation

• The Software Architect

• SPM and SA processes

• In practice

• Improving the collaboration

• Future vision: continuous architecting

• Assignment

2

Software Architecture

• Software Architecture is the set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both (Clements et al., 2010)

• Industry refers to “software architecture” for three things:

1. The (conceptual) high level structure of software (instantiation)

2. Discipline of creating a high level structure

3. Documentation of the high level structure

The Software Product Architect is responsible for creating and maintaining the software product’s architectural structure and integrity

In this lecture we focus on how Software Product Management and Software Architecture relate.

3

Motivation

• Helferich, Schmid and Herzwurm in 2006: SPM alignment with SA is critical to the success of a software product line!

– Reuse potential is lost

– Major product opportunities missed

• Fricker (2012): As of yet it is unclear how effective business-socio-technical congruence is achieved and what its empirically grounded business case is

4

Motivation




• Fricker (2012):

5

Motivation




• Fricker (2012): that’s cool but no one really knows how, let alone whether it’s really worth the effort

6

Motivation

• Therefore… study software product manager interaction with software architect

– What processes should you participate in together?

– What are your reciprocal contributions to one another?

– How can you improve your relationship?

7

Relationship agenda




• In practice



• Assignment

8

The Software Architect

• In Software Producing Organizations (SPOs)

– Software architect is a loosely defined role

– Typically early employee

– “First among equals”

– “Knows everything, but there is no documentation.”

• Has four primary tasks (Taylor et al., 2010)

1. Developing project strategy

2. Designing systems

3. Communicating with stakeholders

4. Being a leader

9


• Over time software architecture forms by making Architectural Design Decisions (ADDs) based on project context:

– Stakeholder requirements

– History of previous ADDs

• ADDs for architecturally significant requirements beforehand

• All others on an ad-hoc basis

• Agile?

10


• Creates architecture documentation for multiple purposes (Clements et al., 2010)

– Design

– Analyze

– Communicate

– Educate

• Architecture descriptions are inherently multi-viewed (IEEE Standard 1471-200)

11

Relationship agenda




• In practice



• Assignment

12

SPM and SA processes

• SPM is closely linked to requirements engineering (Ebert, 2007)

• SA demands good requirements engineering

13

Twin Peaks of Requirements and Architecture (Nuseibeh, 2001)

SPM and SA processes

SPM Goals (Ebert, 2007) SA Goals (Taylor, 2010)

Creating a winning product Developing project strategy

Conquering markets and growing market share

Designing systems

Delivering value to customers Communicating with stakeholders

Being a leader

14

Requirements are central to both stakeholders

• Satisfy customer requirements to deliver value and create product success

Demands selecting the right requirements

Enabling developers to implements them in the right way

Impact on one another’s goals

• Software architect contributes to

1. creating a winning product

2. delivering value to customers

• Product quality depends on architect’s success at

1. Developing project strategy

2. Designing systems

• However, impact of a successful software architect in comparison to less successful is unknown…

15


• Product manager contributes to developing project strategy

– Software architects formulate adequate technical solutions for any requirement

– Solution might be sub-optimal for product context (Taylor et al., 2010)

– Quality Attributes vary per feature

16


• Product manager is the interface for communicating with external stakeholders

– Taylor notes that software architects are in frequent contact with customers and users

– Impossible for SPOs. Large number and widely varying customers and users

– Instead, product manager is gatekeeper

17

Reciprocal Contributions Model

18

Lucassen et al., 2014

RCM-A1: Product requirement

• A product requirement is a requirement to be covered by future product releases described in the company’s own terminology and context.

RCM-A2: Requirement feedback

• Architect reviews the product requirements

• And gives feedback

– Constraints

– Grouping

– Dependencies

– Ask for requirement details

– Technical impact

20

“This requirement necessitates first implementing NGF-137”

“We need to split this requirement into a client and server requirement”


21


Requirement Refinement, identification

and organizing

RCM-A3: Architectural Product Knowledge

• Product manager needs architectural input to

– Identify technical debt

– Understand technical details of the product

– Understand opportunities of new technology

– Create roadmaps

• “HTML5 video is cool. Maybe we should replace our flash player?”

• “We’re still on Ruby on Rails 2.3.2. We need to upgrade now or run into huge problems in the (near) future”

22


23


Requirements gathering, input for

roadmapping

RCM-A4: Release definition

• To be written by Product Manager

– Co-authors: Architect & Marketing

• Scope

– Whole product release

– Only for major and minor releases; not for bug fixes

• Content

– Major theme(s) of the release

– Listing of product requirements to be incorporated in the next release (copied labels from RDB)

– Critical dependencies between product requirements

– Distributed ownership of envisaged work

– Planned release date

RCM-A5: Product context

• Alongside the release definition

– Enables autonomous decision making

– Understand reasoning behind feature (why)

– Prevents mis-implementation

• Requires extra effort now

• Eventually leads to better quality and cheaper development

• “We want the data structure for the questionnaire module to support all imagineable question types. Although we focus on strictly likert and multiple choice now, we intend to expand in the near future”

25


26


Product context

clarification

RCM-A6: Architectural Design Decisions

• Choices that shape your product

• Includes the rationale

• Set of ADDs leads to the architecture of the product

• And thus ultimately deliver value

• “For the time being we keep the Pre-payment module within Ticket Sales. From Release 4.0 on it will be moved to Payment.”

27

Relationship agenda




• In practice



• Assignment

28

SPM & SA Collaborative Processes

• Common collaborative processes:

– Requirements refinement

– Requirements gathering

– Product roadmapping

– Requirements prioritization

• Expected, but unconfirmed:

– Product context clarification

• Others:

– External stakeholder communication

– Requirements organization and identification?

29

Common Indirect Unconfirmed

Requirements gathering Requirements identification

Product context clarification

Requirements prioritization

Requirements organization

Requirements refinement

Product roadmapping

SPM & SA collaborative processes

+ Requirements Refinement

30

Product Context Clarification ?

• Transferring product context is not important

• Yet, software architects have deep contextual knowledge:

– Software architect employee before product manager

– Contextual knowledge grows organically

• However…

– Product context, markets, technology and customers change

31

Requirements Gathering

• Software architect is a unique internal stakeholder

– Technical debt

– Formulate requirements for critical deficiencies

• Even for technically strong product managers

“Gathering requirements from the software architect is our most important collaborative process. Due to my functional

focus, I no longer notice where code quality is degrading and overdue maintenance is growing”

32

Requirements Gathering

• Typically a maintenance meeting every other week

– Software architect presents problem areas

– Product manager shares business perspective

– Go or no go on maintenance effort

• Unnecessary if software architect has strong product context awareness

33

Requirements Refinement

• Virtually all product manager refine requirements with software architect

• Not included in SPMCM

• Approach as described in Vlaanderen et al. (2011) is excellent, but uncommon

• Simple approach

– SPM creates high level definitions for requirements

– SPM coordinates and supports dev team in (bi-)weekly refinement meeting

34

Requirements Refinement Meeting

• Product manager

– Answers development questions

– Validates development’s interpretation of his work

– Sometimes assists in dependency linking (organizing)

• Conveying WHY we are developing a feature is imperative

– Enables developers to:

• Autonomously answer questions

• Prevents additional information requests

• Prevents incorrectly implemented features

35

Requirements Prioritization & Product Roadmapping

• Half of product managers involve software architect in prioritization and roadmapping

• Software architect complements product manager’s technical expertise

• Product manager makes actual decisions

• Less relevant when product manager is technically strong

36

Relationship agenda




• In practice



• Assignment

37

Improving the collaboration

• Virtually no tools/methods available

• Software Architecture Documentation?

• Shared architectural views improves:

– people alignment

– communication clarity

• But SPOs refuse to create meticulous architectural models

– Errors in models lead to wrong decisions

– “No documentation is better than outdated and thus wrong documentation”

38

What can we do?

• Rely on drawing incidental models?

– Forgoes educational and analysis benefits

• Define a company-wide approach:

– Utilize a hybrid functional/technical view

– Agree on a level of detail that both stakeholders can work with

– Document your views in one, community accessible place

– Adhere to a strict step-wise approach like the Accurate Architectural Models Approach

39

AAMA

40

This is still kind of primitive…

Relationship agenda




• In practice



• Assignment

41

Continuous Architecting (vision)

42

Requirements and Architecting on a Video Wall

43

Assignment

• Case study on stakeholder involvement during requirements management and roadmapping

• Focus is on mutual information exchange between product manager and software architect

• Semi-structured interview

– We provide questions

– But you should ask follow-up questions

44

Assignment

• Following four goals:

1. To describe the product manager’s requirements management processes including requirements gathering,

requirements identification, requirements organization and requirements refinement.

2. To describe the product manager's roadmapping processes.

3. To relate the Reciprocal Contributions Model (Lucassen,

2014) to your company’s situation, explaining which artifacts and activities are present and absent.

4. Formulate advice to improve the company's requirements

management and roadmapping processes.

45

Assignment

• 7 steps:

1. Introduce the research goals

2. Explain the interview structure

3. Ask sufficient questions to write a report on the Requirements Management & Roadmapping subjects below

4. Introduce the SPM & SA Reciprocal Contributions Model

5. Discuss the SPM & SA Reciprocal Contributions Model with the interviewee

6. Ask if the interviewee has any questions

7. Invite the interviewee to the Industry Session on Friday October 31

46

Assignment

• Available on website

– Outline case study report (approx 4500 words)

– Suggested Questions

• Not all questions are going to be relevant

• Expected to put more emphasis on some questions/sections than others

47

http://mspm2014.weebly.com/assignment-d---spm--sa-collaboration.html

SPMCM

48


49

Questions?

50

References

51

SPM10 SPM and Software Architecture

Education

software architectin

software product line

software elements

successful software

product successdemands

product requirementsand

product context taylor

future product releases