Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Thursday, May 17, 2007

Product Lines and Platforms

In Software Product Line Engineering one of the core activities deals with determining the central assets common to all programs in the scope of the product line. These assets are not constrained to implementation artifacts but might contain models, aspects, documents, test plans, to name a few. Jan Bosch once proved that ad hoc re-use of assets does not work which leads to the conclusion that re-use of assets in product line engineering requires a more systematic kind of approach. It also implies that re-usable core assets do NOT represent a set of unrelated components, but rather should be combined in a predefined and more tightly coupled aggregation. Now, we are entering the universe of software platforms which denote the central fundament of software product lines. The glue of a platform might consist of different elements such as configuration files or DSLs & generators. It is noteworthy that the platform represents the central core of the software product line including all common components but also supporting the range of variabilites within the program family (BTW, I've already explained in previous postings how architects may analyze commonalities and variabilites.) From the platform all instances of a product line should be derivable by using configuration mechanisms, APIs, a DSL, or other means. If you think, you only seldomly face platforms and product lines, you are plain wrong. The Java JDK and the .NET Framework Classes are examples for such platforms such as all other commonly used APIs. From my viewpoint, all SOA based applications also represent examples of product line engineering.
Why this platform-based approach sounds very reasonable it also reveals some challenges. Suppose, different product line instances, e.g., various mobil phones, leverage a common platform, e.g., a software platform that includes all required communication stacks such as the UI, persistence features, power management, etc. What if one of these application projects requires a modification of one of the common core assets within the platform? There are different alternatives in this context. As precondition, I assume that the modification could not be handled by variation (using a kind of variability hook in the platform), but requires the modification of a common platform component. In a naive world, we would just derive a new branch of the platform without any impact on the other family members. It is a no-brainer that this alternative is unacceptable in the real world as further change requests could emerge each of them leading to a new specialized platform version. Thus, we would end up in a sea of platforms. This is of the same dimension such as asking Microsoft to provide a customized Windows for each customer. Why is this such a big problem? Suppose, that you need to evolve the platform in the future. How can you manage evolution facing a sea of platforms? In the best case, it will work with large efforts and costs, but lead to design erosion forcing the platform team to come up with a complete new platform every second or third product line generation. Needless to say, that the RoI through re-usability which was the primary reason to establish a product line won't be too impressive in such a scenario. Thus, we need another way of handling modifications! Any change request should lead to a modification of the platform. Yes, this will require all application projects to leverage the modified platform. When the platform is a significant part of the application, then we should be ready to pay this price for the sake of platform evolution. In such an approach the platform will be evolved in a systematic way, thus reducing the risk of design erosion. However, successful platform lifecycle engineering is not only a matter of implementation. The development organization must establish a team that is in charge of platform development with a clear interface (and firewall) between the platform team and the application projects which are building the product line members. Otherwise, we will end up in exactly the same approach as illustrated in the first alternative. Of course, a platform team is responsible to meet its customers' requirements. At the same time, a platform team should be empowered to reject all change requests that have a negative impact on the majority of application projects. Moreover, application projects need to synchronize with platform development, and also send change requests and bug reports to the platform team. For these co-operation aspects, an appropriate product line engineering process and tool chain must handle all synchronization and coordination issues. MDSD techniques (Model-Drived Software Development) help to decouple platform from application developers, while increasing productivity. This is the reason why MDA (Model Driven Architecture) introduces PIMs (Platform Independent Models) and PSMs (Platform Specific Models).
To summarize, product lines and platforms denote twins, because product line engineering requires the development of a platform that combines core assets in a common way, while integrating variability management. Unfortunately, platform development is one of the underestimated activities in product line engineering, which is why many projects fail. The reason for this is obvious. Each platform modification has an impact on ALL program family members and is not constrained to a single one-off-application. In addition, the situation gets even worse and messy if you consider the fact that a platform is not only a set of implementation artifacts but also includes tests, documents, models, aspects, among many other entities. Thus, only a systematic platform lifecycle engineering approach will help successfully develop and evolve program families.
If done right, product lines can save time and money. If done wrong, they will make developer life like hell.


  • Hi

    I work as a System Architect for a medium size company. One of our lines is STB (= TV Set Top Box) SW. I would like to add several more aspects of the problem.

    1 - The platform is not necessarily under your control. In my case some 30 HW models, 3rd party drivers, middleware SW etc.

    2 - Projects (typically relevant to a subset of HV models) are delivered asynchronously, so each project has its own platform version. Downloading STBs is an expensive process so platform enhacements are updated with the next project only, say, 2 years from now.

    3 In real life projects there is no clear decoupling of platform/application. I wonder how to persuade management to invest in restructuring SW.


    By Blogger Dan, at 3:08 PM  

  • Dan,

    your comment contains very valid arguments.
    Parts of your platform definitely won't be under control. It begins with the operating systems and drivers upto middleware, 3rd party components and libraries. Nonetheless, it always is a good idea to minimize dependencies on such 3rd party assets. Take the JDK or the Microsoft .NET Framework Classes as examples for such platforms. They use Wrapper-Facades to reduce dependencies.
    I also know the problem with the asynchronous development of platforms and products very well. Within Siemens the most successful product lines are those where there is some kind of synchronization planning. All examples where they did not resorrt to synchronization revealed severe problems whihc brings me to your third point. We definitely need some decoupling between products and platforms. Otherwise, two problems will occur: First of all, if platforms must adopt to different products you will end up with different platform versions which basically contradicts the product line approach. And the second point is that whenever platforms and applications are not decoupled necessary changes/extensions to the platform will be much more difficult. That said, I don't believe, platform and applications can be completely decoupled. After all we need to be able to build applications on top of the platform. The platform is only a means for effective application development. But to much high coupling and dependencies between individual applications and platforms will reduce re-use which is the main driver behind software product lines. Thus, my main argument for management would be the economic aspect.

    -- Michael

    By Blogger Michael, at 6:09 PM  

Post a Comment

<< Home