October 28, 2009 at 8:38 am
I've used SharePoint for a long time, since the beginning of general availability I guess. I appreciate it and get a lot of work out of it, despite the fact that I do agree with most people's gripes. In my humble opinion, the many benefits are significant enough to outweigh the many problems.
It seems that Microsoft stumbled on this product and has been scrambling to shore up its weaknesses. Half of it was originally shipped as a sample/template of what could be done with Frontpage server extensions on the Frontpage 98 CD. (SharePoint Team Services, STS). Thankfully, it's not based on Frontpage server extensions anymore. Then they combined it with their portal product from the Exchange group... they ported it to .NET, moved it to SQL instead of the Exchange engine and the file system...
It's more "unified" then it used to be, but still has plenty of room for improvement. It's change over the years has been a lot of fun to watch, actually.
They've done an o.k. job of taking advantage of their serendipity.
October 28, 2009 at 8:40 am
This is the best document I've seen for setup.
Greg E
October 28, 2009 at 8:41 am
I think it's designed to be a sort of dumbed-down version of creating HTML pages, using web parts, but not quite a WYSIWYG. Ends up as the bastard child of either one. I can't stand it, but we use it extensively, so I have no choice. End users typically get excited that they can create web parts/pages/sites/etc, then get into building it and get frustrated because they can't do what they want. And then complain to my team to fix it 😛
But I have higher hopes for performance point and now PowerPivot. Maybe by the time we (my corporate "we" here) get there things will be easier, or at least well documented so we can figure it out.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
October 28, 2009 at 9:28 am
I've worked with SharePoint 2003 & 2007 and to me it seems like a good solution for an out of the box corporate intranet. The problems I've seen with it all stem from a company buying it because somewhere along the lines they were promised it could do a, b, c, d, etc and then it gets installed and no one really knows how to use it, so there is relatively little adoption. People continue to save their files to the file system directory, email files to co-workers they are collaborating with and all the other items SharePoint is supposed to eliminate.
The functionality is there, but like the others have said documentation and training is lacking on how to use that functionality. Plus if you are trying to set up a check-in/check-out and collaboration/approval process for different documents in SharePoint after users are not used to that type of process, it probably will never get implemented by the majority of users. I think it is like any other new application that gets introduced - a plan has to be in place detailing how the application will be used and that plan has to be visible to the users. Just what I've seen in working with it and working with companies who use the product.
October 28, 2009 at 9:51 am
It uses SQL Server, which means every Sharepoint sale not only increases the need for a DBA...
Sharepoint at this time is giving SQL Server a bad name. That's been my experience.
October 28, 2009 at 10:44 am
We were looking into developing a lot of Sharepoint stuff for a couple customers last year. I looked around and decided it wasn't a great platform right now, given our lack of relevant experience, the mutt-like heritage of a lot of the parts and a major re-architecting on the horizon (early 2010) that might call for a re-write. (They went ahead anyway, relying on a consulting house for some parts of the work, but that's not my point here.)
While digging around I found one article that really made me think about SP, and not in a good way. Peter Seale wrote about why he was"becoming increasingly frustrated with Sharepoint" and "dropping out of the Sharepoint blogosphere".
The nut of his post was that as a platform SP is such a muddle that there are no best practices for many problems. He summarized the rant like this: "There are some takeaways here, notably that everyone's struggling with SharePoint, including the MVPs and "experts." I make the statement that every person working with SharePoint should look beyond their immediate technical challenge and ask, is SharePoint the right solution? Also, I challenge the assumption that SharePoint is a good developer platform."
[font="Arial"]Are you lost daddy? I asked tenderly.
Shut up he explained.[/font]
- Ring Lardner
October 28, 2009 at 12:47 pm
We use MOSS 2007 for a Team site. 2 of our consultants set it up a couple of years ago with a minimum amount of pain. Neither had ever worked with IIS or setup a web site before, and only 1 of them had a pretty good background in SQL Server. It requires no maintenance other than regular automated backups. It is available without the use of a VPN, so makes for better file sharing than network drives, and a better experience than FTP.
We use it for document sharing and collaboration. It does a good job of version tracking and merging, with multiple authors working on a single document at the same time.
For storing files it is much easier to organize and navigate than any network Share(s) you will ever see.
It also makes a better Bulletin Board than say email announcements.
We also use CRM, but some things work better with SharePoint. Customer history can include proposals, support history, and custom projects, among other things. And in multiple subfolders as needed.
By the way. File folders don't have to be configured to require "Approval" of their documents.
October 28, 2009 at 3:29 pm
Hi Steve,
As an ex-DBA/Senior Developer and now a Enterpise Architect, I really encourage everyone to take the tour around SP/MOSS 2007 with all the Service Packs applied.
Don't expect the tour to be a day trip either. You really need to spend at least good solid week with it. Also, there's not much interest at the DB level as the bulk of the functionality is done by configuring SP and then making subtle tweaks via 'code'. These subtle tweaks require an extensive knowledge of the SP object model. Or perhaps put another way - If you don't understand the SP framework, you're first attempts at tweaking it will most probably just be re-inventing parts of SP multi-spoked wheeel.
Of special interest for DBAs would be Custom Lists. A Custom List is analogous to a DB table. It is made up of pre-packaged 'site columns' which are analogous to columns in a database table. All the basics are there (dates, decimals, integers, chars, etc.) but each is wrapped by SP code that automatically creates a UI that can validate the contents. You can create your own custom site columns by inheriting from one of the base types and extending it with code. To 'query' your custom list, you create views over them.
Custom lists can be linked together to provide 'basic' referential integrety and look-ups.
With careful 'custom list' design (basically standard database design principles) you can create a pretty slick looking 'app'.
Once you've mastered custom lists, you want some sort of very basic 'programming language' to make stuff happen when a custom list row is added/changed/removed. This language is Windows Workflow! Its pretty cludgy to use in SP2007 but quite doable using SharePoint Designer which is free. In SP2010, the WF has got far more visually based and far easier to create as its done via the web page UI.
A good intro to what can be done very quickly with minimal coding (sometimes none at all) is to install some of the "fantastic forty" site templates. There's something for everyone amoung the 40.
Just a word of warning, building lightwieght apps with custom lists is about embracing the 80/20 rule. I.e. you'll get 80% of the function in 20% of the time it would takle to build it with standard ASP.Net code. Chase that last 20% tho and you'll consume the remaining 80%.
Another word of warning ... check out how SP stores each Custom List down at the DB level 😉 You'll be not wanting the lists to to get too long or too wide.
If you're not worn out by the tour at this stage - check out the BDC (Business Data catalogue) - I have no idea why they called it that BTW. Basically, its an XML definition of data that can be surfaced in SP as 'lists'. The BDC requires enterprise lics.
Is it a great product? I've been working with it since 2007 beta and, put bluntly, what they should have released is SP2007 at SP2! And yes, doco was pretty awful - but worse was how developers approached using SP. They just didn't want to understrand the object model or the framework! To make matters even worse, the blogosphere is awash with self-styled SP gurus spouting rubbish and mis-information. Google wasn't your friend when trying to resolve issues. Basically, you had to go back to basics as to how windows, IIS, ASP.Net, XSLT, XML, C#, OO, etc worked, tie that to the SP object model/framework and resolve the issues yourself.
Someone earlier in the thread said its like Lotus Notes. Yes it is. And no its not. Warts and all. :hehe:
October 28, 2009 at 3:44 pm
I think the growth in that segment of the market has probably pushed the development of the product faster than it really should have been. I suspect there's a lot of duct tape and bailing wire mixed in, but the fact is that it usually gets the job done, albeit with a good deal of, um, help.
Tim Mitchell
TimMitchell.net | @tmitch.net | Tyleris.com
ETL Best Practices
October 28, 2009 at 4:13 pm
I think half the problem with Sharepoint is that many companies implementing it have absolutely no idea why they want to implement it. They just want to have it because it's the thing to have. MS is partially to blame here. I recently sat in on a meeting with a guy from MS Consulting and he was pushing Sharepoint like there was no tomorrow, and there was no business case whatsoever for sharepoint.
A colleague of mine does Sharepoint consulting (though he hates the product with a passion). One thing he tells potential clients again and again is not to implement sharepoint until there's a good, valid business case for doing so.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 28, 2009 at 5:12 pm
Is it a content management system? Is it an enterprise social networking platform?
Neither. It's an attempt by Microsoft to compete with Lotus Notes
That is not correct for MOSS2007 which is a $50 million dollars content management server Microsoft bought and Woodgrove the oldest complete application archicture on the Microsoft platform, which I think Microsoft took from the platform developers who improved it over the years. Microsoft built MOSS2007 and removed Woodgrove from the sample applications.
It is a competition to Websphere not lotus notes but much lower price point than Websphere. Those of us from Java and very long memory knows what IBM converted to what is now Websphere.
Microsoft is selling it because implementing it does not require knowing the http pipeline or SQL Server to add new features to Sharepoint and the Windows Sharepoint services is free.
Kind regards,
Gift Peddie
October 29, 2009 at 7:25 am
I think half the problem with Sharepoint is that many companies implementing it have absolutely no idea why they want to implement it.
Amen! After all the architects at our place advised against it for a number of reasons, um, hey this month the new SP site should be ready. None of us knew what drove the jump. I think at one point we needed the enterprise search to combine results from multiple sources, but then retreated from one of the data sources (for other reasons) so just about any search functionality would have been fine. We were doing CM, we had portlets down pat, we even had bi-lingual for one site. Whatever, it's just (a lot) of money that could have been spent other ways (like reversing our 5% pay cut in March, just to pick an example out of the air.)
[font="Arial"]Are you lost daddy? I asked tenderly.
Shut up he explained.[/font]
- Ring Lardner
October 29, 2009 at 7:38 am
Like Steve, it gives our organization one more DBA opportunity so, it's not all bad. I haven't drunk the kool-aid on this product but I do see potential.
I'm sure you've seen a folder with document v1, document v2, etc. That can go away with SharePoint if you can get the user community to understand versioning.
You end up with database bloat because everything is stored in the database (storage makers love that) unless you use a product like StoragePoint (I'm not a salesman for them but it's a pretty cool product and worth a look). Workflow is nice but limited (again with the extras you may want to check out BlackPoint).
For development, there's the right way, the wrong way and the SharePoint way to do things. Some folks will just "get it" and others (like me) won't. I've seen some fairly compelling demo's and have seen real world examples of standing up a quick business function. However, I haven't seen any of them scale very well.
The short answer is that MS has delivered a product that offers a lot of easy functionality without a lot of fuss. If you really want to leverage the platform you'll need consultants (so they love & sell it), hardware (server & storage makers love it), 3rd-party add-ons (so they love it) and everybody gets to make a buck -- except for the customer. They're left holding the check and wondering how a product that was supposed to make their business more efficient could cost so much, deliver so little yet look so good doing it.
--Paul Hunter
October 29, 2009 at 7:57 am
Paul Hunter (10/29/2009)
... You end up with database bloat because everything is stored in the database (storage makers love that) unless you use a product like...
The SP application is a DB application and will use it's share of storage. However the main storage requirement depends on the content (documents and other files). I don't see it increasing because its stored in a database.
October 29, 2009 at 8:30 am
Some interesting comments, and it dovetails with some of the reading I've done. Sharepoint does some nice, easy applications, but if you try to completely customize it, the last 20%, you'll get buried. Also, it appears that it's not for everyone, but it's being pushed everywhere.
If someone has done some SP work and wants to write some articles for DBAs about what to look for or be worried about, we'd love to have some.
Viewing 15 posts - 16 through 30 (of 36 total)
You must be logged in to reply to this topic. Login to reply