Software Factories

Keith Short has been working on solving the problem of software productivity for many years - at JMA, Texas Instruments, and now at Microsoft. He is writing a book on Software Factories, and there is a 2-page flyer (pdf) describing the approach. 

I asked Oliver Sims (the author of "Business Component Factory") for a comment. He writes:  

The work going on at Microsoft is very encouraging. I despaired a time ago of the Java community ever grasping the nettle of high-productivity software development. While I think they are going in the right direction, it's not clear that they will achieve as much as they could.  

I have not yet read the book, although I have it on order.  

So, based on the two-page article you pointed me at, I'd say the biggest difference between the MS approach and the BCF approach is that MS is building up from tools, whereas the BCF approach says "this is how we want to design and build systems, to run on a number of platforms; now what tools are needed?". The former is not so concerned with platform independence, rather it focuses on making the MS toolset a lot more productive, given that the MS platform is the target. 

In summary, I think MS could revolutionise the industry if they lift their sights somewhat. But there is a danger that they will not, and will therefore miss the real opportunity. Time will tell ... 

I think there are five key issues that Keith would have to address (a) to maximise productivity and (b) if MS decided to broaden their approach to address other platforms than MS. I'm not attempting to de-conflate these two, since I think they're linked. The five issues are (in no particular order, and wrt the two-page article):  

(1) Level of Architectural Style: It could be that MS is aiming too low, and is thinking primarily in terms of MS platfroms. Thus Jack and Keith talk about a factory schema for building "thin client eCommerce applications using MS [platforms]". I believe one can lift the level of abstraction further than that, and include rich client as well. We certainly got near to this when working with the BCF described in our book. This would reduce the number of different factories, but would increase the complexity of the generators or whatever. However, the big advantage would be much greater platform independence (we were aiming at web-based and rich client, with various server software including AS400!).  

(2) Raising the level of the platform: The aim here is to have app developers (and the people providing tools, patterns, etc) have a simpler environment to target - i.e. more transparencies. This will result in less code being generated, tested and deployed. And less code is goodness. In effect, the more generic code (that performs adequately) there is, the better for everyone.  

The platform level should be raised bearing in mind a specific architectural style - otherwise you can't raise it! I call this a "virtual platfrom" since it's COTS products plus what in any IT shop is called "glue". So it's not a real "platfrom" that you can buy off-the-shelf. Much glue is common to a particular architectural style. MS could really go to town on this within the scope of the MS platfroms, but it's not evident that they intend to do so. (But who knows, perhaps they are?)  

Without a higher-level platfrom, there is a danger that the DSLs (of which I'm all in favour) merely provide a nicer interface to tools, rather than creating a cohesive toolset for building any system that conforms with the architectural style.  

There is much more to say on this, but that's probably enough for this headline as it were. 

(3) Coehesive end-to-end and top-to-bottom architecture: Keith does talk about patterns (and I think he includes architecture in this), and also that you need not only specific point-solution patterns but also end-to-end patterns of several sorts. However it's not immediately evident that all these patterns must be woven into a cohesive whole that defines the architectural style. Of course, we all agree that architecture (and I'd say process) should be delivered to developers through tools, surfacing (for example) as directions on what to build, and constraints as to how the things built can interact. 

(4) Organization: There is no mention of the need to move away from project-based development to a product line development. If this is not done, then all the DSLs in the world will not improve overall productivity much, espeically that no-one wants highly-productive stovepipe building, but rather highly productive develoment of systems that are flexible, scalable, resilient, interoperable, etc etc.  

(5) Executable designs: MS are, I believe, very much focused on generating code (except in such areas as Biztalk of course). They should also be thinking of executing models directly. 

 

See also contribution by Oliver Sims to the WSDL/JINI debate