all bits considered data to information to knowledge


Who needs a Software Factory?

Software [Development] Factory – a concept most eloquently formulated by Jack Greenfield – did not generate much following. The first book Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools authored by Jack Greenfield (also, see MSDN article), Keith Short, Steve Cook, and Stuart Kent was published in 2004, followed by Practical Software Factories in .Net in 2006, with but a single title advertized for release in 2010 (Agile Software Factories by Damon Wilder Carr)

Apparently it did not struck a chord with majority of software architects and developers out there. Some of the reasons could be developers resistance to commercializing and commoditizing the high art of software development; some of it, I believe, could be attributed to misunderstanding of the applicability domain. Simply put, techies do not need it, and business folks do not understand it.

The promise of SDF is to deliver “economy of scope” where “assembly lines” produce variations of archetypal product/template, it is therefore inherently not applicable to one-off projects. I see the SDF closely aligned with Software Product Lines (e.g. Software Product Lines: Practices and Patterns ), where business domain knowledge meets “patterns, models, frameworks, and tools”.

 There could be no discussion about value of patterns, models, frameworks, and tools; these are given for any software project worth the name. They are firmly established in software development practice. Move up one notch in the abstraction ladder and you have all these wrapped up into archetypal template from which you can generate a variation of a domain specific product. An example of such “wrap up” could be used through a DSL  - Domain Specific Language used by business domain experts. Say, you  - a domain expert - are assembling a financial application that processes loan applications – would not it make sense to use language that finance people could understand with keywords such as “loan”, “mortgage”, “originate”, “fee” etc.? Just as most developers shudder at learning intricacies of APY (Annual Percentage Yield) versus APR (Annual Percentage Rate), the finance folks would not want to be caught dead talking about threads, mutexes, arrays and data types... SDF paradigm allows for both to coexist peacefully: technology aficionados take care of the underlying machinery, and business can assemble applications they need without need to translate the requirements - times and again – into techspeak.

 Now, how is it different from CASE  promises?  Here’s my answer: SOA+DSL. The SDF transcends CASE in a way of operating at ever-increasing level of abstraction, where models do not have to be translated into software modules but rather into software services wired together to produce desired functionality, where patterns are built into the language the domain experts use (think BPEL+), where software engineering best practices are implemented on subconscious level…

I can see these trends when IT folks are increasingly urged to “speak business”, when mash-ups and Google Gears allow for creating a reasonably functional web application with minimal understanding of what technology all these gadgets are using, with proliferation of ECM – Enterprise Content Management systems such as Drupal, Alfresco, Sharepoint, with DSL taking more prominent role (check out Microsoft's Domain-Specific Language Tools for .Net)