Kirk Evans is a Microsoft Architect for the Azure Center of Excellence.
Introduction to SharePoint and Azure IaaS
Building SharePoint Apps with Windows Azure Platform as a Service
SharePoint Solutions and Architectures on Windows Azure Infrastructure Services
Understanding Authentication and Permissions with Apps for SharePoint and Office
In Tim Ewald's post, “I refuse to let the angle brackets fall where they may!”, he brings up the point about starting with the XML, then designing the XML schema, then the WSDL, then finishing with a stylized set of classes. In the comments, Ben Lowery asks if this contradicts recent messages of devs not having to worry abotu learning the WS-* specs.
These are 2 separate issues. One issue is knowing the semantics of WS-ReliableMessaging, WS-AtomicTransaction, and WS-Discovery and knowing how to support an implementation for secure, transacted, reliable messaging. The second issue is knowing how to specify the wire-level contract for your messages and the types contained in the messages. You should still know what your message contract will look like on the wire, but you shouldn't have to worry about the other goop in the SOAP header that define the semantics to implement short-lived transaction scope and long-running reliable messaging. You should know how to model a type “Person” to signal a message to a remote system, you should not have to worry about signalling to that system where to send an ACK message back or who to reply separately to.
If you are teaching someone about ASP.NET for the first time, you are going to talk to them about the Request/Response nature of HTTP. You explain that ASP.NET is modeled over the Request/Response nature of HTTP, and you can explain the difference between HTTP GET and HTTP POST. You might even discuss some of the various HTTP headers that are included with an HTTP request versus an HTTP response, but you would stop shortly after. You don't need a mastery of all HTTP verb types, MIME, or the binary representation of UTF-8 encoded streams to be able to work with or explain HTTP or ASP.NET. You might know that stuff is there, you might even be casually familiar with the concepts through reading and reflectoring (that will be a new industry term soon, Benjamin!) Because ASP.NET neatly abstracts those things away from you, you can focus on the things that make you productive and help you to build high-performance web applications. The same goes with what Don and Doug said... Indigo will allow you to focus on the things that make you productive while the gritty details and plumbing are abstracted away for you.
I still strongly encourage architects and developers to understand the WS-* specs at least from an elevator-pitch level. Understand what WS-Addressing seeks to achieve, maybe even understand a visual diagram of how addressing could be used for duplex messaging, but don't feel overly pressured to understand the exact implementation of an EndpointReference or the reasons behind why the wsa:To header must match exactly. Be able to think about how different message exchange patterns can be used to make your applications talk with others more effectively, and think about how WSE 2.0 can help you now and how Indigo can help you in the future.
Unless you just like plumbing, of course.