Wolfgang Emmerich, CEO at Zuhlke Engineering
In the quest for speed of business innovation firms increasingly work on “platforms” that they can use to create derivative products and services in a much faster and cheaper way than if every innovation is developed from scratch. A good example of such a platform is iOS, which is at the heart of Apple’s innovation in mobile devices. iOS was developed for the first iPhone and it then became a platform for iPods, iPads and most recently Apple’s iWatch. Apple now market all of these products in different sizes and form factors and computational capabilities, but they all rely on iOS inside. The cost of producing any one of these products is considerably reduced by reusing the iOS platform for all of them. More importantly, the speed with which Apple is able to bring these products to market is extremely fast because they do not need to develop embedded software from scratch each time.
Apple have not only created the iOS platform, but in combination with the AppStore, it is the first mobile phone platform that opens up creating and marketing new services in Apps to developers outside Apple. Games consoles, fitness monitors, cook books, sat navs and a multitude of other products can be derived from the iOS platform by way of App development. With every App that is added to the AppStore, iPhones and iPads become more attractive to users. The AppStore therefore creates a network effect beyond the iOS platform itself that protects Apple’s investment and is one of the key reasons for the success of Apple and the demise of Nokia and RIM.
However, creating a platform from which products and services can be derived easily involves considerably more engineering challenges than creating a single product or service. What are these challenges and what software engineering methods and techniques can business innovators use to overcome them?
The first challenge that firms need to tackle is to identify features and quality requirements that are common across all products and services that will be derived from a platform and to distinguish them from those features that are specific to single products. Results from research into “Software Product Lines” give us systematic methods and techniques to tackle this. Andreas Metzger and Klaus Pohl published a good overview of Software Product Lines in a recent paper. A key technique described in this paper is “Variability Analysis”. It helps separate requirements that should be met by the platform (called “Domain”) from requirements for specific products and services (called “Applications”). There is a school of thought that suggests that Variability Analysis should be done before the platform is built and the platform should be built before products/services are derived from it. However, this smells a lot like big design upfront. Almost all platforms we have created have instead developed a number of products and services first and that experience has informed the variability analysis so we were able to extract the common domain requirements to build the platform.
The platforms also need to be constructed in such a way that it is easy to implement the differences that create individual products and services. A critical aspect for that is the architecture of the platform versus the architecture of the individual products and services. Practices around defining a Product Line Architecture identify different mechanisms for implementing variability between different products/services. The first one is configuration. The idea here is that one uses a configuration language that describes which platform components and which specific components should be built into a particular product or service. For example, the product line architecture of Eclipse, a popular integrated development environment, relies on the OSGi component model and OSGi containers. In Eclipse-speak these components are called “Plug-Ins”. The Eclipse platform then has a configuration language that can be used which Plug-Ins need to be loaded into the container to a particular Eclipse-based IDE.
Another common way to implement variability in a Product Line Architecture is through the generation of code or interpretation of a suitable Domain Specific Language. An example of such a DSL is the “Natural Rule Language”, which can define validation and transformation components for data warehousing. The NRL compiler generates Java components that can then be called from a platform for validating and transforming different types of semi structured data. We have used NRL in a number of platforms in the financial industry to validate derivative transactions or reconcile trade information.
Thus, by employing advanced software engineering practices, such as Software Product Lines, with appropriate Product Line Architectures, firms can render the daunting task of building a platform for the derivation of services and products more feasible.
Enjoyed this article? Why not meet the author at our CIO Event
Wolfgang Emmerich, CEO at Zuhlke Engineering
You have missed out some details, please try again.