File | New | 'Blank Problem' (Part II)

  • Article

So, we have now had a pretty thorough look at what a factory schema is in a number of previous articles, and now how it can be used from both the factory builder’s perspective and also the factory user’s perspective.

In this article, I wanted to dig a little deeper in usage of the schema and demonstrate how it could provide the vital link between the defining of a problem and the finding of the right tool (factory) to implement the solution.

In the previous article ‘File | New | Blank Problem’ we explored a vision of the future of software development where we could start our development project by exploring the problem domain first, separate from the trappings of technology constraints (purely business requirement capturing). We use a set of relevant and related graphical design tools that interpret the expressions you make on design surfaces that interactively evolve into a definition of the problem domain you wish to address. Once we have that problem definition, after adequate refinement of these expressions, it was then only a matter of having the tools search for and suggest the right tools to help design the solution domain.

 You may know by now that software factories are going a long way to address the concern of defining the solution domain in higher abstract terms and providing domain specific solutions. But we still don’t have either a mechanism to capture problem expressions and interpret them into a problem definition. That is currently up to the individual, and whether they have tools, the right tools to capture this rich information in the early stages of design. We also don’t have a way to match a problem definition with a toolset (factory) that could provide the solution implementation – or do we?

One aspect of the factory schema that has not really been explored yet is the factory's ability to expose its description externally to prospective factory consumers. The factory schema is so far, only geared towards describing the internal workings of the factory. You still have to know about the workings of a factory and what it produces in order to use it effectively.

For example, it would be possible for a factory to define a set of pre-conditions that must be satisfied in order to start to use the factory, and a set of macroscopic Work Products it produces.

As an example, the 'EFx Factory' requires that you at least provide a ‘napkin description’ (in any media form) of the applications and services you which to construct in the factory, a product name, company name and the names of the applications or services you wish to construct. These are the pre-conditions of using this factory.

Without this basic information, the user will find it hard to get started using the factory. All factories will require some pre-conditions of use, (unless of course, the factory is not very specific, or maybe it can make these assumptions to begin with).

In order to encourage adoption of available factories, we are going to have to find a way to classify and advertise them in a meaningful way using a standard set of agreed upon semantics (taxonomy). Without this description, development processes will be slow on the uptake of factories for the simple issue of perceived unavailability of them. If people don’t know about them, how can they possibly use them? It’s a very common problem in software development today which hinders reuse, leading to all kinds of fruitless efforts and resource wastage. Ironically enough, factories were formulated to address part of this problem in the first place, by removing the requirement to own the knowledge and experience to implement solution domains.

So imagine we had a description of the factory which could be exposed to those interested in searching for and using this factory. This meta-description would contain a description of the factory’s solution domain, its’ capabilities perhaps even how it works, the technologies, versions and platforms it uses etc, certainly its main work products. Some of this information would of course have to be meaningful to the machines reading this description, as well as the human consuming it.

So, for now, side-stepping the challenging issues around how to classify this information and what semantics to use, this capability would become a powerful mechanism to track down and select a factory that suited a specific problem definition.

Connecting the Dots

Once we had this description, and an effective standard way to expose it to consumers, we only need to be able to pattern match this meta-description to someone searching for a factory to suit the right problem domain.

In the previous article on ‘Problem’ files, we saw that when we have tools good enough to decipher human expressions from a number of design surfaces into a meaningful problem definition, these problem definitions could start to yield a set of conditions to match those of a factory’s set of pre-conditions.

If we could do this, then we could suggest to the user a set of relevant factories to help them solve the problem. The user could then pick and choose, perhaps even try out, or even compose a larger more specific factory of their own with smaller factory pieces each addressing a part of the problem definition.

Today, we rely too much on the individual knowledge of the people designing the software to locate the correct tool, component, solution for a problem domain. Our stamina for finding and selecting the right tool for the job is very low, and often we resort instead to authoring our own tools convincing ourselves that no one could possibly have provided anything similar or useful enough for our problem. We attempt to use average generic tools to describe the problem domain, and very quickly converge to the ‘solution-first approach’.

Software factories can help us to a certain extent in abstracting the solution, but so far, they are not chartered with capturing problem expressions and definitions.

We need to start thinking about the separation of the two domains (problem and solution) if we are to succeed in this effort. Today, we are a fair way from ‘smart design surfaces’ that can interpret drawing and textual expressions into a problem definition sufficient to suggest a relevant solution. But, today’s technology is rapidly advancing. We already have inking and natural language technologies to recognise human expressions. What we now need is way to interpret those expressions into a definition of a standard problem or variant of that problem. Factories provide the obvious means of mapping from the problem definition to a solution definition, and the factory schema is the key to enable this link.