My Indigo Talk Version 2.0: The “Why” trumps the “How”

On our 4 hour taxi ride from Portoroz in Slovenia to Zagreb in Croatia, I decided to make some significant changes to my Indigo slide deck for the tour. David Chappell called my talk an “impossible problem”, mostly because the scope of the talks we are doing is so broad, ranging from the big picture of Longhorn over Avalon and WinFS to the Whidbey innovations and I am stuck in the middle with a technology that solves problems most event attendees don’t consider to have.

So I took a rather dramatic step: I dropped almost all of the slides that explain how Indigo works. What’s left is mostly only the Service Model’s programming surface. For the eight slides I dropped, I added and modified six slides from the “Scalability” talk written by Steve Swartz and myself for last year’s “Scalable Applications Tour”, which now front the talk. Until about 20 minutes into the “new” talk, I don’t speak about Indigo, at all. And that turned out to be a really good idea.

As I’ve written before, many people who attend the events on this tour have no or little experience in writing distributed applications. In reality, the classic 2-tier client/server model where all user-code sits on one tier (let it be Windows Forms, VB6, ASP or ASP.NET) and the other tier is the database does still rule the world. And, no, the browser doesn’t count as a tier for me; it’s just a “remote display surface” for the presentation tier.

Instead of talking about features, I now talk about motivation. Using two use-case scenarios and high-level architectural overviews modeled after Hotmail and Amazon (that everybody knows) I explain the reasons for why distributing work across multiple systems is a good thing, how such systems can be separated so that each of them can scale independently and what sort of services infrastructure is needed to implement them. And it works great. Once I have the audience nodding to the obvious goodness I can continue and map the requirements to Indigo features and explain the respective aspects of the service model. The flow of the talk is much better and the attendees get more and immediate value out of it. If I weren’t so time constrained I would probably map it to Enterprise Services (now) and Indigo (future) all in the same talk and also show to do the transition. I am sure that I can do that sort of talk at some event this year.

Lesson learned: Less features, more why. With the majority of developers the challenge isn’t about showing them how distributed systems are being improved; it’s about getting them to understand and possibly adopt the idea in the first place.