- The document discusses software product lines as an approach to developing multiple related software products. It compares product lines to alternative approaches like reference architectures and one-size-fits-all. - Product lines involve explicitly managing variability between products through variation analysis, variation points in the architecture, and a variation guide. This is contrasted with opportunistic reuse without explicit variation management. - The key steps are to analyze variability in the problem domain, design the architecture around common and variable parts, and develop assets and variants using domain and application engineering. Non-technical challenges around organization must also be addressed.

1. software product lines
aka:
product line architecture
product family engineering
...
jason@miles.no
@miles_no

2. why
jason@miles.no
@miles_no

3. your problem to solve:
design the solution architecture for standardised case
management for all employment and social security
benefts in Norway (26 → 40 benefts)
Enterprise Architect: “They all follow the same
business process!”
Domain Expert: “They are all diferent!”
Case Handlers: “They all have to look for the same to
us!”
jason@miles.no
@miles_no

4. “On the design and
development of
Program Families”
- Parnas, 1976
Alternatives:
- Reference Architecture
- One-size-fts-all
- Software Product Line
jason@miles.no
@miles_no

5. core problem:
must understand the nature of variability in your
problem domain
Structural
(Essential)
Incidental
(Accidental)
jason@miles.no
inherent in the problem domain
- business wants to offer a set of
products
- product differentiation is a competitive
advantage
purely technical
- technical debt
- different development teams
- etc
@miles_no

6. alternative 1: reference architecture
SU
SP
FP
common logical architecture for all products
separate product instances in production
reuse of knowledge
opportunistic reuse of components
no explicit variation management
jason@miles.no
@miles_no

7. alternative 2: one-size-fits-all
SU
SP
FP
one physical architecture for all products
single product instance in production
complex variation management
significant reuse of components
difficult to deal with variation in quality
requirements
regression testing for all products for all changes
jason@miles.no
@miles_no

8. alternative 3: software product lines
FP
SU
Felles
common logical architecture for all products
separate product instances in production
reuse of knowledge
explicit variation management: functional and
quality requirements
explicit reuse of components
requires more architecture investment
jason@miles.no
@miles_no

9. jason@miles.no
@miles_no

10. what
jason@miles.no
@miles_no

11. jason@miles.no
@miles_no

12. jason@miles.no
@miles_no

13. jason@miles.no
@miles_no

14. Domain
Engineering
Application
Engineering
jason@miles.no
@miles_no

15. jason@miles.no
@miles_no

16. jason@miles.no
@miles_no

17. how
jason@miles.no
@miles_no

18. how
jason@miles.no
@miles_no

19. how
jason@miles.no
@miles_no

20. BDUF or agile software product lines?
jason@miles.no
@miles_no

21. how
jason@miles.no
@miles_no

22. variation points in the architecture
For our case management
domain:
variation in process
variation in domain model
variation in presentation
variation in legislation
variation in integration with
external actors
jason@miles.no
@miles_no

23. variation guide
. domain model
. rule templates
. java component integration
. service level integration
jason@miles.no
@miles_no

24. Jones, Lawrence G., and Linda M. Northrop. 2010.
“Clearing the Way for Software Product Line Success.”
IEEE Software 27 (3) (June).
. selling the business case
. getting product owner(s) / domain experts to think
across products
. project organisation structure for common
components and product development
. how do you defne user stories and other
requirements?
. how much upfront design?
. SPL for enterprisey software rather than
embedded systems
jason@miles.no
@miles_no

25. summary
. is variation inherent to the business domain?
. are there enough products to justify payof with a
product line approach?
. analyse the variation
. design the architecture wrt commonalities and
variations
. develop a variation guide for combining common
assets and product-specifc variants
. don't forget the non-architecture challenges
jason@miles.no
@miles_no

26. more info
http://splc.net
http://www.sei.cmu.edu/productlines/tools/framework/
●
slides and images liberally
stolen reused from
http://www.sei.cmu.edu/library/assets/spl-essentials.pdf
jason@miles.no
@miles_no

27. software product lines
aka:
product line architecture
product family engineering
...
jason@miles.no
@miles_no
* will talk about product lines
* illustrate concepts with the modernisation of case
management at NAV

28. why
jason@miles.no
@miles_no
* start with the why and compare it to other
techniques
* then look at what is a SPL
* and then how we have been going about it

29. your problem to solve:
design the solution architecture for standardised case
management for all employment and social security
benefts in Norway (26 → 40 benefts)
Enterprise Architect: “They all follow the same
business process!”
Domain Expert: “They are all diferent!”
Case Handlers: “They all have to look for the same to
us!”
jason@miles.no
@miles_no
* how do you design the architecture for a while set
of solutions?
* all the solutions have many things in common but
there is considerable variability
* nobody is too sure what that variability is, nor
what can be standardised

30. “On the design and
development of
Program Families”
- Parnas, 1976
Alternatives:
- Reference Architecture
- One-size-fts-all
- Software Product Line
jason@miles.no
@miles_no
* lots of research and industry experience on
dealing with variability in software architecture
* long history of dealing with Product Families
* variations in functionality
* variations in support for quality requirements
* all that background shows three main alternatives

31. core problem:
must understand the nature of variability in your
problem domain
Structural
(Essential)
Incidental
(Accidental)
jason@miles.no
inherent in the problem domain
- business wants to offer a set of
products
- product differentiation is a competitive
advantage
purely technical
- technical debt
- different development teams
- etc
@miles_no
* before you can analyse which alternative is
relevant for you, you need to understand the nature
of variation
* Is it Essential or Accidental?

32. alternative 1: reference architecture
SU
SP
FP
common logical architecture for all products
separate product instances in production
reuse of knowledge
opportunistic reuse of components
no explicit variation management
jason@miles.no
*
@miles_no

33. alternative 2: one-size-fits-all
SU
SP
FP
one physical architecture for all products
single product instance in production
complex variation management
significant reuse of components
difficult to deal with variation in quality
requirements
regression testing for all products for all changes
jason@miles.no
*
@miles_no

34. alternative 3: software product lines
FP
SU
Felles
common logical architecture for all products
separate product instances in production
reuse of knowledge
explicit variation management: functional and
quality requirements
explicit reuse of components
requires more architecture investment
jason@miles.no
*
@miles_no

35. jason@miles.no
* summary.
* notice when and how you explicitly handle
variation (or not at all)
@miles_no

36. what
jason@miles.no
* all about product lines in general
*
@miles_no

37. jason@miles.no
@miles_no
* all about product lines in general
* architecture astronaut definition but there are
actually many that use it successfully in practice
** Nokia
** GM car software
** etc

38. jason@miles.no
@miles_no
* variation in software products directly linked to
business case that can be build a business model
around products.
* easy in the embedded domain but not as common
in the enterprise domain

39. jason@miles.no
@miles_no
* long term goal is to achieve this
* not necessarily how you start
* can't forget the management and organisation

40. Domain
Engineering
Application
Engineering
jason@miles.no
@miles_no
* core asset development = domain engineering
* product development based on assets =
application engineering

41. jason@miles.no
* not just component reuse
* all the artefacts in the dev lifecycle
@miles_no

42. jason@miles.no
@miles_no
* requires architecture investment and you wont get
the payback on the first system
* There are alternatives. Ex: huge developer base
in india

43. how
jason@miles.no
@miles_no
* variation analysis
* variation points in the architecture
* variation guide to describe how to deal with the
variations in technology

44. how
jason@miles.no
@miles_no
* Need to consider the approach from two
dimensions:
** product, process and organisation
** setting the context, getting started, working longterm

45. how
jason@miles.no
@miles_no
* example activities you can do in all these areas.
** we looked at each of these to understand the
ones that were the most relevant and pressing

46. BDUF or agile software product lines?
jason@miles.no
* Do you have to do all this upfront?
* we started reactive but are moving to more
incremental.
** focus on analysis on variation rather than
building components
@miles_no

47. how
jason@miles.no
@miles_no
* variation analysis
* variation points in the architecture
* variation guide to describe how to deal with the
variations in technology

48. variation points in the architecture
For our case management
domain:
variation in process
variation in domain model
variation in presentation
variation in legislation
variation in integration with
external actors
jason@miles.no
@miles_no
* domain analysis to find the commonalities and
variations
* feature models are a popular technique
* what we have been focussing on in case
management

49. variation guide
. domain model
. rule templates
. java component integration
. service level integration
jason@miles.no
@miles_no
* how do you solve each of the variation point types
in technology
* some variation will disappear by simply analysing
it with the business team and they realise that its
unnecessary - harmonisation
* separate bounded contexts for the legislation
domain and user facts domains
most facts become value objects that can be
handled with collections
domain model structure is less dependent of
variation
soft-schema document based persistence
* sprint contexts for java component integration
* SOAP service integration handled with WSAddressing because of the cloud infrastructure

50. Jones, Lawrence G., and Linda M. Northrop. 2010.
“Clearing the Way for Software Product Line Success.”
IEEE Software 27 (3) (June).
. selling the business case
. getting product owner(s) / domain experts to think
across products
. project organisation structure for common
components and product development
. how do you defne user stories and other
requirements?
. how much upfront design?
. SPL for enterprisey software rather than
embedded systems
jason@miles.no
@miles_no
* many known pitfalls which are good to keep in
mind
* we've had to deal with the following already

51. summary
. is variation inherent to the business domain?
. are there enough products to justify payof with a
product line approach?
. analyse the variation
. design the architecture wrt commonalities and
variations
. develop a variation guide for combining common
assets and product-specifc variants
. don't forget the non-architecture challenges
jason@miles.no
* When is it relevant?
* How do you go about it?
@miles_no

52. more info
http://splc.net
http://www.sei.cmu.edu/productlines/tools/framework/
●
slides and images liberally
stolen reused from
http://www.sei.cmu.edu/library/assets/spl-essentials.pdf
jason@miles.no
@miles_no
* the framework has all the basic info you need to
get started
* Product line conference exist and the website has
a nice set of case studies (HoF)