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!

A few days ago I was asked by one of my colleagues why I am spending a lot of my time experimenting with Visual Studio Team System 2010 (Team Architect), Blueprints, App Arch Guide and Application Lifecycle Management (ALM) in general. He noticed me ‘living’ in VSTS 2010 CTP for some time now and he was wondering if it isn’t a bit too early for this and what I did to convice to management to let me do this. My immediate answer to this question was ‘No, it is not to early!’ and I explained that we (Inter Access) expect VS 2010 to help us optimizing our Application Lifecycle Management practice. This answer was a bit too vague for my colleague and of course the next question was how will we benefit *exactly* from investing in VSTS 2010 and ALM. Will it make our life easier?, will it makes us better people?, will it improve quality?, will it save us time?, will it save us money?

Exactly these same questions popup when discussing ALM with customers. Apparently making the business case for ALM (and/or VSTS licenses) isn’t always easy. How come?

From our experiences we learned that currently most people and organizations are relating ALM to their development activities (Software Development Lifecycle). Therefore it is only logical that this is the area where people are trying to identify their benefits (costs savings) from ALM. But is this correct? Is this focus too limited?  Shouldn’t we focus on more than only development when it comes to cost savings? Especially if we keep in mind that, on average, only 30% of the IT budget is spend on new application development (the remainder is spend on maintenance/operations)!

How come most of us still only focus on development? Is it because we still focus too much on the tools instead of facilitating collaboration between ‘Business’ ‘Development’ and ‘Operations’?

Everybody experienced in VSTS 2005 and/or VSTS 2008 will come to the conclusion that these tools mainly focus on the different roles within the development team (developer, architect, project management). Source control, unit testing and quality assurance features of these products provide us with a professional development environment and help us improving the overall quality of the products that we deliver. Work item management, a centralized store, reports, portals, etc. improve the collaboration within the development team and support project management in tracking progress, staying in control and managing risks adequately. All of this is great and potentially boost the performance of the development teams but experience learns that these benefits don’t come ‘out of the box’! Installing the tools doesn’t make the development team collaborate by default and most certainly doesn’t stimulate collaboration with the Business and Operations!

Now we know where most of us focus on for their ALM related activities, let see how this relates to the complete application lifecycle. For this we will use an the graph below were the x-axis represents time and the y-axix represents value and negative value displayed as costs.

Obviously the lifecycle of the application starts with its development. During this phase we have to make costs to design, develop and test the application. At that time the application doesn’t bring us (actually the business) any value and the complete development phase of the project only costs money. From the moment the application (parts of it?) are installed into production the appliaction starts to generate value till the moment it needs to phase out where it starts to cost money again.

What we see is, that most organizations are focusing on reducing the developments costs and (sometimes) try to shorten the time to market. Btw. it doesn’t come as a surprise that these are exactly the areas where the current releases of Visual Studio Team System focus on.

Reducing costs and make the application add value earlier is good but if we have a look at the image above we can see that the application lifecycle doesn’t end at the moment the application goes into production (where lifecycle line crosses x axis). So, wouldn’t it be great if our ALM practices help us optimize (reduce costs and/or increase value) during the remainder of the application lifecycle also?

For example, one of the things we can do to increase the business value is to practice a proper User Experience design (see this post of my colleague Andries for more info on this). By taking ‘Operations’ into account during the design and development phase of the application we can reduce operations costs during the remainder of the lifecycle. These things combined will result in an application that is more successful for a longer period of time (because it adds more value and costs less to maintain). Also, because we have done a good job developing the application, we know exactly what it does, where it is interfacing with (something VSTA 2010 will help with) and most importantly when it stops adding value which will help reducing the ‘phase out costs’ of the application.

Adding this to the graphical representation of our application lifecycle results in a graph that looks like this.

Based on this, we can now draw our new  application lifecycle which might looks something like this (dotted line is new lifecycle).

The good news is that the green area between the ‘old’ and ‘new’ lifecycle is the area were we can make money by adding extra value. The red colored areas is the place where we can make money by reducing costs. Doesn’t that look great???

Please note that ‘Reduce operations costs’ might be misunderstood from this graph. We don’t mean less value but less costs. I didn’t know how to display this correctly

Of course, all of these things don’t come by itself. We have to actually work for that to make that happen and we can’t do everything at once. In this post I am not going to detail all the steps that we can do to make that happen and where we can use the current or future tooling for. However, hopefully this last image makes it very clear that there are others areas, besides development, within the application lifecycle where we can either reduce costs or increase value. So, if anybody aks you why they should invest in ALM this image should give you a starting point for your discussion…

At least, it *did* help me explain why I should spend my time on ALM and experimenting with VSTS 2010, Blueprints and App Arch Guide

In an earlier post we mentioned that it is relatively easy to get the current Blueprints bits running on the Visual Studio 2010 CTP by modifying the .MSI in Orcas. At that time we forgot to mention that we need a few extra steps to really get things going with Blueprints in Visual Studio 2010.

When trying to build a Blueprint solution in Visual Studio 2010 we will notice the following error in the error window.

As we can see, the build task ‘BASM’ is failing to retrieve the correct path. This task is implemented in the ‘Microsoft.SoftwareFactories.Blueprints.Builds.Tasks.dll’ that can be found in ‘..\Program Files\MSBuild\Microsoft\Blueprints\2.0’. It turns out that the execute method of this tasks looks for a (hardcoded) ‘String Value’ called ‘Blueprints’ under the ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports’ tree. Because we replaced all ‘9.0’ in ‘10.0’ in the Blueprints .MSI to get it to install on Visual Studio 2010 this value doesn’t exist under ‘9.0’ anymore (but does under ‘10.0’).

To fix this we can either make sure to skip this particular replacement when modifying the .MSI in Orcas or manually add the Blueprints ‘String Value’ under the ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports’ and give it the value ‘C:\Program Files\MSBuild\Microsoft\Blueprints\2.0\Microsoft.SoftwareFactories.Blueprints.targets’.

Another issue occurs when debugging our Blueprint in Visual Studio 2010. Currently, there is no property page implemented for the Blueprint project type (.bpproj) and therefore starting up Visual Studio 2008 is hardcoded in the Blueprints core. To get around this we can add an empty C# ‘Class Library’ project to our solution, set this project as the ‘StartUp’ project and make this project startup Visual Studio 2010 (property page) when debugging. Although this solution does work it makes the Visual Studio instances in my Virtual PC image VERY slow (don’t know why). Another option, that does work for me, is to leave the Blueprint project as the ‘StartUp’ project, let it start up a Visual Studio 2008 instance, (and simple ignore it) manually start another Visual Studio 2010 instance and attach this instance to the debugging process of the Visual Studio instance we started the debug session in.

Now everything is in place to *really* start developing Blueprints for Visual Studio 2010 CTP!

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 .

During the development of our Blueprints we can sometimes use a little extra help to understand what is really going on. It turns out that if we add a Registry setting called ‘EnableDeveloperFeatures’ under the ‘HKey_Local_Machine\Software\Microsoft\Blueprints’ key and set its value to ‘true’ we get a few extra features enabled in the Blueprint Manager that might help understand (debugging) Blueprints . In the screenshot below we can see the checkboxes that become visible after we have added the ‘EnableDeveloperFeatures’ setting to the Registry. The checkboxes are read only in the Blueprint Manager dialog but can be set through the Registry.

As we can see, the ‘Custom Menu Filter’ checkbox is checked which means custom menu filters are enabled by default for our Blueprints. We can disable this feature by adding a ‘DisableCustomMenuFilters’ setting under the ‘HKey_Local_Machine\Software\Microsoft\Blueprints’ key and set its value to ‘false’.

To enable logging in the Blueprint Manager we can add the ‘BPMLogging’ setting to the Registry and set its value to ‘true’.

In an earlier post I demonstrated how to create a custom menu filter. After adding a ‘MenuDebugging’ setting to the Registry and set its value to ‘true’ we can see that Blueprint Manager now logs (output window) that it actually detects the custom menu filter that we created and also determines if it should be visible or not.

Hopefully, enabling these features help a little during the development of your Blueprints…

For some (experimental) work that I am currently doing with Clemens we needed a version of Blueprints that installs on the current VS 2010 CTP. I am sure every developer already knows how to modify an .MSI package by using ‘Orca’ (part of Windows SDK) so I am not going to explain in detail how to do that. However, the good news is, that if we open the Blueprints 2.1.2 CTP in Orca, replace every occurrence of ‘Visual Studio 9.0’ by ‘Visual Studio 10.0’ and save it again we are good to go. No other changes needed. The modified installer runs without issues on VS 2010 CTP and so far we haven’t found any problems with Blueprints on VS 2010.

If you are interested in the work we are doing, I suggest to go read an introductional post that Clemens just posted which describes some early ideas. Expect some more details in the next coming days, weeks, months on both Clemens blog and/or this one.

My friend Pablo just released Sticky Notes. As one of the beta testers for this cool Visual Studio extension I had the opportunity to play with it for some time and I found this a very handy and easy to use tool for ‘managing’ comments in source code. I mentioned to Pablo it might be cool to include TFS integration so I really hope this will be a feature for Sticky Notes vNext! I suggest you take a look at the screenshots and videos and decide for yourself how this can help your development activities. Great work Pablo!

For one of the Blueprints I am currently writing I had to add a menu item that enables the Blueprint user to execute a specific task (command). Adding menu items to a Blueprint is pretty easy by using the Blueprint configuration dialog. As we can see in the screenshot below we can also set the ‘visibility for the menu item by specifying a menu filter in the ‘Visibility box’ on the dialog.

The current Blueprints CTP comes with a few ‘built-in’ menu filters like: Project=roject name, FolderEndsWith=folder name, etc. (complete list can be found in de Blueprints documentation). Of course I needed a menu filter that wasn’t available out of the box. Unfortunately the documentation doesn’t say anything about adding custom menu filters but luckily a little experimenting (and Reflector ;)) was enough to get this to work.

Here are the steps to implement your own custom menu filter: 

The first thing to do is to simply add the name of your new custom menu filter in the ‘Visibility’ box of the menu item you want the custom menu filter to be applied on. In this example we also pass a custom argument (‘BlaBla’) to our custom menu filter.

The second step is to actually implement the custom menu filter. This can be easily done by adding a ‘Command Extension’ project to your Blueprint solution (Blueprints menu –> Add Command Extension). This project already implements a post build event to make sure the .dll that hosts your command extension is copied to the correct location to let Blueprint Manager find it during execution of your Blueprint.

for this example we can delete all default files in the extension project and add a new class to this project that implements the ‘IMenuFilter’ interface (add a reference to the ‘Microsoft.SoftwareFactories.BASMAPI.dll’ assembly that can be found under the Blueprint installation directory).

In this class, the ‘FilterSupported’ method is used to decide whether a  custom menu filter is supported in our Blueprints. Àll we have to do in this method is return ‘true’ for the custom menu filters (name) that we want to support in our Blueprint. (note that we can handle multiple custom filters here).

The ‘Visible’ method is used to decide whether the menu item that has our custom menu filter applied should be visible or not. The screenshot below demonstrates a, not very useful (and not bulletproof), implementation of a custom menu filter that only shows the menu item in case the Blueprint user right clicks the Solution (Solution Explorer) and the name of the selected Solution starts with the parameter supplied to the custom menu filter (‘BlaBla’ in this case).  As said, not a very useful filter but it hopefuly demonstrates what can can be done here.

After we finished the ‘Visible’ method, we are done implementing our custom menu filter and all we have to do is make sure the Blueprints Manager knows about our custom menu filter. How?

As we can see in the screenshot below, the menus that we define in our Blueprint configuration dialog (see above) are stored in the ‘config.xml’ file of our Blueprint (located in the properties folder in our Blueprint project).

At some point, the Blueprint Manager parses this config file, searches for custom menus, detects the ‘MyCustomMenuFilter’ that we specified in our menu item and notices it isn’t one of the ‘built-in’ menu filters. At that time the Blueprint Manager checks if any additional ‘resources’ are registered for our Blueprint that might host an implementation of the ‘IMenuFilter’ interface. To make sure the Blueprint Manager can find our extension, we register our custom menu filter by adding the following (screenshot below) to the config file of our Blueprint.

After that, if the Blueprints Manager detects a menu filter that is doesn’t recognize, it will search its additional resources and find our custom menu filter implementation. It will then call the ‘FilterSupported’ and ‘Visible’ methods on our ‘CustomMenuFilters’ class to decide whether or not the custom menu item is supported and under what circumstances display our menu item.

When working with a Blueprint to deliver a product, we very often start with unfolding a solution/project structure (template) that reflects some architectural guidance. When building a Blueprint, we have a few options for unfolding templates within our Blueprint (that we can set through configuration as displayed below). The option ‘None’ obviously doesn’t unfold a template at all, ‘Auto-generated’ unfolds a predefined project template (C# class library) and ‘User-supplied’ provides us with the possibility to define our own solution/project templates. (The guidance that comes with the current release of Blueprints does a pretty good job describing these three options)

However, sometimes we need even more control before, during or after template unfolding (ie create folder structures, complex dialogs, Add to source control, etc.). Luckily, there is another mechanism that we can use for this scenario that gives us full control!

We can add a ‘Command Extension’ (right click on your Blueprint and select ‘Add Command Extension’ from the Blueprints menu) and write an extension that unfolds our custom project templates. 

Adding a Command Extension to our Blueprint gives us a new project in our Blueprint solution. This new project already contains an example extension that we can modify to implement our custom unfolding logic.  Below, a simplyfied implementation of this modified Command Extension is given that uses the custom ‘MyTemplate.vstemplate’ template and unfolds that to a (hard coded) location.

After we fully implemented our extension, we can add this Command Extension to the commands collection of our Blueprint (More info on how to add commands can be found in the Blueprints documentation).

The real ‘trick’ here is to name the command ‘INIT’ which will force the Blueprints Manager to execute the command automatically for us when unfolding our Blueprint to a (empty) Visual Studio solution. Also, don’t forget to set the ‘Template’ option in the Blueprint configuration dialog to ‘None’! Note that we also added a switch statement to our implementation of the Command Extension to only execute the template unfolding in case the ‘INIT’ command gets executed.

With this in place we can write complex ‘vstemplates’, that include WizardExtensions to collect user input and rely on the Blueprints Manager to execute our ‘INIT’ command to unfold these templates when developers add our Blueprint to their Visual Studio solutions.

Apparently I wasn’t the only one with questions about the relationship between OLSO and the DSL Tools. Both Stuart Kent (DSL Tools) and Keith Short (OSLO) respond to these questions from their point of view. Although both offerings are based on a different technology stack, they both have a lifecycle in front of them, the responsible teams aligned their vision and differences will be bridged over future releases. That’s what I call good news!