Letting the GAT out of the bag

Weather permitting, we will be releasing the first tech preview of the Guidance Automation Toolkit, or GAT, this week. <Update: It is now released> GAT is a little different to what you have come to expect from patterns & practices deliverables, so I'd like to spend a bit of time explaining why we did it, and what it will mean to you. Also make sure you check out the recent posts on this subject from Wojtek, kzu and Oscar, and the recent webcast is also a great way of getting up to speed.

Now, over in p&p land, we think of ourselves as in the guidance business, not the tooling business. We produce things like application blocks, reference architectures and patterns. While all of these asset types have quite different form factors, they also have a lot in common - they consist of a combination of source code and written guidance, they demonstrate proven best practices for building certain types of things, and they need to be contextualized or extended in order to fit into your solution. This last point is important as it allows our guidance to be applicable to many types of applications and architectures - but it does mean that "some assembly is required" (to quote from Ikea). Naturally, we try to make this assembly process as easy as possible, but until recently our main technique for doing so was writing documentation. For example, we need to tell you that in order to use an application block, you need to add a reference to certain assemblies, write certain code, and add certian configuration information. With EntLib we've made the configuraton process simpler, but there is still a need to put everything together before you get any kind of useful result. And application blocks are one of our simplest deliverable types. If you've played with larger deliverables such as EDRA, there are many more steps to complete and things to understand. This isn't really the fault of the deliverable - it's just a much bigger thing - but the result was that we needed to create lots of documentation and samples. Most of the feedback we got was that documentation we supplied with EDRA was very good, but we also know that most people would prefer not to need to read through hoards of documentation just to use a guidance asset.

So out of all this, our In Product Guidance program was born. The goal was to find ways to make it easy to integrate our guidance deliverables into our toolset, predominantly Visual Studio. While Visual Studio has always been extensible through Enterprise Templates, interfaces like EnvDTE and the VSIP program, we found that these mechanisms weren't at the right level of abstraction to meet our requirements without a lot of code. So we decided to build our own abstraction later over the top of Visual Studio 2005, ultimately christened "GAT", which used all of the underlying extensibility mechanisms, but exposed simple but powerful concepts such as recipes, templates, launch points and text templates. I won't go into what all these concepts in this post, but basically they are designed to make it easy to automate routine tasks associated with guidance assets such as application blocks, frameworks and application architectures by exposing the necessary functionality at the locations, and times defined by the asset's architect.

So GAT was born out of the need to improve our own guidance deliverables, and over the next year or so we hope to start utilizing GAT in more and more of our projects. But wait (as they say on late night infomercials), there's more. Although p&p is a relatively unique team, we found that many customers had a need for this type of deliverable in their own organizations. Many organizations have defined an application architecture, often consisting of frameworks and components, but frequently the architect's preferred tool for expressing architectural concepts is the three-ring binder. (Why three, I often wonder. Maybe there are some things that we mortals are not meant to know). Now impressive though these three-ring binders often are, the problem is that very few developers actually read them. And of course, this makes it pretty difficult for them to build apps that comply with the architect's wishes.

This is why we are releasing GAT to you, rather than just keep it as one of our own secret ingredients. We've tried to make it very easy to use (especially compared to previous extensibility options), so that building "guidance packages" around your organization's guidance assets will be a real option to improve usage and compliance with your architecture. In fact most of a guidance package is definied in XML, so very little programming is involved (dare I say, even an architect can do it :-).

Before I finish up (I know this is getting long!), I'd like to quickly touch on why we are calling this a Technology Preview release. GAT is actually pretty well fully baked, and went through the same amount of test rigor as any p&p deliverable. However we called it a Tech Preview for a couple of reasons. First, it is tied to Visual Studio 2005 Beta 2, and any pre-release issues with VS may also impact GAT. The other big reason is that this is something of an experiement, and we aren't quite sure exactly where it will go. We chose to release this as a preview to show that we haven't got all of the answers yet, and we'd love to hear your feedback on how useful this is and where we should take it next. Once the site goes live, you'll see that we are positioning GAT as a part of our larger Software Factories initiative. This is also a work in progress, and we need your help to make it as valuable as possible.

This posting is provided "AS IS" with no warranties, and confers no rights.