Pretending Not To Be Microsoft

I’ve mentioned off-hand the ‘big app’ we’re building to exercise Oslo thoroughly, the so-called ‘FTA’, and I’ve promised to talk about it but so far have failed to deliver on that promise. Today that changes.

First, a word of caution: it’s easy to assume that ‘FTA’ is a real product name, or that it should be and intends to be. It isn’t, it probably shouldn’t and it doesn’t. ‘FTA’ is just a large enough and useful enough application that it will stretch the Oslo platform to its limits in some areas and will actually get used by people, which is key to our ‘stretch and stress the platform’ intent.

First, what is it? ‘FTA’ stands for Federated Task Assistant, which could just be descriptive enough to tell you what it does, but probably isn’t. So, let’s start from this premise: you have a bunch of tasks you have to perform, from a bunch of sources and as parts of many bigger things. For example, I need to order a new credit card because my current one’s magnetic strip is failing; I need to write people’s reviews because it’s that time of year; I have to write a blog entry on ‘FTA’; I have to ensure my wife’s rather substantial list of tasks for me is at least partially addressed, and so forth. Some of these tasks are personal, some are work-related; some get tracked through other systems (like our internal bug tracking system, our HR systems, TFS, and so forth) and some get forgotten if they don’t get tracked (well, for me, that’s most things).

I want to be able to see all my tasks across all of these different systems in one place, and I want to be able to interact with them (say they’re done, assign them to someone else, change the priority, create new ones, and so forth) no matter where I am. So we wanted to create a system where this can actually be done, hence the ‘FTA’. It turns out, of course, that the ‘FTA’ (can I drop the quotes now? It’s not a real product name, OK?) is the ideal target application for Oslo, because it makes extensive use of workflows, has numerous client, server and cloud components, and integrates with external systems.

But we have to build it as if we were not an internal Microsoft team. We have to try to think like an ISV, and make decisions based upon our needs rather than our division’s platform strategy.

To be frank, it’s extremely hard to stick to this, for a number of reasons. First, we are a part of our division’s platform teams, so it’s kind of hard to ignore what we’re all up to. Secondly, to be really good at pretending not to be Microsoft, we’d need to be suitably externally motivated – that is, we’d have to believe in the FTA as a real, standalone product that stands to make us millions, one that we’d like to float off as a separate company so that we can have that money for ourselves. Let’s be honest, that’s not our intent so we’re faking the faking, somewhat. Still, we are making some reasonably independent decisions, often even thoughtfully J, so it’s working to a degree.

We really see three competing tensions for our efforts:

1. Be an excellent and independent assessor of Oslo’s capabilities, and use our feedback to make the product great. Not just bug reports and feature requests, but try to move it strategically where necessary and possible

2. Create an application that everyone in the division, the company, the world wants to use, and get it dog-fooded – heavy use gives us a much better feel for the resilience of the platform to stress, load and all those famous ‘-abilities’

3. Create an excellent canonical reference application/sample for the world to use as best practice examples when building applications with Oslo

Which of these priorities is on top? What do we do when there’s a conflict? Well, then we have to decide if we’re being Microsoft today or not.

Next time, I’ll dive into some of the FTA’s capabilities and maybe even some architecture.

Adam (adamde@microsoft.com)