In a previous post I explained that Jezz and I are working together to prototype a different “approach” for authoring software factories.

In this experiment we are trying to validate this new approach based upon design ideas refined in the implementation of the EFX factory, and verifying that against the publicly available release of p&p Service Factory.

Basically, we think that we need to be able to let the factory author describe the ‘Product’ that is built by their factory at a higher abstraction level than we do now. We suspect that this approach will greatly help in improving the factory authoring experience and the factory user experience, which therefore simplifies software development as a whole.

Part of this experimental approach is describing the important concepts of the factory product in a so called “Factory Product Model (FPM)”. Below you can see a first attempt to model the Service Factory ‘Product’ in an experimental version of the FPM designer.

To make the example a little more realistic we introduced a few new concepts and made some assumptions.

For example we assumed it is possible to develop different type of services (entity services and process services) in Service Factory (there could well be others too). We did this to illustrate the concept of ‘Product Variants’. Which are basically one type of product the factory creates. Since a factory can create several variants of the product in its product line.

[Think of a ‘Product Variant’ as a very similar product but different in architectural definition, rather than something different in instance values of the concepts.]

Another assumption we made was that the difference between these services only reflects in the “service implementation” part. This is probably not completely true but we are only using these assumptions to simulate the situation where the factory enables us to build different family members of the service product line.

Figure 1. Factory Product Model for Service Factory 

The picture of the FPM for Service Factory shows us that we identified a “Product Variant” for each service type that is supported in (our imaginary) Service Factory. Also we identified the “System” product variant that makes it possible to group together any number of these services. We could have gone with one product variant for all types of services, but we wanted to define some that are different to validate the approach.

You can imagine then, that each product variant would be represented to the factory user as a separate solution template offered to them when they create a new solution using this factory. (In this case we would have 3 solution templates: ‘Entity Service’, ‘Process Service’ and ‘System’.

Looking at the concepts in the model, one interesting thing is the “Service Contract” concept; the (green) concept we are using, reflects that we will be using a custom Domain Specific Language for modelling Service Contracts in our factory. This custom DSL for modelling service contracts is responsible for modelling all the concepts that are defined within the “Service Contract” shape in the Service Factory FPM. This kind of model is called a Work Product Model (WPM), since it defines work products of the FPM. The child concepts of the ‘Service Contract’ concept will be refined in this WPM, and are represented here for logical structure.

The other concepts in the Service Factory FPM reflect common terms used in the Service domain that are therefore part of Service Factory. The concepts in this FPM will be represented to the factory user as a mechanism to “drive’” the factory. This view provides the user with a higher level abstraction than the current “Solution Explorer” view that is used in today’s factories. So instead of being confronted with all the technical details he can develop his services by using concepts that make sense to the service domain.

Figure 2. Example of the Service Factory Product Explorer

To make all of this happen, the next step would be mapping each concept in the FPM to physical solution structure, projects, and project items of Service Factory. Once that is complete, we define the assets (recipes, templates, designers, etc.) that will be used to create and configure these physical artefacts. Once configured correctly, the FPM is then used as a starting point for populating the factory schema for this factory. It already contains the definitions of all the work products, their assets.

Another idea we would like to validate in this experiment is the speculation that we can use the concepts modelled in the FPM to use as reusable parts in other factories. It would be great if we could find a way to just “query” this FPM (and/or factory schema) of a factory, and select the available concepts that we want to use to compose other factories from. You could imagine in this case that the ‘ServiceContract’ concept is self-contained enough to be reused in another factory (complete with DSL model and definitions).