TechEd 2008 Keynote
I just got back from TechEd. I had a great time and met some terrific people. This is the first TechEd where the conference has been split across 2 weeks – the first for developers, the second for IT.
This TechEd has a first for me. I got to do one of the big demos in big keynote with Bill – his last big keynote as full time chairman at Microsoft. One of the things I learned in this exercise is the amount of work that goes into putting this together. The work on the demo, the rehearsals, getting everyone to agree on the talking points, all of the back stage logistics. I’d estimate I spent days preparing for my little 7 minute appearance. It was fun though 🙂
In my mind (admittedly biased), the demo was terrific. That’s not to say my delivery was particularly amazing but rather the demo itself was very good and the technologies we were showing are just amazing. The demo I did basically highlighted two things – the new direction we are headed in architecture tools and modeling and the work we are doing on DBPro extensibility along with the extension IBM is building that enables Visual Studio Team System for Database Professionals to give you the same great experience against a DB2 database that you can get against a SQL server database.
The architecture tools we are building are so unbelievably exciting to me that I can’t stand it. I’m wishing I’d have had these tools years ago. I can tell you for certain that we could have shaved months off of the development of TFS over the past few years if we had had them.
The thing that has me the most excited is a new feature called a layer diagram. This layer diagram allows you to design the logical layering of your application and specify the dependencies you intend to have. For example, you wouldn’t want your client to have a dependency on you data layer in a 3 tier app. You wouldn’t want your server business logic taking a dependency on something in the Windows.Forms assembly, etc.
Once you have this logical layering, you can associate the layers with specific assemblies, namespaces or classes in your actual application. Now, the magic happens. VSTS can parse/reverse engineer your code to determine the "actual" dependencies in your application. Having done this, it can compare the actual to the "desired" as specified in the layer diagram and let you know about any problems you have. Going even further, you can configure a checkin policy to validate this on every single checkin. This way you can prevent people from checking in spaghetti architecture in the first place.
It’s very hard to communicate an architecture to everyone on the team. It’s even harder to prevent them from accidentally violating the architecture. These tools are a huge leap forward in ensuring that you end up with the architecture you designed.
On top of this cool new layer diagram and validation is another feature called the "Architecture Explorer". It is a very handy tool for visualizing the architecture your code implements today. It allows you to graphically browse through your application and its dependencies and understand them. As you update your code, you can see the Architecture Explorer diagrams change.
All of this (and more) represent a pretty big shift in our approach to the VSTS Architecture SKU towards tools that are applicable to a broader set of problem domains and compelling to a larger constituency of users. It catapults the architecture SKU from a moderately interesting overall value to one the the most exciting things in Team System. I can’t wait for Rosario to become "go-live dogfoodable" so that we can use this new stuff in our daily jobs.
Brian
Light
Dark
0 comments