Software Factory Elevator Story

To start the ball rolling, I thought I’d write down the Software Factory elevator story. People are always asking us “Can you please just quickly summarize what one is?” That’s right, boil down a 600 page book, and thousands of words in white papers and articles to just three points. So here’s what I think are the key ideas, resisting the urge to expand on them here (that’ll come later).

1. Models are first–class artifacts in software development

Model-driven development uses higher levels of abstraction than code oriented development to reduce the complexity of the development process, to enable faster response to changing technologies and requirements, to make developers more productive, and to make development projects more predictable. It is a continuation of the constant migration of platforms and tools to higher levels of abstraction that has characterized software development since its inception as a discipline. Models designed to be used as source artifacts can support analysis and validation, provide holistic views of otherwise scattered details, and streamline communication between different groups involved in designing, building and deploying complex modern applications. Such models do not get out of sync with the software because unlike models acting only as documentation, they define the software, and must be changed to change the software.

2. There is no single, fixed collection of DSLs that can be pre-specified for all kinds of applications

To be effective, models are instances of well-focused, inter-related DSLs arranged into a collection that provides layers of useful abstractions with which to specify, design, build and manage applications. Each collection should be customized so that the collection overall exactly meets the needs of specific families of applications – like e-commerce, financial arbitrage or home banking – that have a well-defined architecture, and well-defined dependencies on platform frameworks and components. Common features of applications in the same family, and how each may family member may differ, should be clearly identified. How each member of a family should be built depends on how variability highlighted in the family architecture is mapped to variability in the requirements the family is designed to meet. Software product line thinking emphasizes the importance of well-defined architecture, and sets the context for effective reuse.

3. It’s about more than just models

Also important are customized development processes – matched to the specific needs of the architecture and assets of the application family. Likewise for frameworks, components and patterns – these should be arranged for use by the developers and architects in a way that is custom-fit for the family of applications. Developers should not be forced to scan through catalogs and repositories in the hope that they can find something to reuse. Note that models are used not only for analysis and design. With Software Factories, models are used to support many varied types of computation across the entire software life cycle – even at run time – a fundamental principle of Microsoft’s DSI Strategy. Model-driven deployment, operations and management tools are equally important. Ensuring design metadata and runtime metadata is available wherever it can be utilized is a key principle of Software Factories.

Comments

• Anonymous
  March 08, 2005
  Umm, your elevator story doesn't work because you're defining one compex, hard to understand, phrase ("Software Factory") in terms of another complex, hard to understand phrase ("Domain Specific Language"). Actually, it's worse because happen to know that DSL stands for Domain Specific Languge.
  
  The point of an elevator story is to give someone who may be intellingent but isn't versed in the terminology (aka, most IT manager) an idea of what the project is for and why it's important.
  
  Food for thought...

• Anonymous
  March 08, 2005
  Yep - good point. I thought this might happen. I should have at least pointed to many past postings here, at the blogs of colleagues, and other articles for an explantion of this term. Thanks for the comment.

• Anonymous
  March 09, 2005
  Good description.

• Anonymous
  March 09, 2005
  I did spend a year in Marketing at my last job and helped write a bunch of elevator speeches. Here's an attempt to distill this post into a 30-second elevator speech:
  
  "Software Factories make software projects less complex and developers more productive via three key principles. First, models become an integral part of the code: they provide the focus for design and specification efforts, manage all the scattered details, and most importantly the code cannot be changed except via the model. Second, each model is a concrete instances of a "domain specific language" that provides a collection of common architectural elements for a specific family of applications, e.g. e-commerce, financial arbitrage, or home banking. Third, Software Factories allow developers to easily locate the models needed for a custom application and support the necessary computations at runtime. In short, Software Factories bring together design and runtime metadata across the entire development lifecycle, and support model-driven development, deployment,operations, and management."
  

• Anonymous
  March 09, 2005
  Mike, I like your short version - thanks. I think I can see a few ways to improve it though. I'll post later in the week.

• Anonymous
  March 10, 2005
  I like Mike's elevator story better, but it still presupposes an understanding of domain specific languages - do the common architectural elements essentially boil down to the equivalent system architecture patterns? Since I am just now exploring what is meant by DSL, I am a perfect representation of an IT manager that does not know anything
  ;-)

• Anonymous
  March 13, 2005
  Hi Keith.
  
  Could you shed some light (or point to information to) on how Software Factories relate to MSF (if at all).
  
  From what I can tell both seem to be software development methodologies proposed by Microsoft and I have seen separate information on each of them but I have not seen any information on how they relate.
  
  Thanks
  Fredrik Sjodin

• Anonymous
  March 16, 2005
  The comment has been removed

• Anonymous
  March 17, 2005
  As part of my response to the previous feedback item, I meant to plant a reference to information on MSF. HEre it is:
  
  http://lab.msdn.microsoft.com/teamsystem/workshop/msfagile/default.aspx
  
  

• Anonymous
  May 26, 2009
  PingBack from http://castironbakeware.info/story.php?title=keith-short-s-blog-software-factory-elevator-story

• Anonymous
  May 26, 2009
  PingBack from http://backyardshed.info/story.php?title=keith-short-s-blog-software-factory-elevator-story

• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=keith-short-s-blog-software-factory-elevator-story

• Anonymous
  June 08, 2009
  PingBack from http://quickdietsite.info/story.php?id=3301

• Anonymous
  June 09, 2009
  PingBack from http://insomniacuresite.info/story.php?id=9160

• Anonymous
  June 15, 2009
  PingBack from http://mydebtconsolidator.info/story.php?id=2127