1. Siemens Corporate Research Princeton, NJ
Synergies between Service-Oriented Architecture and Software Product Lines
Siemens Corporate Research
Princeton, NJ
Christoph Wienands

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
SOA obviously fosters reusability e.g. at the service level. However, how reusable are these services really? Looking at product lines might give us an answer.

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
process
Core assets
Product
specification
Product line
architecture
Assemble core 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. Objectives 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
There are clearly fundamental differences in the objectives of PLE/AFE and SOA. PLE/AFE methods have been developed to create more generalized COTS products that allow for configuration with the primary focus on design time reuse of highly generalized components. The prime objective is reuse for productivity and efficiency. In contrast SOA is primarily about loosely coupled shared services that serve a business purpose with variability managed using SOA policy. Further the search for variability in SOA is constrained, (in the CBDI thinking specifically) there is a strong focus on standardization of shared services in order to implement consistency of business policy and business process. SOA is focused on loose coupling of the service usage to enable rapid solution assembly and orchestration, not about the fundamental design of an application product. (John Butler)

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 logic and potentially business 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
Compare to traditional monolithic application. With SOA now we have many independent but very similar applications.

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:

26. References
The Standish Group, CHAOS Report (The Standish Group, )
Software Engineering Institute (SEI) at Carnegie Mellon
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)
RosettaNet standards,
Czarnecki, Eisenecker, Generative Programming: Methods, Tools, and Applications (Addison Wesley, 2000)