Re-Post: I have republished these articles to make them better accessible for search on the blog. This article has been published first in the Newsletter No. 2/2004.
This guest article by Jorn Bettin, Managing Director of SoftMetaWare, a consultancy that provides strategic technology management advice, introduces the mass customization concept as it applies to the development of mass-customized software products.
In the software engineering community the techniques and technologies necessary for mass customization of software are part of the discipline of software product line engineering. Mass customization of software is somewhat different from mass customization in other industries, where the transition is from mass production to mass customization.
In the software industry the transition to mass customization is about providing an economically superior alternative to both of:
* Manual development of off-the-shelf software products, which may or may not be configurable/customizable, and where the total cost of ownership is driven upwards not only by high costs for the base product, but also by very high costs for configuration and implementation.
* Manual development of expensive one-of-a-kind custom applications.
In other words the paradigm shift is from "massive manual customization and configuration" to "massive automated customization and configuration". The main objective is to raise the level of abstraction of software product specifications to a level that relates to the problem space rather than the solution space (software technologies).
The first step towards mass customization of a software product is the derivation of design templates for software products of a certain type from one or more prototype product instances. The design templates are then used in conjunction with user supplied specifications for a specific product to automatically generate a corresponding product instance.
In the world of software it is very easy to expose thousands of configuration options and switches to users, and the varying needs of customers have led vendors to continuously increase the degree of configurability of their products. Enterprise resource planning systems provide a prime example of extremely complex configurability, and in fact this complexity has become a major cost issue for those wanting to implement such systems.
Software product line engineering tackles this problem head-on by ensuring configuration knowledge is presented to the user in an intuitive format, and by ensuring the user can't create an "illegal" configuration. For example, when configuring a product, the user should be provided with a single selection of the country that the software is used in, rather than separately needing to specify country-specific address formatting rules, date formats, legislation options for accounting, etc. In software product line engineering a process of domain analysis is used to uncover the deep domain knowledge required to build domain-specific [configuration/specification] languages that prevent users from creating "illegal" configurations. In many cases software product instances can be drastically simplified by applying some product specifications at "product generation time", i.e. before the software is compiled and deployed in a specific environment. This approach minimizes the post-installation configuration effort, and often it also reduces the overall size of the software, which is less of an issue for enterprise systems, but can be an important factor in the development of embedded software.
So far the theory. In practice, time-to-market requirements usually don't allow the significant ramp-up period postulated by most software product line engineering methodologies. At OOPSLA'03 (http://www.oopsla.org), a group of researchers and practitioners met in a birds of a feather session to share their experiences. The objective was to define the foundation of a new paradigm for software development that builds on software product line engineering principles, but which also is compatible with the principles of the Agile Manifesto (http://www.agilemanifesto.org). The result is a paradigm called Model-Driven Software Development (MDSD).
The relationship between MDSD and software product line engineering can be compared to the relationship between Component Based Development and Object Technology: One builds on the other, and the terminology of MDSD can be seen as an extension of the terminology for software product line engineering. The concept of core assets from software product lines carries through into MDSD and is directly reflected in "Industrialized Software Asset Development", the subtitle of MDSD.
What sets MDSD apart from classical software product line engineering is the emphasis on a highly agile software development process. One of the highest priorities in MDSD is to produce working software that can be validated by end users and stakeholders as early as possible. This is consistent with the major shift towards agile software development methodologies in the industry. MDSD provides the scalability that is not inherent in popular agile methodologies such as Extreme Programming.
Further Reading
Model-Driven Software Development, http://www.mdsd.info
Jorn Bettin, 2004, Model-Driven Software Development: An emerging paradigm for industrialized software asset development, http://www.softmetaware.com/mdsd-and-isad.pdf
Jorn Bettin, 2004, Model-Driven Software Development Teams: Building a software supply chain for distributed global teams, http://www.softmetaware.com/distributedsoftware-product-development.pdf
Carnegie Mellon Software Engineering Institute, Software Product Line Practice, http://www.sei.cmu.edu/plp/plp_init.html
Contact the author at Jorn Bettin, [email protected], www.softmetaware.com, Tel +64 9 372 3073