There are lots of great tools for domain specific modeling - particularly the openArchitectureWare toolkit within Eclipse, MetaEdit+ and the rapidly improving DSL tools from Microsoft). There are also promising language workbenches from both a prominent ex Microsofter (I'll start linking to them again when they actually ship a public beta :-) ) and the MPS from JetBrains (the guys behind IntelliJ and Resharper) which was presented at Code Generation the other week in Cambridge.

However, when you start to look at support for re-use of models and model statements, none of the existing tools are designed out of the box to support efficient model reuse across projects. This posting will look at various concrete syntaxes for model storage and editing and their suitability for efficient model and model statement reuse . . .

[More]

I seem to have a worrying habit of making up my own terms. Whether it's the "Iterating Business Object" in the CFML world, "mixin injection" in LightWire or now "model statement" which seemed to confuse people who know a lot more about DSM and SPLs than I do (which suggests it's not a common term in the industry). So, I guess I need to explain my term as I'm yet to find a better word for it and it's a very important concept when you try to reuse models across a software product line . . .

[More]

There's pretty broad consensus and plenty of studies showing substantial business benefits from developing a software product line, but the question is usually how to fund the development . . .

[More]

A Software Product Line (SPL) is a set of resources that allow for the building of a set of similar applications more efficiently. Generally the ROI for a SPL is 3-4 projects. In addition, it's usually best to build a SPL around a known domain - if you haven't built at least a couple of applications in a particular domain it's unlikely that you'll make good decisions when designing the spl. Because of this, you need to be working in a domain where you plan on building at least 5-8 projects in the first year or two.

What's a Domain?
When I speak to a lot of developers, they often believe that they wouldn't profit from a software product lime because "every application I build is different". In my experience, as long as you build at least 5-8 applications a year (probably in the same programming language and on the same general stack - but not necessarily) you can probably find enough similarities to make it worthwhile to formalize the reuse of assets.

If all you do is build e-commerce applications or insurance quotation applications, you have a pretty well constrained vertical (business) domain (e-commerce or insurance respectively). If you build lots of different types of applications but they're all for the iPhone or are all web applications using Spring and Hibernate (or Railo, ColdBox, ColdSpring and Transfer), you'll probably find enough similarities within the horzontal (technical) domain. If you use different languages and/or frameworks, constructing an effiient horizontal spl may be more difficult as you'll have multiple target platforms and you're going to have to ensure there is enough conceptual similarity between the technical domains to be able to reuse your models. For example, it's possible to describe a generic UI DSL for generating the UI for both Flex and HTML web applications, but it's a non-trivial problem and depending on the level of customization required it may not be worth the effort. Similarly, while Seam, Seaside, Django and Ruby on Rails are all frameworks for building web applications, creating a single meaningful and useful set of abstractions which would allow you to generate to all of those target platforms would be unlikely to provide a ROI.

What's in it for Me?'
The benefits of software product lines is that they've been shown to consistently cut the cost of developing similar applications - by anything from 20% to 80% or more. There are plenty of cases where businesses are building applications using a software product line in a small fraction of the time it used to take, giving them a substantial economic advantage when developing projects.

Why Does it Work?
There have been so many silver bullets proposed over the year. At one time everyone seemed to think that all you needed was to use classes or (later) components and the re-use problem would be magicaly solved. Unfortunately there is no perfect generalized solution to the reuse problem. Classes are too granular a level of reuse and often require too much knowledge of their internals to customize them effectively. Component based development is great for a relatively small number of projects, but as the number of projects (and customizations) grows, the complexity of the component interfaes and/or configuration requirements makes the components unwieldy and hard to maintain.

Software product lines are not a silver bullet, but by providing a bigger, more powerful toolkit for customizing and configuring applications, they allow for the development of more complex product families while still keeping the complexiy of the system under control.

However, before you can profit from a software product line, you need to build it. And funding that effort is the first challenge - and the topic of the next posting in this series . . .

Want to know more about the practical application of software product lines? There is a new conference devoted to the topic - from the team who brought you Code Generation. Check it out!

Over the next few weeks I'll be posting a series on software product lines - what are they, why you should care, and what are some best practices for implementing them successfully. I've been really focused over the last couple of years on getting up to speed on everything from project methodologies (particularly lean and agile including concepts like emergent design and fields like complex adaptive systems), development best practices (especially the appropriate use of testing) and developer tools (git, Hudson, xUnit, Selenium, and even a greater familiarity with the command line and TextMate). I'm now ready to bring it all together along with a better understanding of Domain Specific Modeling to make a number of changes to my in-house software product line.

Perhaps the biggest surprise is how little I plan to change in terms of the overall approach. The more that I look at other approaches, the more I appreciate the system I've built as a really nice fit for my use case, but I'm looking forward to a lot of smaller refinements based on the last couple of years of learning.

Oh, and the bad news is I've just flown back to the US, so yes, there are *lots* of postings. The good news? I'll try to spread them out and I probably won't be flying anywhere for at least a month or two, so hopefully I won't go on another blogging binge for a while!

Want to know more about the practical application of software product lines? There is a new conference devoted to the topic - from the team who brought you Code Generation. Check it out!

In my last posting, I looked at how you can use statements in horizontal DSLs to implement configurations of a software product line. In this posting, I'm looking at some of the challenges we're wrestling with using this approach.

The problem with using statements in horizontal DSLs for implementing SPL configurations is that it isn't a common approach so it makes it hard to take advantage of existing DSM tooling such as MetaEdit+ or openArchitectureWare. Both have great tooling for working with DSLs, but leveraging them within a SPL appears to require some trade offs . . .

[More]

Many Software Product Lines use configuration management tools like feature modeling for managing the variability between their applications. The problem is that if you want to create hundreds or thousands of instances of a SPL, this approach just doesn't scale.

Back in 1999 I co-founded a company called The Strategy Factory in Houston Texas. The goal was to deliver "million dollar websites from a thousand bucks a month" . . .

[More]

If you build more than a couple of applications a year that have any commonalities at all, it's worth learning more about Software Product Lines (SPLs).

In this InfoQ video recorded at JAOO, Markus Voelter gives a great overview of approaches to managing the variability between the different projects you develop using a SPL.

Markus has a strong background in the Domain Specific Modeling world and does a great job of describing how DSM and SPL approaches to variability (historically DSM has focused on modeling using creative construction/unlimited variability approaches such as Domain Specific Languages whereas the SPL community usually focus on configuration and feature modeling based approaches to managing a finite set of configuration options).

Obviously this stuff is pretty core to my business (which is basically one big SPL for efficiently quoting, specifying and delivering well architected custom web applications - quickly and cost effectively). Anyone else out there playing with SPL's?

One of the interesting challenges when you have a software product line is determining how best to market the solutions you provide. A SPL is neither a product nor is it completely custom code, and while it can be hugely beneficial to both the developing company and their clients, the marketing of such solutions is a bit of a tightrope.

[More]

I've been getting more involved recently with the XP and test driven development lists. One thread that has come up is the appropriateness of unit and integration tests within a software product line. That lead to the following exchange which raises the question: "when does configuration become programming"?

[More]