Product Line Architecture Product line architecture for enterprise size software infrastructure

Chapter 06 – Product Line Architecture 18 October Page 1

Product Line Architecture Product line architecture for enterprise size software infrastructure

Summary: Software product lines present many benefits over the traditional methods of building systems. With the diverse implementation of both application and technology architectures, organizations are faced with complex design constraints. Layered architectures assist with breaking down of the complexity through separating elements based on their use. To really achieve high levels or re-use without only focusing on one architectural style is difficult to do. This chapter presents a higher level of abstraction whereby the focus is on functionality to the user. The absolute separation of business related, from software related assets, is argued to bring the next level of benefits required over the existing component paradigm. The Software Engineering Institute and Carnegie Mellon University’s initiative around the software product line practice is used as a basis to present an architecture that can bring about the changes required to improve the ability to deliver products. Product line architecture is introduced, after which the separation is discussed. Keywords: process innovation, designing for innovation, product line, product architecture, separation continuum, COTS based systems

1. Introduction

Software product lines present many benefits over the traditional methods of building systems. With the diverse implementation of both application and technology architectures, organizations are faced with complex design constraints. Layered architectures assist with breaking down the complexity through separating elements based on their use.

This chapter presents a higher level of abstraction whereby the focus is on functionality to the user. The absolute separation of business related, from software related, assets is argued to bring the next level of benefits required over the existing component paradigm. The Software Engineering Institute and Carnegie Mellon University’s initiative around the software product line practice is used, as a basis to present an architecture that can bring about the changes required to improve the ability to deliver products.

1.1 Assembly and the Product Line Architecture

Tools to assemble, maintain and deploy software assets provide great levels of productivity. Roles in the organization are assigned to the level of complexity most suited. Aspects and features essentially are defined to result in the architecture shown below. Assembly tools are required to weave together all the components into a final product line.

Product Line Architecture


Figure 1: Assembly and Product Line Architecture and the separation continuum

Figure 1 shows three distinct groupings of concepts. Technology and platform architectures form the basis on which software assets are built. Core software assets are the different elements that make up a complete software product. Software components, designs and documentation are built using patterns and frameworks, and are all included in this area. Product families are made up of product lines that are, in turn, assembled from core software assets.

The “separation continuum” will show how the “Platform Implementation” continuum is implemented. Applications, web-services, components and objects can be built pro-actively depending on the predictable nature of the customer environment. However, it is more likely to see radical changes in how the product lines and families are assembled. The concept of assembly is applied at this level to obtain the highest levels of productivity, without sacrificing quality and other non-functional requirements.

In order to have a clearly separated technology and platform architecture [Doerr] suggests that certain elements of flow control must be removed from the underlying architectures. Components might be independently defined and built, but the flow of processes and data presents many platform specific challenges. The core software assets must include tools to perform these tasks without having a specific platform feature implemented.

Section 2 provides an overview of the software product line practices as promoted by the Software Engineering Institute.

Section 3 briefly shows where some of the process innovation processes related to product development fit into the product line architecture infrastructure.

Section 4 introduces the concept of time-to-market and how it relates to product lines.



Section 5 discusses the separation continuum that forms one of the important concepts when product lines are defined, managed, and built. It also shows that the separation of concerns must be taken into account in product line architectures.

Section 6 discusses one of the dimensions of the separation continuum in detail, namely the platform implementation dimension.

Section 7 introduces the concept of assembling new product lines from pre-defined software assets. It also shows how product lines are realized.

Finally, section 8, closes with an example and a brief discussion around the practical implementation.

2. Overview of the Software Product Line Practices

Software product lines have emerged as a very important paradigm in delivering systems. Major benefits are derived from the practice of using common assets to build systems. Remarkable increases in time-to-market, product quality, and customer satisfaction are realised through this framework. With the “component paradigm” maturing, companies are ready to build systems from commonly available software assets. The technological aspects are not without their problems, but the process of product line practices presents more benefits than existed previously.

2.1 Software Product Lines

The Product Line Management v2.0 [SEI PLP] presents the following definition:

“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”.

Common software assets are invented, designed and built in such a way that they can be used in a multitude of product lines. The ability to build and evolve these separately has major benefits as architectural, resource and other dependencies can be balanced. “Independent synchronised product delivery” is now possible as products are assembled depending on the customer’s need.

2.2 Product Line activities

The practice of product line development can be broken into two major areas of activities: The development or acquisition of core assets, and the development of the product itself make up the essence of product development or acquisition. Figure 2 shows the product line activities as defined by the SEI/CMU initiatives.



Figure 2: SEI’s product line activities [SEI PLP]

These activities happen throughout the product’s life cycle and are iterative in nature. Management activity is responsible for the coordination and delivery of the process as a whole.

2.3 Core asset development and acquisition

The purpose of this activity is to produce or acquire product production capability. Figure 2 shows that various aspects are considered throughout the core asset development process. A product space is described and used to direct the content of the product line. Core software assets are used to assemble the product line. The assets are based on an underlying architecture that will be included in the final product.

Figure 2: Core asset development and acquisition [SEI PLP]



A production plan is needed to describe the way in which these products will be produced. It is based on the practices that best suit the product line architecture. Inputs into the process are used to produce the final core assets, product space or assist with production planning.

The product constraints are used to direct the way in which the products are built and assembled. Styles, patterns and frameworks are the principles used to construct the assets to be developed. Production constraints and the production strategy are used to direct the ways in which the assets are built and deployed into product lines. Existing pre-built software assets are used throughout the management and building phases to ensure optimal re-use of existing assets.

2.4 Product development and acquisition

The ability to turn out products with a high level of productivity is one of the goals of a product line. To be able to do this, three inputs are required, as described in the asset development and acquisition activity shown in figure 3, namely: the product space, core assets, and the production plan.

The products produced and organised into product lines essentially represent a group of products. Ultimately the products are produced independently by groups of product developers and are synchronised and integrated into a coherent product line. Product managers manage the vision and goals of the product line that needs to be commercialized [van Zyla].

Figure 3: Product development and acquisition [SEI PLP]



Different relationships are built between the customers that use the products and customers that sell the products. When partners, that are essentially customers, sell products to their target market issues are raised that need to be fed back into the product provider. Commercial viability is analysed and used as a business case to, in extreme cases, create new product lines.

3. Process Innovation and product lines

Producing innovative products to market requires a formal and disciplined approach. Many viable ideas are generated by strategic processes: customers require certain features; the market needs certain concepts to be implemented, and other scenarios like these provide input into the product development process. Concepts such as prototyping and mock-ups are used to ensure that a product can be built and taken to market.

3.1 Strategic product development

How are product management and learning used as an integral part of product delivery? Both core asset development/acquisition and product development/acquisition require a higher-level paradigm to be considered when it comes to market relevance and positioning.

Figure 4. Product funnel [van Zyla]

Taking the product funnel as a method to invent new products, idea generation is restricted mostly by the view that the filter will stop the idea from developing because of technical feasibility or market potential. If the existing core asset base already contains many different technology and business related assets, the selection process can be radically optimised. Previous experiences will provide the critical metrics with regard to the ability to implement a certain strategy.



By the time that the projects are defined that are needed to take a product line to market, the richness of the asset base will determine the critical criteria around time-to-market. Features might be included purely because of the availability of assets. This might compensate for features that require assets to be built.

Prototyping in the concept development phase becomes an academic exercise because of the learning that took place over time with the building and assembling of product lines. Prototypes are no longer just prototypes as they represent products built from real and tested software assets.

The focus eventually becomes very engrossed with the ability sell the product lines. It also allows for radical changes within one architecture without de-stabilizing the environment. Evolution can be managed as the process of product line management can be used to build products predictably.

3.2 Product line balancing

Product line design needs to cater for the ever-changing needs in features and feature combinations. The ability to balance the time-to-market requirements; features to be released, and non-functional requirements, needs to be honed and monitored to produce the right product line.

3.3 Product lines and patterns

The use of patterns can save the various roles that are involved with product line development an enormous amount of time in design, feature analysis and other activities that normally recur from product line to product line. Each of the levels in the separation continuum, that will be presented later, needs to have pattern development initiatives that are driven by the product line development teams. The richness, completeness and correctness of these patterns will significantly reduce risks on drivers like time-to-market and scalability.

4. Concept of time-to-market and how it relates to product lines

Product line architectures should be designed so that the critical drivers around time-to-market requirements are satisfied. The more complete the architecture and software asset base, the quicker it is to turn around the design prototypes. This turn around is needed to get into product development with a clearly defined concept of commercialisation.

Software developers can learn from research in other fields that are more mature. Clark and Fujimoto’s [Clark] research created a set of propositions that was found to be relevant in software product development through this research.



4.1 Product complexity and the specialization of personnel

Firstly, the product development process is directly dependent on the complexity of the product that must be produced. Secondly, the level of specialization and knowledge required to realize the product is also related to the level of complexity.

To be able to produce a highly complex product in order to secure a competitive market, can be disastrous. “Independent Synchronised Product Delivery” [van Zyla] principles can reduce the risk of failure. The following propositions form a starting point for dealing with new product development risk:

• Higher product complexity is correlated positively with greater specialization of new product development (NPD) personnel.

• Higher product complexity and greater specialization of NPD personnel are both correlated negatively with speed to market.

Product managers need to work with product designers in order to find the correct balance between complexity and resource availability in producing a certain set of features. The software assets that exist will obviously contribute to the balancing act that needs to take place.

4.2 Internal integration

The ability to integrate all personnel across the product development life cycle has a major impact on the final product to be produced. Overlaps in product definition, design and software asset development people will improve the performance of the teams producing product lines. The complexity in design and development is dealt with in more detail and reduced due to the diverse effort.

The following propositions can be defined:

• Both higher levels of specialization of people and higher product complexity are positively correlated to the level of internal integration.

• Internal integration is positively correlated to both product performance and time to market.

The value chain design in producing product lines must have integration points into the product producers and software asset developers. Product architecture forms the underlying platform from which all team integration points are designed. This results in the following construct; organisation design is the realisation of the strategy that is the realisation of products to be produced to certain markets.



4.3 Effects of product performance

Specialization of personnel is expected to increase the performance of product development. This has been proven repeatedly looking at the research around learning curves. The knowledge curve suggests that, productivity and problem solving only come to the fore after the initial period of learning. This means that if the speed-to-market is reduced, product quality and performance should improve. The following propositions can then be defined:

• Higher levels of specialization can be correlated positively with product performance.

• Quicker time to market is correlated negatively with product performance.

Product availability is always created and planned for in accordance with the product line strategy that is, in turn, aligned with the product’s company strategy. The relevant stakeholders need to be aware of the trade-offs that will affect the areas of the product as deployed.

5. Separation continuum

The principle of separating concerns has been used by various architectures. Essentially, it is used to deal with the complexities that exist in the definition and use of software systems. Principally if the inherently static rules that require high speeds of execution are placed in an environment where they are best suited and are separated from the dynamics of user interface metaphors, the risk of having an imbalance between performance and dynamic capability is reduced radically.

The Separation Continuum can be defined as a systemic view of an entity in order to understand the vertical and horizontal layering needed to have a balanced realization between abstract and implementation, and human and machine facing aspects to have attributes of adaptability, context and relevance.

Model Driven Architecture [Dsouza] has a vision that overlaps with the separation continuum: “An integrated enterprise is one whose business areas, strategies, architectures, organizational units, processes, machines, technology platforms, data and information – and the organization's understanding of these − form a consistent, cohesive, and adaptive whole.”

5.1 Separation of concerns

When architectures are designed for new product lines, there needs to be one main objective [Pronk] namely: avoiding a monolithic design by extreme de-coupling of components and localization of functionality so that every component can be replaced or upgraded in isolation. The separation continuum takes this concept one step further in that other dimensions in systems delivery need to be considered.



“Horizontal separation” is concerned with the separation of how the user interface is independent of the connectivity and, in turn separate from the business logic and data access. “Vertical separation” is the layering needed to implement platform elements separately from the higher levels of abstraction needed at application levels.

Figure 5: Separation continuum

Architectures from many platform vendors are available that specialise different kinds of separation. Both J2EE and Microsoft .NET platforms are focused strongly on the notion of separating out the various dimensions of a system.

5.2 Horizontal continuum

These groupings can be classified into two areas called “customer facing aspects” and “infrastructure facing aspects”.

Figure 6: Separation continuum and major aspects

The horizontal dimension is made up of the following elements – moving from visual to non-visual capability on the platform implementation continuum:



• User interface: the interface that is used by the user of the system that might include a multitude of devices including web browsers, personal devices, etc.

• Connection or middleware layer: the ability of the user interface to connect to a server that directs the way in which the interface is used.

• Services layer: the ability to have a cluster of business and/or technical services exposed to the user interface.

• Data provision layer: the ability to store in a reliable fashion that is used by the services layer to deal with transactional, system and meta-data data definitions.

5.3 Vertical continuum

The separation of dimensions, based on context and relevance, are fundamentally important when defining a product line architecture [Doerr]. Aspect-Oriented Frameworks [Constantinides] can assist with the challenge that is faced by so many designers and architects. Aspects refer to the properties of the system that do not align directly with a system’s functional requirements, but cut across functional components increasing their interdependencies.

Figure 7: Separation continuum and layering

Vertical separation of contexts in the organization, considers the following moving from abstract layering to platform implementation:

• Business Model – This layer represents the basic concept of “doing business”.

• Systems Model – The systems model deals with the portfolio of systems required to satisfy a specific business model.

• Applications Portfolio – Systems are required to automate required systems.



• Services Architecture – This architecture is concerned with the breadth of functionality needed to implement the business systems via the applications portfolio. A generic term that could be used here is “web service” or “service based architecture”.

• Component Architecture - The component architecture view presents a complete view of the business components that can be exposed as services. Components are typically course grained software elements that satisfy a particular requirement.

• Object Architecture – Components are created from object or other technologies and exposed as business components. Objects are the finest granularity of functionality in a typical system.

Application engineering [Atkinson] uses the concepts as articulated at the various levels in the continuum. Even though the concept might seem more “Platform Implementation” specific, it is not. Overlaps into the “Layering Abstract” become more apparent when systems can be constructed quickly, and the stakeholders decide to accept changes in this level rather than the technology [van Zylb].

This continuum also assists with application context realization [Atkinson]. Contact with the customer can start at a number of layers, as long as all the levels are covered by the time the product line architecture is defined. “Zoom-in” and “Zoom-out” concepts can be used in order to move up or down the horizontal continuum. This ability allows for a direct mapping onto the Model Driven Architecture through platform independent and platform dependent models [MDA].

6. Layering abstract

This continuum is concerned with the links that are required to ensure that the platform implementation is relevant to the environment or context within which it is required. These layers can overlap, and probably will, with existing business design and modeling methods. It is still required to ensure continuity.

Having an organization or a unit in an organization understand requirements in terms of the horizontal continuum, will greatly affect the benefits derived by business. From the systems model layer and below can form a critical map for the chief information officer or technology executive in that once continuity is achieved, all dependencies are understood and new development and packages product purchases can be seen in context of the overall organization.

6.1 Business model

This layer represents the basic concept of “doing business”. An example could be the way in which an organization deals with its customers with relation to the kinds of products provided. The business concept of “personal banking” is a way to deal with



high net individuals on a one-to-one basis, where “electronic banking” has no human contact.

Elements of the business model cannot be implemented directly into systems such as key performance areas and business scenarios, but can form a critical influence and success factor.

6.2 Systems model

The systems model deals with the portfolio of systems required to satisfy a specific business model. Looking at the example above, “personal banking” requires systems where individuals need to get to the client in order to perform the relevant process. “Electronic banking” provides a completely different kind of experience whereby the only human function might be to ensure that extraneous loan applications are dealt with.

The systems models must create sufficient know-how of the systems by understanding the automated and manual processes required to produce the required outcomes. Systemic thinking can be applied to systems to optimally design customer-facing processes to reduce latencies for example.

6.3 Applications portfolio

Systems are required to automate required systems. The software required to do customer management for example might be the same for both business models and the related systems. Differences will be prevalent when the various audiences use the software interfaces for example, the “electronic banking” user will have a specific means to maintain information, where the “personal banking” agent might have access to more information related to the client such as internal banking ratings.

A typical applications portfolio might involve software applications that might be classified as legacy. This means that this portfolio is the implementation view of the systems model without the manual operations. It does however show the relationships between human and machine, resulting in flow-of-activity-definitions that are specific to the way in which a certain role would utilize the software product.

7. Platform implementation

Product lines that cover a wide spectrum of functionality can only be produced if the underlying architecture is independent of the business functionality required by the ultimate user. Many architectures cover the ability to transform software developed objects and components from one area to the next. This has still proven to be problematic as the skills shortage and level of understanding of the architecture are critical elements in transforming strategic features into products.

This part of the continuum is most affected by standards usage. Standards help in the ability to integrate with diverse software assets, and settle the mind of the purchaser that



lock-in is minimised. But, “there are standards and there are standards”. The selection process of implementing standards is as important as selecting an entire architecture in some cases as these are closely interrelated. Standards also assist with basic requirements that need to be included to make architectures more competitive.

7.1 Services Architecture

This architecture is concerned with the breadth of functionality needed to implement the business systems via the applications portfolio. A generic term that could be used here is “web service” or “service based architecture”. It means that the application portfolio is constructed out of independently usable software components that are exposed as services. A typical service might be “customer management” that entails all the basic elements of maintaining information about a customer. Another related service could be “customer portfolio” that is the portfolio of account that the customer has with a particular institution.

Services must be defined in such a way that they can be used in a loosely coupled way. This means that an assembly process is applied to tie together the different functionality areas at run-time of the software system’s execution. People performing the role of assemblers, need not have the technical skill than that of a component builder or assembler. It should be made safe to tie together various services to make up an application. A concept such as contracts can be used to ensure that services have the correct inputs, produce the appropriate outputs and are controlled by means of pre- and post conditional checks.

7.2 Component architecture

The component architecture presents a complete view of the business components that can be exposed as services. Components are typically course grained software elements that satisfy a particular requirement. The customer management service requires a number of components in order to realize functionality for example, there might be different components to read customer information and create new customers. More generic components might be grouped together in order to realize more business related functionality for example when a generic storage management or security component is used. More generic components might have associated configuration environments to direct the behavioural and data usage principles applied.

Components within one technical architecture can be tightly coupled to ensure good performance. Tightly coupled means that there is specific work involved in getting components wired together, and they share and have optimal ways to execute using high performing techniques. Loosely coupling differs from tightly coupling by amount the work involved in wiring and architectural characteristics.



7.3 Object architecture

Components are created from object or other technologies and exposed as business components. Objects are the finest granularity of functionality in a typical system. The term is used in this context more generically than in object orientation. Data objects for example might be realized in a particular database technology, where connectivity might be realized using a particular transport mechanism. Functionality provided by objects are grouped and used as components.

Object usage would normally involve the use of an underlying technical architecture. It involves a programming model that has specific semantics, characteristics, and usage criteria. When used in programming, objects are applied in a tightly coupled fashion, meaning that programming would be required to change the way in which execution sequence is implemented for example.

7.4 Technical architecture

Architectural styles are described by five canonical structures:

• Functional structure is concerned with the decomposition of the functionality that is required by a system.

• Code structure is concerned with the key abstractions that are used to build a system.

• Concurrency structure is concerned with the units of concurrency that are refined into processes and threads.

• Physical structure is concerned with the physical implementation of the architecture and includes the hardware and networking requirements.

• Developmental structure is concerned with the administrative control of the system.

Each of these structures represents a number of challenges when realising features. Methods are needed whereby the anomalies can be removed from the software component and the business component builder’s process of assembling a system.

7.5 Design centric

A number of basic patterns have stayed the same over the history of computer systems. These basics are applied repeatedly in the design and development of systems. To be “design centric” means to be focused on the timeless concepts needed to construct systems. Patterns have been used to fill this gap to a certain extent. Programming languages have come and gone, but the basic design of language semantics and usage has stayed the same.



Design needs to take into account both functional and non-functional requirements when designing architectures.

Figure 8: Outline of the core software architecture design process [Bosch]

Architectural design always starts with a “requirements specification”. The requirements of quality and re-usable product line principles are typically not addressed in this phase. A first version of the application architecture is produced once all functional areas are integrated into the architectural design.

Quality attributes are analysed and given an importance rating. Qualitative and quantitative methods can be used to determine relevance of quality attributes. If all attributes are satisfied then the architectural design is complete. If the requirements are not met, transformation starts, whereby the architecture is redesigned, and reviewed a number of times. The effects on the application architecture need to be assessed and checked for desired results.

7.6 Using software as assets

The SEI’s (Software engineering Institute) report called “An Activity Framework for COTS-Based Systems” explains why COTS (Commercial off-the-shelf) based systems are different to other systems: With COTS-based systems, continuous, rapid changes driven by new mission needs, product upgrades, and technology advances are facts of life. An architecture that can retain its structure and cohesiveness yet allows the system to respond easily to these changes - an evolve-able system architecture - becomes an important strategic asset to an organization.

The componentization of software systems has brought about a new area of using software in a manner similar to the electronics of motor vehicle components. The drive towards common standards still seems to be the major obstacle as the industry moves forward with objects, components, services and agents. Each of these principles can be encapsulated, once available for use, as an asset owned by an organization.



Assets can be fixed or dynamic. Fixed software assets are the ones developed with a programming language that encapsulates the more volatile business definitions. Dynamic software assets are the ones where the behaviour and data requirements are loosely coupled, and fully configurable once deployed.

Principles of altering behaviour and information requirements of more dynamic assets can be applied in assembly processes.

There are always two dimensions to consider when designing systems for commercial use. Data is the first, and deals with the “remembering” of aspects of a system. Aspects are used in the context of behavioural concepts. COTS-based products present many challenges when trying to change the behavioural and structural aspects of the underlying functionality [van Zylb].

8. Assembling new product lines

Product lines are defined in order to satisfy a specific market need or niche. The process of determining which features to include should not be part of the assembling process. The focus should be on the tying together of predefined assets that come in the form of web services, components or objects.

Figure 9: Separation continuum and the flow of dependencies

Component and object architectures form the nucleus of software execution. Product lines are realized where the abstract layer joins the implementation layer. The diagram above shows that there are two ways to realize product lines:

• Top-down: The business model drives strategic initiatives from the top all the way to the implementation.

• Bottom-up: The architectures already implemented either present enablers or inhibitors onto the business model.



8.1 The product space

Each product line becomes an integral part of the larger product space. Flexibility is required with regard to the way in which product lines are assembled to cover a specific problem domain.

Product marketing defines the target usage of a proposed product before product development or product architecture is involved. This step is one of the most important processes, as the homework is done with regard to competition, pricing and usage of the product by a selected number of potential customers. Positioning plays an important role as the proactive development of software assets needed for product lines will reflect the business strategy. Potential customers’ needs are predicted and development might take place to produce prototypes to test the specific product space.

Figure 10: An example of patterns in the Rubico Assembler Tool

The four areas in the tool as shown in figure 10 are used as follows:

• The tree view on the left indicates the patterns as classified in the library that is being browsed. Personal banking is used as an example where the elements are structured based on the layers in the continuum. Note that the application portfolio and services architecture layers are not present – the library under view does not include the product line mapping, under normal conditions these will be shown.

• The area in the middle is used to give a contextual view of the selected element. Each pattern has abstract, behavior and abstract definitions as per the Y-Model [van Zyl]. The example shows a component pattern called “Masterfile – Standard” – and it contains six classes that are related in a pre-defined manner.



• The top most right area gives a detailed view of the pattern under view. It reflects the vertical continuum by indicating the user interface and non-visual elements.

• The bottom right area is where attributes for a pattern can be specified to give context and default properties. Additional attributes can be added to a pattern as usage over time might require.

The product line will be realized by creating an instance of the selected patterns. This instance will be given additional properties and attributes will be assigned values.

8.2 Core assets

Product lines are assembled from core software assets. If these assets do not exist, the production plan will schedule the development and other system life cycle activities needed, to produce a fully integratable asset.

Most effort should go into the refactoring requirements of assets as the ability to produce product lines with aggressive time-to-market deadlines can be a market winning strategy. Patterns can be used to deal with the refactoring requirements and should include all aspects of data usage, behaviour definition and interface standards.

COTS-based products are the ultimate realization of the concept behind software as assets. There are a number of challenges as integration with diverse architectures can present many obstacles. These obstacles can slow down the ability to take product lines to market successfully and, in turn, reduce the momentum of software asset development.

Core executable software assets are realized through the object, component and services architectures. Each layer has a different set of criteria that deals with abstraction, functional requirements and non-functional requirements. Components need to be abstracted [Doerr] in order to allow for changes in COTS-based systems over time. This requires a number of non-functional requirements to take preference over others for example, interoperability, becomes very important.

Certification of COTS-based systems needs to be taken into account when assembling product lines [Yacoub]. Functional attributes include the functionality inherent in the COTS component and quality of service criteria (like reliability ratings and security criteria). Structural attributes include understandability and adaptablility. Operational attributes relate to the execution environment and rate efficiency of implementation and user interface characteristics.

8.3 Producing product lines

Product lines are produced from software assets to satisfy a specific product space. This production exercise should be executed with vigour, based on processes that reflect mature capabilities. Scoping of product lines has posed challenges to the



production of product lines [Schmid]. Producing the product by using the “independent synchronised product delivery” [van Zylc] concept, poses risks to the team if the scope of the asset and overall product line is not clearly defined and communicated. The different parts being produced might ignore certain critical dependencies despite being constructed independently. Integration of all the parts must take place purely as an assembly process.

Domain analysis or domain engineering techniques are used to extract features systematically from existing stakeholders of a product line [Griss]. This process is cumbersome and can take a long time. [Griss] proposes that “aspect-oriented” methods can be used to simplify the process of delivering product line features. Each feature that is obtained must be realized in a fragment or code or component implementation. No effort should be made to try to manage the components while they are being built, but to only manage the features and aspects.

This brings up the fundamental issue that software-producing organizations have to deal with, and it being when do project versus product management apply. The most practical solution for the project manager that is customer facing, is to build the solution totally focused on the current customers requirements. The more strategic project manager will want to re-use the common solution that is being created.

9. Discussion

Product lines are made up of various software assets: those that are part of existing development effort and those that are classified as legacy. These disparate systems need to communicate based on the feature requirements and process definitions as defined by the product line. It is ideal to have the various architectures that exist separated. These loosely coupled systems can integrate easily if standardized protocols are used, for example XML over HTTP.

Figure 11: Separation continuum and four dimensions described



The diagram above shows an example of how the separation continuum can be used to classify application elements.

Human computer interaction is the domain where metaphors are implemented, and application and component flow described. An organization’s business and systems models have direct input into how the software products will be used, validations performed, and other specific designs that relate to the kind of business.

Business functionality must be in human readable form to reduce the reliance on specialist skills for changes to rules, for example. These rules relate to how the business really operates in the background. Background rules can obviously have a profound effect on how the human interaction will take place.

Once the human interaction and business functionality is understood, an implementation architecture needs to be selected.

Devices to deal with human interaction should be defined in such a way that optimal spread of usage and interactions are implemented practically. Specific software concepts are used to realize this.

Business logic execution deals with the platform implementation of the business functionality. Application servers using specific protocols and component execution methods are applied.

One concern of this implementation is that design architects try to deal with as many eventualities as possible, even for the unforeseen. Other projects like San Francisco found similar issues [Carey] as developers try and build “tanks”. The separation continuum must be seen as a means by which developers, architects, design specialists, and business analysts, to mention a few, can participate without having to “step on toes” when creating large and complex systems. The continuum takes into account some of the latest architectural principles for example the use of “web services” as a means to re-use someone else’s code.

10. References

[Atkinson] Atkinson C., Bayer J. and Muthig D. (2000). Component-based product line development. Software product lines: Experience and research directions. Edited by Patrick Donohoe. Kluwer Press. ISBN 0-7923-7940-3.

[Bosch] Bosch J. (2000). Design & use of software architectures: Adopting and evolving a product-line approach. Addison Wesley Press. ISBN 0-201-67494-7.

[Calantone] Calantone R. and Benedetto A. (2000). Performance and time to market: Accelerating cycle time with overlapping stages. IEEE transactions on Engineering Management. May Vol. 47, No. 2.



[Carey] Carey J.E. and Carlson B. A. (1998). Deferring design decisions in an application framework. IBM Corporation. ACM Computing Surveys.

[Clark] Clark K.B. and Fujimoto T. (1991). Product development performance: Strategy, organisation, and management in the world of auto industry. Harvard Business School Press.

[Constantinides] Constantinides C.A. Bader A. Elrad T.H. Fayed M. E. Netinand P. (2000). Designing an Aspect-Oriented Framework in an Object Oriented Environment. ACM Computing Surveys. March 2000.

[Doerr] Doerr B.S. and Sharp D.C. (2000). Freeing product line architectures from execution dependencies. Software product lines: Experience and research directions. Edited by Patrick Donohoe. Kluwer Press. ISBN 0-7923-7940-3.

[Dsouza] Dsouza D. (2001) Model-Driven Architecture opportunities and challenges. Kinetium. http://www.kinetium.com/

[Griss] M.L. (2000). Implementing product-line features by composing aspects. Software product lines: experience and research directions. Edited by Patrick Donohoe. Kluwer Press. ISBN 0-7923-7940-3.

[MDA] Architecture Board MDA Drafting Team. (2001). Model Driven Architecture a technical perspective. Document Number ab/2001-02-01.

[Pronk] Pronk B.J. (2000). An interface-based platform approach. Software product lines: Experience and research directions. Edited by Patrick Donohoe. Kluwer Press. ISBN 0-7923-7940-3.

[Schmid] Schmid K. (2000). Scoping Software product lines

[SEI COTS] SEI (2000). An activity framework for COTS-based systems. CMU/SEI-2000-TR-010.

[SEI Diffusion] SEI (1999). Perceived control of software developers and its impact on the successful diffusion of information technology. SEI CMU/SEI-98-SR-013.

[SEI PLP] Clements P. and Northrop L.M. (1999). A framework for software product line practice. Version 2.0, SEI.

[van Zyla] van Zyl J.A. (1999). Strategic product development. SPLC1.

[van Zylb] van Zyl J.A. (2001). Class of solution dilemma. IEEE Engineering Management Conference proceedings.

[van Zylc] van Zyl J.A. (2001). Product line balancing. IEEE Engineering Management Conference proceedings.



[van Zyld] van Zyl J.A. (2001). A model that deals with system complexity. PhD submission at the University of Witwatersrand, Johannesburg, South Africa.

[Yacoub] Yacoub S., Kaveri C. and Dehlin M. (2000). A hierarchy of COTS certification criteria. Software product lines: Experience and research directions. Edited by Patrick Donohoe. Kluwer Press. ISBN 0-7923-7940-3.



List of figures

Figure 1: Assembly and Product Line Architecture and the separation continuum.........2

Figure 2: Core asset development and acquisition [SEI PLP]......................................4

Figure 3: Product development and acquisition [SEI PLP] ..........................................5

Figure 4. Product funnel [van Zyla] ............................................................................6

Figure 5: Separation continuum................................................................................10

Figure 6: Separation continuum and major aspects....................................................10

Figure 7: Separation continuum and layering.............................................................11

Figure 8: Outline of the core software architecture design process [Bosch]................16

Figure 9: Separation continuum and the flow of dependencies...................................17

Figure 10: An example of patterns in the Rubico Assembler Tool..............................18

Figure 11: Separation continuum and four dimensions described ................................20

n

Documents

Product Line Architecture Product line architecture for enterprise size software infrastructure