Quick Tip: Emulating $$Return in SharePoint

When you add a new list item in SharePoint, it always seems to take you back to the list once you submit it. However, this is fairly easily controlled, in cases where you would like to send the user to a different page after they submit their form. (As in, when you would use a $$Return field in a Domino App.)

The URL of a new list item, by default, is:
http://server/pathtosubsite/Lists/List/Newform.aspx

But take a look at the QueryString that is appended - you will see a “Source=” parameter. This is the URL from where the form was launched, and it is the URL that SharePoint will return the user to upon submit. Simply change that parameter to the URL of your choice, and your user will go there.

Evolution of our Mindsets

We have gone through a fairly quick evolution on our opinion of SharePoint since I started this blog. I wanted to break it down, because it seems that people’s attitude towards SharePoint can sometimes flag exactly how well they know the product.

Phase 1: “SharePoint can do anything. Let’s migrate everything.” These are the folks who have read the marketing, but never worked with the product. They just don’t have a realistic sense of what makes it difficult.

Phase 2: “SharePoint sucks. It is a horribly immature product that cannot do much of anything, and any real complexity takes custom .NET coding.” Noobs. People who haven’t yet learned the subtleties of how to piece things together in SharePoint, and what kind of advanceed customizations can be done with SharePoint Designer.  (And yes, I was here when I started this blog.)

Phase 3: “Look at all of these cool WebParts I’ve written to help us get the most from SharePoint” Sadly, most consultants I see are here. They say they are SharePoint experts, but really, they are .NET experts who front-end their code through SharePoint. Their first reaction to anything complex is to fall back into custom coding. But they can do more with SharePoint than most corporate folks, so there are a lot of these folks out there building SharePoint environments.

Phase 4: “SharePoint can do a lot more than people think, if they know how to work it.” This is the first level of expertise that I’d actually hire to work on a project. They understand how to do all the basics, and also can work the XML/XSLT to tweak the UI, they know how to create complex sets of workflows, lists, and libraries, then pull them all together into a slick interface. They know how and when to integrate InfoPath, and how to throw in C# code-behinds instead of giving us custom DLLs and webparts to deploy.

Phase 5: “SharePoint is just a tool. I have expertise with it and can make it do quite a bit, but let’s evaluate it alongside other technology options and pick the best solution.” Here we go. This is where we all want to end up — knowing the strengths and weaknesses of multiple platforms, and matching solutions with business needs.

Of course, no one fits neatly into one of these categories. My team has elements of phases 3, 4, and 5 in their attitudes, but none of us have actually built so much experience that we’d claim experitse in the platform yet.

The reason this really matters to me is mostly for vendor relationships. If you are hiring a consultant, or even an in-house employee, I’d be very wary about anyone whose attitudes aren’t at level 4 or 5. When looking at everything we’ve done in this first year, I’m concerned that we could have done things better, and have built some poor precedents for how we architect apps. We can certainly change the patterns we’ve fallen into, but that actually takes leadership skillz, and hey, we’re tech folk.

Writing Complex Workflows

This isn’t really going to be an in-depth technical post… just a brief description of a change of mindset that our Notes team needed to realize to work with SharePoint:

In Notes/Domino, we are used to a single agent holding all of the logic for a complex workflow. Between LotusScript, Java, Script Libraries, even calling out to system DLLs, an agent can become quite a sizable chunk of code. And we like it that way - it makes the agent list a readable, maintanable catalog of what code runs in each application. New developers can take a quick look at forms and agents and understand how an app works.

So in SharePoint, we were incorrectly expecting to see something similar - a single container that holds all the logic for a complex process. What we are finding is that expectation is making us fail at appreciating what SharePoint can really do. If we accept that a complex process may hold dozens of similar workflows to be called by separate lists, and come together into the full process, we are able to do much more work.

As the perfect example, from the day we sat down in a SharePoint training class, we were in shock that you could not have a workflow branch its logic based on form data. At least, not via the SharePoint designer. What never ever occurred to us is that you branch your logic before the workflow starts. Each branch is its own workflow object, and you call the proper one.

Our mindset needed to change from expecting a single object as the “parent” of all logic, to thinking of each object as its a single function of the greater whole, even though there is no place in the interface to point at as the container for the whole app.

A complementary Blog from Steve Walch

For those of you who do not know him, Steve Walch has spent the last few years writing tools to integrate Notes/Domino with SharePoint, and now is working with Quest on migration tools. And now he is blogging:

http://notes2sharepoint.org

His blog is focused on his tools, and one of the differences between he and I is going to be our bias and focus. He states in a comment:

“My #1 objective is to discuss the various issues that users of my product face on a day to day basis. My #2 objective is to discuss the broader set of migration issues that are not product-specific. You can expect this blog to be Quest-positive, Microsoft-positive, and indulge in plenty of “product pimping” along the way.”

In my mind, this sounds great. It fills a gap in the online world today - Microsofties don’t bother to talk about Notes, and Notes people tend to be in attack mode when SharePoint comes up. The reality is that migrations are going on, and will continue for the foreseeable future. Having a blogger around who will un-apologetically post content that tells us about tools and techniques to help these efforts is quite welcome, in my mind.

I look forward to reading more from him as time goes on…

LOE comparison - Notes vs. SharePoint

For those keeping track, our formal strategy on what to do with Notes vs. SharePoint was on hold pending some hard data on the level of effort to develop and maintain applications.

So we did what any group of people without data would do — we made some ourselves. We selected an app that was basic enough to be realistic, but with enough quirky features to throw a wrench at us, and went ahead and made a prototype.

Results were as follows:

• 1 week to get the development environment all worked out, mostly by finding the right patches for Office and SharePoint.
• 4 days of learning the various controls and techniques available to us.
• 1/2 day of actual development once we got it all put together.
• Approximately 80% of functionality with an exact match, 15% with a reasonable change of function to met the same business needs, and 5% not achievable with a realistic amount of effort.

And we concluded the following:

• For strategic purposes, we should ignore the 9 days of “learning curve”. That is a one-time effort for each developer, probably decreasing as the team’s skills grow.
• The actual development effort between SharePoint and Notes is fairly comparable, IF you stick with certain restrictions (listed below). Details of specific apps may make one side quicker than the other, but the delta is small enough that it shouldn’t impact our strategy.
• Security is weak in SharePoint. Before SharePoint folks jump on this, let me give a caveat to that statement - You can make SharePoint security match every Notes security function short of field-level encryption, BUT that then changes the level of effort significantly. To keep development levels on pace with each other, apps that require complex, strict security need to remain within Notes.
• You must use InfoPath. We, as developers had decided that InfoPath was nice, but not really needed. But the time savings in development has changed our minds. Without InfoPath, stick with Notes.

The bottom line is this — from a purely technical point of view, migrating to SharePoint is a “neutral” activity. It neither offers great benefit, nor does it offer great harm. The decision is going to be made on a non-technical basis. The cost of running SharePoint is likely higher today, but it will likely come in line over the next couple years as skill sets improve and Microsoft improves the product.
Technical folks will be able to punch holes in SharePoint to their heart’s content… there are enough gaps and issues to do so. However, SharePoint will meet a significant majority of requirements, and the amount of technical effort required to fill in the gaps will be an acceptable risk/cost to most organizations with valid strategic reasons to be moving to SharePoint. In particular, if a small/medium sized Notes environment is kept around for the ~10% of functions that SharePoint cannot handled.

Our overall recommendation in our organization is to do new development in SharePoint, web-enable as much Notes as we can, remove the Notes client from the organizations, and let the Notes system decrease over time through natural attrition, as the SharePoint environment matures.

(Note that this is a change. When I started this blog, the strategy was “Get rid of Notes. Now.”)

This path also leaves us with options - if the platforms undergo major change for better or worse, we can always turn our strategy around.

Getting Started With Notes

A number of bloggers have recently written their stories of how they got started with Notes. I didn’t read them all, but the ones I did read share a common thread, and it is a thread that is applicable to the reasons people are migrating to SharePoint.

Every Notes person I know has been doing it for many, many, many years. I was in a room with about 50 Notes folks on morning, and the presenter asked every who had more than 10 years experience with Notes to raise their hands.
Everyone had a hand raised.

We are an “old” pool of talent. We are highly skilled, but expensive. Young developers don’t usually gravitate to Notes. I say “usually” because there certainly are younger, hipper, people who do Notes work. But they don’t seem to stick with it, and they don’t seem to become the die-hard evangelists that the online community presents.

So its great that we have this well-developed talent. My last few years of work have been with wonderful teams, where any member of the team could have led the team, managed the projects, etc. It made for great working relationships, and we put out great work. I think those teams were worth every penny the customers paid.

But that is exactly the issue - without young, inexperienced, cheap talent… the hiring process for Notes folks tend to be unfriendly to budgets.

So what’s my story?

I started as an end user of Notes, when I got a job at IBM research doing desktop support in… must have been 1994.  That job was just a temp contract, so I moved on to an analyst firm, where I did Notes admin for a while. sending their research to customers via Notes replication. (via modems to 300 servers. Ouch.)

Again, that was a short term job, but I then moved to a hospital that was converting from green screen apps to Windows-based apps, and I was able to build up a small Notes environment to track the hardware assets, projects, and helpdesk work.

I then moved back to IBM, helping them roll out Notes internally, and becoming a development team lead for one division. That led to senior develop positions in startup companies for many years, until I got back into the corporate world, being asked to help remove the platform.

The on consistent pattern through all my career has been one of underlying changes in technology platforms. I’ve (almost) always been either build a Notes platform, or removing one.  It is a technology that enables change on a very fundamental level.

Synthesis of Discussions on Notes v. SharePoint

In the past week, I’ve received numerous emails, comments, and reactions to the general concept of migrating Notes to SharePoint.
I wanted to post a brief synthesis of some of the main points, and add some commentary of my own:

1) Notes vs. SharePoint is not comparing apples to apples. Quickr is the better comparison tool.
This is true. However, Quickr does not have the market penetration that Notes in general does. Much as I’d like to say it is a fair discussion for organizations in my situation, unless you already have Quickr going in your environment, it just isn’t realistic. We’re talking about determining the best platform for our current functions, not evaluating a new platform for future collaboration. Quickr just is not a consideration in our current environment, for political, if not technical reasons.

2) Web enabling an entire Notes environment is a difficult, expensive task.
Maybe it is because I’ve been web-enabling Notes apps since the first IBM-internal beta of R5, but I just don’t think it is as difficult as people are making it out to be. There is certainly a large learning curve, but I got over that curve almost 10 years ago. Am I the exception? From all the wonderful tips and techniques offered in the blog-o-sphere, I thought more Notes developers were comfortable in this arena. Is my perception inaccurate?

That being said, I agree that a 100% web enablement would be a chore. We’re more likely to pick the easy apps, and pick the apps with a large user base. If we can web enable enough apps to decrease the number of Notes Clients in the environment, we decrease support and maintenance costs. The more we decrease those costs, the more management will support keeping Notes/Domino as a technology platform.

3) Why would you migrate anyway?
It all comes down to cost. I think everyone will agree that today, Notes is cheaper to run. We already have a talented staff, the environment is stable, we have processes in place, etc. In addition, truly talented SharePoint experts are rare and expensive. A lot of people have it on their resume, but they crash and burn in a real project situation.

So with all that in mind, how can SharePoint save money? People I have spoken with believe that in 3-5 years, the costs will reverse. 3-5 years from now, SharePoint folks will be as common as C# folks are today. Microsoft will have released one or two more major releases, and will respond to the major weaknesses being identified in the platform. (With Ray Ozzie at its helm, no less…)

On the other hand, Lotus folks are a dwindling population, at least in my area. I’ve talked to a number of organizations who will accept a greater cost today to get to the platform that they believe will become cheaper as Microsoft responds to the weaknesses of SharePoint, and the talent pool increases their skillsets.

After all the talks, my general strategy hasn’t changed much from one of my previous posts, and it is very close to becoming the official strategy at my workplace:

1.  Increase the internal skillset on SharePoint, BizTalk, .NET, etc. to reduce the amount of consulting required on the platform.
2.  Web enable Notes apps, and integrate them with a SharePoint portal, striving for a reduction in Notes client deployments.
3.  Create new apps in .NET/SharePoint, unless Notes has a clear cost and speed advantage for the specific functions requested.

Let me just add one or two caveats:

• If you are already on Quickr, your strategy may be different.
• If you are so large that the enterprise-level weaknesses of SharePoint are unacceptable to you, Notes makes more sense.

And I would like to close with an open-ended question — given the following root causes of the desire of “management” to migrate to Notes…

1) Decreasing Lotus talent pool, and increasing cost of that talent.
2) Confidence that MS will resolve their SharePoint issues, and decrease long-term costs and pains in a SharePoint world.

….What can IBM/Lotus do to turn around migrations like mine?

(From a truly unbiased point of view, I shouldn’t care. But with 15 years of Notes experience, but only 2 years of .NET, and 6 months of SharePoint experience, I just plain got more skillz on the Lotus side, and I’d like to use them.)

Two Types of SharePoint/MOSS Environments

Welcome to all the new readers. I guess getting Brilled is somewhat similar to getting Slashdotted, if the 5000% increase in traffic is any indication. Thanks, Ed.
I’m mildly amused that when I start to border on ranting, the level of attention increases, but I won’t worry about that today. I have other things on my mind.

Now, this is all based off circumstantial evidence, not hard research, but given that caveat…

There seem to be two different ways organizations are approaching SharePoint, and they are diametrically opposed to each other:

Method 1: Install a server, see what it can do, use it for small apps, and expand its function and the scope of the environment based on demand.

Method 2: Assume that demand will be huge, and engineer a large, complex architecture to support that assumed long-term demand. (We did this.)

While I appreciate the strategic foresight of method 2, and the desire to not be constantly re-working your infrastructure, I have yet to talk to someone who went that route that actually has been successful. Up and running, certainly, but successful? Seems rare. More often, the end users are happy with the platform, but there are internal teams like mine pulling their hair out. Or maybe that does qualify as success, if you have the right perspective.

In any case, folks going with Method 1 seem to be doing just fine. They are getting their feet wet with small stuff, learning the technology on the fly, as needed, and letting the growth of their environment march right alongside the growth of their skillset.

Mistakes are made under both methods, but a small mistake in a large, complex environment, especially if identified after the platform has experienced immense growth into your organizations production systems, can be a real nightmare to fix. I know we’re suffering the pain of mistakes made in the planning phases that didn’t show themselves until 6 months later. And of course, politically, it is unwise to say that the consultants for whom we paid a couple million dollars just plain screwed up. So I won’t say that.

And maybe I’m just looking at the greener grass on the other side of the fence. But seeing as our environment runs about 4 brochure-ware sites, front-ends a handful of custom .NET apps, and runs a few dozen each of lists, doc libraries, and discussions…
I’m just not seeing why we couldn’t have gone with method #1, saved millions of dollars, had a simpler infrastructure, taken less IT resources to support it all, and sure, maybe added a 2nd server if needed.

So as a message to anyone else out there, when planning a new SharePoint deployment, KISS.

Results

After all of my inquiries and research into real measurable data comparing SharePoint Dev and Maint costs…. there is no data.

Everyone I talked to is in the same boat we are - just getting going, spending more money on SharePoint at the moment, but with no real idea of what it will cost long-term. It is all guesswork.

I’ve seen no evidence that anyone really is having a successful migration that saves them money. If anyone does have evidence, feel free to share it.

But as I look hard at the two technologies, I see a few things… and this may show my bias, but it is what I see:

1. SharePoint ties everyone to MS Office. Why? Most other web technologies are working to eliminate desktop products, not push your web site down into your desktop. SharePoint does not take your enterprise to the web, it marries you to Microsoft Products at a very deep level.
2. There is no SharePoint expertise internal to the corporate world. Consultants and business partners have the majority of skills, and very few major projects are done without shelling out money to them.
3. Microsoft does not yet have their training together. The only available training that I have found is through their business partners. I went to that training. I found it very basic.

In general, SharePoint feels like a big old marketing scam to me. It doesn’t do as much out of the box as Microsoft would have you believe, but it does give Microsoft and their partners a good chunk of money. A decision to go with SharePoint is a decision to tie yourself into their full product line.

Now, does that mean it is the wrong decision? Not necessarily. I don’t know. It depends on your requirements, I suppose. It certainly makes me nervous, though. Why shake up the status quo for a new technology that nobody is skilled in, that costs more money to deploy, that is guesswork for long-term costs, and that ties you to a specific vendor? Even if it did perform as advertised, I just don’t see justifiable answers to that question.

Soliciting Feedback

I’m looking for some answers from the community…

As I mentioned previously, the status of Lotus Notes/Domino is again under discussion. To make an educated, unbiased business decision, we are looking for data on the following questions:

1) Development Effort - In General, how does development time in SharePoint compare to development time in Domino. Assuming skilled talent in both technologies, and non-trivial apps…  does anyone have any real numbers and data comparing the level of effort to write applications on both platforms? Or even any anecdotal data?

2) Maintenance Effort - How does the level of effort compare to maintain SharePoint Applications vs. Notes Applications. (Again, in general). I’m not talking about the infrastructural support for the platform - just the application support. How many developers does it take to support a 500-app Notes platform vs. a 500-app SharePoint platform?

If anyone has any real world experience, and in particular measurable data dressing these issues, please either comment here or contact me directly at migratenotes@gmail.com.

Thanks!