What do .Net Solution Architects need to know?

  • Article

A friend and colleague, J.D. Meyer, asked me to consider this question, and I have to admit that it's a bit of a tough question: What do .Net Solution Architects need to know?   (If you have an opinion, please go here).

Why so tough? 

For me, being a .Net architect means "applying various architecture skills to the Windows .Net platform."  We could just look at the intersection of architecture and platform and go from there.  This is a narrow scope: only platform-specific information.

On the other hand, there are a great deal of topics in architecture and engineering that are not specific to any platform.  We do a great service by providing a consistent message that allows architects of all stripes to seamlessly blend good practices with an understanding and knowledge of the platform.  This is a wide-scope: take best practices and apply them to a particular platform.

I tried to create a Venn diagram to illustrate these intersections (off the top of my head) for a small subset of practice areas.  This is what I came up with...

intersection of architecture and platform  

So let's scope that question a little... With an architecture guide, what problem are we trying to solve?  Are we providing:

Advice for solution architects who happen to use .Net, or

.Net technology-specific advice for solution architects

I asked J.D Meyer that question.  His answer: Both!  The following is a (mostly) direct quote from his e-mail back to me:

I’m a principle-based, platform kind of a guy so I tend to focus on principles, patterns, and practices that are tech agnostic. But we need to provide specific guidelines as well.

You can see that the big up front part of these guides are tech agnostic … and then tech guidelines are pinned against the backdrop:

· Improving Perf Scale (check out the first few chapters) - https://msdn.microsoft.com/en-us/library/ms998530.aspx

· Improving Web App Security (check out the first few chapters) - https://msdn.microsoft.com/en-us/library/ms994921.aspx

So, how I’m solving it now is … a thin, lead principle/pattern based guide as much as possible … and a KB, where the KB has how-to's, cheat sheets .. etc. for applying it to the technology.

That’s the working model so far.

Here’s the last WCF project:

· The KB: https://www.codeplex.com/WCFSecurity

· The Guide: https://www.codeplex.com/WCFSecurityGuide

So, there you have it!  When providing advice, from Microsoft to all of the brilliant folks who live in the "real world" using our tools and technologies, we want to provide both the high-level principles and patterns, as well as the detailed level: here's how to use all this good stuff in .Net.

My ask: if you have some ideas of "What .Net Architects need to know," Please go to J.D.'s blog and share your ideas with him.  The link is here.