Mark Groves' Weblog: Architecture

New Work Blog

Mon, 24 Jul 2006 22:57:09 GMT

Since I have been a Microsoft employee for about 9 months (WOW, 9 months already), I thought it would be a good idea to move my work related content over to blogs.msdn.com. Of course since I have been very lazy, on even updating this blog, I guess I now have twice as much content that needs published :)

My new work blog is: http://blogs.msdn.com/mgroves

Design for Security

Wed, 12 Apr 2006 01:34:27 GMT

One of the lesser know features in Visual Studio Team Edition for Software Architects (VSTESA), is the ability to run Validators over your models. The designers within Team Architect use System Definition Model (SDM) to model Systems, Resources and Endpoints. SDM provides a constraint validation mechanism to validate mutual conformance of application and logical datacenter designers against each other's requirements defined. This constraint mechanism can be extended to validate the design against best practices as well. A Validator is just a custom defined constraint validating the design against items such as security, performance or architectural design best practices. There will be an upcoming walkthrough and accompanying white-paper describing how to build a Validator in the coming months on MSDN, that Erbil is working on.

The ability to build validators that check models for known security risks are key to our ability to do Threat Modeling through tools like the Threat Analysis & Modeling v2.0. Although validators are great, not all countermeasures can be validated through our tool. Some items just need to be checked manually, to ensure that work is done and not forgotten, that's Team Foundation Work Items come into play. ACE is working on exporting the countermeasures into TFS as work items in their next release. This ability, along with Validators, really makes the ability to conduct Threat Modeling on your design traceable as you work through various iterations of your project.

MSDN Webcast: Visual Studio Team System Extensibility: Creating and Extending System Definition Models (Level 200)

Tue, 04 Apr 2006 00:45:35 GMT

If you are interested in some of the ways you can extend Team Architect, check out Dmitriy Nikonov and Erbil Yilmaz tomorrow (4/42006) at 10 AM Pacific time. If you were ever thinking of creating your own Models within Team Architect or wanted to understand how to create your own custom Validators this is a required Webcast.

MSDN Webcast: Visual Studio Team System Extensibility: Creating and Extending System Definition Models (Level 200)

Top-Down System Design

Tue, 07 Mar 2006 01:25:05 GMT

When I first started to evaluate Visual Studio Team System for Software Architects, before I joined Microsoft and the Whitehorse team, I really did not understand how I was intended to use the product. Of course being like most techie's I did not bother to read any documentation, etc. I just dove right in, and tried to use to product how I expected it should work. From my perspective, as an architect, I designed systems, so I concluded that I should jump right into the System Designer. I was attempting to design my Systems in a very top-down approach, and my experimentation was met with several issues. First, only application that had been previously modeled on the Application Designer could be placed on the System Designer, and the only way to add Systems within Systems was to add new systems from the File > New Distributed System Diagram... menu. This seemed very counter intuitive to me, since I wanted to evolve the design from top-down, not from bottom-up.

Now that I am a Program Manager on the Whitehorse team I have learned more details about the System Designer, and how there were just some features that did not make it into version 1. There are some workarounds, Bill Gibson has a great Tech Note on Top-Down design and how Shadow Applications could be used to enable such functionality. Randy Miller (of MSF Agile fame) has even written a paper on agile development where he discusses the use of shadow applications in an agile process.

So my question is: has not being able to iteratively design your systems in a top-down approach been blocking your adoption of Team Architect? If so, does the process outlined in Bill's Tech Note a reasonable workaround? If not, what are your adoption blockers?