Synergies between Service-Oriented Architecture and Software Product Lines

1. Synergies betweenService-Oriented ArchitectureandSoftware Product Lines Siemens Corporate Research Princeton, NJ Christoph Wienands christoph.wienands@siemens.com

2. Contents • Motivation • Introduction to software product lines • Comparing SOA and product lines • Product line concepts of interest • Software Engineering • Technical Management • Organizational Management • Conclusion

3. Motivation • Service-oriented architecture supports requirements of businesses processes and software users • Fosters loose coupling, interoperability and protection of legacy investment • Therefore, promotes business agility However: • Services and applications are often built for specific needs and requirements • Redundant development is done • Limited systematic reuse  Techniques from software product lines can help addressing these issues

4. Contents • Motivation • Introduction to software product lines • Comparing SOA and product lines • Product line concepts of interest • Software Engineering • Technical Management • Organizational Management • Conclusion

5. Introduction to Software Product Lines A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Paul Clements and Linda Northrop, 2002

6. Key Benefits of Software Product Lines • Achieve productivity gains • Improve time to market • Exploit economies of scope through reuse of common assets • Enhance the predictability of software development processes • Improve software quality • Focus on the unique aspects

7. Software Product Line Development Product development process Core assets Product specification Product line architecture Assemblecore assets Core Asset Development Product Development Product line scope Create extensions Feedback to core assets Domain analysis

8. Software Product Lines Concepts: • Scope: What products/solutions can be built(without extensions) • Commonality/Variability: Identifies the common and variable (optional) features of product line members • Extensibility: Well-defined extension points allow to add customer-specific features outside of the scope

9. Contents • Motivation • Introduction to software product lines • Comparing SOA and product lines • Product line concepts of interest • Software Engineering • Technical Management • Organizational Management • Conclusion

10. Service-Oriented Architecture Mainly about loosely coupled services Focus on standardization of services and data types Services serve a business purpose and variability is managed by SOA policy  Goal is to enable assembly, orchestration and maintenance of enterprise solutions to quickly react to changing business requirements Software Product Lines Developed for generalized off-the-shelve products Focus on generalized components Adaptation and customization through configurable components and variability mechanisms  Goal is to harvest economies of scope through planned and systematic reuse Objectives

11. How problems in today’s software development are addressed • One-off development Product Lines: Planned and systematic reuse  SOA: Possible reuse of services • Monolithic systems and increasing system complexity Product Lines: Reusable, composable components and a product line architecture common across all products  SOA: Pretty clear, that’s what SOA is replacing • Working at low levels of abstraction Both methodologies: Use of specialized domain-specific languages, editors and code generators • Development process immaturity Product Lines: Mandates a strict product line development process with organization-wide dedication • Increasing demand for software and IT services Product Lines: Allows for rapidly building customized product line members  SOA: Allows for quick adaptation to changes

12. Contents • Motivation • Introduction to software product lines • Comparing SOA and product lines • Product line concepts of interest • Software Engineering • Technical Management • Organizational Management • Conclusion

13. Product Line Concepts of Interest Software Engineering • Reuse • Variability Technical Management • Feature-Oriented Domain Analysis • Scoping • Make / Buy / Mine / Commission Analysis Organizational Management • Launching and institutionalizing • Operations

14. Example 1: Technical Issues • Solution originally incepted for one department or market • “Same” (similar) solution requested for another market • Some of the problems • Different middleware and underlying “legacy” systems • Differences in ontologies and data types • Differences service logic, policies and processes

15. Software Engineering:Reuse in a Service-Oriented Architecture Identify areas with high potential for reuse, such as • Enterprise services • Basic services  Reuse of data,business logicand potentiallybusiness processes

16. Software Engineering:Reuse in a Service-Oriented Architecture • Even more reuse potential within services • Each service can be considered an individual application • Can occur anywhere there is duplication and redundancy

17. Software Engineering:Variability in a Service-Oriented Architecture • Assets with high reuse potential need to support a certain level of variability in order to be widely applicable • Product lines provide techniques for discovering variation points, such as feature-oriented domain analysis • Service-oriented architecture supports a large number of variability mechanisms, such as • Patterns such as façades, adapters, mediators, dependency injection, etc. • Rules and workflow engines • Service discovery and service versioning • Orchestration and message routing • Extensible protocols and data types • WS* extensions • Installation wizards and configuration files

18. Technical Management:Feature-Oriented Domain Analysis and Scoping • Used to develop generic and widely applicable products • Modeling concepts are abstraction and refinement • Scoping determines the supported common and variable features Documented through Feature Models:  Common feature  Variable feature A Feature set (m..n)

19. Technical Management:Make / Buy / Mine / Commission Analysis • Any software comes from one of these four sources • Uses techniques from decision analysis • Reuse can recover higher cost for either option • Evolution path and competitive advantages very important criteria Legacy Investment Cost Competitive Advantages Evolution Path In-house skills COTS Availability Vendor Stability Resources

20. Example 2: Organizational Issues • Some of the problems: • Existence of reusable assets unknown (or poorly documented) • Existing services almost fit, but not quite exactly • Missing policies and governance regarding reuse • “Not developed here” syndrome • No “reuse” champion or authority

21. Organizational Management: Launching and institutionalizing • Just as with product lines, planned reuse in SOA needs to be embraced throughout an organization • Perform pilot projects • Determine reuse champion (individual or group) • Work towards SOA governance (see next slide)  Raise general awareness and establish a culture of systematic reuse

22. Organizational Management:Operations: Development Cycle Model Plan Analyze Design Planning & Design Integrate & Deploy Reusability Analysis Core Asset Planning Test Development Scoping Refactoring Plan Implement Development Plan

23. Organizational Management:Operations: SOA Governance • SOA governance means the creation, deployment, enforcement and verification of policies throughout the entire lifecycle of SOA artifacts. • A SOA governance platform provides easy service discovery through a centralized service registry and management tools for planned reuse (on the service level), such as subscription requests, service level agreements, and consumer tracking. • Ensures that services are developed, tested, integrated, deployed, and changed according to defined standards and policies  enhance reusability

24. Contents • Motivation • Introduction to software product lines • Comparing SOA and product lines • Product line concepts of interest • Conclusion

25. Conclusion • Service-oriented architecture is inherently predestined for systematic reuse as it comes with a large number of variability mechanisms and loosely coupling. • Product line techniques help generalizing SOA development artifacts for broader applicability. • SOA governance, together with supporting governance platform, will allow for implementing these efforts. Questions Contact: christoph.wienands@siemens.com

26. References • The Standish Group, CHAOS Report (The Standish Group, 1994-2004) • Software Engineering Institute (SEI) at Carnegie Mellonhttp://www.sei.cmu.edu/productlines/index.html • Thomas Erl, Service Oriented Architecture (Prentice Hall, 2005) • Krafzig, Banke, Slama, Enterprise SOA: Service-Oriented Architecture Best Practices (Prentice Hall, November 2004) • John Butler, Applying Product Line Techniques to SOA, Part I and II (CDBI Journal, February and May 2006) • Richard Veryard, Business Modeling for SOA Series (CDBI Journal, January and February 2006) • Clements, Northrop, Software Product Lines – Practices and Patterns (Addison Wesley, 2003) • Bass, Clements, Kazman, Software Architecture in Practice, 2nd Edition (Addison Wesley, 2003) • Jan Bosch, Design and Use of Software Architecture – Adopting and evolving a product line approach (Addison Wesley, 1995) • Schmidt, Stal, Rohnert, Buschmann, Pattern-Oriented Software Architecture Volume 2 – Patterns for Concurrent and Networked Objects (Wiley, 2000) • Network World, SOA Governance: Preventing Rogue Services (August 2006)http://www.networkworld.com/supp/2006/ndc3/062606-ndc-soa-governance.html • RosettaNet standards, http://www.rosettanet.org • Czarnecki, Eisenecker, Generative Programming: Methods, Tools, and Applications (Addison Wesley, 2000)