GAT is now Blueprints
The old GAT is dead! Long live the new GAT aka “Blueprints“. This news caught me by surprise. I thought I was fully abreast of the happenings in this area, but was caught napping. [Ok, so I’m being a bit dramatic here. GAT isnt actually dead but has evolved into a new offering thats IMO much better. As far as the old GAT (runtime, support, tools etc) is concerned , I’ve put in a couple of points at the bottom of the post, but make sure you check the official support information before making any long term decisions on all this].
So, what’s all this Blueprint stuff about?. Well, essentially GAT/GAX and the first set of factories (Service Factory, WCSF etc) all validated the concept of factories and established how tooling could work and where it fell short. VS Extensibility has also improved a lot since these factories first came out. So its now time to take the concept of Factories up one level into Software Product Lines etc which is closer to the original vision of factories. Along with the P&P factories, there was a separate project called Glidepath for ISV’s which provided lightweight tooling and was instrumental in delivering the S+S Blueprints. It made sense to align the two areas together and thus the new project.
An excellent video which introduces the Blueprints concept including demos of currently available blueprints can be found on Channel 9 titled “Beyond VS Packages – Adding Value with Blueprints” and is presented by Jack Greenfield and Michael Lehman. Some of the things that I find really cool and worth calling out here are
- Dynamic Versioning
- Workflow Based Process
- Workflow Based Commands
- Design & Runtime Composition
- Designer Integration
- TFS Integration
I’m not going to talk about them in depth as Jack and Michael explain them very well in the C9 video.
The big problems I found with GAT were (a) the authoring experience and (b) the appalling lack of good documentation. In terms of the documentation, the CHM files provided with the install gave a quick overview of recipes and actions and then dived straight into class library level. Having info on class libraries in the tool is ok when you have grasped the basics and are productive to some extent and then need to look deeper. There were a few blog posts by folk who had played with it, but no official stuff. You had to learn by poking into existing factories like Service Factory etc.
In terms of the authoring experience, GAT is too low level. Hand editing XML files doesn’t make for a great authoring experience. Clarius Consulting played a big role in helping matters with their Software Factories Toolkit (SFT) and in fact that toolkit was even used in the Service Factory and also in the BizTalk Solution Factory. The SFT introduced the concept of a visual designer for recipes and actions. The P&P team did a nice thing in releasing the Guidance Extensions Library (GEL) where you could cherry pick the recipes and actions they used for various factories and put them into your own. But IMO, the thing that was missing was an overall design tool, which, for instance, could allow you to put all the items from the GEL and your own into a sort of toolbox and then drop them on to a design surface to build your package.
Now I was pleasantly surprised to discover that the Blueprints does feature this sort of design tooling, specifically using WF to achieve this (essentially GAX Actions become WF Activities). WF is a perfect fit for this sort of thing so I’m glad we’re getting this kind of authoring support. WF is not only for the package building but the whole guidance process is represented as a workflow. With the WF based process, the guidance can even take on a “parallel” nature. This will be useful for some packages where after a certain number of steps which lay the foundation, you can do any other actions that dont have to follow a sequence or which arent dependent on each other.
Now, one of the limitations with GAT was that if a menu item (corresponding to an action) was missing or disabled, you were left wondering if there was a problem with the package. With Blueprints however, we can see what actions are available or not depending on pre-conditions and post-conditions so there is no guesswork involved in knowing what comes next. Blueprint authors can use pre and post conditions to examine the solution or check an external system (say a live web service) and do various other things as part of the flow. This makes ‘composition’ of actions much easier because an action can come with a little ‘pack’ of conditions to help the author decide where it slots in the oiverall flow and what guidance or extra steps may be required between one action/step and another.
The story now gets even better with Design & Runtime composition which is explained in the video.
Going back to GAT/GAX, two key things are
(a) there will be a ‘rev’ of GAT/GAX for VS10, but no new functionality and no changes to the current set of factories and
(b) There will be a migration blueprint which will allow authors of current factories to move their code-base into the new system and the GAX runtime will still be available so actions will continue to work. I imagine this migration blueprint will be intensely dog-fooded as the P&P factories would need to move to this platform and they have made a large investment in GAT.
Another thing which is worth pointing out is that we’ve still got a long way to go to Dev10 etc and although we are in the Blueprints 2.0 era already, in terms of the GAT ‘integration’ I think there’s a long way to go. GAT may have authoring issues but its pretty rich functionally and once you really get into it you can be quite productive. I’ve started to poke into Blueprints now and trying to ascertain whether it really is ready to take over from GAT. At this point, I’m not totally sure it is, but I could be wrong. Let’s see. GAT isn’t really dead yet, but if you are just starting to look at factories, its best to understand where things are headed.
Looks like the world of VS10 and associated products/offerings is going to be very exciting and productive indeed.