Why Restaurants aren’t run by the Software Industry (part 2)

  • Article

In my last post, I discussed some assets that restaurants enable to deliver high quality dishes on budget and on time. I truly believe that in the software industry we have to step up to the next level of predictability, quality and efficiency. Software Factories are a long term vision to improve productivity and predictability across the software life cycle. Let’s have a look at the four “pillars” of Software Factories and how they address some of our pain points in our industry:

Software Product Lines

Product lines help to avoid expensive and error-prone one-of developments. In our restaurant example, once the core dishes are defined, a customer may still choose his preferred type of meat (configuring) or he might even be able to convince the kitchen to use tofu instead of one of the meats on offer (customization). But most of the processes, the ingredients and the used tools are still the same and therefore well planned.

In Software Factories, Software Product Lines are described as following:

  • Build new solutions by assembling partial solutions and/or configuring general ones
  • Specify only the unique features of each solution and assume the common ones
  • Variations in requirements map predictably to variations in artifacts and processes
  • Reduce custom development by 40% to 80% for the typical solution

Software Factory Schemas

The Software Factories Schema describes how the different assets (tools, patterns, guidance…) are aligned with the supported viewpoints for the whole software lifecycle. In our restaurant example, the waiter presents you with a menu. Every item on that menu has a clear relationship to a dish preparation process. Every stage of this process lists recipes, ingredients, essential preparation steps (such as heating a plate) and the transition between these stages.

In Software Factories, Software Factory Schemas are described as following:

  • Define viewpoints that identify and separate key stakeholder concerns
  • Organize tools, process and content by viewpoint
  • Relate and integrate life cycle phases, system components, and levels of abstraction

Model Driven Development

Models are used to formally express the artifacts of a certain domain. The menu is a formal way the restaurant presents its customers the available dishes. It usually consists of a name, a price and optionally a number and/or description. Sometimes it also lists available variations such as the different meat. In most cases, menus are easy to understand and are the preferred way of communicating the available dishes to the customer. Different type of restaurant may require different type of menus to ensure they speak the language of the customer (pizzeria vs. gourmet restaurant).

In Software Factories, Model Driven Development is described as following:

  • Create highly focused custom languages for specific problems, platforms or tasks
  • Develop custom tools to support them
  • Use metadata captured by models for automation

Guidance in Context

Context-less guidance is not very useful because different project types require different decisions. Guidance in Software Factories is valid in a certain context and is optionally supported by automation. Having well described recipes in place allows the restaurant to distribute some of the work to less experienced stuff. The chef just has to ensure that the recipes are not too generic but explicitly tight to the menu he is going to prepare.

In Software Factories, Guidance in Context is described as following:

  • Provide guidance that helps practitioners know what to do and that helps them do it
  • Build installable packages containing organized sets of configurable guidance assets for common use cases
  • Attach guidance to steps in the process and parts of the architecture
  • Scope process steps with pre and post conditions to let project work flow vary subject to constraints

Resources

If you’re interested in learning more about Software Factories, here’s a list of resources: