Has Microsoft Implemented the Software Factory? I think not.
Long ago I started this blog with a rant about a technology, or a promise of one, that really got under my skin.
I guess the real aggravation stemmed from the role of the Software Architect being dismissed by Microsoft. That may not have been their intention, but it was the result of VSTS 2005 Architect Edition. Not only were we dismissed, but the industry standards that I have watched deliver success after success where spit on by the offering of the DSL tools and the dismissal of UML. That is only my opinion. I am not sure if you will find it widely accepted.
The one shining hope I had was that the new movement would be used as intended to help produce software factories. What I have seen come out of patterns and practices are not software factories as prescribed by the initial movement. If we look back to the original core piece of what a software factory encapsulates, we should see a software product line embedded within the factory.
What we find with the Microsoft software factories is that they are only a small part of what one would consider a software product line to be. They are code generation frameworks that have no domain specific knowledge at all. A software product line contains core components that support multiple selections of domain specific configurations. They are managed and configured using variability techniques.
The Microsoft software factories are simply plumbing that enables more of the same type of plumbing to be added through code generation.
They do however offer a solution that can enable a product line to be created and then lead into what one might call a software factory. Yet that is several iterations and projects down the road past where a software factory gets you to. I like to think of the Microsoft Software Factories as software factory enablers for certain types of architectures, that fall within the scope of what a Microsoft Software Factory can supply.
Although a little off topic I should mention that a common mistake that I see with them is that they are only squares that a lot of people are trying to make fit into circles, rectangles, and triangles. They are not good for every type of architecture or application. In my experience when they fit the needs of the architecture, they work great for producing a software product line. I have yet to take the software product lines any further to the point where they would be considered software factories.
I don't really know what to expect in the future of the software factory movement. It seems to have taken a path that left the original movement somewhere off in the distance. Like I said above, I think they are cool little tools that offer a great advantage when used correctly, but they should be renamed and redefined.
I guess the real aggravation stemmed from the role of the Software Architect being dismissed by Microsoft. That may not have been their intention, but it was the result of VSTS 2005 Architect Edition. Not only were we dismissed, but the industry standards that I have watched deliver success after success where spit on by the offering of the DSL tools and the dismissal of UML. That is only my opinion. I am not sure if you will find it widely accepted.
The one shining hope I had was that the new movement would be used as intended to help produce software factories. What I have seen come out of patterns and practices are not software factories as prescribed by the initial movement. If we look back to the original core piece of what a software factory encapsulates, we should see a software product line embedded within the factory.
What we find with the Microsoft software factories is that they are only a small part of what one would consider a software product line to be. They are code generation frameworks that have no domain specific knowledge at all. A software product line contains core components that support multiple selections of domain specific configurations. They are managed and configured using variability techniques.
The Microsoft software factories are simply plumbing that enables more of the same type of plumbing to be added through code generation.
They do however offer a solution that can enable a product line to be created and then lead into what one might call a software factory. Yet that is several iterations and projects down the road past where a software factory gets you to. I like to think of the Microsoft Software Factories as software factory enablers for certain types of architectures, that fall within the scope of what a Microsoft Software Factory can supply.
Although a little off topic I should mention that a common mistake that I see with them is that they are only squares that a lot of people are trying to make fit into circles, rectangles, and triangles. They are not good for every type of architecture or application. In my experience when they fit the needs of the architecture, they work great for producing a software product line. I have yet to take the software product lines any further to the point where they would be considered software factories.
I don't really know what to expect in the future of the software factory movement. It seems to have taken a path that left the original movement somewhere off in the distance. Like I said above, I think they are cool little tools that offer a great advantage when used correctly, but they should be renamed and redefined.
posted by tadanderson at 8:26 PM
1 Comments:
Tad, although not directly related to factories you should take a look at the April CTP of Team Architect:
http://blogs.msdn.com/jeffbe/archive/2008/04/11/april-rosario-ctp-now-available.aspx
Post a Comment
<< Home