I’m very, very tired of seeing/hearing the phrase “no code”. I see presentations advocating “no code” solutions for SharePoint. I see advertisements from companies who proudly declare that they’re all about “no code” apps. The issue isn’t confined to the world of workflow, but I see it arise in workflow-land readily and frequently.

It’s not that eliminating code isn’t a useful thing — it is — but when authors/speakers lead with the phrase “no code”, it suggests that they’ve likely missed the point. To wit:

“No code” doesn’t really help users.

The implication of “no code” is that it’s easier, and that “even users can do it”. Well, “no code” does not always mean “easy”, let alone user-accessible.

Take SharePoint Designer, for instance. Users aren’t being done any favors if they still have to do things like increment counters, check flags and semaphores, initialize variables, stage a set of dictionaries in order to call a web service and parse the results afterwards, or poll for results. Actually, add calling web services to that list.

People who think like developers and DBAs see value in data models, but users just see content (documents, lists, images, etc.). They need to know what they’re working with, not see it abstracted into generic objects.

Other offerings may look friendly at first glance, but every drag, drop, configuration choice, and term in the user interface belies a developer mindset bias.

Still other offerings all but require the user to learn a new language to get anything done; it may be a visual/graphical language, so it qualifies as “no code”, but it’s still complex and hard to follow without training. For example, to get a manager to even understand a process model authored in Business Process Modeling Notation, you need to teach her how to read BPMN. To get a business user to author BPMN, you need to teach him a whole new discipline.

“No code” doesn’t really help IT.

“Citizen Development”, as Gartner puts it, has immense potential. But ask many IT professionals what they think of all those elaborate Excel, Access, InfoPath, and SharePoint Designer solutions and you’ll very likely get an earful of complaints.

Just locating and keeping track of those no-code solutions is difficult enough. Monitoring bad behavior (e.g., runaway loops, excessive network and database I/O, etc.) gets tricky. Understanding what is affected when a no-code solution is changed/deleted is hard. Figuring out who will maintain existing no-code solutions when the author leaves the company can get nasty, let alone the odds of the new no-code developer being able to understand what the previous person did.

“No code” gives an impression that code is bad.

Believe it or not, sometimes code is actually pretty attractive. Why? Code can be versioned. Code can be profiled. Code can be validated. Code can be optimized. Once you have to think a developer’s thoughts, you should at least have tools equal to the task.

It’s not about “no code” — it’s about user focus.

Many of us want users to have the ability to build some solutions for themselves. Many organizations need this if they’re to get past backlogs and bottlenecks. If that’s to be the case, users should see concepts they find familiar. Or at least not entirely unfamiliar. Put another way:

Not having to code like a developer is not enough.
Not having to think like a developer is the goal.

“Power users” shouldn’t have to denote users who can act like developers, but rather users who can understand a business problem, the content, the process, and the logic needed to make something happen. They deserve tools that reward that thinking. Those tools should be governable and extensible, too — without getting in the way.

If all you think you need to do is free them from coding, you’re going to have to do better than that.

I can’t take credit for the idea; I got it from something James Urquhart wrote for GigaOM. But I’m going to paraphrase it, extrapolate from it, and talk about what it could mean for Office 365.

The cloud is teeming with infrastructure as a service (e.g., Rackspace, Azure VMs, Amazon EC2), platforms as a service (e.g., Azure .NET, Google Cloud Platform), storage as a service (e.g., Amazon S3), and full-blown software as a service (e.g., Office 365, Salesforce.com, DropBox, Box). There’s a battle going on out there for the hearts and minds of developers and architects, and there are pundits betting on winners.

I’m not sure there’s going to be an out-and-out winner, and I don’t think it matters. An inflection point is coming after which business apps won’t be built on one platform. They’ll be built using the most appropriate services from what may well be a variety of vendors. In other words, the array of services that best fit a need will be the platform on which a solution is built.

Companies that understand this can profit from it. IFTTT does a good job of this with consumer services. Nintex is embracing this for business-focused cloud services in a big way. Several companies are waking up to this, and who wins is likely to involve a combination of pure cleverness, ability to execute, and partnering prowess. Those that offer services of substance and make them easily accessed via APIs lend themselves to being mixed-and-matched by these kinds of tools.

SharePoint is an interesting case. The whole point of SharePoint has been to provide multiple workloads (e.g., ECM, collaboration, search, BI, etc.) on a common infrastructure. The individual services didn’t need to be perfect (although some of them were great anyway) as long as the overall package was superior to (and cheaper than) buying multiple standalone one-off solutions.

The cloud, however, makes that advantage nearly moot. If I can assemble a set of content, BI, collaboration, and discovery services to do what I want, I won’t care whether they come from a common server platform. To address this challenge, the services that make up SharePoint will need to be compelling even when standing alone. You can see this happening with OneDrive for Business. Ditto Project Online. Yammer, too. The BI stuff all but begs to be made available for those who want that and only that.

In fact, to ensure further success, it may be necessary for SharePoint to be carved up for parts. Given that the Office 365 brand is the one that has all of the attention, the services might become the platform there, too.

Some people are seeing the “death” of InfoPath as if the sky were falling. Calmer heads aren’t overreacting, but they’re nevertheless starting to look for a replacement. Before going too far down that path, I’d urge careful thought, because I don’t think anyone should be looking for “a” replacement.

“Forms” means different things to different people. I can think of four:

Structured Documents – There is information to collect and each piece of it must be identified. The form’s contents need to be a permanent document that can be copied/moved/archived/signed, but we want to be able to parse the contents and do things with them.

Data UI – There is data living in a database table/SharePoint list, etc., and we want to be able to get at each row/item in an attractive, understandable, easy-to-view-and-edit way. The form is basically a nice viewport into the data — the data is the important part.

Solution UI – There’s an overall app that’s the star of the show. It could be a custom solution, a workflow process, a CRM environment, or really anything. They key is that we need to show the user some things and ask them for other things, and the data could come from and go to just about anywhere. And there are likely to be a lot of these forms that work with both each other and with other application assets.

Standalone Applications – We have a form that’s a document and a solution in and of itself. It stores some data, fetches/sends other data from/to other places, has its own code, or at least its own macros/rules.

Now let’s look at InfoPath with the above in mind…

It was originally conceived as a way of doing Structured Documents from a desktop smart client. Along the way to version 1.0, the team added the Standalone Applications scenario, because at the time — the Office 2003 era — Microsoft’s Office division viewed the world from a client-centric point of view.

By 2007, you could use InfoPath for Solution UI if that solution was a code-based workflow, and in 2010, it worked even in declarative workflows (e.g, SharePoint Designer, Nintex Workflow). 2010 also introduced InfoPath support for Data UI — if that data source was a SharePoint list.

In other words, it tried to be all things to all people. How often does that go well? Let’s see…

Using InfoPath for Solution UI isn’t a bad idea in theory, but there’s nothing in InfoPath’s designer that knows about the rest of the solution (workflow context, for example, which is one of many reasons Nintex developed Nintex Forms). In addition, those UI assets need to be developed completely independently of the rest of the solution. If you make a change to the data, the workflow logic, the authorization model, etc., you have to make sure the forms are independently updated accordingly. If code is required, it gets even nastier. It’s no wonder that as early as last year the Office team blog was suggesting a look at Access.

That led a number of InfoPath people to conclude that the best course of action was to move to the Standalone Application model, throw away “workflow”, and put all of the logic in the form. That’s a problem – a big problem. For decades now, we’ve been taught that solutions should be broken up into a presentation tier, a logic tier, and a data integration tier. Who thinks cramming process logic and data access into the UI is a good idea? Hopefully no one. Even if you did, how easy to follow was an InfoPath form with a lot of views, field rules, form rules, and embedded code?

As for the Data UI use case, InfoPath does a fine job of this if you have SharePoint Enterprise Client Access Licenses so you can use InfoPath Form Services. But I hope that’s not the only reason you have Enterprise CALs, because a number of companies have or will disrupt that. Nintex Forms disrupts that, albeit not deliberately. Heck, even CodePlex projects like Forms7 disrupt the Data UI use case.

Actually, InfoPath is an excellent structured document product. Then again, that was before all Office documents became XML documents in 2007.

So if not InfoPath, what? There is no one replacement. There are three. Use the right tool for the right use case:

You want app-coupled forms? Get a product that’s tightly coupled to workflow solutions. I obviously have a favorite, but this blog is not a promotional vehicle for Nintex; suffice to say that decent workflow companies offer you form options — look at them. Your app isn’t about workflow? Consider Visual Studio. Visual Studio LightSwitch, Access, etc.

You want structured documents? Every Word and Excel file can be a structured document. So can PDF files.

Data UI? There are a lot of options for that, too. Pick one you like. Again, I obviously have one I like, but your preferences may and will vary.

Yes, I know I mentioned four use cases at the beginning of this post, but I really hope you’ll abandon Standalone Application forms — those are just nuts.

The first time I ever met Joel Oleson, I was SharePoint team’s first Technical Product Manager, and he was working for Microsoft’s IT division. I went to them trying to get them to allow custom Web Parts on the SharePoint 2003 servers they used to provide team sites to all of Microsoft worldwide.

His response (and his boss’)? “No. We have no way of knowing whether a custom Web Part is poorly written and could crash our servers.”

When I was trying to advocate building on SharePoint to “regular” Web developers, their usual reactions went something like “Nice portal. How can I show my web site inside of it?” or “What? To develop for this thing you want me to bolt on components and modify its behavior?”

When did research with customers to see if they’d make use of a public Web Part gallery, a near-universal response was: “Are you going to vet what’s in there? If not, how will we know it’s not malicious?”

SharePoint still became a success, but extending SharePoint became a specialized area of knowledge, and the goal was (usually) controlling SharePoint, not contributing to it. Solutions were built, but they never really became a self-service thing.

Fast forward to 2013.

There’s now a means to (a) surface web content you created *any way you want, with any tool you want* inside of SharePoint, (b) a way to pass context, identity, and requests back and forth, and (c) a way to display apps in a curated catalog for self-service purposes.

It’s what you wanted.

It’s not perfect. Some things need to be finished. Some things really ought to be redone. But it’s still the right approach to take.

Now, of course I’ve been working with Office 365 for a long time — longer than most people. But a week and a half ago was when I made it personal, and completed the changeover of mikefitz.com from Google Apps to Office 365.

Yep — mikefitz.com. One of the benefits of being around for a long time is having had the option to get first choice on domain names. And as such, if you want to email me personally as opposed to via Nintex, I’m reachable at mikefitz@mikefitz.com.

Admittedly, I’ve started with mail, and Exchange is great. At $4 per month per user for Exchange-only support, I’m hard-pressed to find reasons not to do it. No ads! ActiveSync for mail, calendars, contacts, tasks, and notes — with multiple mobile devices! IMAP (when needed) with real folders instead of labels-that-kind-of-behave-like-folders.

I don’t yet have a need for Lync on a personal level, so I haven’t done that. I have, however, started adding apps to SharePoint Online sites to see what I can make use of. I’ll investigate putting files in document libraries, but SkyDrive Pro is a pale shadow of SkyDrive, and DropBox does already does such a good job. Still, if I can pay fewer cloud providers for storage, the move would be worth it.

SharePoint Online will remain a non-public thing, however. I thought about activating the public site and using it for blogging, but then I remembered just how limiting SharePoint’s blogging capabilities are. I’ll stick with WordPress and just redirect http://www.mikefitz.com to mikefitzmaurice.wordpress.com for the foreseeable future. Pity. I’d like to be more “all in”.

Still, this is good. I’ve known why companies have flocked to Office 365 for Exchange first, but now I feel it too.

You can read more about the phenomenon here, but the basic gist is that there are people out there who have deliberately given things low-score reviews, even when they actually loved the product, app, etc., that they’re reviewing (and they’d say as much in the body text of their reviews).

Why? They wanted you to read their review. They want their reviews to be rated as “most helpful”, and there’s a higher chance of you looking at a lone “1” when most people award an app/product a “5”. Their reputation score mattered more to them than the reviews they were writing.

Individual goals trump group goals more often than not.

I remember an attempt at Microsoft Consulting Services several years ago to build a website of best practices, technical advice, etc. The plan at the time was to have consultants rewarded for the number of posts they made. What happened? A few of my then-cohorts tried to game the system and submitted article-after-article of near-useless, obvious, already-covered-in-product-documentation stuff.

Same phenomenon: the individual goal of meeting metrics trumped the group goal of building a body of reusable knowledge.

There are many cases of perverse incentives. The most extreme one I’ve heard of is the Cobra Effect. A less dangerous one involved paying developers for every bug they fixed (after a while, they’d ignore code quality just so they could find/fix bugs more easily).

What can be done? I can think of three options:

Make the game more elaborate by adding more rules. Think through the possible perverse incentives. More rules can make participation less attractive, and if so, the reward had better be worth it.

Make the payoff so low that the incentive to misbehave just isn’t present. Of course, that may result in lower levels of participation.

Alternatively, don’t crowdsource.

I’m not a curmudgeon when it comes to social computing, in SharePoint, in Yammer, or anywhere else, but I do believe in caution. Too many people hype “social” to death. “Social” is useful, but it’s not magic. If you treat it as such, you might find that sometimes it’s actually black magic.

We have a new product on the way called Nintex Live. I did a few webcasts about it for Nintex partners a few weeks ago, and I demoed it at the Nintex booth at the SharePoint Technical Conference in San Francisco two weeks ago. We’re planning to put it into beta late next month, and release it well before the middle of 2011.

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 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…