What My Group Does For Microsoft

My daughter just went to bed and I need to go to sleep too since I have the night feeding so I'll keep this relatively brief (for me). My group at MS (which is led by Bill Zissimopoulos (Dev Lead) and myself (Group Program Manager)) has the following responsibilities:

1. Provide guidance to Windows Live groups on how to design their external interfaces

2. Provide a software as a service platform for Windows Live properties

3. Provide a software as a service platform for external properties

4. Hire "A" Players

1. Provide guidance to Windows Live groups on how to design their external interfaces

This mostly involves things like when to use URL encoding versus microformats versus XML versus JSON, etc. How to deal with XML versioning, schemas, etc. I'd love to expand this to include SIP as well.

Note to Mark: we love JSON, seriously, Scott Isaacs thinks it's the cat's meow. I think it's very cool as well. My general view is that services should have multiple protocol 'heads'. The basic head should be POX for maximum reach. But having language specific heads like JSON is just hunky dory with me. Although I am concerned that it could lead people to create RPCs rather than Protocols. Hence why I insist on starting with POX, it's easier to design a protocol when you can abstract the endpoint environments.

2. Provide a software as a service platform for Windows Live properties

Over the years Windows Live (read: MSN) has learned a lot about how to build software as a service (read: pain free software installation). Part of those lessons have resulted in a lot of internal infrastructure. More to the point, it has resulted in a lot of redundant internal infrastructure. I think three or maybe it's four groups have invented their own Application ID infrastructure. Everybody has their own monitoring infrastructure. Everybody has their own application level throttling infrastructure. Etc. My group's job is to harvest best practices, steal lots of code and bring it all together into a coherent platform that services at Windows Live can build on top of.

3. Provide a software as a service platform for external properties

A lot of the common services that will come out of goal #2 will be useful to lots of folks beyond just Microsoft. This is not about hosting other people's logic. The app hosting business has nasty margins. Rather it's about enabling people to re-use our services for common scenarios rather than building their own. I suspect this will mostly consist of white labeling a bunch of our existing stuff. So, for example, someone could use our monitoring or security platform without anyone having to know or care where it came from. I will be talking a lot more about this challenge in the future and discuss in depth my contention that the future belongs to the client (damn latency). But anyway, more on this later. I need to go to bed.

4. Hire "A" Players

We are hiring! If you want to get in on the ground floor of a brand new team tasked with building an insanely scalable platform to enable all sorts of cool services both inside and outside of Microsoft then drop me a line. We are primarily looking for developers (all levels of experience) but we also need program managers and testers. Location is not a big deal (e.g. you don't necessarily have to move to Redmond). I was a telecommuter for the last five years; so if it makes sense we might be able to arrange things so you can work remotely. I'll have more on the specific job positions later.