Making Oslo Great
Hi – I’m Adam Denning, and I’m the PUM of the CSD End-to-End (E2E) team. I want to use my first blog entry here to explain what all that means and to let everyone know about the work we’re doing.
First, what is CSD? It stands for Connected Systems Division and is probably best characterized as the division that creates the service-oriented application platform components from Microsoft. This means things like BizTalk Server and all its adapters, WCF and WF, messaging and queuing products, and much of the identity and authorization services, such as Windows CardSpace. Many of us are now working on the next major evolution of all of that, code-named ‘Oslo’. Oslo is a bunch of technologies which together make the platform more declarative (that is, you get to express more of what you want to do and less of how you want it to be done), more process-oriented and more distributed. See official word on this at https://www.microsoft.com/soa/products/oslo.aspx.
Clearly much to debate there, but that’s for another time. (I did have someone just point out that I should emphasize that CSD doesn’t just do stuff that lives on server-type machines – technologies like WCF and WF are used for a variety of purposes. Fair point).
Secondly, what is E2E? Ours is a small team whose job it is to ensure that Oslo is right and fit for its intended purposes. We do this in two main ways:
1. We define/select – and build – the scenarios that we use to say that a particular milestone is ‘done’; if we can’t build the designated scenario during the integration phase of the milestone, the milestone is not complete. I call this ‘pulling’ Oslo, as we declare up-front (see – declarative!) what we want Oslo to achieve
2. We act like a software company in our own right by defining and building a major distributed application that we believe is canonical for Oslo’s intended purposes and is also something that people want to use. This way, we get to evaluate Oslo’s features as they are developed, give our feedback to the teams building it, and help them understand what it takes to convince independent-minded people to use their software. I call this ‘pushing’ Oslo, as it can be used as a lever to ensure that Oslo provides the right set of features.
This big app is called the FTA – Federated Task Assistant. I want to talk about that in much greater detail in a subsequent post, too. The important thing is that it is a big app which exercises a lot of Oslo technologies and will end up as a key reference sample.
Thirdly, what is a PUM? It stands for Product Unit Manager, so it’s my job to ensure that the E2E team does its job and is happy about doing it. Given that we’re a small team with a fairly unusual mission for Microsoft, I’ve organized the team somewhat unusually, too. First, I have two senior people acting as architects for the whole team, one mostly for the scenarios work and the other mostly for the FTA. The rub is that these architects are remote, something that remains out of the ordinary for Microsoft. One lives in Virginia, close enough to DC to have electricity, and the other in France, close enough to Marseilles to have cheese and wine of note. But that’s just France all over.
I then have a set of people who come from a wide variety of backgrounds who are not definitively cast as one of our traditional developer, tester or program manager roles, but who all perform all three. We have a tacky title for them, and it’s in deep need to improvement: ‘DevPMT’ – meaning ‘developer, PM and tester’. The name sucks, I know. Care to rise to the rename challenge? We typically say that each individual ‘majors’ in either dev or PM and then minors in the other role, and everyone is a tester regardless. We also have a full-time SDET – a tester who also codes – because we have so much work that requires that set of skills.
So, we have an unusual team, at least for Microsoft.
We also follow some agile processes, most notably SCRUM. While we’re by no means the only team at Microsoft that practices these development methodologies, we remain in the minority. The good news is that it allows us to release new builds of the FTA every five or six weeks, and we can react pretty quickly to customer demand – remember that we’re building the FTA as if we’re an independent software vendor (ISV), so we do have customers (they’re internal right now, but that could change), and we have to satisfy them in order to get maximum usage.
We’re hiring, of course, and you can see the jobs here:
SDE Pos# 208695
https://members.microsoft.com/careers/search/details.aspx?JobID=F4EE8DE8-E5C5-499C-9F7F-43563E00A524
SDE Pos# 214675
https://members.microsoft.com/careers/search/details.aspx?JobID=7AFF0BF6-0CC0-40A2-B519-7E123B1989AF
PM Pos# 176223
https://members.microsoft.com/careers/search/details.aspx?JobID=C4198008-E83A-411C-BB03-7CDC8AECCA49
You’ll notice that, contrary to what I write here, those jobs are posted as PM and SDE jobs, but that’s just a reflection of the ‘major’ skills we’re looking for.
Next time, more on Oslo and the scenarios, and why building them is so beneficial to the Oslo team and therefore, ultimately, to our customers.