This Monday we are kicking off the refresh of the Visual Studio Architecture Tooling Guidance.

If you are a subject matter expert or have feedback on the previous release, please contact us!

(More info about this refresh can be found on Willy’s blog)

A few days ago Microsoft patterns & practices released a (preview) set of Layer Diagrams for Visual Studio that comply with their Application Architecture Guide 2.0. The diagrams are included in a simple VSIX package that can be downloaded from the Visual Studio Gallery. The image below gives you some idea about what to expect from this package. The diagram also contains a link to the complete architectural guidance on MSDN.

The layer package is a great start but there might be more opportunities for integrating architectural guidance in Visual Studio 2010. Right now, the package contains 5 layers diagrams so it shouldn’t be too difficult for an architect to decide which of the layer diagrams he should choose from the toolbox. But, what if we have additional layer diagrams or in addition to the diagrams we also have predefined architectural inspections and/or validations that the architect can choose from? In that case we might need additional guidance to help the architect choose between the various diagrams, validations and inspections. Below you can see a screenshot of a prototype we did in this direction where we use a WPF form to ask the architect some questions. Additional questions pop up based on the selection the architect makes (clicking yes or no on the form) to help him decide what exactly he needs for his architecture. In the end, based on his selections, the the environment is prepared for him.

This is just a prototype and not production ready but it might give you some ideas about how we think we should provide guidance. In the past couple of months Clemens and I have done some work on these ideas  but we haven’t really finished it yet. Now Visual Studio 2010 becomes close to RTM it is time to finish this so expect some updates in this direction.

Stay tuned!

Currently, Clemens and I are writing a whitepaper about Architecture, Application Architecture Guide 2.0 and Visual Studio Team Architect 2010. (VSTA). In addition to this paper we are also working on some ‘tooling’ that we plan to deliver with the paper. Since we are not done with the paper and tooling yet and this blog becomes a bit too quite I decided to start sharing some of our thoughts and work in this space on this blog.

One of the topics in the paper is, what we call, ‘Architectural Inspections’. Without going into too much details just yet we can think of an Architectural Inspection as a ‘check’ to help us verify the correctness of (parts of) an application architecture. The concept isn’t totally new, in fact the Application Architecture Guide 2.0 comes with an organized checklist that sums up important inspections that an architect can use during the design and/or validation phase of an architecture. Although a checklist is a great start, we think that a standalone checklist doesn’t get the most out of these so called Architectural Inspections. In our opinion it will be much more powerful if we can include these inspections in our Application Lifecycle Management practice, integrate them in the Visual Studio IDE and provide the right guidance at the right moment!

To validate our thinking, we collected all the inspections in the Applications Architecture Guide 2.0 checklists and stored them in an XML format. In fact, we used the Team Foundation Server 2010 (TFS) Work Item Type XML format which enables us to easily upload our Architectural Inspections into TFS as work items. In addition to the ‘core’ Architectural Inspection data, like title,  status, description (where we explain what we need to validate and can add additional guidance) we added some meta data to categorize our Architectural Inspections and make it possible to do some grouping. For example, we can categorize our Architectural Inspections per ‘Cross Cutting Concern’ (Logging, Validation) or ‘Layer’ (Service Contract, Business Logic, etc.) or ArchType (Mobile, Rich Client, Service, etc.), or whatever we think makes sense. In addition we have build a little tool that lets us upload these Architectural Inspections into TFS as work items. Currently we store our Architectural Inspections as normal ‘Task’ work items and abuse some ‘hidden’ fields to store the meta data that we need. However, we already realized that we are better of defining our own work item type for our Architectural Inspections. So, this is probably the next thing on my ToDo list…

Below you can see a screenshot of (a very basic prototype of) the tool that we are using to upload our Architectural Inspections into TFS. As you can see we haven’t spend too much time on the User Interface yet and the data in the screenshot is just dummy data that doesn’t make too much sense.

However, the most important thing right now is that by using a tool like this we (as an architect designing an architecture) can easily decide which Architectural Inspections make sense for the architecture we are designing and add only those inspections into our Application Lifecyle. This means we can, for example, add only those inspections that apply to the layers or cross cutting concerns that our architecture requires. (In a future post we will demonstrate how we can even relate the inspections to layers in our Layering Diagram.)

Another thing that we think is important is to have a clear overview of all the inspections that are considered and/or executed during the design and/or implementation of the architecture of the application. Knowing that the guidance and best practices of a particular inspection wasn’t properly implemented or worse totally neglected is important information and (potentially) tells us something about the quality of the application. Of course sometimes it makes perfectly sense not to spend time on cross cutting concern X. However, at a later time we can’t recall the reasons for not spending effort on them.  The fact that we now have our Architectural Inspections stored in TFS (as work items) makes it possible to track the current status (by using the status field (Active, Closed, Rejected?) )and provide us with valuable information about the design decisions (captured in the description field?)  that are made during the lifecycle of our application.

Last but not least we think that, to get Architectural Inspections fully integrated in the Application Lifecycle, we need a proper way of visualizing them. In fact, an overview of these inspections and their status might be good starting point for a quality check or valuable input for our testers. The most common way for visualizing the status of work items would obviously be to create a report in TFS. However, we thought we better get some experience with another cool new feature of VSTA 2010 so we decided to visualize our inspections in DGML. So, what we did is, we create a little utility that extracts the Architectural Inspection information out of TFS and generates a nice DGML diagram for that. Below you can see a screenshot of how our first implementation of this looks like. (again, we might need some UI improvements and some real data) 

The little icons in the nodes (representing an inspection) display the status of the inspection. At this moment the green check means the inspection has the ‘Closed’ status in TFS and the warning sign means it has the ‘Active’ status (so nothing has been done with it yet).

There is a lot more to tell about the things we have been working on and the thoughts we are still having about Architectural Inspections, Application Architecture Guide  and VSTA 2010 extensibility. We are currently busy improving and refactoring all of the above. In the coming period we will share some other VSTA extensions that we are working on and if things goes as planned everything will end up in the whitepaper and/or downloadable assets. So, stay tuned and of course we are very interested in your opinion, concerns, etc. so leave us a message!

In a previous post we already mentioned Blueprints as a means for integrating architectural guidance from the p&p App Arch Guide in the VS2010 IDE. Clemens already mentioned how we can capture some of this knowledge in an item template and use the IWizard interface to populate the diagram. Now, let’s see how we can use Item Templates in a slightly different way and use them in a Blueprint to unfold a predefined architecture (Layering Diagram) in VS2010.

The first step is to capture the architectural guidance in a Layering Diagram that we can reuse. To do this we can we create a new Modeling project and add a Layering Diagram to this project.

In this diagram we can model all layers, dependencies, etc. to make it reflect our architectural guidance. Once we are done it might look something like this.

To make this diagram reusable we have to create an Item Template for it. Unfortunately VS2010 doesn’t let us select the layering diagram in the Export Template Wizard so we have to manually create an item template for our layering diagram. The easiest way to do this is to create an Item Template for another file type (i.e. C# class) and modify the ‘MyTemplate.vstempate’ file in the .zip file that VS2010 generates and add the two diagram files (.layer and .layer.diagram) to the .zip file. The modified MyTemplate.vstemplate file should look something like this.

Now we are done creating a reusable layering diagram we can integrate this with a Blueprint. (of course we can create more item templates for other architectures defined in the p&p App Arch Guide)

In this post we will not explain how to create a Blueprint from scratch but this is pretty easy. Especially after watching the How To videos. Once we have created our Blueprint we can use a Workflow Foundation based workflow to actually add our predefined layering diagram to our solution.

To do this, we first have to add a Workflow Command to our Blueprint (screen cast for more details) that will enable our Blueprint users add a layering diagram to their solution. The documentation that comes with the Blueprint Workflow Command provide us with the code we need to execute a workflow. However, this code assumes we are executing a ‘XOML only’ workflow. In our case we choose to use a codebehind for our workflow so therefor we use the ‘ExecuteWorkFlow’ method instead of the ‘ExecuteXomlWorkflow’ method. The code in your command might look like this (added some hardcoded paths instead of calls to helper class to get the correct paths).

Now that we have the command in place we have to create the actual workflow that we execute from the command. After installing Blueprints we get a few extra activities that we can use in the workflows in our Blueprint. Below we can see how this workflow might look like.

The ‘ShowDialog’ activity in this workflow is a normal ‘Code’ activity that in this case shows the (very simple) dialog that is displayed below. This dialog lets the user select the architecture that will be used in his solution.

Once the architecture is selected, the workflow continues with the ‘CheckProjectExists’ activity. This Blueprint specific activity checks if the current solution contains a ‘Modeling project’ with the name ‘Architecture’ (I am sure you can come up with a better name ;)). If not, the project is created. After that the ‘AddLayeringTemplate’ activity is executed to actually unfold the selected item template that will add the predefined layering diagram to our modeling project in our solution.

In this post we deliberately left out some implementation details that you might need to implement this yourself. However, hopefully it does explain the basic scenario of how to add some architectural guidance from p&p App Arch Guide by using Blueprints and VS2010 Layering diagrams. In future posts we will ellaborate on this scenario, share some more technical details and eventually might even end up with a working solution that we can share .