Sharepoint Growth is Good

  • Comments posted to this topic are about the item Sharepoint Growth is Good

  • I think like their CRM product, clever sales people impress manangement with pretty reports & graphs.

    But the business requirements are often more complex than what the application can handle "out of the box". Bring in the consultants & developers to customize. Then employ staff to manage the cleanliness of the data etc.

    From what I've seen the end user needs to be trained well to use the application in an efficient manner - Without that, it's just another white elephant.

    Maybe the licensing is reasonable, but there are other costs that shoots up the TCO.

    On a positive note, if deployed properly, Sharepoint can be beneficial (I just haven't seen it :-))

  • Ah, Sharepoint.

    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

    ...I know quite a few people that see it as a great source of revenue for their consulting businesses...

    That's because it's so badly put together. There are such gaping holes that almost any business implementing it will find something missing that they thought should be in as standard, so will need some development to address this.

    I hate Sharepoint with a passion. I know it uses SQL Server, and that this increases my usefulness to the business, but its quirks, omissions and bugs are so numerous that it eats up colleagues' time - time that has to be paid for, and could otherwise have been spent on development that might actually be of real use.

    You might have noticed; I'm not a fan....

    Semper in excretia, suus solum profundum variat

  • Hmmm... I'm doing a global Sharepoint roll out at the moment.

    I have to say from a technical point of view it is a pig of a product, not least because there are so many interdependancies between Sharepoint, SQL and IIS, and the front end is flaky at best when it comes to setting this up. I haven't found any decent documentation for it which explains all this so fixing the inevitable problems is a complete pain in the backside and a bit "press this and see what happens".

    The Microsoft training is close to useless, it tells you how to do stuff but not why you're doing it or how it works, so the main problem is working out what the hell you're supposed to be doing in terms of what the users sees, we used a consultancy for the main "webby" bit and now have a template for each roll out.

    My main problem with the users is convincing them that the rather slow MOSS server is a better place to put their documents than a shared network drive, also every document they put up has to be approved before anyone can see it regardless of whether they are a document approver or not, which is stupid (and it can't be done in bulk). The only solution I've found so far is to get them to upload all their stuff then delete it from the shared drive.

    One big win, however, is global collaboration and project work, here it is the best solution we have by a long way. I'm also seeing a lot more interest in terms of documents which need to be published to the whole company - it is a nice, easy, secure front end for our shop floor guys to look at stuff like risk assessments, ISO documents and company policies etc (as well as providing version control for it).

    I am at the moment playing with K2, the workflow tool - this looks promising, with our export business expanding we're getting shipments held up at customs all the time because of incorrect documentation, so modelling the customs requirements of each country would seem like a win - in this regard I see it more as a rapid application development tool than an intranet tool, but more for stuff you wouldn't normally bother building an app to control.

    One last area I'm examining is as a sort of lightweight global datawarehouse - I'm playing with the concept of uploading an Excel doc to a website which then populates a database (kind of like Misalea) - looks promising but (again) a bit flaky.

  • I agree with Lian Pretorius about the Sales wow factor. I built 2 public facing sites on it and hated it for a long time, but after about a year it seemed to look after itself. Workflow is nice and the fact that the built in search will index word documents. Though the effort in bending it to do what you want rather than what comes out of the box makes you think (regularly) - if it doesn't do what you want, haven't you bought the wrong thing in the first place?

  • It uses SQL Server, which means every Sharepoint sale not only increases the need for a DBA, but also provides lots of opportunities for report development and custom application development, all helping to grow the SQL Server market share.

    That's like saying, "Crappy cars create opportunities for mechanics." or "Arson helps employ firefighters." 😛

  • But crappy cars do create opportunity for mechanics. Whether that's good or not is another story.

    I can't tell if it's that crappy, or it's just a little shoddy. There are plenty of people that like it. It might be mis-used, or mis-applied, which is partially a user fault.

    I didn't realize it was a $1b business for MS. My guess is it's not going anywhere at that scale.

  • I'm with the haters... For the short time I was part of a team that supported Sharepoint it was nothing less than a constant pain in the arse. The company had absolutely no idea how to utilize the product yet we spent many long days and nights on the phone with Microsoft support to patch it, fix it and keep it running. The mindless IT director who kept driving the project to roll out Sharepoint couldn't even tell us why the company purchased it or how the company was going to use it, yet he kept plowing forward blindly.

    I do not recall the version we supported but it had 7 SQL Server databases in the background. I never found out whether it's true or not but someone told me the reason behind the 7 databases is Sharepoint was not developed as one product, rather there were 7 different teams working on 7 different components for the product and each component had its' own database. Can anyone support or shoot down this theory?

  • Steve Jones - Editor (10/28/2009)


    But crappy cars do create opportunity for mechanics. Whether that's good or not is another story.

    [raises hand]

    Disagree, M'Lud

    Those cars will create a small blip in short term repair requirements, but ultimately consumers will shun the shoddy products. This will result in an overall reduction of opportunities for mechanics with those skills. There will also be a small proportion of potential consumers who will question the need for a car at all, thereby reducing mechanics opportunities across the board.

    [/raises hand]

    Semper in excretia, suus solum profundum variat

  • Nah, if Microsoft are getting a billion in revenue out of it you can bet they're working on making it less of a pig. I reckon we're not at version 3.0 yet. What it does well, it does well. Whether the adoption rates will shrink when business can't achieve the levels of user adoption they need to justify the spend is another thing. Having said that I thought the same thing about Dynamics Nav, and version 6.0 is far buggier than 3.6.....

    Of course us mechanics who know all about the metaphorical chokes and carbureters will find ourselves a lot less well paid when any 17 year old can plug a diagnostic computer into the engine, read an error code and replace whatever part it corresponds to.

  • Grumpy DBA (10/28/2009)


    I never found out whether it's true or not but someone told me the reason behind the 7 databases is Sharepoint was not developed as one product, rather there were 7 different teams working on 7 different components for the product and each component had its' own database. Can anyone support or shoot down this theory?

    Funnily enough, it was only when the different constituents were put together that it became a mess; each of the component products worked well independently, and I'm sure you've heard of several of them

    Etch a Sketch

    Alphabet Desk

    Scrabble

    Buckaroo

    Pacman

    Pin the tail on the donkey (admittedly an acquisition of an already successful product)

    and, of course....

    ...Monopoly

    ;-):-P

    Disclaimer - please do not assume any degree of seriousness on the part of the poster....

    Semper in excretia, suus solum profundum variat

  • Do you mind? I'm spending a lot of my time on this half baked product and I'd thank you to take it a little more seriously. If you were at all professional then prior to making disrespectful comments you'd at least have read into the problem deeply enough to be aware that the etch a sketch had been deprecated in version 1.7.

  • :-D:-D:-D

    Semper in excretia, suus solum profundum variat

  • deprecated? deprecated? I keep seeing more of them all the time. Even one for the iPhone!

    http://www.macworld.com/article/134425/2008/07/etchasketch.html

  • One advantage that isn't mentioned is the "Web parts" (including dashboards). Of course they're not much use to a DBA who doesn't care as much about the front end (myself included), but Web Parts are configurable by the end user and like mini-web pages themselves that can "talk" to each other. (Change one variable and the other web parts can accommodate via parameters passed to them.) There may be another way to accomplish the same thing - I'm not sure though.

    What I -am- frustrated with is how many hoops you have to jump through to simply get data out of a Sharepoint list (with SQL Server). Yes, you can simply query the Sharepoint system tables, but we're not supposed to do that. So we have to go to the front-end (sort-of) to get data from the back end - which is where we started from in the first place! That's convoluted.

    The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking

Viewing 15 posts - 1 through 15 (of 36 total)

You must be logged in to reply to this topic. Login to reply