Jezz Santos : Factory FAQ

FAQ - How does EFx Factory differ from the Web Service Factory?

jezzsa — Wed, 17 Jan 2007 12:50:00 GMT

Naturally, I get asked this all the time.

What are the differences between the 'EFx Factory' and software factories such as the 'Web Service Software Factory' from patterns & practices?

[Now, I do need to say this, I do work closely with the patterns & practices teams who built Service Factory, in fact, I am still a member of the expert advisory board on that project. So, I do need to be careful how I word this :) or Don and Tom will kill me.]

My aim here is to give a fair comparison between the two factories from the point of view of the customers using them and market assessing them. What is available today, and what customers can expect to see from factories in this space in the future (especially from Microsoft). Therefore, this is not about how they were implemented technically, but more about how they are designed, and how they are used to do what they do from the customer end-user perspective.

I thought this was going to be a brief post, but I was wrong again. (I'll get there eventually).

[I'm using colour to distinguish the answers for each factory, and aid readability (hopefully). Not here of course, but below.]

Backgrounder

The Basics

The Web Service Software Factory (Service Factory) is a released public available deliverable from the patterns & practices group. Currently, it's in version 2.0 and addresses building secure ASMX or WCF web service layers and building data access layers.

The EFx Factory is a limited, unreleased, prototype offering developed within Microsoft Consulting Services. Currently, version 0.9 and not complete or released. It provides the end-to-end architecture for building both Client Applications and Web Services with a choice of any combination of technologies.

Both factories target similar problem and solution domains and are both founded upon well known .NET architectural patterns and other assets and deliverables from the patterns & practices group.

Let’s have a look at both factories from a high level, and then we’ll consider the differences in detail in the answer below. If you are familiar with these factories already, then skip this part and move straight to the answer section below.

Web Service Software Factory (Service Factory)

The objectives at the start of this project (circa start of 2006) were to make building web services easier, quicker and provide the right guidance and patterns to implement them. At the time of inception, the application of Software Factories was not well understood and the DSL toolkit was in its infancy. GAT was a recent enabling technology investment made by p&p which steered them to more automation than modelling approach. The p&p project team (consisting of some web service pattern legends: Jason Hogg, Don Smith et al. and a number of key industry expert advisors and leaders from our partners and customers) had heaps of valuable web service guidance to put into the factory.

The approach taken was focused on implementing web service patterns with ASMX, and now WCF technology, and on providing the factory user with the source code and solution structure to flesh out the service functionality. Using available p&p deliverables such as GAT, a set of Guidance Packages (GP's) do the code generation from a set of recipes and wizards which capture the user’s settings and generated configuration and source code (via the Text Templating Engine). From there, the developer is expected to enhance the generated source code in order to complete the solution. It also includes recipes for automating some common development tasks. As well, the deliverables include a great deal of invaluable documentation, reference implementations, and guidance for designing and creating web services and implementing web service patterns today.

You can find more details about the features of Service Factory here.

EFx Software Factory (EFx)

The EFx Factory evolved from an Architectural Application Framework called 'Enterprise Framework' (circa 2003) which itself is founded upon Enterprise Library and a number of other application blocks. The project was initiated internally within Microsoft in response to demand from customers and partners for a implementation of the .NET architecture and enterprise development patterns prescribed in written form from the patterns & practices group. Over a long period of time, the framework has encapsulated these patterns implemented on the .NET framework and has refined class libraries to aid the construction of client applications and services according to these architectures as the .NET platform has evolved. The net result of using the architectural application framework was that a developer need only write a small amount of source code to complete a service/application. The software factory that evolved from this framework (circa mid 2005), focused upon the modelling, tooling and automation of the variability points of the architectures of the client applications and services. The framework provided or pointed to most of these abstractions that would have otherwise have been coded directly to the framework class libraries. The primary focus of the factory has been architectural guidance, usability, and the separation of the technologies that would be used to implement various layers of the architecture. In effect, the factory allows any technology, pattern or strategy to be used to implement the various architectural layers, which promotes re-use and composability of factory variants.

You can find more details about the features of the EFx Factory here.

Answer

So let’s have a look at the key differences of these two factories, in detail.

[For the purposes of this comparison, we are only going to compare the ‘services’ that are built with the EFx Factory to the ‘service’ that is built with the Service Factory.

The EFx Factory actually assembles not only ‘services’, but also ‘client applications’ and also ‘systems’ which are a combination of multiple client applications and multiple services together as one product.

Furthermore, the EFx Factory is somewhat of a different generation of software factory, being much closer to implementing the pillars of factories (Model-Driven Development, Architectural Frameworks, Product Lines, Guidance in Context) and raising the level of abstraction to logical design rather than physical design, so it's not really a level-playing field to do an exact comparison.]

Factory Mechanics

Service Factory is the following:

A set of Guidance Packages, one per technology and architectural layer: ASMX, WCF, SQL. These create initial solution structure, and primarily generate source code artefacts for each layer directly into the solution structure, invoked from projects in the physical solution structure.

EFx Factory is the following:

Guidance Packages to create initial solution structure, and create the logical work products of the architecture, invoked from a view of the logical architecture of the product, DSL models and Visual Studio Application and System designers.
DSL designers to visualise and define the 'specification' of the internals of the applications and services.
Factory runtime tools & runtime services to provide, view, and manage the Product Model, exposing a public automation API of the factory and its product.
A pluggable technology extensibility mechanism (models and programming interfaces) for other 3^rd party factories to plug in and extend and enhance the provided technology-independent models - enabling re-use and composability.
Integrated extensions to the Distributed Application and Systems designers of Visual Studio, enabling top-down development of the service.

Assets

Both factories deliver guidance assets that automate the development of the factory product (the service).

The guidance assets included in Service Factory provide invaluable guidance for service implementation of WCF and ASMX technology web services, and data mapping to and from a SQL database. These assets include a number of key innovations in web service patterns and secure web services with class libraries to implement common concerns in building services (i.e. Exception Shielding, Versioning etc.).

The factory delivers comprehensive written guidance on web service architecture, and message exchange patterns, to aid in completing the services which it initiates.

It also includes reference implementations to act as examples of what the factory can create using this guidance.

The EFx Factory core assets are based upon service oriented, and enterprise architecture patterns, separating the architecture and design of a web service from the technology implementing it.

The factory includes an Architectural Application Framework, itself an abstraction of Enterprise Library, and this framework underpins the models and artefacts which the factory creates.

The factory also includes a reference implementation, but minimal documentation of its use.

Solution Structure

Both factories provide solution templates that determine the initial physical solution structure (solution folders, projects, and layout etc) of a service.

Both use recipes to define the structure and naming of the solution and its artefacts. The physical solution structure is viewed using the familiar ‘Solution Explorer’. Both factory's solution templates can be customized, in both structure, layout and naming.

Both factories use metadata on the created artefacts (solution folders, project etc).

In Service Factory, this metadata determines the ‘responsibilities’ of the containing artefact (solution folder, project). The metadata denotes the type of physical artefacts that are contained in the container artefact, and furthermore determines what actions (recipes) can be applied to them.

The assignment of these responsibilities is configurable by the factory user.

In EFx Factory, this metadata exposes the meta-model of a logical work product the factory is assembling (i.e. a service interface or business component, etc). In other words, a containing artefact (solution folder or project) is the physical representation of one of the logical work products of the service (i.e. Service Interface, business components, data contracts etc).

The metadata describes the actual state and properties (configuration) of the work product, and the containing artefact (solution folder, project) contains the physical artefacts of that work product within it.

The work products of the service are configured in a separate view of the factory’s logical product in another window called the Product Explorer. This view shows the logical architecture of the service.

The EFx Factory maintains a runtime mapping between the work product in the ‘Product Explorer’, and its artefact realisation in the ‘Solution Explorer’. This separation (physical from logical) enables the factory user to re-arrange the physical structure to focus upon the deployment of the solution, rather than mixing that with the logical architecture of the service.

Artefact Generation

Both factories use GAT recipes and wizards to automate the creation of artefacts or work products of a service.

The Service Factory uses recipes and wizards to either generate source code, or to configure generated source code (on compiled CLR types), and automate some common development/debugging tasks. Source code artefacts are generated and assigned directly to the solution structure.

The EFx Factory uses recipes to create the work products in the logical architectural model, and recipes to configure the metadata of the work product in the model. In this way, the logical architecture of the service is separated and abstracted from the physical implementation of it.

Some work products of the service are represented in more detail using DSL models, and recipes are used to configure those models directly.

The factory also uses recipes to automate the restructure and renaming of physical artefacts representing the work products. For example, renaming a work product will require renaming certain physical artefacts and namespaces.

The EFx Factory defers and delegates source code generation of the work products to 3^rd party pluggable factories at designated times in the development lifecycle of the product. The factory itself is responsible for the generation of the solution structure artefact containers (solution folders, projects), and the assignment of generated source code artefacts (from 3^rd parties) to these artefact containers. This process is managed through the factory runtime.

Models, State and Process

In Service Factory, the source code is the 'model' of the service (albeit a 'weak' model). When creating the work products of the service (data contracts, service interfaces etc.), a recipe is invoked from the physical solution structure (solution folder, project in Solution Explorer) according to the assigned responsibilities of that folder or project. (See previous sections). The wizard alone provides the abstraction of, and the configuration for the 'work product' (although there is no formal concept of a 'work product' in Service Factory per se). Once the wizard is completed by the factory user, it generates the required artefacts straight into the current solution folder or project.

There is no ‘state’ of the service expressed anywhere - except in the source code of the service. The factory (not surprisingly) provides no round-tripping or reverse-engineering of the source code, so there is no way to view this 'state' at a simplified (abstract) high-level.

As there is no state, and the recipes are keyed from the assigned responsibilities on an solution artefact (project or solution folder), it's difficult to determine what activities have been performed, and what needs to be done to complete a service. The user must be aware of (or will have to discover by right-click trial and error) which recipes are assigned to which solution folders or projects. Furthermore, they must be very familiar with the process of how to complete a service and in which order they have to execute these recipes to complete the service.

Furthermore, the user must know at what stage of the overall process they are in, as this is not depicted anywhere. This is problematic when development of the service is shared between team members.

If the user needs to change something about the service that was generated by the recipes before, they either must re-run the recipe, and recall how they configured the recipe previously beforehand. The recipe will overwrite any customization to the generated code (if any) although the user is warned of this. Or alternatively, rather than re-run the recipe and recall all the settings used previously (usually in the case of a small change), the user can modify the generated source code by hand to make their change.

The Service Factory does provide additional Code Snippets to create the most common artefacts. However, these last options are the realm only of technology domain experts, and the benefits of automation that the recipes provided is really lost.

The EFx Factory provides (and persists) a model of the entire product (service) and all its work product instances. The product is managed in the Product Explorer view.

The primary work products have graphical DSL designers in which their architecture is defined. Recipes are used to configure these models. Because of this visual abstraction, the user (and his teammates) can more easily visualise what state the service is in and what steps needs to be taken to complete the service. (This is aided by validation, discussed later).

To create or modify work product instances, recipes are invoked from the models themselves.

The models provide the appropriate abstraction of the components of the service, its' variability points, and the state of the product and work product instances. The recipe wizards reflect this state when they are run, and instead of generating code directly, these recipes act upon the work products and product model itself.

To enhance the usability, and increase the productivity of using these models, and creating work products, the factory provides a number of specific editors, recipes and wizards to configure these models.

Abstraction & User Level

In the Service Factory, because the 'model' of the service is in the source code, source code is essentially the medium that the factory users must manipulate to create, configure and complete their service. This is a low-level abstraction of the solution domain.

All manipulation of the service is done via the 'Solution Explorer' view, which is the detailed physical view of the solution, (and best suited to display the deployment of the solution, not it's logical architecture). As long as this is the working view, the level of abstraction will always be at the source code level.

As there is no state of the service, and no state of the process to completing the service, the factory user will always have to be a 'developer' class user familiar with the the overall process of constructing a service from the current state of the source code (as a whole).

In most cases, to modify or enhance this 'model' this developer will require expert domain knowledge and experience of the technologies implemented by the factory.

The 'Guidance Explorer' does help provide a list of steps to complete certain processes, (and a log of the recipes executed previously), but it still does not provide a clear, reliable picture of where in the process the developer is and what needs to be done next.

In the EFx Factory, the model of the service is visualised in DSLs and in the Product Explorer. The model offers high-level abstraction of the web service architecture and patterns, and holds the current state of the service. Furthermore, these models do not depend on any technology.

To change the service the user simply uses the visual abstractions (models, explorers) used to view the models.

The factory user can be any technical user that is familiar with the patterns and architecture used by these abstractions.

The user can create the specification of a service without ever having to have any detailed experience of the technologies used to implement it. However, eventually, a technology domain expert will be required to apply and optimize the various technologies at some stage, but this activity can be deferred till later in the lifecycle of the product.

Designer Integration

The Service Factory does not leverage existing models or facilitate high-level top-down development of services.

The EFx Factory integrates and extends the Distributed Application and Systems designers of Visual Studio (Team Architect Edition if installed). The factory provides additional shapes to represent the implementation of a service, and enables implementation of the service straight from these diagrams using the project templates provided by the factory.

From the Distributed System Designer, the EFx Factory allows the user to drill into theses shapes to expose its' internal specification.

Validation & Completeness

In the Service Factory, since a weak 'model' of the web service is effectively defined in source code artefacts themselves, Service Factory can do little (apart from depending on the language compiler) to validate whether the web service source code artefacts have been created at all, in the right order, correctly or completely to form a valid and complete web service. Although, in principal it's possible to create recipes to perform this kind of validation at a course grain level.

The WCF guidance package does add FxCop code analysis rules that help verify the completeness of some WCF related code.

The EFx Factory has a comprehensive model of the service as a whole and the individual work products. The factory performs comprehensive validation of this model before any source artefacts are generated from it. In fact, this validation is a prerequisite to generation of source artefacts. The factory prevents the user from making invalid architectural configurations, and ensures the work products are configured correctly and completely.

This validation guides the factory user in pre-empting the tasks required to complete the service.

Architectural ‘concerns’ (cross-cutting concerns) for each layer in the architecture are defined in the model and enforced through validation, ensuring that these concerns are addressed appropriately, and the service complies to these enterprise-level concerns.

Architectural Coverage

The Service Factory guidance packages provide automated guidance assets (recipes, templates etc) for the generation of the Service Interface and Data Access Layers of a service. It addresses the middle layer Business Logic implementation and wiring up of the Service Interface and Data Access layers through written guidance, and customization of the source code. The Service Factory provides no guidance about architectural concerns of these middle layers, although there is plenty of written guidance available elsewhere on this.

The EFx factory provides a comprehensive architectural model of the entire service end-to-end.

The EFX factory models all the architectural layers, and their individual cross-cutting concerns (like: Authorization, Exception Management, Logging etc) at all layers in the architecture.

The models define the interaction between the components (method mapping & entity mapping) in the layers. The wiring up of the Service Interface to the Business Logic Components is automatic.

Since Business Logic implementation is difficult to model (too many technology patterns and strategies). The factory instead offers a pluggable technology strategy to implement this layer. This strategy then wires up the business logic components to the data access layers. Common strategies are: custom coding, sequence diagrams and workflow activity diagrams, each of which is provided by a 3rd party factory that can use any pattern or technology to model this layer.

Service Implementation Technologies

The Service Factory comes in two technology flavours for the service interface- WCF or ASMX, and one flavour for the Data Mapping - SQL. In order to create a 'specification' of a service, you must make a technology choice before using the factory. Once that choice is made, you are tied into that technology implementation – it is very difficult to change that technology decision later - and you'll need to start from scratch again. There is no de-coupling of technology implementation from architecture of the service – so you can’t create a design and specification of your service without first choosing a technology.

The EFX Factory separates the architectural specification of the service from the technology used to implement it - using a technology-independent model.

By providing these technology-independent models of the service's internal architecture, and a rich extensibility mechanism for other factories to plug into this factory, the EFx Factory enables the layers of the service to be implemented by any technology.

Furthermore, there are several layers in the architecture that can be extended, primarily: Service Contract Implementation, Business Logic Strategy and Data Mapping Implementation.

In each of these cases, a 3^rd party software factory specialising in a particular technology and architectural layer, can plug into the EFx Factory and implement that layer. They do this in a number of ways:

Enhancing the technology-independent model views with technology specific implementation metadata, commands and UI cues.
Providing separate technology specific views when that technology addresses work products not present in technology-independent view, or when the technology is best presented in a different view from that provided by the factory.
Providing technology specific implementation of the layer.

The EFx Factory, through technology separation and this extensibility mechanism, promotes 3^rd party domain experts to produce the authoritative abstractions and implementations of specific technologies of these layers for re-use. These implementations, themselves software factories, will then address and promote a standardised model of these layers. This then promotes re-use of these software factories in other similar architectures of other software factories.

Composability & Re-use

In Service Factory, the recipes to create the structure of a service are based upon a specific technology. Because of the lack of a 'model' and separation between the service specification and the technology implementation of that service, the recipes are bound to a specific physical implementation which they create – they assume certain source artefacts (CLR types) in a certain structure. This makes the assets and recipes very hard to re-use in other factories with different physical implementations.

The EFx Factory separates the model of the service from the implementation of it. The implementation is provided by 3^rd party factories based upon the logical architecture of a service layer. When these 3^rd party factories create physical artefacts for the layer, (specific to their technology), they don’t populate the physical solution structure directly, since they have no coupling to or knowledge of that. Instead, they pass the artefacts to the factory, and the factory, through its physical<->logical mapping determines which physical artefact container (solution folder, project) these artefacts will be assigned to.

Since the 3^rd party factories are only bound to a logical architecture, they can be re-used by other factories sharing the same logical architecture. This means that other factories can be composed using these factories.

Availability & Support

Service Factory is a freely available, released, documented, tested and supported deliverable from the patterns & practices team. It will continue to evolve as the .NET platform and emerging software factory platform evolves. This deliverable will continue to receive support from the patterns & practices team, and the development community as a whole.

EFx Factory is not finished and is not released to the general public. It was prototyped internally at Microsoft, but has not received the necessary development, testing, documentation resources and support to move forward as a releasable deliverable.

Summary

The Service Factory represents the first generation of software factories from Microsoft, which has made a significant step towards the creation and automation of web services.

The Service Factory is primarily focused upon the automation of web service implementations and patterns for specific technologies, using a wizard-based code generation process.

Its' very valuable guidance assets provide the best patterns and guidance for implementing web services and managing their lifecycle and operation.

This factory is available and supported publicly today, and is successfully being used by many of our customers in production to help them build web services more rapidly today.

The EFx Factory represents a prototype of a new generation of software factories within Microsoft, which has pioneered many of the concepts representative of future software factories from Microsoft tomorrow.

The EFx Factory is primarily focused upon logical architectural design, designer integration, automation, usability and architectural re-use and composability.

It provides a managed automated environment that uses and leverages many abstractions, models and extensibility mechanisms to present an end-to-end logical architectural view of a product, enhancing that with a rich design experience for the user.

It has no dependence on technology. Instead, it provides architectural-based technology-independent models that can be extended by custom technology-specific providers, promoting re-use and innovation in the community.

In turn, the core factory and the technology-specific providers can be re-used and packaged up to compose other factories to solve specific solution domains.

This factory is not publicly available and remains an unfinished prototype.

Moving Forward

Despite the significant advantages, and advancements that the EFx Factory offers in automating the assembly of service oriented client applications and services, Service Factory (and Web Client Factory), because of their availability, support, resource investments and ongoing development will remain the premier software factories available to Microsoft Enterprise partners and customers moving forward in this space.

FAQ - Where are my skills going to be required with Software Factories?

jezzsa — Thu, 04 Jan 2007 01:10:00 GMT

In a previous FAQ we addressed some of the fears that our 'eager-professionals' are likely to have about the introduction of software factories into their projects and organisations. In this post I want to address one of the concerns that the expert solution developers among them and their organisations will face with the advent of software factories.

Some of those fears raise the question of "where will my expert development skills fit in with solution development with software factories?"

Specifically, how, adoption of software factories will change aspects of the landscape of software development today, and how that shapes the way we as solution development professionals focus our efforts from the tasks we perform today. In short, how prolific adoption of factories will change the roles of today's developers, and the mix of developer skills in organisations.

Backgrounder

An overall objective of the industrialisation, that software factories bring, is to reduce the shear amount of manual labour required to be performed by solution developers (and cost of course) in developing solutions to specific well defined solution domains. I'd also say that just as important - is to reduce the amount of re-work, and increase the amount of re-use of experience (and assets) of others who have already solved those problems thoroughly already. Today there are an inordinate amount of solution developers who re-craft artefacts for already solved solution domains over and over again, and that is handicapping what they can deliver. In order to do this today, developers knowledge and skills are required to span, in depth, many domains in order to piece together whole solutions. Due to practical resource limitations (like time and money) this often results in sub-optimal solutions, either because they don't have the resources, experience or knowledge to do this - which of course means the solution doesn't get whatever the individuals don't have.

OK, I think everyone understands the issues here and where this is going, so let's not harp on too much about it at this stage. Suffice to say, that the introduction of factories should basically relieve a great deal of current expert solution developers from having to possess (and maintain) a great deal of knowledge, experience and skills specific to known solved domains that they build.

So, this begs the question: "if a factory already does a lot of this work for me, what is left for me to do now? How are my current skills relevant anymore?"

[Just to clarify, we are really addressing those solution developers whom today create whole solutions rather than those who are only focused on very specific highly customizable tasks and responsibilities. For example, those who only write business logic rules. Of course, these folks roles and responsibilities probably won't change much with introduction of factories.]

Answer

I think the obvious answer is that the skills are still very relevant and will continue to be, but the role and focus of the individual developers now changes - particularly those who craft large parts of the overall solution. Instead of creating whole solutions (or parts of them) repeatedly, certain developers are going to have to focus on more profitable tasks in a software factory product value chain. In other words, some developers are going to build solutions using factories and some are going to build the factories (and their assets). These two primary roles are going to require a different division of skills, knowledge and experience and ultimately resource than what is done today.

[I believe there might be further secondary roles also, like those for factory customization and those for factory product customization, which may, or may not be the responsibility of the same people in the primary roles. I just wanted to focus on the main roles for now].

It might be a safe assumption therefore to conclude that once software factories are in wide and extensive use in development organisations we can expect to see a change in the mix of development resources required on mainstream solution development projects.

Whereas we see today most expert solution developers are required to possess expert level knowledge, skills and experience in all domains of a solution, tomorrow we will see that the expert solution developers will be either required to have higher-level development skills using high-level assets and abstractions (models, designers etc), or required to have lower-level programming skills for creating the assets (models and designers). [Lower-level programming skills means the programming skillsets we see in expert developers today. Although, tomorrow they will be relatively more specialised to certain domains than today.]

Furthermore, we can also expect to see a change in percentage of each group. Whereas we see most solution developers possessing the lower-level programming skills today covering whole solution domains, tomorrow the majority of mainstream solution developers will possess the higher-level development skills to cover the whole domain, leaving fewer (more specialised) lower-level programming skilled developers. Very few bridging this gap. In fact, this gap may just be transitory, and a means to go from mainstream development to specialist programming developers. We can also predict that some organisations will branch out further to either business.

So, to summarise. If you are an experienced mainstream solution developer today, chances are you are required to be an expert in many of the domains of the solutions you build. Of course, few can say they are the top enough experts in all the required domains of their solutions, but most (due to market pressures, and resource constraints) have to deliver on all those domains.

Tomorrow, when factories are prolific, you will have a choice, of either 'keeping your hand in the game' and specialising more in many fewer of these domains and create/customize re-usable assets that are likely to find they way into the factories to build solutions, or generalising more (at a higher-level of abstraction) and assembling the solutions using factories. As an entrant novice into the development market, the chances are you'll enter as the latter and through experience, or by organisation necessity (or perhaps passion, or other pressure), work your way into specialisation.

Like it or not, customers and the market will ultimately determine the required balance of skills, and organisations will have to adapt to be able to deliver on the market demand. One thing is for sure, once factories have proven their value in productivity, quality and cost savings, those organisations who still hand-craft solutions as inefficiently and of variable quality as they do today for mainstream markets, will certainly be mainstream no longer, and will be forced to move towards boutique software solutions to be profitable.

FAQ - Why do I need Software Factories?

jezzsa — Mon, 11 Dec 2006 11:18:51 GMT

OK, so first off I want to address the more personal, individual aspect of this question, rather than the more broader industry angle - which can be found in many other references online and offline (books, articles and the like). These other references describe in detail the drivers for software factories, and why we as an industry need them to industrialise software development. But that's not what we are going to explore here.

Instead, I want to tackle the personal view points of the folks perceived to be at the 'pointy end' of this proposition - the developers. It is the developers (the authors, and users of the factories) who ultimately decide the fate of factories, because factories become their new 'tools' to get part of their jobs done. It should be no surprise to anyone, that this won't happen if they (our 'project saviours') don't want to use the tools.

I want to explore the reasons, (during this evolutionary period of software factories), why some of our software professionals, particularly the 'eager-professional' developers, may find factories hard to embrace. I want to explore what lurks behind that, where that cynicism and fear comes from and why.

[I define what I mean by 'eager-professional' developer later on in this post. If anyone has a reference to developer behaviour profiles I can leverage instead, please comment - I'd like to accurately and precisely get to the right term for the behaviour and circumstances I am trying to convey here.]

This has got to be the most controversial question to answer, since:

We are dealing with individual emotions, opinions, perceptions, experiences of the folk who find themselves in circumstances not favourable for this type of new automation. So, I am expecting that not everyone will see eye-to-eye on this. I merely offer observations from this moment in time, in a new evolving and fluid marketplace.
We are also dealing with essentially disruptive technologies to replace well-established technologies and tools in an existing marketplace, and therefore this new technology requires (demands) a new approach, with new optimism and newer goals than have been previously defined.

Answer

What we face, with factories, is a departure from established development attitudes, behaviours and approaches towards a vision that has previously failed to deliver - sometimes more than once (in some people's professional careers). We are bound to face resistance and scepticism from the purists, the development empires, and individual kingdoms set up in development establishments, from the persons who have established livelihoods and comfort zones out of developing software the inefficient, unaffordable, one-off, 'artistic' way it's done today. It's a natural reaction to change, and its healthy, since it qualifies exactly what, and whether, factories can actually invoke and achieve industrialisation of software development in the future.

Now - let me scope this back. What I want to focus on is here is how a certain group of developers today feel about this impending change - the 'eager-professionals'. What some of the opinions are of these groups, and why they (quite rightly) are sceptical and downright passionately adverse to what could be perceived as a god-send to others in the profession.

I define 'eager-professionals' as those professional developers who are typically, but not always, less experienced in small companies or more specialised in larger companies. The eager professional feels the need to prove his worth by displaying his prowess at the art of software development. Since the eager professional is driven to prove himself, he tends to compete with other eager professionals in what they perceive is the most important skill - hand writing the best code possible. The eager professional focuses on solving individual problems, and solving them in the most elegant and most efficient possible way, and evolving that in every iteration. That’s a very valuable and necessary set of skills in any development project. However, excelling at these skills puts a lot of self-emphasis (over emphasis perhaps) on their own unique knowledge, their understanding of that knowledge, and the value of that knowledge, as well as the tools they wield - their programming languages. The eager professional considers his freedom to choose his tools and techniques to be absolutely necessary. Otherwise, creativity and innovation will be stifled and the solution will be sub-optimal. For this reason the eager professional strongly resists any perceived threat to his freedom to apply his tools, knowledge and techniques as he sees fit. The 'eager professional' has an ardent distrust for other development professional's contributions brought to bear on, or mix with, their own. It is therefore quite easy to predict that software factories will present a perceived threat and - specifically to this group of developers - evoke strong resistance, stifling widespread adoption - for a number of reasons we will dig into later on.

There are other groups of individuals of interest in this context too that we may touch upon. Such as:

[BTW: I am not attempting to profile all developers here, just the ones I feel will have particular resistance to software factories in this context]

The risk-adverse 'mature-professionals' who have fought and bore the brunt of past failed software revolutions, some they pioneered themselves, who are naturally sceptical. But I believe, it’s the mature-professionals who are ultimately more open and optimistic to change - albeit, super-cautious about it. They are quietly, positively waiting for it to succeed in a big way, so it can vanquish earlier failed attempts, some of which they championed. In fact, would argue that it will be these professionals who in fact make it happen or not, since they see a more maturer picture of the strategic direction of their groups.

Then there are the 'purists' whom are chartered with unraveling and championing the essence of what lies at the core of software development. They are naturally adverse to this kind of change and automation because its perceived to understate the pure art or source of development to which they dedicate their passion and theoretical studies. They will probably, not for a long time, embrace 'such a generic mongrel, and they will scoff at this perceived de-throning of their highly insightful knowledge as being of primary importance to the mass software development audience.Those that follow the purists religiously will also share the same opinions.

Then, there's an interesting group of very ordinary professional developers, I am calling the 'apathetic-practitioners'. In my experience, by far the largest group presently. These are the guys who don't necessarily tout any techno-religions, who are not driven to excel or be creative, who work together to just do their job and return to real-life at the end of the day. Their opinions (and pain) are based on what works and what doesn't - they vote with their feet. They are not paid, nurtured, incented or given latitude to care about the best way to do their jobs, or what the latest techno-trends are, or who the demi-gods of software development are. They don't participate in the raging forums, attend the latest tech-events, read the cool-blogs and techno-sites, or immerse in the best practices. They just want to get the job done because of the circumstances they are in. They find a way to do it, and if it works, they stick with it. As a result, these guys bear the brunt and pain of all past failures and attempts of the other more eager groups and the pioneering attempts of the industry to make life easier for them. They of course, by necessity, will always find the easiest path through the mazes and mine fields presented to them. They couldn't care less if it fails, they would just again raise their eyes to the roof, tut to themselves, and work around it. But if it succeeds, then they are fully onboard. Because it's for these people, collectively in the masses, where it would have the most significant impact on everyday work, and therefore sizable benefits for their businesses, their markets and the industries they work in.

Why the fear?

Now that we have roughly categorised our developers into behaviour profiles based upon their circumstances, we can start to analyse the reasons why software factories will meet initial resistance as they emerge into the existing marketplace.

Most of the objections and resistance we will face (particularly for the 'eager-professionals'), from the introduction and use of software factories, will be from fear of what factories will mean to the individuals themselves, rather than having any technical basis. (and boy are we good in this business at de-bunking ideas based on a marginal technical bases!!). That is not to say that factories are the applicable silver bullet for all developers in all situations, certainly not. Quite the opposite, it is a narrow band of software solution domains that factories apply to, but even in the cases where factories make perfect sense, these threats are perceived as encroaching insidiously on the individuals purpose, usefulness and status.

What I have noticed from my own experiences as a professional developer and from evangelising software factories to developer professionals in the field, is that there are several ways for dealing with fear from these types of perceived 'techo-threats'. For some, denial is a safe and comfortable place to hide. For others it's dis-association. Many others just 'pick the battles' worth fighting. Now, I am no psychoanalyst or professor of human behaviour, but what I have noticed, is that a common way to get over these types of fears - if you decide to confront them, and come out positively on top - is to understand what drives the fears in yourself and then question the basis of that fear within. That all starts with recognising the fear of course, and what threats drive it in you.

I predict that if those who fear software factories were to 'look inside themselves' and identify what threats that fear is based upon, and then rationalise that, they too would come out on top of it. Hopefully then, they would view software factories for what they really are, their value and the benefits they bring many in the circumstances they were designed for, rather than a wholesale threat to their individual status.

This last point is leading to a new discussion about how a future of software factories may change individual status and the mix of developer skills in any given organisation. The required skill sets, the expectations put upon them, the types of creativity and design skills they will need to exercise and the impact that will bring to the end customers. I'll address this in a subsequent post called: 'FAQ - Where are my skills going to be required with factories?' (coming a little later on) but I do touch on some of it below.

What are the threats?

So, finally. Lets have a look at some of the perceived threats to these individuals, primarily from the point of view of our 'eager-professionals' who see themselves as expert professionals. Let's have a look at what's concerns the individuals and how that concern is actually a benefit of factories.

These threats are primarily aimed at those expert professionals who create solutions by hand today. Although most are related, I have tried to tease out the differentiators.

[BTW: This list is obviously not exhaustive. I fully expect others will have identified other threats through their own experiences, which I would encourage you to share in the same format.]

Concern: 'Lowers the bar' required to create software solutions. ('Open the country club to the riff-raff').

Description: With factories, it might appear that novice or undisciplined, even cowboy developers now have the power to wield a 'powertool' such as a factory to do the same job as a 'hard core' expert professional developer would do. This is a similar perception many C/C++ developers had when VB developers became mainstream. This leaves the impression with the experts that the art of software development will be lost (or depreciated) through the abuse and misuse of the 'tools' (in this case - the programming languages). The expert developers are concerned that the markets will appreciate mediocre quality, and cheap solutions rather than precision engineered, aesthetically designed and quality products.

Fear: Depreciation of deep technical understanding, principals, techniques and materials required to coalesce into quality solutions. Fear of technological change.

Benefit: Allows the organisation creating the product (using the factory) to focus upon business requirements implementation and logical design rather than technical implementation details.

Solace: The factory assets will be built by the expert professionals with the deep technical knowledge to encapsulate the principals and techniques for creating a specific solution for a given set of requirements. Therefore, there is little loss of quality or precision engineering of the solution. Unlike the introduction of high-level generic programming languages such as VB, which made creating whole applications much quicker and easier (RAD), software factories are a much more specific tools confined to well defined, managed environments to operate within. The potential for widespread poor use and abuse is greatly reduced since the factory (through the factory schema) defines precisely how the product is to be built, its bounds and the variability of the product and its pieces.

Concern: Can a tool really do the job of a expert software professional today?

Description: Introducing a tool which can automate the creation of source code for whole or part of a complex solution (rather than just discrete components) appears to an expert developer as means for less skilled developers to do their job - as good, if not better than them. This of course inevitably asks the question "what therefore, is my purpose?".

Fear: Loss of relevancy, value in the project/organisation- redundancy?

Benefit: Developers with higher level skillset's are empowered to develop the solutions using the factory, more cost effectively. These developers won't be required to possess the highly specialised (and therefore expensive) solution domain expertise to create these solutions in such detail (at such a low level), since that investment has been captured and reused within the factory's assets already created by the expert developers.

Solace: Expert developers skills are still highly valuable, perhaps more so, since the potential scope for re-use is now much greater in a factory rather than in just one-off developments. The pursuit of excellence in low level development skillset's will still be most definitely required. However, the demand for them will no longer be in the bulk of creating well known solution domains that factories address. Instead, expert developers will be required to create the factories themselves and/or the assets within the factories, as well as the customization of the factories and the refinement of their products. Furthermore, there will always be a requirement for customized one-off solutions in the market place, but whilst they are common today, they will be less common in the future.

Concern: Can a tool address a whole solution domain? Shouldn't we be hiring more domain experts? (Generalisation vs. Specialisation)

Description: Solutions today are becoming more and more complex addressing more and more solution domains, each requiring more specialised domain specific expertise. Organisations today therefore require possession of these domain expertise to create even the most basic solutions. This is, for most organisations, a mounting challenge. Until recently, few have conceived the idea that a single tool could address a whole solution domain, and therefore take it upon themselves to master most of all the expertise of these domains. However, this has its practical resource limitations, and poorly or over-engineered inferior solutions are re-crafted or cobbled together to make up for the lack of these expertise. The introduction of software factories brings with it a requirement for specialisation and generalisation, and for most expert developers today, re-use of other's domain expertise will be required to be profitable. For the end customer this means higher quality solutions, at lower costs. It will no longer be acceptable in the marketplace to deliver poor quality standard solutions, which implies for most expert solution developers today that being a generalist in an average delivery capacity will no longer be profitable. Factories will require some expert professionals to generalise solution domains, and some expert professionals to specialise in smaller domains. The generalists will define the factories that assemble the assets created by the specialists.

Fear: Becoming a specialist: become more accountable for a more specialised higher quality reusable asset for use in many solutions. Becoming a generalist: move to a higher level (perhaps less-detailed) understanding of particular technology domains, but more focused on bigger picture scenarios.

Benefit: Better products, higher quality, newer markets, and sustainable businesses.

Concern: Are we to trust this person's implementation (i.e. source code) of our unique problem space? ('Not invented here')

Description: Using factories, to create a products, brings advantages in time-to-market and high-quality which fulfils the customers demands today. These drivers are going to force the software creators to assemble factories from standard assets not necessarily built within their own organisational boundaries. These standard assets are best acquired from the domain specialist organisations that specialise in the best-practices and principals of these domains. For some factories, particularly the first generation factories we see emerging now, this will mean the introduction of assets that create source artefacts - visible, editable source artefacts (as opposed to binary obscured artefacts). Since source artefacts are the focus and domain of most expert professionals today, these assets will be perceived as providing implementation that could have 'just-as-easily been created in-house'.

Fear: That my/our implementation is not good enough, and the other's might be better.

Concern: Is source code really not the most important artefact anymore?

Description: Today, for most expert professionals, it is the creation and management of source code artefacts which defines their purpose and status within an project. Since the primary first-class artefacts of Model Driven Development (MDD) are models, this may be perceived by most expert developers as being no longer any place to realise their value.

Fear: That my/our speciality, skills and mastery of programming languages are no longer more valuable than the application of them.

Benefit: As factories evolve, developers will certainly focus on higher level artefacts as their tools become more graphical and abstract, as the lower level artefacts are generated as outputs of the factory for verification and compilation. The interfaces for configuring and changing the product of the factory may become more important than the organisation or structure of any source code implementation underlying them. (In much the same way it is with C#/VB over the machine generated byte-code today).

Solace: Although source code artefacts and management of them are the focus of most expert professionals today, this may not necessarily be the case or focus for them in the future. The first generation of factories will very much be focused on source code assets to bridge the modelling/automation gap, but in the future it probably won't be the case as we move up to higher level languages and platforms. We may even see in the next generation of factories, models which generate assemblies or other binaries directly, and certainly (even now) factories which generate no source code artefacts at all (no source code, models or otherwise). However, today and for the first generation of factories at least, there will most likely be a requirement for fine tuning or refinement of the factory created products at the source code level. So the requirement for these skills will certainly not dissipate with the advent of software factories.

[Much thanks again to Martin Danner for helping me precisely articulate some profiles and Kimmo Forss for some very good idioms for my concerns.]

FAQ - Isn't that MDA?

jezzsa — Thu, 30 Nov 2006 19:01:12 GMT

Considering the EFx Factory and its core composability features with extensible technology-independent models, a few astute people soon get around to asking the following question:

Isn't the EFx Factory just another implementation of MDA?

Backgrounder

Model Driven Architecture® (MDA) is a methodology created by Object Management Group (OMG). Their definition of MDA can be found from their FAQ page. (excerpt below)

"The MDA is a new way of developing applications and writing specifications, based on a platform-independent model (PIM) of the application or specification's business functionality and behavior. A complete MDA specification consists of a definitive platform-independent base model, plus one or more platform-specific models (PSM) and sets of interface definitions, each describing how the base model is implemented on a different middleware platform. A complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one on each platform that the application developer decides to support."

There is also a good wikipedia definition here, with more references to other sources.

The EFx factory defines architectural based models (such as the one here) for parts of its product model. These are based upon common architectural implementation patterns (such as SOA contract patterns and the .NET distributed architecture). These models define views which are technology-independent abstractions of an underlying architectural framework that actually helps implement the products of the factory. The underlying framework itself, defines abstractions of the .NET framework class libraries and Enterprise Library.

The factory has been designed to define 'base models' of the internal architecture of applications and services - called 'specifications' which have no dependency on a particular technology or implementation pattern. The technologies that are used to implement the specifications are provided by other software factories that are plugged into these base models to allow extended technology-specific models, abstractions, patterns, meta-data and artefact generation from other factories suited to this architecture. This means that the technology-independent models can be specialised towards a specific technology or technology strategy. This approach prefers an extensible technology implementation to a prescriptive technology implementation.

In effect, the models and abstractions that the EFx Factory exposes, defines a technology agnostic model, where specific technology models can be provided and overlayed by other 3rd party factories. This mechanism is outlined also in this article.

Answer

The EFx Factory is not an instance of MDA.

From the definition of MDA above, it might appear that in fact, the approach taken by the EFx Factory modelling strategy, would appear to be similar to that of MDA® - that could only be true if you equate a platform independent model (PIM) is the same as the approach as taken by EFx factory which is providing an extensible technology-independent model.

The truth of the matter is that the EFx Factory approach is in no way derived from an MDA approach, nor uses any processes, technologies nor standards that are defined by MDA, such as UML, MOF or XMI.

Using MDA as an approach in the context of software factories has several challenges that should be considered in any comparison between software factories and MDA. Jack outlines some of these in the FAQ section of his book 'Software Factories'. However these issues are more related to MDA as an alternative approach to Software Factories as a whole, rather than a specific instance of a factory - which the EFx Factory is.

You might also want to read about the concerns around MDA here which appear to address some of the undelivered promises of MDA.

Technology-Independent Models

The EFx factory does not provide a platform independent model (PIM). Rather, it does provide extensible, domain specific technology-independent models. I am not just splitting hairs here. The models define specific extensibility points based upon architecture, that can be addressed by other pluggable factories ('factorettes' in this context) that either provide a technology-specific implementation or provide strategies to implement them. This is not the same as the platform independence described by MDA.

The plugged-in factorettes provide their own abstractions of a technology-specific view of the architecture that is exposed through an extensibility point. These extensibility points (variability points) have been determined by identifying which parts of the architecture require specific technologies or implementation patterns. The factorettes provide the abstractions, user experiences and implementation of that extensibility point. The abstractions provided by the factorettes are then integrated into the technology-independent base models to provide a technology-specific view of the architecture. That view can be either overlayed onto the technology-independent view, or displayed separately. It is then the combination of the views provided by the factory and the factorettes that provide the final user experience and actual implementation of the factory products.

Instead of MDA, you might say that the EFx Factory subscribes to a Model Driven Engineering (MDE) approach - which would be more accurate. It's worth noting that the approach used by this factory has evolved from a grass roots approach of iterating automation and modelling of an established application framework use, which is more in line with what software factories promote.

FAQ - What is a Software Factory?

jezzsa — Fri, 03 Nov 2006 22:36:00 GMT

The question usually goes something like this:

Define what is a Software Factory? Followed by something like this: I built a command line application/a guidance package/a script (make your choice) that code generates some useful component – is that then a software factory too?

This one is a real challenge to define in a short post.

Chinnese version here.

Backgrounder

This is more than a fair enough question, and most people are now asking it, and trying to distinguish whether they already have factories or whether these things are something new, using something they already built or know about as a starting point for understanding the difference.

Answer

Let's start with an official definition of a software factory, then I will try to interpret that in simpler terms and expand those with examples to hopefully aid your understanding.

An official, extensive definition can be found here, but I am going to start with this shorter one from Jack and Keith's book on software factories. Or you can find some others definitions here in our glossary.

"A Software Factory is a software product line that configures extensible tools, processes and content using a software factory template based on a software factory schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling and configuring framework-based components."

Woah, okay, (gulp!) that's the academic definition, let's expand that a little: So, the essential ingredients of a factory are a product line, which is created using a set of tools (i.e. editors, code templates, recipes, domain specific languages, command line tools, etc.). These tools then configure a generic, extensible development tool (like Visual Studio) using a thing called a 'factory template' that is really just a physical incantation of a 'factory schema' (i.e. the factory template contains the tools, guidance and a blueprint of the things the tools create of configure). Then provide automation for the development and maintenance of different things the factory creates (a 'product') by assembling the required components, ideally re-using existing frameworks that are tailored for the created products to work on.

OK, the key pieces here are the product line, the factory schema, its factory template and a product. I reckon, if you have all these you have a pretty good approximation of a factory, because most of the other stuff comes along with having these.

The frameworks are pretty important too, because with one you have taken a large step in the process of defining the variability points of the products in your product line, and most of the work is already done for you. Remember, you should not be creating factories for solutions you have not yet solved, so the basic pre-condition of wanting to create a factory is that you already have some solutions with assets to automate.

[If and when the Visual Studio team release tools to enable you create custom Software Factories of your own, the Microsoft definition of the term will be concrete, and, I guess, you only have a Microsoft approved factory if it fits this concrete template. But until then, you can still create your own factories with the current tools and a bit of innovation to fit the definition above].

A Product

Let's start with the product. To clarify; a product is the thing a particular factory builds.

"A product is what falls of the end of a factory production line."

Don't confuse a 'production line' with a 'product line'.

Now, a product does not have to be a complete, finished, shrink-wrapped, boxed product like 'Microsoft Word', which is the thing most people have in mind when they hear this. It is simply the term to describe the output of the factory.

For example, a car engine manufacturer created car engines as their 'products' and sells them to other factories to assemble them into cars. The engine is still a 'product' of the engine factory.

So, all factories create a useful product that may or may not be assembled into larger products by other factories.

Factories define a model of this product, (a meta-model) which is the schema of that product, containing the parts and their variability points. This model provides the user with a means to create, configure and maintain the parts independently.

A Factory Schema and its Template

We already did quite a bit of work explaining a factory schema, so I won't repeat all that here.

But suffice to say in this context: it is the blueprint of the things the factory builds - the product (and its variants) and there configurations. It defines not only what the factory builds, but how to build it, the pieces it's built from, and the tools used to build them.

Incidentally, the 'factory template' is nothing but the tools, runtime, documentation, frameworks and other assets packaged and shipped as 'your factory' – perhaps within an installable MSI.

A Product Line

Now to the product line – what on earth is that? This is not the 'production line'.

"A product line consists of the product variants the factory creates"

OK, factories are expected to create more than one instance of product to be really useful (we call each one of these a 'product variant'). To be precise, a product 'variant' is the instance of the product you have created, rather than the actual type of the product. A factory could define several different 'types' of products (each one fixing perhaps some variable aspect of the product).

Therefore, the solution domain of your factory is defined by its product line.

[There is a more in depth discussion on product variability and variants, (what it is and when to use) found here.]

So - is your command line app/guidance package/script a software factory?

FAQ - Round-Tripping

jezzsa — Fri, 03 Nov 2006 20:39:00 GMT

The first question I always get asked:

Do you support round-tripping of the generated code your factory creates? In other words, do you support a developer going into the generated code, modifying it in an arbitrary way, and then read back those code changes and their intended meanings into the models used by the factory?

[Quite often the asking party has the handy Class Diagram functionality of Visual Studio in mind when they ask this.]

Backgrounder

It works like this for our particular factory (the EFx Factory):

The factory user designs the logical components of the applications and services in architectural layers using a logical model explorer and visual designers. Each component is part of an overall (combined) meta-model that has a set of metadata (properties) associated to the elements in it. This metadata defines things like the naming, structure and concerns of the component within the architectural layer and ultimately governs how that component should be implemented. This diagram shows one of the designers used in this process.

Of course, these metadata 'properties' provide an abstraction to the actual generated solution artefacts and it is defined in architectural terms, since we don't want the factory users to have to be expert C# solution domain experts to use the models. That's on of the powers of using abstraction your factory.

[As a side note: In this factory, we do allow and support (even facilitate) the developers hand-crafting the business logic in source code, since we don't feel we can sufficiently model business logic successfully or completely for all cases to suit all solutions. The hand-crafted custom source code is referenced by the models and maintained separately from the generated code, so won't be considered as part of this discussion.]

At any given point in the design time of the logical models, assuming certain constraints and certain validation rules are satisfied, source code and other artefacts are generated from the model and designated to the appropriate container (project or solution folder) in the physical solution. It is then subsequently compiled into assemblies at a later stage.

Answer

The answer for this factory is: No

We are not saying it can't be done; just saying that the considerable effort required to support this is wasted when:

The Model is King. The model is intended to represent the architecture, its components and the architectural patterns it implements. In this factory, all the components (with business logic components being the exception) are modelled in the architecture and configurable to suit certain identified variability. This 'specification' is meant to define the specification of the solution, not the source code it generates. Since those interested in the abstractions it provides will not necessarily be interested (or skilled in reading) low level source code. The model is king, and the authority on the actual state of the factory product. All analysis and generation tools read and write to these models.
Abstraction assumed to be high: In this factory, the generated solution artefacts that represent the physical incantation of the models is provided by pluggable providers (we call them 'Artefact Generators' for obvious reasons). These providers are intended to implement a pattern or technology to satisfy a set of concerns for a set of components at a particular layer of the architecture. For example, we would have one such provider for a service to implement the Service Contract and Data Contracts using a given technology, say - WCF. Now these providers themselves may be mini-factories ('factorettes' as we call them) with their own abstractions that remove the requirements for the factory user to be experts in implementing their best practices or patterns in specific technology terminology or using a low level tool – like source code. The providers are expected to hide that complexity, and only expose a simple interface to configure it, in generally understandable terms and patterns. So, the abstractions they provide may not be as simple as perhaps the Class Designer in Visual Studio (which could be said to have little to no abstraction).
One-way mapping assumed. In following with the previous point, but more importantly, since the providers are to implement a technology based upon a meta-model of components and metadata in a well defined architectural model, they are encouraged to provide more than one set of patterns for their technology which vary and are each optimized depending on the configuration of that meta-model. You can imagine this being the same way that source code compilers implement different byte code sequences depending on how the developer wrote their source code. One pattern may not be most optimal for all configurations. So how do you determine from the modified source code which pattern is in use, and how that change in source code should be reflected in the model? It's the same problem most people see when reverse engineering assemblies using a reflector. You never get back the original source code with its abstractions in place – because there is a one to many mapping between source code and compiled code.

The next point is (philosophical)?

This factory does not want to promote source code development, favouring more powerful abstractions, visual modelling and extensibility (except, as we mentioned above, for the business logic – which we do want the factory users to define in source code). So, we don't expect the developers to tweak the generated source code.

Having said that, there are legitimate reasons they might want to do this - customization. The assumption here is that; in modifying the generated source code your intention is to define a variability point (or configuration of a variability point) that the factory does not cater for currently. In these cases, this deliberate action is interpreted as a case for further factory customization – which is a valid reason to create a variant of the factory to accommodate this variability. Its part of the natural development cycle of a factory.

Just as an interesting point of strategy to identify these cases, this factory employs a validation rule that checks the last generated source code artefacts for modifications, before re-generation. Then, if any modifications are found, the generation process is halted and the factory user is notified of the change. In those cases the modification needs to be resolved with an appropriate manual action by the factory user in order for generation to continue.

Software Factories FAQ

jezzsa — Fri, 03 Nov 2006 17:57:00 GMT

I often get the same basic set of FAQ questions reoccurring when discussing or demonstrating factories to technical focused folk, so much so I thought I'd do a short series on those frequently questions and answers.

The idea being to share the thinking behind some of this stuff that may be useful for other people's factories and helping you make informed decisions in the design of your own factory.

Also I will be trying to socialise the terms used and use practical examples.

I will be creating a number of subsequent posts on these time permits.

If you have some of your own questions you want to ask, simply comment this post and I'll do my best for you.