Microsoft plans ‘software factories'

Microsoft has decided that its next big idea for the future is ‘Software Factories’, and Team System, part of Visual Studio 2005, is a first step towards this goal. A software factory is designed to be an alternative to using generic tools, ad hoc processes and custom architectures. Instead, the idea is that modelling software is used to define systems and then create code. The model can be modified to easily and quickly create the code for a customized version of the application. This isn’t exactly new, but it is argued that traditional modelling tools have been too far removed from the applications that they eventually generate code for. Microsoft’s new tool – codenamed “Whitehorse” – is intended to make it easier to create Service Oriented Architectures (SOA). The modeller is designed for the specific application, and it is claimed that it is more useful because it is more tightly coupled to the application domain. The class designer is UML-like rather than supporting any existing standards. The reason for this approach is that UML doesn’t adequately support .NET language facilities.

Microsoft demonstrated the technology at the recent ACM OOPSLA conference, and also released a Community Technology Preview (CTP). If software factories sound like nothing more than a marketing idea, it is worth recalling that application specific languages, modelling and code generation have a long history, but to date they haven’t delivered what they promised. It is difficult to know if ‘software factories’ have anything to offer over and above existing modelling tools and previous attempts to create application specific 4GLs (4th Generation Languages). It could just be that we have reached a high enough stage in our development to make these long-held ideas and goals feasible at long last.

If you’re keen to learn more about Microsoft’s Team System, Dave Wheeler of QA will be presenting two in-depth sessions at DevWeek 2005 in February. The first will take a high-level look at the new product and its constituent parts, from requirements analysis to design, and the second will look at how developers and testers will work with it from development to release.