Michael Yeager's MSDN Blog : Workflow

eXtreme End-User Driven Architectures (XEUDAs)

mty — Fri, 07 Nov 2008 18:03:00 GMT

There is an emergent solution architecture which the most ingenious of our end users are piecing together without our help. It is an architecture without a name - so let's give it one:

the eXtreme End-User Driven Architecture or XEUDA (zoo-da)

A XEUDA is an Architecture - not an Application. It is an architecture of many applications that end-users compose to empower complex business processes. End users do this by themselves - no developer/IT intervention required.

XEUDA is an architecture that can be changed, rearranged, reconfigured, repurposed, redesigned, re-architected by the end users. Right now end users can only do this to a very limited degree, only with a small sub-set of applications, and only to drive particular activities of some business processes, but if the application architect and developer community, along with the IT governance powers that be, were to relax their grip and embrace this impulse, XEUDAs will push IT controlled architectures aside by producing productivity gains of 10X or more.

Anywhere there is an Enterprise MOSS infrastructure with even a handful of power users you will sense the yearning for XEUDA. MOSS power users and champions build fabulously flexible applications on their MOSS sites. MOSS is a wonderful end-user driven system. But it is not extreme enough - inevitably users drive up to the edge where pieces can no longer connect, where their InfoPath or Word or Excel docs, their content types and custom lists, and their SharePoint enabled LOB applications, are left hanging on a library ledge - their structured and unstructured data in danger of being backed-up into oblivion.

And when the developers and architects are brought in, and the problem is laid out and the requirements gathered, their next impulse, more often than not, is to move to a purpose built application - ripping control out of the hands of the users, and placing it in the hands of a Solution Lifecycle and project managers and development teams and a change management process which may take months or even years to hard boil what the end-users had loosely assembled in a matter of days...

We have all the tools and skills to give those magnificent MOSS and OBA applications the ability to turn into more powerful and more flexible XEUDAs -- what we don't see enough of are architects and developers that are advocating and building the end-user architectable elements that a XEUDA requires; and agile, apolitical, IT governance teams that are ready and willing to hand-off the architectural keys to their power users and domain experts...

SharePoint Solution Generator - Deploying to a Production Server

mty — Fri, 29 Jun 2007 23:10:00 GMT

Just a short note on the SharePoint Solution Generator - which is a great little tool!

If you don't have the SSG yet, it is part of the Visual Studio Extensions for WSS v3.

Customize your SharePoint site adding web parts, lists etc., then point the SSG at it, and it generates a Site Definition. Open the Site Definition in Visual Studio. Right click on the solution and select "Deploy", and assuming you are working on the server where you want the new Site Definition installed, it deploys the new Site Definition to that server.

But what do you do when you want to deploy your new Site Definition to a Production Server where installing Visual Studio is not an option?

Well, there must be an easy way, I wish I knew what it was, and hopefully someone will chime in and let us know, but in the mean time I thought I'd share a manual process that has worked for me.

The jist of it is that you need to:

copy the new files and folders that are created by the deployment on your development server to the production server
copy the DLL that was created to the GAC on the production server
use STSADM to deploy all of the features that were created (there will be one feature.xml in each folder created in Template/Features)
either use STSADM or the Admin UI to activate those features

Once all of that is accomplished, then you can go create a new site using the Site Definition.

The folders and files you'll need to copy are in:

Template/Features
Template/SiteTemplates
Template/1033/xml

The new folders have the name of your solution plus a guid at the end, making them easy to find.

The STSADM commands for deploying and activating a feature are:

stsadm -o installfeature -filename <FeatureFolder>/feature.xml
stsadm -o activatefeature -filename <FeatureFolder>/feature.xml -url http://site

There should be one feature.xml file in each of the new folders created in Template/Features, and you have to run this command for each one of those feature.xml files.

I hope this is helpful.

One "All Singing, All Dancing" SharePoint Web Part

mty — Thu, 02 Feb 2006 04:03:00 GMT

When the ProcessVelocity project began a little over a year ago as Approval Manager, it would never have occurred to me to try to build a complex workflow application as one big hunking SharePoint web part.

Seemed just a wee bit too funky since as a web part the workflow application can only ever be loosely connected to the actual document and form libraries.

But then a few months ago, over the Thanksgiving holiday, it occurred to me that moving all of the workflow "management" functionality into a web part held the possibility of solving multiple important requirements at once.

The loose coupling of the web part and the libraries actually ended up being the main attraction - keeping all of the workflow mechanics separate from the libraries enables the ability to convert an existing library into a process library. The users are no longer forced to move their documents to another library or another site and sacrifice all the structure they've labored hard and long to create.

Point the web part at one of your standard libraries packed with documents - push a button and whoosh - the library can now participate in global SharePoint processes - processes spanning multiple SharePoint workspaces and libraries.

At least that is the promise that we're burning up our spare time to fulfill.

This new web part version (the Approval Manager version was a list-definition design) is only in Preview at the moment - still plenty of bugs and issues - but the results delivered since Thanksgiving are very encouraging.

There are something like 17 different screens - various displays of Processes, Sites/Libraries, Activities and Documents... What can I say... serious workflow gets complicated and ProcessVelocity is intended to get very serious.

Choices on the ballots are all customizable through the GUI and the actions underlying those choices are intended to be extensible by 3rd parties.

Beyond being able to handle multiple various significantly complex workflow scenarios, the primary design goals for ProcessVelocity are:

Absolutely Free
A completely native SharePoint application
No requirement for any additional anything other than WSS
Completely GUI driven, no programming required

If you're particularly curious about the possibilities, there are links to a couple of demonstration videos in the sidebar, as well as a link to the SharePoint ProcessVelocity Web Parts workspace.

michael

Visio and Workflow

mty — Tue, 10 Jan 2006 18:07:00 GMT

As some of you know, I have been spending a lot of my spare time lately working on the ProcessVelocity application (you may be surprised to hear that it has advanced to a preview release - more about that next time). This means that I have been spending a lot of time thinking about workflow.

And then last Friday I was on a virtual panel as part of the US Portals Community, and the one question that I fielded for the team was about Visio 12 integration with SharePoint v3.

So in this round about way, the two things, Visio and Workflow, have once again converged in my mind.

Did you know that the number one use of Visio, after the obligatory corporate hierarchy diagram, is for process diagrams?

I have piled up a lot of hours guiding clients through the diagramming of their enterprise processes using Visio, and then incorporating them into SharePoint in various ways. Carrying that over into workflow seems like a natural next step, and many third party workflow solutions do exactly that.

But ProcessVelocity does not use a Visio interface for representing workflow. It uses tightly constructed web forms as the UI for both configuration and execution. I've debated that choice many times, but the bottom line is that ProcessVelocity is first intended as a free add-on to the base WSS installation and the first design goal has been that it makes no additional requirements on the user - no additional database required and no additional applications such as Visio.

My point is, after all that, is that in the process of implementing workflow without using Visio, I've started to question the efficacy of that approach. The logical design of the ProcessVelocity forms gives you a sense of the overall flow, and it also puts the tools right in your face. No questions about how to make changes, the levers and switches are all right out in front.

I'm not quite sure how to design a Visio interface that demonstrates that same direct utility, or that makes a really good transition to an effective set of levers and switches while still conveying the larger view.

Visio is a fabulous tool for creating high level representations, much like a map is a great tool for finding your way around. But you don't steer your car with a map. You have a steering wheel for that.

The issue I'm suggesting here with using a Visio as a workflow designer is - it gives you a great high-level view, but it seems less effective when you jump into nitty-gritty and absolutely critical details that make a workflow work. You typically right-click on a shape, and then enter data into the property form, but this takes you completely out of context - you no longer see the whole process, but only the particular attributes of a particular Visio shape.

So the question is, how do we go about resolving this disconnect between the high-level and the nitty-gritty?

One pie-in-the-sky possibility would be really tight integration between Visio and InfoPath. If there was a seamless transition from a highly customizable diagram directly to a highly customizable form - now that would be a big thing! Then you could go from the map to the steering wheel without ever taking your eyes off the road.

And then, to take a little longer jump down the SharePoint road - what if all the forms in SharePoint were actually InfoPath forms? What if a SharePoint List was a completely InfoPath concept with all the customizability and smarts right in the InfoPath UI!?

Then your process diagrams would go directly to forms, and then the forms directly to SharePoint lists - with all of the levels in between customizable through these wonderfully rich, user-friendly UIs.

Just thinking.

michael