Siemens Corporate Research Princeton, NJ Synergies between Service-Oriented Architecture and Software Product Lines Siemens Corporate Research Princeton, NJ Christoph Wienands christoph.wienands@siemens.com

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

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.

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

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

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

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

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

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

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)

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

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

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

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

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

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.

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

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)

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

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

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

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

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

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

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

References The Standish Group, CHAOS Report (The Standish Group, 1994-2004) Software Engineering Institute (SEI) at Carnegie Mellon http://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)