Daniel wrote a nice little post about status of building Software Factories today - using DSLs to express intent around common models and Guidance Automation Extensions (GAX) to automate common use cases. See his perspective here
As the team who has shipped most of the Software Factories from Microsoft, patterns & practices continuously tries to help you build better applications using less effort by applying these technologies. Once the rubber meets the road, we all learn, and we build infrastructure to support better experiences today and at the same time provide feedback to the VS.NET folks building next versions, so they can add features that will make p&p's and your lives easier down the road. Entlib Config and GAT/GAX was an example of such infrastructure.
But where is it going? We think there are many opportunities in the following areas:
1. Integration of multiple models - obviously you can express parts of your application with models, but the moment you start adding different domains - especially crosscutting ones, think authorization; or models at different levels of abstraction- you obvioulsy require to have dependencies, relationships and interoperability/integration of models. A good infrastructure for model integration would allow you to yuxtapose concepts around workflow, and manageability events, for example, without having any unecessary dependencies that wouldn't allow you to use that same manageability model around a totally different concept like web service calls or business data state transitions.
2. Bringing in the team to the factory - Right now the factory experience is a lonely one - you build a thing, move on. Artifacts like models and code survive, but beyond this sharing there is no coordination to the collaboration. Just like GAX can be used to automate 'atomic' use cases that are done by one dude/dudette sitting at Visual Studio, we think that something akin to small team workflows can be used to express outcome-centric activities that coordinate many smaller actions. These are not end-to-end processes, rather small pieces of activities that can't be done all at once - like setting up an environment for mobile app testing, or building/reviewing/checklisting against a threats & countermeasures model.
3. Specializing aspects of the software engineering process - we have ways of expressing with VSTS the process (workitem templates, content, etc) that you use for building stuff. What happened if the process could be specialized in the right areas to help you build not just stuff but a special shape of stuff? Are there templates in requirements, bugs, development tasks etc that would be more valuable to you if they were specially built to help teams build (for example) web services?
Of course a key concern I hear is - wow, with all this stuff won't things just become heavier and more context-dependent to the point I won't be able to use anything just because I'm not living in your little world? - and I understand it. My hope is that we can work on our packaging (which isn't precisely a beauty right now!) so that you can take the parts that you need, yet at the same time have a great experience with the whole. And all of what I blogged about is just the work needed to give your team a guided experience when building solutions. Every team in p&p building a factory has to make a balance between distilling the proven-practice guidance itself, and expressing that guidance in runtime, tooling and content. I hope that, as we continue to roll out more of these, you out there in the community will keep us honest and help us make the right tradeoffs.