Guidance Automation Toolkit (GAT), Architectural Description Document, Architectural Synthesis, Restrictive Development, and Product Line Engineering

The Guidance Automation Toolkit (GAT) has potential to be a very useful tool, especially if the organization is willing to make the upfront investment in an Architectural Driven Development process or a Product Line Engineering (PLE) process. It may provide usefulness in other processes with lower ceremony also, but the overhead of implementing it may not be allowed for in such processes. Not that it couldn't be, but the $$$'s for time are usually not allowed for by most organizations when doing one-off development, or other low ceremony projects.

Let's start by defining what we are talking about.

Guidance Automation Toolkit (GAT)-
The Guidance Automation Toolkit is an extension to Visual Studio 2005 that allows architects to author rich, integrated user experiences for reusable assets including frameworks, components and patterns. The resulting Guidance Packages are composed of templates, wizards and recipes, which help developers build solutions in a way consistent with the architecture guidance. From: http://msdn.microsoft.com/vstudio/teamsystem/workshop/gat/

Architectural Description Document-
I am not referring to Architectural Description Languages (ADLs), I am referring to a document that provides viewpoints and perspectives that are used to drive the architectural definition process. From: http://www.viewpoints-and-perspectives.info/index.php?page=library
Read more from this link to gain an understanding of what I am referring to by an Architectural Description Document.

Architectural Synthesis-
This is a production level Proof-of-Concept. It is a scaled down version of your application's architecture that includes all the pain points you find. By pain points I mean anything questionable found during your architectural definition process. The difference between a Proof-of-Concept and an Architectural Synthesis is that the later is most, if not all production level code, and a Proof-of-Concept is throw away code. An Architectural Synthesis provides a base of code with all the pain points and the implementation patterns implemented for the development teams to reference and use.

Restrictive Development-
This is an architects way of propagating the architectural constraints and patterns they want implemented through the analysis, design, and construction phase of the process. This is how they insure their quality attribute expectations are met throughout the process. A patterns catalog, including a pattern relationship diagram and code samples, for the architecture should be included in the Architectural Description Document, and they all should be implemented in the Architectural Synthesis. Developers are restricted to using these patterns when they need to implement functionality the patterns address. I plan to elaborate on this topic in a later Blog.

Product Line Engineering (PLE)-
A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. From: http://www.sei.cmu.edu/productlines/index.html

The GAT has the potential for providing the SPL application developer with an application architecture and providing that architecture with the constraint's implementation defined by the restrictive development patterns put in place during the Architectural Synthesis.

The following is directly out of the Microsoft's GAT help file:

Your company has developed Web services that can access both local and remote business logic. The Web services are exposed to internal and external clients through Web service interfaces. You want to define an application architecture that standardizes the development of these services. The architecture has the following properties:

• It prescribes a structure and architectural constraints for new applications implementing services.
• It is designed to be used across multiple business applications.
• It prescribes the use of reusable components and frameworks in the context of the architecture.

You want to create integrated user experience that simplifies adherence to your architectural guidelines.

Scenario Goals
You want to use the features of the Guidance Automation Toolkit to simplify and clarify the following processes:

• Starting a new application that complies with the architecture
• Adding new business logic and reusable components to work within the constraints of the architecture

Implementing User Experience with Guidance Automation Toolkit
To meet the stated goals, you develop a Guidance Package that consists of a number of recipes, wizards and templates. The Guidance Package meets the scenario goals in the following ways:
Starting a new application that complies with the architecture
Adding new business logic and reusable components that work within the constraints of the architecture

Starting a New Application that Complies with the Architecture
You write a solution template that creates the recommended structure of an application for developing new services. The application has solution folders and projects for Web Service interfaces, business actions that implement those interfaces, and service gateways that actions use to communicate with other services. The template places unbound recipe references and template references in the solution. The template also defines bound recipe references and template references that, along with unbound references, help the developer with repetitive tasks such as creating messages or implementing new business actions.

Adding New Business Logic and Reusable Components that Work Within the Constraints of the Architecture
The recipes and templates associated with the solution guide the developer through the routine tasks of developing business actions and exposing their logic through Web Services. To assist your developers, you create the following recipes and templates:

• A message-defining recipe that creates a message class and associates a custom tool with it. The tool uses an XSD utility to generate an XML schema for the class. This recipe can be designed as a recurring bound recipe associated with the solution folder that hosts projects with messages. The recipe would include a project as an argument, placing the generated message class in that project. Alternatively the recipe can be defined as an unbound reference, associating itself with a project in the solution folder.
• A business action template that creates a project for a business action and unfolds a class template for the action. The recipe associated with the template collects the project name, business action name, namespace for the class, and the input and output message classes. The template is a bound template, associated with the solution folder created for the business actions.
• A recipe to add a Web service for the business action to an existing Web service project. The recipe generates a new ASMX file and class with a method that is a façade to the business action method.
  © 2005 Microsoft Corporation. All rights reserved
  

The GAT does have a learning curve, and the implementation of a Guidance Package of substantial size will require management to allot the time needed to do so, but for companies already investing in making re-usable architectures for a SPL, the time will be worth it.