In our paper “REARM: A Reuse-Based Economic Model for Software Reference Architectures” [7], accepted in the 13th International Conference on Software Reuse (ICSR 2013), we discuss the similarities and differences of software reference architectures and product line architectures. Below, we show them. An extended version can be found in [7].

The terms software reference architecture (RA) and product line architecture (PLA) are sometimes used indistinctly inside the SPL engineering context, in which the term RA is used to refer to “a core architecture that captures the high-level design for the applications of the SPL” [9, p. 124] or “just one asset, albeit an important one, in the SPL’s asset base” [3, p. 12].

However, out of the SPL context, RA and PLA are considered different types of artifacts [1][4][6][8]. In Fig. 1 we show the main similarities and differences:

• PLAs are RAs whereas not all RAs are PLAs [1], i.e. PLAs are one type of RAs [6]. PLAs are just one asset of SPL [3, p. 12].
• RAs are more generic and abstract than PLAs that are more complete architectures [1][6]. Hence, “RAs can be designed with an intended scope of a single organization or multiple organizations that share a certain property” [1] whereas PLAs are produced for a single organization [6].
• RAs provide standardized solutions for a broader domain (i.e., “spectrum of systems in a technology or application domain” [6]) whereas PLAs provide standardized solutions for a smaller subset of the software systems of a domain [8] (i.e., “group of systems that are part of a product line” [6]). Therefore, PLAs give a coherent and more congruent view of the products in a project (i.e., possible to track the status of) [4] whereas by means of RAs it is more difficult to obtain congruence [1], since they can only provide guidelines for applications’ development.
• PLAs specifically address points of variability and more formal specification in order to ensure clear and precise behavior specifications at well-specified extension points [1]. In contrast, RAs have less focus on capturing variation points [1][4][8]. Although variability is not typically addressed by RAs in a systematic manner, it is also a key fact for RAs [5], and it can be treated as a quality attribute, rather than explicitly as ‘features’ and ‘decisions’ [5].
• RAs include “the reuse of knowledge about software development in a given domain, in particular with regard to architectural design” [8] and dictate the patterns and principles to implement, i.e. “what the design should be” [4]. Conversely, PLAs specifically indicate deviations, i.e. “what the design is” [4].
• RAs include architectural knowledge and the instantiation of this architectural knowledge (i.e., reference model) into software elements [2]. In this sense, both RAs and PLAs are “a superset, a tool box, with every possible architecture element described, which can be used in the design of a product architecture” [4].

Although we also consider that RA and PLA are different, some perceived benefits of RA (e.g., cost saving from reusing software elements) and cost-benefit factors (e.g., common software costs, unique development costs) are applicable to both, since both have reuse as their core strategy. For this reason, we studied the applicability of some economic models originally conceived for SPL to RAs. The reader is referred to [7] to see details of REARM, an economic model for RAs.

References

1. Angelov, S., Grefen, P., Greefhorst, D.: A framework for analysis and design of software reference architectures. Information and Software Technology 54(4), 417-431, 2012.
2. Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice. Addison-W, 2003.
3. Clements, P., Northrop, L.: Software Product Lines. Addison-Wesley, 2002.
4. Eklund, U., Jonsson, N., Bosch, J., Eriksson, A.: A reference architecture template for software-intensive embedded systems. In: WICSA/ECSA, 2012.
5. Galster, M., Avgeriou, P.: Empirically-grounded reference architectures: a proposal. In: Proceedings of the joint ACM SIGSOFT conference QoSA/ISARCS, 2011.
6. Galster, M., Avgeriou, P., Tofan, D.: Constraints for the design of variability intensive service-oriented reference architectures an industrial case study. IST 55(2), 428-441, 2013.
7. Martínez-Fernández, S., Ayala, C., Franch, X., Marques, H.: REARM: A Reuse-Based Economic Model for Software Reference Architectures. In: Proceedings 13th International Conference on Software Reuse (ICSR), 2013.
8. Nakagawa, E., Oliveira Antonino, P., Becker, M.: Reference architecture and product line architecture: A subtle but critical difference. ECSA, pp. 207-211, 2011.
9. Pohl, K., Bockle, G., Van Der Linden, F.: Software product line engineering, vol. 10, 2005