So one thing I am starting to see in my journey deep into factories is the difficulty most people are having in understanding what exactly is a ‘factory schema’? I mean what does it actually look like?
I remember, not so long ago in fact, when I first encountered the concept called ‘A Factory Schema’ that it just did not sink in, it took quite a while to get it. There’s way too much talk about schemas, meta-this, meta-that, models and a bunch of other abstract terms. The factory schema still a fairly abstract concept in the documents we have publicly available today, so not many people come to the software factory table with a solid understanding and practical understanding of what a factory schema is and what it looks like. (of course this will become much clearer over time, as we flesh out the tools and realisation of a real factory).
I noticed recently I am not alone in this, that most people just didn’t get it the first time they encountered it. This is a shame, but understandable, because in order to understand the power of the factory schema and the benefits of having one in the overall vision of software factories, you have to overcome this mental block and realize what this actually means, and until you do – the rest of the factory description really has no context.
Like most solution architects/developers today, the term ‘schema’ has different meanings in different contexts. Like most, you know about database schemas, you also know about XSD schemas; as two of the most common examples of schemas in use today.
They are completely different realisations but really the same thing – a structured description or specification of something unique. This I don’t think is misunderstood. But there is something about a ‘factory schema’ that just does not fit into these familiar terms and understandings, and it does not quite make the connection initially.
Lets attempt to draw a parrallel with a well-known concept. When we talk about a database schema. I ‘see’ a database (Entity Relationship) diagram in my mind with a bunch of tables connected by relationships.
But this is an instance of another schema. The schema for the ‘database schema’ is the ‘database engine schema’ (for want of a better term). Something like this fragment below from a SQL database server.
The ER diagram for an instance of your particular database looks quite different to this ‘database engine schema’. That’s because your database schema (ER) diagram is an instance of this database engine schema.
Now, when we talk about a ‘Software Factory Schema’ we are normally confronted with an image of a ViewPoint as the central concept related to Activities, Roles, Mappings, with Activity related to a WorkProduct etc.
[the diagram below may not be the final version and may change slightly in the next few months or so, but its good enough for this discussion.]
But this is not the schema of your factory. This is the software factory ‘Meta-Schema’.
An instance of ViewPoints, WorkProducts and Assets etc defined for your factory is your ‘Factory Schema’.
Of course the ‘Factory Schema’ for your factory is a description – a schema, in the same way we think about an XSD as being the description of a particular instance of an XML document.
The schema for your factory (‘The factory Schema’) would be an instance of the factory schema (depicted above) specific to your factory. In the same way a database schema is an instance specific to your database.
SO now, you can now image what the XML representation for your factory might look like, with the XSD for that being the ‘metaschema.xsd’.
Now we don’t currently have a great way (or standard way) yet to visually depict the schema for your factory in the same way we can create an ER diagram for a database. There could be many ways to describe this at present.
We are working on a DSL model of the schema, which would allow you to model your factory visually. However, for now it might be easier to visualise an XML document instance of your factory schema, conforming to an XSD document which describes the ‘Meta-Schema’.