Tech·Ed Wrap-Up

It’s been days, but I’m finally getting around to posting my Tech·Ed wrap-up. I had a great time as a speaker, track owner and attendee. My Data in SOA talk ended up with an 8.0 score and our track overall scored a 7.5. Not bad for our first time out!

My boss’s immediate reaction was to raise the bar for Tech·Ed 2005, which is fine by me as I have got some specific plans for an even better Architecture track next year. I learned a lot swimming in the deep end of the pool, such as:

  • We could have been much better integrated with the other tracks, esp. the Dev track. Being involved in the planning from the start (Tech·Ed 05 content planning starts in earnest in the fall) should help out a bunch here, as will knowing the other track owners from this year’s event.
  • We could have managed our track better. But hey, it was my first time! Things like speaker meetings, more content reviews and ensuring speakers go to training all help out here. Also, I’d like a little less churn on the management side next year. I took over co-track ownership duties when one of my teammates moved onto another team.
  • I mentioned that several people commented that there should be “more code” in the track. Techie types like sessions that are heavy on the hands-on practical and code is about as hands-on practical as it gets. However, while I am on record as being an architect with a lower case “a”, I don’t think architects are just senior developers. It’s a different skill – one that I want to see broad knowledge of, but still different. Architects work primarily in models, patterns and process, not code. So for the Architecture track next year, I want to see “more models, patterns and process”, not “more code”. Watch for a focus on VS2005 Team System for Architects, Whitehorse and MSF.

What do you think should be in next year’s Architecture Track?

This entry was posted by DevHawk on June 2, 2004. It was posted in Architecture. It was tagged Community.

Comments:

I am willing to stick my neck out and say that I think code has very little to do with a true architecture track. Hold your ground. Models, Patterns, Process and/or Practice is a good mantra.
This comment was posted by Chris Kinsman on June 03, 2004 at 9:21 AM.
**** I don't think architects are just senior developers. It's a different skill - one that I want to see broad knowledge of, but still different. Architects work primarily in models, patterns and process, not code. **** I think this is correct, but it implies several different sub-tracks (security has the same issues) 1) How should I as an architect think. I think the cabana discussions diid a great job on this 2) So, I've built a lot of monolithic apps, nw how should I really think about systems. In many ways, this was the focus of the Metropolis series 3) I'm a code jockey and I want to stay one. How do I recognize architecture isses - and come to aknowlege when I need to pull the chord and stop the train until architecture is dealt with. This might be symptoms of an un-architected solution, you know you need an architecture if, . . . 4) Liberal education in what is architecture, what is program design, and how do you tell the difference. A good principal is it is better to have an architecture and do simple(r) things than to require virtuoso code that does the impossible. Each of these might have high or low level tracks, but none is about a lot of code.
This comment was posted by Toby Considine on June 11, 2004 at 7:49 AM.

Categories

Tags

Series

Disclaimer

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.