If you look at what we have on our website you can see some preliminary content that’s been crafted.  It’s fine.  But I thought I’d talk about it a bit more conversationally…

What is Nintex Live?

“Cloud-hosted ‘air support’ for SharePoint workflows” is my current shorthand way to describe it, although that’s not perfectly on-message.  You can choose any or all of the following as well:

• - A cloud service hosted in Windows Azure that provides value-added services to Nintex workflows running in SharePoint.
• - A way to add new activities/actions to one’s workflow toolbox without installing any extra code on SharePoint servers.
• - A way to make virtually any web service “out there” look and behave like a workflow action.
• - A way to present a catalog of available actions to workflow designers – all of which have been sanctioned by IT.
• - A way to run a workflow that has been created/published in a remote SharePoint farm.
• - A way to publish a SharePoint workflow and allow it to be remotely invoked by a different workflow running in a remote SharePoint farm.
• - A way to make use of many of those data and calculation services published to Windows Azure Marketplace from inside SharePoint workflows.
• - A way to do all of the above very quickly, and very, very easily.

How You’d Use Nintex Live

Here’s how you’d use it from within Nintex Workflow 2010:

From inside of the normal workflow design environment, you’d click the ribbon bar button marked “Catalog”.  In the image below, it’s the button near the upper-right, next to the “Help” button.

If you click that, you get access to a catalog of workflow actions you can add to the design toolbox on the left side of the screen.  The catalog, at the moment, looks like this:

Choose the actions you want, click “OK” and they’ll show up in your toolbox a few moments after that.  Use them in your workflows like you would a local action.  When the workflows run, they’ll call out to the cloud to get the data – and/or perform the instructions – that you’ve requested.

There will be a method for IT to pre-filter which actions show up in the catalog for governance purposes.

What Nintex Live Does Behind the Scenes

If using Nintex Live seems easy, then we did our job.  What’s going on behind the scenes is actually pretty involved, but virtually none of it happens inside SharePoint itself.  We go to a great deal of trouble to avoid adding extra code to any SharePoint environment, and this is no exception to that rule.    We’re communicating with a service we have running in Windows Azure, in several ways, actually:

• - We query its catalog of available services – filtered in accordance with IT-supplied instructions – to present to workflow designers a list of available cloud-brokered workflow actions.
• - We even provide UI instructions to the SharePoint-located Nintex Workflow designer so it can construct the design-time UI out of metadata.  No code is sent to the SharePoint environment at all.
• - We listen to requests made by the SharePoint workflow over Windows Communication Foundation, and respond the same way.
• - We transform the request into the format required by each individual web services or remote workflow, invoke it accordingly, transform the results into a format consistent with a workflow activity’s results, and pass it back to the original calling workflow.  We handle all retry, warning, and error logic in a service-specific way.  If we have to poll for results, we do that.  If we need to wait for and handle a raised event, we do that instead, etc.

What Kind of Cloud Services Are Available?

We’ve already created wrappers for several cloud-hosted services, and we’ll be creating more on an ongoing basis.  Some are SOAP-based, some are Restful, others are, well, any of a number of things. 

So far, in anticipation of next month’s beta, we’ve exposed things like:

• - Services from Bing that check news stories, look up flight statuses, translate text, etc.
• - Services from StrikeIron that handle IP address lookups, check “Do Not Call” registries, etc.
• - Services from social media like Twitter and Facebook for posting status updates, searching for content, etc.
• - Services we created ourselves for reaching out to remote SharePoint sites to get/put content from/into lists and libraries.

It’s Not Just About Connecting/Consuming – It’s Also About Contributing

We have no intention of being the only people who can register services with Nintex Live for easy use within SharePoint workflows.  We’re publishing the API for creating service wrappers for custom Web services, for one thing, but that’s not the fun part.

The fun part is that you’ll be able to publish a Nintex Workflow to Nintex Live, at which point it will be available as a remote workflow (with inputs and outputs) that can be executed by other workflows in other locations.  Effectively, you can turn any workflow into a cloud-brokered service.

And any service publisher can decide who can/cannot use their services.  They can also see who’s using their services and how much.

Why Did We Use Windows Azure?

That part’s actually easy.  Everything else would have been painful.  Queuing?  It’s in there.  Scaling?  We can scale up via multiple threads and/or multiple instances if need be.  We don’t want to operate our own data centers.  We don’t even really want to maintain the OS and the application platform on hosted machines.  Windows Azure let us just write the app, deploy it, and use it. 

What’s more, Nintex Live isn’t a product – it’s an investment.  We’ll build forward from this to do a lot more than act as an action server to SharePoint workflows.  But first thing’s first.  More to follow as it’s ready…

• Microsoft Office SharePoint Server 2007 shipped in November 2006.  Work on what we now call Microsoft SharePoint Server 2010 began months before that date.  I didn’t leave Microsoft until the end of May 2008. 
• Make no mistake: the day I left Microsoft, I put up a “Chinese wall” around part of my own head, and I continue to regard my ex-employee NDA as a sacred trust.  But ask yourself:  would Fitz join a company whose products would be rendered obsolete by what he knew was being planned for “Office 14”?  (Hint: no.)

And now let’s address the general issue, which applies to many, many ISVs…

• Microsoft develops software in three-year cycles.  Not every group at Microsoft follows this rule as closely, but the Office group (which develops all SharePoint technology) certainly does.  It’s for several reasons, the more interesting of which are:
• It appears to be the sweet spot; wait longer and the product gets stale, don’t wait enough and people are driven crazy with upgrade chores.
• It times nicely to Software Assurance (SA) agreements, which are signed for three-year cycles.  SA is essentially upgrade insurance.  Pay a certain amount of money over a three-year period and you get any new releases that come out during that time.
• There’s only so much that can be done by a finite number of people in three years.  You can’t increase the number of people without the coordination costs going through the roof.  That leaves limiting the feature set.
• To add to the above point, SharePoint technology has so many interactions with so many other Microsoft products – all of which usually ship at the same time – that they’re extra constrained by how much they can accomplish.  The test matrix alone is staggering, and at a point much sooner than most people think, testability determines whether something is kept or cut (or, very rarely, added).

The above argument pretty much ensures that the next version of anything you buy will be nicer, better, probably (in this case, I suspect definitely) worth the money and time spent upgrading, but it won’t be the release to end all releases.

There will be a gap between what you really want and what’s in the box.

Toward this point, Microsoft (at least the product teams in Redmond) all but depends on the partner ecosystem to plug feature gaps or create specific productized solutions.  Systematic procedures and practices are in place to help ISVs do exactly this.

In fact, when faced with enough resources to either add a user-facing feature or improve the platform so ISV products and custom development efforts can build such a feature, the second approach usually wins.  Not always, but most of the time.  Here’s why:

• It’s a bigger bang for the buck.  If they enhance the platform, many solutions can be offered that leverage the new functionality.  From different vendors.  Taking different approaches.  One of which will probably address your needs.
• Many people can build features or solutions.  Only Microsoft can build platform enhancements.  If ISVs attempt to do that, they’re basically hacking the back-end product – not the safest option in the world.

So, what makes for a decent ISV versus a not-so-decent one?  One topic at at a time — give me about 24 hours or fewer to post about that.

We’ve gotten a couple of inquiries about this already.  Actually, we get asked about what we’re doing for 2010 all the time, but these posts spurred two new questions:

• Does this mean I’m not going to need/want any third-party workflow tools anymore?
• This still means I’ll need to work with three products (Visio, SharePoint Designer, and SharePoint Server) to design, deploy, and use a workflow, won’t I?

These answers are easy, actually:

• For the most part, no.
• Yes.

Now, before I elaborate, let me reiterate what I said in my previous post; if there’s an early adopter program, anyone in it can’t talk about it. If I have any inside info, I’m not going to disclose it; if I don’t, I have nothing to disclose.  That having been said, I’ve frolicked in the SharePoint playground for a decade (if you count the prerelease Tahoe stuff) and I’m far from clueless…

The Visio 2010 stuff looks nice – really nice, in fact.  But yes, it looks like you’ll design workflows in Visio, transfer them to SharePoint Designer to deploy them, and actually use them within SharePoint itself.  At that point, three things come to mind:

• The platform is improving, probably by a lot.  This would bode well for anyone leveraging SharePoint’s workflow investments, including Nintex.  (It might give pause to companies that seek to replace SharePoint’s workflow technology with their own alternative products, though.)
• The design-and-deploy story looks like it will continue to rely on client-side tools.
• Unless a lot of people start buying a lot of new copies of Visio, this scenario will be fine for some, but by no means will it suit everyone.

Selfishly-speaking, all of these things are good for Nintex.  We want SharePoint’s native workflow infrastructure to get better; whatever they’ve done to accommodate Visio should help us as well.  We like the idea of Visio offering an offline design experience; heck, if it outputs standard XOML, we may well try to import Visio workflows ourselves (no promises). 

And as nice as this scenario appears, it’s far from the “workflow for everyone” ethos we espouse.  We put visual workflow design and deployment right into the SharePoint UI.  It’s there at your fingertips whether you’re a professional process-mongers or a casual user. 

And that’s just the design environment side of the equation.  I suspect we’ll learn nothing about what’s happening with actions/activities, logging/tracking/reporting/managing, and support for complex logic until the SharePoint Conference in October.

But a rising tide lifts all boats.  And the tide indeed appears to be rising.

For the last three releases of SharePoint technology, there were early adopter programs.  In fact, for independent software vendors (ISVs), there were extra-early adopter programs so they could sort through, adapt, and enhance their products (or even create new ones) based on what was coming down the pike.  The thing was, any company involved had to sign a non-disclosure agreement (NDA) that precluded talking about, well, anything, even to people in other NDA programs.

If one were to assume that such a program is in effect for SharePoint Server 2010, et. al., the people who know the most are the people who can/will say the least.  You can, to a certain extent, identify people who will be very likely be thought leaders after all is revealed at the October SharePoint Conference, because right now, they’re pretty much keeping their mouths shut and their blogs silent.

This isn’t to say that speculation isn’t running rampant.  And there are now four sources of official information on what’s coming up that are public:

• Technical preview copies of the Office 2010 client applications
• Updates to the Protocol documentation created and published a few weeks ago
• Posted information at http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/default.aspx 
• Two sessions presented at the Worldwide Partner Conference, one by Arpan Shah from the SharePoint team and one by the Visio team

You can get a reasonable amount of information from these sources, but it pales in comparison to what isn’t being said.  Some diligent souls will do their best to sort through all of this, and I’m sure they’re welcome to try.  You can spot the good ones by the fact that they’ll stick to explaining what’s been revealed rather than speculating as to what hasn’t.

I’ll post some follow-ups on this topic presently. It’s kind of near and dear to my heart these days…

They’re singing — I kid you not — the jazz tune from the bar in Tatooine in Star Wars. And they’re lamenting that they still don’t get chicks.

This is weird. So I’m happy.

I’m here in Stockholm right now because I’m speaking at the SharePoint/Exchange Forum this Monday and Tuesday.  But I flew in two days early, and Patrick was planning to stay in Sweden a few extra days so we could hang out here this weekend.  Stockholm is a gorgeous place, but to me it’s going to have a melancholy glow attached to it for some time.

We went to Antarctica together this past December (it meant having set foot on all seven continents for both of us). We were making plans to climb Mt. Kilimanjaro. The first time I ever visited Belgium, he spirited me away to the beach with his family. He wasn’t just a professional friend, or a conference friend, he was a bona fide carry-secrets-about-each-other-to-the-grave friend.

It’s really funny that things turned out that way because the first time we met, it was over an exchange of blog posts, which started a short period of antagonism borne of misunderstanding.  We cleared that up pretty quickly, though, and became professional friends in short order.

But that’s what he meant to me.  Here’s what he means to you (at the very least), whether you know it or not:

• Patrick fought the good fight in terms of development with SharePoint long before SharePoint was cool. Heck, long before it was even legitimately possible.  He’s one of the original pantheon of SharePoint heroes. If not for his efforts (and the other short list of solution builders), I’m not sure where we’d be today in terms of SharePoint having taken off.  I mean, I, and a few others, asked you to develop on SharePoint technology — he (and a few others) went out and did it.  His work influenced countless others. He helped make the initial snowball that picked up mass and started the avalanche.
• He started blogging about SharePoint technology long before the rest of us, certainly long before any of us at Microsoft.
• Patrick, along with Jan Tielens and other people at U2U were instrumental in making Web Part development a whole lot easier than it would have been otherwise thanks to their creation of the SmartPart. They evolved it multiple times since then to keep up with technological changes.  And that’s just one of many things Patrick and those with whom he worked did for the community as a whole.
• If you were privy to any prerelease training on WSS 3.0/MOSS 2007, you have Patrick and Ted Pattison to thank for it. One of the best decisions I made back in 2005 was to hand Patrick and Ted the keys to the kingdom, meaning unbridled access to the development teams and a cooperative relationship with the documentation team. I hooked them up with the Developer and Platform Evangelism team, which led to them developing all the early adopter development training for Microsoft partners, which included worldwide delivery of that content.  Why Patrick?  Because I knew I he had the talent, the motivation, the professionalism, and anything else that might have been relevant.  I just plain trusted him. So did everyone with whom he wound up working. One of the best darned decisions I ever made.
• Even if you didn’t receive any prerelease training, a large part of the training content in existence stems from, or was inspired by, the work Patrick and Ted did.  That’s certainly true of the Microsoft Official Curriculum for WSS 3.0 and MOSS 2007 development.
• Patrick literally wrote the book on MOSS 2007 development.  And frankly, that’s a harder job than writing the book on WSS 3.0 development (no disrespect to Ted intended), because the object models for MOSS represent a patchwork of different pieces of functionality developed by different teams, sometimes almost schizophrenically so.  To tie that all together and make it make sense was no small feat indeed.  And then, not having tired of that kind of hair-tearing, he then went out and teamed up with Lars Fastrup (formerly of Ontolica, then Mondosoft) to write the definitive book on SharePoint Search development.
• If you live in Europe, and wanted SharePoint training, you probably got it from Patrick himself or one of his cohorts at U2U, and if you didn’t, you got it from an outfit that strove for excellence because they have to compete with U2U.  Patrick and his partner, Wim Uyttersprot, built a top-notch outfit devoted to SharePoint, Office, and .NET training/consulting. They’re big on community give-back, and the consulting they do keeps their training extra relevant. When I worked for Microsoft,  it wasn’t acceptable to out-and-out endorse specific partners over others, but I no longer work for Microsoft, so let me say this in no uncertain terms: U2U is simply the best in EMEA, and is among the best worldwide, and while Patrick’s passing is terrible, U2U remains the best.
• There have been precious few conferences involving SharePoint technology at which Patrick hasn’t spoken, and hasn’t had obscenely high evaluation scores afterwards.  Knowing that Patrick was speaking motivated me to do better myself, and there are many, many others who felt the same way.

Patrick was the master of the wry, knowing smile, keeping quiet until just the right moment and saying just the right insightful thing.  He was a living example of the quiet ones being the ones you need to watch.

My heart goes out to his wife, Linda, and his daughters, Anahi and Laura.  I’ve met them multiple times, and I’ve always thought they had the patience of Job.  Her husband/their dad loved technology, loved to write, loved to teach, and loved to travel. And they let him, because he always had them in his heart and he always came home.   Except for this last time.

He wasn’t a religious man, and neither, for that matter, am I.  But given the current Scandanavian setting, I can’t help but think of an afterlife, in fact, a SharePoint Valhalla, into which Patrick just walked swinging a hammer twice the size of Thor’s.

I could go on for a lot longer, but I’ve got no better testament as to how good a guy he was than that of Terrance and Phillip, our two little Shih Tzus.  On Patrick’s first visit to my house, those dogs immediately made friends with him.  No multi-minute “intruder alert” barking at the outset.  That’s never happened before or since with anyone else. Wise dogs, those boys.

Patrick, my friend, you’ll be missed.

Adios, amigo.

Guess which of those two was often more readily received by salespeople (although not necessarily customers)?  Customization.  This is, in fact, how IBM sells software; they front all customer interactions in a service agreement, part of which involves the cost of the software but then depends on extensive consultant work.

Why the reluctance (some of the time) to consider third-party add-ons?  Sometimes there’s an irrational fear that the third-party will try to control the sale; I can’t really speak to that, other than to say that independent software vendors usually don’t want that at all.  What happens more often, I suspect, is plain ol’ sticker shock.

What I find troubling, and not just because I now work for Nintex, a company that creates third-party solutions for SharePoint technology, is that it’s rare that off-the-shelf third-party add-ons don’t save money…

Consider my company’s workflow product (since I know the pricing, etc.): the Enterprise Edition of Nintex Workflow costs (in the United States) $17,500 per SharePoint web front-end server.

Let’s assume you can find a SharePoint technology consultant for $200 an hour.  That would mean that he/she has just two weeks and one day (87.5 hours) to build the same functionality.  For one thing, that’s an extremely short consulting engagement.  For another thing, the odds of being able to build something like Nintex Workflow in that amount of time approach zero.  Even doubling it (let’s say you have a two-server deployment) still leaves you with one man-month and an extremely unlikely chance of approaching even a fraction of the product’s functionality.

As for why consulting sometimes feels better than add-on products, I invite discussion in the comments section.  Similarly, if you think there isn’t such a tendency, I’d welcome that, too.  Heck, if you agree and just want to vent, I’m all for that as well.

–Fitz

I don’t want to be unfair about it.  When you’re a giant software company and many, many interdependency issues exist among your own products (let alone those of partners), and many, many requests for good, justifiable changes get received in a steady stream, that’s a cold, hard reality.  Even a simple change could result in months of testing to make sure it does no harm.

Contrast this with what we’re opting to do with Nintex Reporting 2008.  We debuted it at TechEd North America this month.  Response has been great.  To a person, anyone who saw a demo raved about it, some in very public places.  But we also got a non-trivial number of suggestions, several of which were too good to pass up.  We also got a couple of volunteers working through database size requirements for a data warehouse covering a farm of a certain size with a certain amount of activity.

This pointed to two things we needed to do: (1) add a few extra reports, and (2) do a bit more optimizing on the way our warehouse stores data.

So we’re doing it.  Nintex Reporting will start arriving in the hands of customers next month instead of this one.  It’s for a far greater good.  And it was easy to react.  Outright fun, actually.

My stance of staying the heck out of the SharePoint databases is a matter of public record.  I wasn’t kidding then, and I’m still not kidding about it.  It’s a bad idea.  That having been said, a frequent question that came up in response involved how to report on what’s going on within SharePoint farms. 

You’ve got basically two options: walk the object model (many tools on CodePlex do this) or directly query the databases used by WSS/MOSS (don’t do this).  Or you can take a blue-sky, hybrid approach:  walk the object model and save the results to a data warehouse.  That was usually met with nods of understanding followed by cringes of understanding on just what it would take to do such a thing (no matter how much it would be worth it).

Well, Nintex did it anyway.  You’ll see it at TechEd in Orlando next week and/or on our Web site — we RTM today.

I’ll post over the next several days a few snippets about how the product works and what you can do with it (both for using it and extending it).  But the gist of it is that we — in a completely “legal”, supportable way — inspect the farm and stage nuggets o’ insight into a proper data warehouse, then provide plenty of tools for you to report on that warehouse’s contents to your heart’s content.

Details to follow.  This is fun.