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.