Better Today…

Well, the previous post was not so unbiased, I will admit.

But I’m feeling better about SharePoint today. I had a number of small problems to fix, and was able to fairly quickly and easily get into the site, make the udpates, get everything tested, and declare the problems resolved.

We’re starting to realize that going into SharePoint with a “Notes vs. SharePoint” attitude is dangerous. While they try to be competitive products, their architectures and techniques are so vastly different that comparisons inevitably leave us frustrated, wishing we could stay with Notes. But that just isn’t reality in our organization.
So we are trying instead to discipline ourselves, taking SharePoint for what it is, finding its strengths, and enjoying the experience of learning a new technology.

At the same time, as we look forward to next year, we are seriously starting to consider the details of application migration. Even though I don’t have a huge audience here, I have received a few emails from other people involved in application migrations, and there seems to be a level of interest in sharing our experiences. To that end, I’m wondering if I should expand this site into something more than just a blog. Perhaps add some places for us all to document our techniques that have worked well, as well as the lessons we are learning. I’d naturally expand the authorship of the site to let multiple people contribute to the content.

Would there be interest in an expanded site along those lines?

Notes vs. SharePoint Analogy

After a couple days of fighting SharePoint, and spending hours getting small details into just the right place, an image came into my mind.

 Imagine Notes/Domino as a trainyard – while it has a lot of power, and definitely needs some technical knowledge, once you are set up properly, you just need to know which switches to throw to get the results you want. Your ‘train’ smoothly goes in the direction you desire.

Sharepoint is quite similar. Except that instead of a trainyard, your train is sitting in a big open parking lot, and you have lots of monkeys throwing crowbars under its wheels, and you need to see what happens and keep giving the monkeys new directions until you get the result you want.

 SharePoint is fun. Really.

Migration Status

I have not been posting very often in the past few weeks…. mostly because I’ve been swamped with working solely within SharePoint, learning some more of its details, and how it was configured in our environment. But I’ve been working 100% within the browser-based areas of SharePoint, so I haven’t written any code to share or devised anything profound.

I do have a stronger sense of how to “think SharePoint”. If you recall, a while back I wrote out a list of analogous Notes and SharePoint components to help me wrap my head around SharePoint, but I’m now getting past that. I’m beginning to think of SharePoint as if it were Legos. No single feature within sharePoint is very complex. You need to build them on top of each other to reach your goals. You have some moving parts that you use to connect your pieces and make them move in some limited ways. The more creative you are, the more you can make it do. To work with the out-of-the-box features, you almost have to stop thinking like a coder — it isn’t code.

Its security is also more open-ended. While Notes/Domino has many layers of security, they all come down to the same IDs and groups. Not so in SharePoint. While you do often use your Windows Login as your primary identification and authentication, it gets blurry after that. You can use SharePoint groups, you can use AD Groups, you can use LDAP queries, you can write your own membership provider. In some places, you can mix and match, while in others you cannot.

I’ve always maintained that a Notes/Domino system is exactly as good as the people who design it. There are world-class systems out there and there are catastrophes. I think SharePoint is going to exaggerate this trend even more. You will find elegant, wonderful implementations, and you will find utter disasters, and the key will be the people behind it.

The problem is the level of expertise in the industry – Domino has been around a long time, each new version compatible with its predecessor. This has built a core group of developers who have well over a decade (or two) of experience, and can really put together a nice architecture. SharePoint 2007 is brand new. There is no expert with 10 years experience. The most senior folks out there are still working out the kinks of the latest version. And as each new version is its own beast, and not built upon the previous version, I fear that this will always be the case.

SharePoint is not a Sandbox

It is too bad that I have a policy against writing anything directly about my projects at work.  Because it stops me from getting into some details that would likely interest this audience. I can say this much — I have been reading for a long time that running a Microsoft platform will cost more than a Notes/Domino platform. After the past week, I now understand why that is. Readers in the past have question how long it took to get a SharePoint environment up and running. That is still the quick and easy part. The difficulty comes not in the setup… but in the maintenance.

Maybe I just haven’t figured out the best practices yet, but it seems like SharePoint is designed to require ongoing maintenance. The theory is that the end users can manage their own sites, and IT just need to keep the environment running and do special projects. But wait — this sounds exactly like the Notes world back in its early days. At that time, IT shops thought Notes could just be thrown to the users, and they can create their own DBs without much help from IT. And some shops did do that. But most of the places I worked did not… instead, the IT shop handled every single request for a new Notes app, they handled every maintenance issue, and eventually the Notes environments were locked down fairly tightly, with end users having freedom only within specific areas of applications pertinent to their business.

I would be surprised if SharePoint did not go that same route. Business users will probably really like being able to throw out a new document library, discussions, etc. But I don’t think they will like creating lists. I doubt they will want to bother with the tedium of creating columns and views, and I doubt they will enjoy learning about all the different data types and function you can do in a list.

If I had to predict the future, I’d predict that SharePoint environments will degenerate into a mishmash of document libraries, with a high-level structure generateed by IT, and utter chaos once you drill down to the areas controlled outside of IT.  In a couple years, the major SharePoint projects will not be setup projects, but cleanup projects. We will spend our time reorganizing content, locking down access, and treating SharePoint like one large application (which it is.)

The idea of collaboration gets confused with the idea of complete freedom within an application. Collaboration works best when there are enough controls in place that everyone works in the same way. SharePoint does have the power to create a good collaboration environment. But it needs IT oversight. Repeat after me – SharePoint is not a Sandbox.

Granularity

If you recall, back when I first started this blog, I wrote out a brief mapping of SharePoint features to Domino features.

I now think that should be thrown away.  The more I get into SharePoint, the more I realize a very fundamental difference between the two systems.

They both offer very granular control of your environment… but Domino starts at a high level, but with features that let you get more detail as you need it.  SharePoint forces all the detail upon you, but roll it into an interface that lets you manage it.

For example, Security — with Domino, you start with a basic ACL on the  database. Everything works from that ACL. You can then add form level security, document level security, and field level secuity as your develop your app, but none of those are required.

SharePoint on the other hand, really does store security information for each component. When you create something new, it inherits the security from its parent. You can (and often do) just leave it at that. But each list always has its own security properties.

It makes SharePoint slower to learn, in my opinion. A New Domino developers can learn how to build a form, a view, work the ACL, and be somewhat productive very quickly. They can always go back and learn all the details later.  A new SharePoint Dev can quickly build a basic list with some simple columns, but to start working with security and workflow… that takes more effort.

Both systems have a great detail of potential. And a slower learning curve with SharePoint isn’t really a problem – we just need to sit down and suck it up.

But I do question long-term maintenance efforts on SharePoint. MOSS 2007 hasn’t been out very long. It is too immature of a product to have established any real-world best practices yet. I’m surprised at how many corporations seem to be diving in to bleeding-edge technology, instead of giving the world a year or two to shake out the kinks. As a Domino  folk, I still see SharePoint as the less mature product. So the management decision to put  this much effort into a new technology that costs more, requires more maintenance, and has a chance of matching, but no chance of surpassing Domino still confuses me.

Nevertheless, I don’t guide my career by a technology, but by business needs. If corporations make this choice, I intend to build my skills and give them the best system I can, even if I would have made a different choice.

Yes, it could work…

(After some experimentation, I’ve concluded that yes, you could very well write some script libraries to extend LotusScript for your SharePoint migration. It wouldn’t work as directly as I had hoped, but there is still quite a bit of value you could put together. My current projects are simple enough that it is not needed, but I will keep it in mind and hopefully build something over time.)

I am finding that the important part of building a SharePoint environment is not really technical, but that shouldn’t be a surprise to anyone who knows me. Over more than a decade of Notes development, I’ve  learned many aspects of collaborative development that are harder to define –  for example, having an understanding of the ways people really will use a system. Knowing which technical features they will gravitate to, and which ones sound cool to the developers, but will get ignored. Knowing which kinds of people want to work from a list in a browser, and which ones really do want everything in their email. And combining all of this with a basic understanding of UI design, and HCI.

I’m finding that many of the experienced MS developers have not worked directly with the end users enough to gain this understanding. There are some who have, to be sure…. but for the most part, MS developers seem to be used to working from a spec, and spitting out code to match. Some of them are very good at this, but the resulting application is only as good as the guy who wrote that spec. I’ve seen many apps that are beautifully, brilliantly coded, but that just aren’t very useful. This isn’t specific to MS — I’d say 99% of today’s internet startups also fit that brilliant, but useless category.

But the whole reason collaboration software came to be is to simplify and streamline the communications within an organization. How can an application developer be successful at this if they do not first understand the way that people prefer to communicate?

Integration Thoughts

I have a few ideas I want to try in the near future. I don’t have much spare time, though so I wanted to throw them out here to see if anyone has a reaction before diving in…

1) SharePoint API via LotusScript – I’m sure we’ve all seen and/or written code that calls functions from DLLs on our system. Well, SharePoint’s API is housed in a DLL. why not call it directly? The only catch is that it is an OO platform, not procedural, so declaring your functions only gets you half-way. You would need the objects as well. I’ve never looked into the syntax, or the possibility, of declaring an object from a DLL in LotusScript. I will need to research it. If it can be done fairly easily, and you can in effect extend the LotusScript Object model with the SharePoint object, that really changes things. If not, Variants may still let you use a portion of the model, but it would be much more tedious.

2) Lotus Notes as an offline platform for SharePoint – I’ve designed, but not coded, a program that will take a sharepoint list, convert it to a Notes database, and keep the two in sync, allowing for a dual interface. It was mostly just an exercise to understand the two data models, but once I did it, I realized that it could serve a highly functional purpose – It could allow people to use Notes as an offline storage mechanism for their SharePoint data. How would that change the marketing of thse products if Notes could consume any SharePoint list, and make it available offline just as if it were a Notes database?

Like I said – neither of these ideas has much code behind them at the moment, but I think they could lead to some very powerful integration between the two systems. I have very little time in my life for side projects, but I’ll keep people posted as I play with these and see what I can come up with.

Now this is an app that should migrate quickly…

I normally refrain from talking directly about work, but this app deserves special mention because it is a rare one – it practically screams, “Migrate Me!”.

It gathers data from the end users, then lets them select their own approvers, and when approved, uses a Word Template to copy their data into a printable Word Document.

The way it is done in Notes is very fragile. It uses OLE Links to the Word Templates. It creates multiple NotesDocument objects with the updated documents, and again uses an OLE Link. It then activates that link to display it to the user. Of course, if your files ever move, your app is broken. I can think of better ways to achieve the same result in Notes…

But why even bother? If your requirements are for Word documents with a specific format, SharePoint becomes a clear and simple answer.