Committed to guidance

One of the really great things from TechEd was to hear Andy Lees tell the world that Microsoft was committed to providing architectural guidance for common scenarios.  I mean, how great is that?  Especially when it is my job to get that done. The problem is, that this is really a very hard thing to do well.

First off - what are the “common scenarios” that we need to provide guidance about? 

Secondly - what is the best way to communicate architectural guidance?

When I read the comments from TechEd evaluations, I am often surprised to see one person saying that this was the “best session ever” while the next person complains that it was “too high level” or “too low level”.  You see each person approaches the problem space from a different perspective, background and agenda.  We try to take this into account as we design our guidance so that it will resonate with different audiences but I'm telling you, this is a very difficult thing to do.

This week I am summarizing the results of a usability test we have done and I wonder how we will ever get to the place where we can please most people.  I don't mean to sound depressed or whiny, so enough of that.  I am all for great solutions so what I want to hear from you is.

Question: What kind of architectural guidance (format, code, patterns, books, etc.) helps you the most?  What do you want to see more of?

I'm all ears people - tell me how I can help you.

Comments (3)

  1. Adam Weigert says:

    Mistakes. How do we learn what is the right way to go? By having mistakes and learning from them.

    Best practices are often pushed, however many times when a developer tries to take a best practice they incorporate many bad practices with it try to achieve the best practice.

    I learn from coding in the attempt of getting to a good practice, and finding that the design is flawed, refactoring it and coming up with a much more supple design that meats the best practices and/or the performance goals.

    Supple design is not easy, because it is not really something taught, but something learned.

  2. Adam Hill says:

    One of the issues is non-MS end to end scenarios. Example: Web form auth, lots of AD examples out there for Roles, not a lot of home grown Roles examples.

    Perhaps some ‘here are what *other* peoples Web Services look like’ are in order and here is how you interop. Especially now that WS-* is getting complicated.

  3. Doug says:

    For me, reading about the concepts are great but what is really most helpful for me is seeing the code in action.

    My co-worker just got back from TechEd, and interestingly when he spoke with some architects about SOA (at the cabanas) and the lack of real world examples, the response he got back was "we’re not coders, we’re concept guys".

    How are some of MS partners or MS consulting services best applying <insert new architectural approach buzzword here>? As Adam W. mentioned, it’s an iterative process and we learn from our mistakes. Why can’t you publish code/project examples using this same approach?

    Put out examples of what you know *now* to be the best approach for XYZ as it currently stands. A week later or a month later the code/approac is refractored. Publish the examples side-by-side explaining why it was refactored. (The code was slow, it wasn’t optimized, there was a bug, I didn’t have enought caffine that day, I don’t know what the hell I was thinking – whatever.) Show people the mistakes that were made in the original example and why the new one is faster, more extensible and better now that it can slice and dice…

Skip to main content