Product Line Challenges and Organization Structuring Critical Success Factors

Product Line Challenges and Organization Structuring Critical Success Factors Agnes Owuato Odongo Kenya Electricity Generating Company aodongo@kengen.co.ke Abstract: Several methods have been published to address technical issues of product line engineering, such PuLSE, KobrA, COPA. However, attempts to alleviate organizational issues have not been addressed. This is one of the issues that need special focus from software community researchers. Defining the right organizational structure ensures successful institutionalization of product line within a company. Software product line engineering is comprehensive and touches many parts of an organization. Selecting a specific organizational structure is complex and no method has been developed. At planning stage, it is critical to align organization overall product set to its long-term strategy. Therefore, organizations require synchronization of structure and technical management. This paper describes the overview of product line approach to software development. It focuses on organization structuring for Product Line Engineering (PLE). It demonstrates that PLE indeed needs sound management in practice that calls for organizational structure. It explains why architecture should be structured in organizational settings. It identifies the factors to consider in organization structuring for the successful PLE adoption. It presents the procedures to perform to evaluate the framework to assert that the chosen factors have desirable psychometrics properties. Keywords: Software Product Line, Structuring the Organization, Organizational Management, Product Management, Software Product Line Engineering, SPL. 1. Introduction PLE has drawn great attention among software development organizations during the latest years. Many organizations, including Philips, Nokia, Cummins, Hewlett-Packard, have experienced large-scale PLE productivity gains, reduced time to market, improved productivity and products quality, increased customer satisfaction, and mass customization. Although successful industrial cases have shown PLE potential benefits, the literature also tells of failed organizations that did not apply product line (PL) concepts correctly. In the real world, PL success is unpredictable. However, practical experience can be used to prove the success or failure of software PLE. Compared to other software engineering techniques, PLE is difficult to manage. It is a multi-concepts technique that needs considerable time to develop the needed items. It is a life-cycle encompassing approach that needs deterministic development evaluation success in a realistic organizational structural architecture. Most research focus on technical management aspects. The focus on organizational aspects is low. A good PL management structure enables small and big companies to build better products faster and to efficiently maintain them. The problems of evolving and maintaining software organizational architecture are organizational. Software PL touches many parts of an organization. When adopting PL development, an organization faces challenges in running it from the initial planning stage, early development, and in continuous evolution. At planning stage appropriate alignment with the overall product set of the organization and its long-term strategy should be established. There is a direct interface of product-line development with strategic management to be designed and managed to ensure success. A successful software PL organization relies on close coordination among the core asset which are the basis for producing PL products and product development projects. Organization design/redesign must involve all of the appropriate people in thinking through the design, because its design is not an engineering problem. Undertaking a software development as a single unit does not need special management organization structure for PL assets and derived products. However, as business expands, software development spread to other units and departments, organization structure to manage software development becomes a reality. PL organizational structure should match with the software architecture for appropriate responsibilities assignments. The paper focuses on organization structuring for PLE. It demonstrates that PLE indeed needs sound management in practice that calls for organizational structure. The paper demonstrates why architecture should be structured in organizational settings; and the factors to consider for successful PL organization structuring for PL adoption. The factors are evaluated to assert that they have desirable psychometrics properties. The paper is organized as follows: Section 2 gives a related work. Section 3 provides a meaning of what is PL and SEI framework for software product line. Section 4 describes multiple and single system. Section 5 explains the necessity of PLE organization structure. Section 6 gives four case studies that applied PL approach successfully. Section 7 gives a key success factors for structuring the organization. Section 8 provides the framework for designing organizational structures in PLE. Section 9 provides procedures for validating the framework. Section 10 is the conclusion. 2. Related Work Most research focus on the process, architecture and business aspects of the software PL; and fails to focus on

organizational management issues. Bosch (2001) identifies four organizational structures: development department, business units, domain engineering units, and hierarchical domain engineering units. [Jacobsen, 1997] focuses on roles and responsibilities of personnel within PLE organizations. [PClements 2002] discusses organizational management issues of PLE and identifies four functional groups. The groups include the architecture, the component-engineering, the PL support and the product development groups. [Birk, 2002] argues that introducing software PL concepts into an organization affects organization practices, structures, and task assignments. [Bayer 1999] developed PuLSE PL Software Engineering) for the purpose of enabling the conception and deployment of PLE within a variety of organization contexts. PuLSE-BC is a technical component of PuLSE Methodology [BaFlKnLaMuScWiDe, 1999]. It deals with the ways to baseline PLE organization and customizes the PuLSE methodology to the specific organization needs. [Verlage and Kiesgen, 2005] concluded from a successful PLE case study that organizational structure is an important area of concern. 3. SEI Product Line Practice Framework 3.1 What is Product Line? PL is defined as 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 [ClJoNoMc, 2005]. PL helps organization to realize mass production and to produce customized products at reasonable costs. 3.2 Product line life cycle Process Adoption Domain Engineering Domain Application Engineering Application Products Product Users Figure 1. PL life cycle Business Objectives Market and Project Needs Customer Needs PL life cycle (Figure 1) consists of process adoption, domain engineering, domain, application engineering, application product and product use [Paulish, 2001]. Domain engineering is the PLE process defining and realizing commonality and variability of the product. Application engineering focuses on building the products by reusing domain artifacts [PoBoLi]. 4. Multiple and single products systems There are differences in benefits between multiple and single product systems. The benefits of a single product system includes market evolution technology and future application constraints; changing domain requirements engineering; defining common rules; incorporating configuration mechanisms; and testing chunks. The multiple product system benefits include requirements elicitation, application architecture development; components existence, interfaces, specific application realization; test artifacts derivation; and defective configurations detection. 4.1 Management Strategy Unlike management of a single software development, PL management is subdivided into core assets and end products management. Core assets management focuses on the activities that create and evolve core assets. The end products management deals with the activities that create and evolve products. These two management operations have the same challenge to plan, manage, and control the corresponding lifecycle [JOAC, 2005]. 4.1.1 Technical Management In this management strategy, the challenge is to continuously provide a PL infrastructure with the required functionality and quality [JOAC, 2005]. PLE managers responsible for product development projects need to understand each project s role as a core assets consumer, and its position in the PL. The products must make the best use of the core assets and the assets must be useful to the products and their evolving needs [CLEM, 2005]. Unlike management of single-software development, PL projects require enhanced coordination of both product and PL managers. For successful PLE, managers must get strong feedback from each other. 4.1.2 Core asset development projects The project activity is iterative and has four inputs: product constraints, preexisting asset inventory, existing components and artifacts; and production strategy. The production strategy affects the management of core asset projects and determines whether to build the PL proactively or reactively or combination of the two. 4.1.3 Organizational Management A successful software PL organization relies on close coordination among the core asset and product development projects [Beckert, 2000]. A successful PL organization requires strong, visionary management. The traditional management practices differ with that of PL. 4.2 Structuring the Organization Organization structuring is about forming groups in an organization to carry out roles and responsibilities in a

software development effort [Mannion, 2002]. PL structuring approach deals with placing roles and responsibilities into organizational units. Several ways to structure an organization exists. The chosen structure to adapt must fit into the organization. An organization's structure may be complex, formal or centralized. Designing organizational structure should be guided by clarifying, understanding, de-centralizing, and stabilizing. The departmental organization structures include functional, product and matrix. PLE organizations deal with core assets and products development and traditional approaches are not applicable as-is in product line. 5. Necessity of PLE Organization structuring 5.1 Organizational Issues Organizational models do exist and range from a single unit to a hierarchical structure. Identifying the organizational structure that is best suited for a specific situation is complex and has not been tacked. The factors that influence the decision include existing structure, peoples experience, market positioning, organization size and technical aspects. Organization structure and software architecture should change together. Software PL development involves software reuse and may look like traditional software reuse. However, it is much more elaborated than traditional reuse. PL development reuse is planed, enabled and enforced. PLE asset customization to the current product does not include any major code writing as traditional software. 5.2 New proposed organization model 6. Case Studies Analysis is conducted of four organizations that implemented PLE. The objective is to identify the factors that attribute to the PLE organization structuring. 6.1 CelsiusTech Systems The company implemented a PL approach to the construction of large, complex, software-intensive systems. The Key factors used in adapting PL in the organization included architecture importance, process, organization, people and business. PL helped a company to be efficient and economical, reliable and predictable and enables quality products for market expansion. 6.2 The U.S. Army s Common Avionics Architecture Syste The organization adopted a PLE for developing a family of software-intensive systems [CleBer, 2005]. Architecturally, there is an issue about the number of the architecture functional partitions representing configuration items. More items lead to a finer functionality decomposition that leads to higher levels of reuse; results in valuable systems that are easier to test. 6.3 Control Channel Toolkit (CCT) This organization sets up a software asset base that went through 6 overlapping increments. The groups were formed to ensure communication between the stakeholders. Groups enhanced stakeholders communication and flexibility that led to its success. 6.3 Salion It provided systems solutions tailored to the needs of automotive suppliers [Clements, 2002]. Suppliers could organize and manage their disparate customerinterfacing activities as one coordinated business process. Two models existed [Bosch, 2000], a model that establishes the platform group and that which assigns responsibility. Salion focused on who builds the core assets? Salion gathered fundamental customization insights and configuration that led to the success story. 7. Key Success Factors Figure 2: Organizational Model Figure 2 is the proposed organization framework that shows both PL architecture and organizational structure that establishes organization lines of communication. PL organization structure goes hand in hand with PL operations as it defines roles, actors, and responsibilities. Larger organizations use business units to address different functional and technical areas. Domain engineering units share a central engineering unit. Different factors influence the decision process and include existing organizational structure, peoples motivation to reuse, high market positioning, organization size and technical aspects. Organization structure should match the software architecture of the product line so that the tasks and responsibilities are assigned correctly to the development units. The structure and software architecture must change together. Culture can either hamper change or influence it. Organization structure should reflects business goals and focuses on what to achieve. The management should focuses on organization size, budget, management commitment, management maturity, PL scoping, flexibility, coordination, communication, adaptability, optimization, change management and clear identified

employee roles. Attention should be given to the geographical spread between core asset and product development in an organization. 7.1 How the Structure Evolves with Strategy There are four distinct stages of strategy-related organization structure that have been identified [Weiss, 2001]. The four stages include: Stage I: A small single-business enterprises managed by a single person having close contact with employees. Stage II: The increased scale and scope organizations. The number of operations forces the transits from a one-person to a group management system. Stage III: A PL organization that is geographically scattered to justify decentralized operating units. Stage IV: The business has diversified and decentralized business line units headed by a general manager. 7.2 The Strategy-Related Pros and Cons of Alternative Organization Forms There are five strategy-related approaches: (1) functional specialization, (2) geographic organization, (3) decentralized business divisions, (4) strategic business units, and (5) matrix structures. The Functional Organization Structure The business capitalizes on efficiency gains from specialized manpower, faculties, and equipments. Geographic Forms of Organization Used by large-scale enterprises with strategies tailored to fit particular needs and features of various geographical areas. Decentralized Business Units This groups activities along business and product e.g. Du Pont and General Motors in the 1920s. Strategic Business Units (SBU) SBU is a grouping of business units based on some important strategic elements common to each. Matrix Forms of Organization Product and functional lines of authority are overlaid. Managerial authority is shared between the product and functional managers. Selecting People for Key Positions Assembling a capable management team and focusing on the core management team to carry out the strategy. 8. Product Line Organizational Structure Framework Design Organizational structure is a framework for dividing, grouping and coordinating business activities. Managerial process makes decisions on appropriate structure of PLE to achieve financial viability and quality products [CleNor, 1998]. The first step is to propose the requirements and second a framework. 8.1 Effective Structuring Process Requirements PL organization structuring the deals with placing roles and responsibilities into the appropriate organizational units; by assuming that organization is capable of determining the production strategy and PL scope associated with the business case. 8.2 Step-by-step process This section describes a step-by-step process model on how to establish the appropriate organization structuring. The structure should match with the organization s goals, strategic plans, capabilities and, environmental factors. The process model involves six-sequence process: 1) Define the key activities requisite 2) Coordinate diverse activities 3) Group activities into units 4) Establish lines of authority 5) Coordinate between units 6) Monitor, evaluate and adjust structure. Table. 1 Summary of the structuring process Steps and Purpose Prioritized Key Factors Outcomes Step 1: Identify the key activities requisite -Vision, objectives and strategic plan -Document key activities are in a written form - Scoping - Organization s size -Architecture and process Step 2: Coordinate organizational activities -People s capability - Culture -Maintain open and reliable activities communication channels Step 3: Group activities into units - Scoping -Organization size - Architecture and process -Document units activities in a written form -Define units contribution to overall organization goal. Step 4: Establish formal lines of authority Step 5: Coordinate among the units -People s capability -Management commitment - Culture -Geographic Distribution -People s capability - Culture -Define roles and reporting relationships -Align accountability, authority, and responsibility - Provide management policies and procedures - Maintain open and reliable communication channels between activities Step 6: Monitor, evaluate, and review structure -Vision, objectives and strategic plan -Organization chart or revisited chart Each process step in Table 1 is described in terms of purpose, desired outcomes and activities and tasks to be performed to achieve the outcomes. The purpose describes the goals of performing a step, the key factors are those that should be considered while performing the steps, and the outcomes express the observable results. 9. Validating the Framework Although the framework for structuring PLE is presented, finding a willing organization to use the new concept is difficult. Verification of the framework is shown in Table 2 by showing its compliance with CMMI model. It qualifies why CMMI was chosen as an

alternative for evaluating and discussing how the structuring process complies with CMMI model that has been used and accepted by many software industries. 9.1 CMMI Models Structure CMMI has two representations: 1) a staged and a continuous representation. A staged representation focuses on the organization s processes as a whole. A continuous representation focuses on improving individual process areas aligned with specific needs. Maturity levels and their process CMMI area groupings include Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS). The continuous representation uses the concept of capability level to measure process improvement within individual process areas. Capability levels represent the application of the generics to a single process area and indicate the process area s degree of institutionalization. 9.2 CMMI Process Areas A critical organization structure element for CMMI models is the process area. It focuses on the collective activities performed to achieve a set of goals. Process areas include Process Management, Project Management, Engineering and Support. The organization must decide the process areas to use and maturity level to reach with process areas. Staged representation groups process areas by maturity level. The generic goals 4 and 5 are not used because not all processes will be raised above a defined process. To reach level 3 to 5, appropriate process areas and low maturity levels are used. 9.3 CMMI and Product Line Synergy CMMI is used to evaluate the proposed structuring process because it has been widely applied to PL organizations regardless of the adopted production approach. CMMI is applied to software and systems engineering and this affirms that it can be extended and tailored to software PL. Secondly; there is a relationship between CMMI model and PLE practice. Jones and Soule compared PLE and CMMI model (JONE, 2002) and discovered that practice and process areas are associated in regard to software production. The similarities and differences between my framework and the CMMI process areas: OEI and IT. In CMMI v1.1, the Integrated Product and Process Development (IPPD) material consisted of two process areas, IT, OEI as Integrated Project Management (IPM) process area. All of this material was used only if the IPPD option was selected by the organization for its process improvement program. In CMMI v1.2, a goal is added to Organizational Process Development (OPD) to address the organizational commitment to IPPD and the integrated IT team concepts was consolidated into IPM. The approach reduces the number of IPPD-related practices and process areas. According to Table 2, a close association exists between the first four framework steps. The four steps relates to the CMMI Project's Defined Process and Coordinate and Collaborate with Relevant Stakeholders. Proposed Framework Steps - Define the key activities requisite; - Coordinate diverse activities; - Group activities into units; - Establish lines of authority; - Coordinate between units; - Monitor, evaluate and adjust organization structure. Table 2: How the proposed framework relates to CMMI Process Areas (v1.2) CMMI Process CMMI Process Areas Specific Goals (SGs) and Specific Areas Practices (SPs) Integrated Project Management +IPPD (IPM) SG 1Use the Project's Defined Process SP 1.1 Establish the Project's Defined Process SP 1.2 Use Organizational Process Assets to Planning Project Activities SP 1.3 Establish the Project's Work Environment SP 1.4 Integrate Plans SP 1.5 Manage the Project Using the Integrated Plans SP 1.6 Contribute to the Organizational Process Assets SG 2 Coordinate and Collaborate with Relevant Stakeholders SP 2.1 Manage Stakeholder Involvement SP 2.2 Manage Dependencies SP 2.3 Resolve Coordination Issues SG 1 Establish Organizational Process Assets SP 1.1 Establish Standard Processes SP 1.2 Establish Life-Cycle Model Descriptions SP 1.3 Establish Tailoring Criteria and Guidelines SP 1.4 Establish the Organization's Measurement Repository SP 1.5 Establish the Organization's Process Asset Library SG 2 Enable IPPD Management SP 2.1 Establish Empowerment Mechanisms SP 2.2 Establish Rules and Guidelines for Integrated Teams SP 2.3 Balance Organization Team and Home Responsibilities Comments Define the key activities requisite in the process model covers SP 1.1, SP 1.2 and SP 1.5 in terms of activities. Coordinate diverse activities and between units match with SP 2.2 and SP 2.3. Establish lines of authority that meets SP 2.1 and SP 2.2 Monitor, evaluate and adjust organization structure. That is loosely associated with SP 1.3 and SP 1.4. Tailoring, organization structure impact and measurement is part of monitoring and adjusting However, the step 5 is loosely related to Establish Organizational Process Assets. 9.4 Performing Framework Evaluation An effective organization structure facilitates individual goal and objective contribution with minimum resources. Procedures for monitoring the structure includes 1) determine the location of entity structuring process 2) obtain and review manuals, policies, and forms 3) determine management process of selecting and employing the structuring 4) identify activities linking mechanism 5) determine alignment accountability 6) obtain a complete organization chart. In executing procedures, the structure strengths and weaknesses can be identified. Possible procedures to this

effect includes 1) ensure inclusion of all major steps in actual organization process 2) determine process steps value 3) review the order of process 4) review if the structure promotes productivity 5) review the level of process technology used. Procedures to determine if controls for the structure works as intended includes 1) draw the process picture and control objectives 2) determine objectives alignment with management 3) identify the structure success or failure 4) compare controls cost and the risks 5) determine monitoring controls and evaluate process effectiveness 6) identify, describe, and assess the process 7) make decisions using organization chart and flowchart 8) determine structure susceptibility management override 9) review observations, interviews, documentation, and design audit procedures. Review and analyze any reports to monitor the outcomes of the structure and determine if the structure is actually achieving the desired management objectives. Procedures to achieve this include 1) analyze outcome reports over time for trends 2) discuss any negative or positive material trends with management 3) determine how management acts on outcomes 4) obtain and review a sample descriptions and performance plans for consistency 5) compare staffing activities patterns to similar activities elsewhere 6) indicate whether conditions are observed during the audit. Determine the circumstances that caused process weaknesses. Possible procedures include 1) determine if the process participants understands mission, goals, and values 2) determine if the participants understand structure resulting roles 3) determine if the entity process structuring entity is clear 4) determine if structure has multiple locations 5) determine if the process activities have adequate resources 6) determine entity alternative resources 7) determine if resources for developing, maintaining, and evaluating structure are available. Determine internal or external constraints to remove to overcome weaknesses. The procedures to this effect include 1) review the applicable entity change prevention; key employees are not for changing the structure and why. 9.5 Discussion Software product lines methods have been published such as PuLSE, KobrA, COPA [Matinlassi, 2004]. However, only few attempts have been made to alleviate organizational issues. Organization structuring needs special focus from software community researchers. The paper identifies the key factors to consider while devising PL organization structure to meet the needs. The framework confirms some compliance the process model with CMMI model. It is at the start and only focus on what to be done in PL organization structuring. The activities list for each step is limited. Therefore, further study is required to refine the proposed process. That aside this framework is an important step to tackle the organizational structure issue in PLE. It explains the importance of establishing the right PL structure. 10. Conclusions The paper identifies and discusses the critical factors that influence the organizational architecture of those organizations which intend to institutionalize software product lines. A framework is proposed that offer guidance to managers on what to consider when choosing PL organization structure. The framework is analyzed to determine its compliance with CMMI. Procedures and their set of steps are provided on how to practically evaluate the framework as it is used. 11. References [Weiss, 2001] J.W. Weiss, Project Management Process in early stage e-businesses: Strategies for leading & managing teams, Proceedings of the 34th Hawaii International Conference on System Sciences 2001. [BaFlKnLaMuScWiDe, 1999] J. Bayer, 0. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Widen, J.M. DeBaud, PULSE: A Methodology to Develop Software Product Lines, Symposium on Software Reuse, 1999. [Chen,2005] Kuan-Chou Chen, Real World Pedagogy for E- business Applications - Project Management Approach, Proceedings of the Fifth IEEE International Conference on Advanced Learning Technologies (ICALT 05), 2005. [Clem, 2005] P.C. Clements, L.G. Jones, L.M. Northrop, and J.D. McGregor, Project Management in a Software PL Organization, IEEE SOFTWARE, Published by the IEEE Computer Society, 2005. [Matinlassi, 2004] M.Matinlassi, Comparison of Software Product Line Architecture Design Methods: COPA, FAST, FORM, KobrA and QADA, Proceedings of the 26th International Conference on Software Engineering (ICSE 04), 2004. [Beckert, 2000] Michelle T. Beckert, Organizational Characteristics for Successful Product Line Engineering, Massachusetts Institute of Technology, 2000. [PClements, 2002] P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, published by Addison- Wesley, 2002. [Bosch, 2000] J. Bosch, Design and use of software architectures: adopting and evolving a product-line approach, published by Addison-Wesley, 2000. [Birk, 2002] A. Birk, Three Case Studies on Initiating Product Lines: Enablers and Obstacles, in Proceedings of the PLEES 02, International Workshop on Product Line Engineering: The Early Steps: Planning, Modeling, and Managing, Fraunhofer IESE, 2002. [16] P. Clements, L. Northrop, Salion, Inc.: A Software Product Line Case Study, CMU/SEI, 2002. [ClJoNoMc, 2005] P.C. Clements, L.G. Jones, L.M. Northrop, and J.D. McGregor, Project Management in a Software Product Line Organization, IEEE SOFTWARE, Published by the IEEE Computer Society, 2005. [ClCoDoNo, 2001] P. Clements, S. Cohen, P. Donohoe, L. Northrop, Control Channel Toolkit: A Software Product Line Case Study, CMU/SEI, 2001.