Five and a half myths about SharePoint

The more I read discussions about SharePoint, the more I argue that the very concept of “SharePoint” carries with it a stack of myths and delusions. Some of them live in the minds of those who are thinking about the use of this platform, some (and it is the most dangerous) - for those who only recently started creating sites on SharePoint. Since the second part is more difficult to describe (and today is also Friday), being terribly lazy, I would rather talk about the first one.

So, the myths. Or delusions? Never mind. I describe it in the order that came to my head, and not because some myth is “more terrible” than the other.

Myth 1. SharePoint is actually designed on another planet and transferred by Microsoft humanoids from a single UFO to break the brain of humans.

Sometimes it seems to me that this is true ;-)

')

Myth 2. SharePoint is expensive.

About it already wrote on Habré. If you use the free one in the framework of the promotional company Windows Web Server 2008 along with the free Windows SharePoint Services and the Windows Internal Database (or SQL Server Express), then the cost of server software becomes almost zero. The limitations inherent in such configurations fit well into the needs of small projects. You just need to adequately assess the requirements at the initial stage and the prerequisites for growth. SharePoint is also good for allowing you to grow painlessly, both in the direction of the solution scale and in terms of the features used.

It is quite logical that as the project grows (and its monetization, as they say), there is a need to use and an adequate configuration. Here, of course, software costs increase, as do all other expenses: servers, channel rental and, finally, staff . It is the last item of expenditure that is the most tangible, but it is often considered separately. This is excusable for small start-up teams, but when serious experienced companies do not include in the project budget the salary costs of people who are called to develop and then support it, it is surprising.

I am convinced that the advantages of the platform and its supporting development tools, including the now free SharePoint Designer (for quick fixes), justify the price of such software. The same goes for SharePoint Server (MOSS). The latter is far from free and in the version for Internet sites it is worth it, but I will repeat it once again: stop maximalism in choosing the configuration and evaluate the whole project in terms of real needs and income. It is ridiculous to hear about the high cost of the Internet-license MOSS from the mouth of a person earning several thousand dollars a day on the site. Again, if you plan to create a community site with an income that barely covers costs and hosting, you first need to think about what SharePoint can give in its minimum configuration.

As a summary of the "myth", the voice seems to be an obvious thought. In projects of any size, start by thinking about what the most basic SharePoint features will give you. The opportunity to save on the development of storage systems, authorization, site infrastructure management and layout templates, integration with Office applications and built-in tools for content deployment is already a lot.

Myth 3. SharePoint is slow and demanding on hardware.

This is my favorite myth. And it arose from the strange misunderstanding of many people of the fact that even an easy-to-install and initial setup product requires the knowledge and application of a number of rules that allow it to be used in certain conditions. Yes, of course the platform has a certain overhead in terms of resources - the “universality” embedded in it never passes for nothing. But ultimately it can be said that in terms of the requirements of SharePoint, it is no more difficult than a typical ASP.NET application that stores content in SQL Server. And there are so many in the world. And they are loaded - hoo th! It’s just that in the case of such projects it doesn’t occur to anyone to simply deploy a solution - and let them work as they are. But after all, SharePoint is also not a magician, in order to guess in what conditions it works. He, meanwhile, allows you to do a lot through a convenient web interface, which, however, does not cancel picking in the configs. Swearing once again at slowing down SharePoint, remember the following keywords:

· Load balancing

· Ouput Cache

· BLOB-cache

· Object cache

For interested links: technet.microsoft.com/en-us/library/cc298466.aspx and " Accelerate Sharepoint to the speed of Highload Internet site ." ASP.NET Bison, pay attention to the last section in the post MissUFO (IHttpModule and hard optimization). With a neat approach and a responsible attitude with the help of this technique, you can make pages of racing cars really out of the pages.

Finishing this topic, I will tell about my first impressions after buying a car. Hardly sat behind the wheel, I realized that the car terribly restricts freedom of movement. Now I have to plan and study where turns are allowed, where traffic jams are more often, how to drive around and how not to get on a one-way street while moving in the opposite direction. And also gasoline, worries about the "washes", tire pressure. Motorists are familiar, aren't you? It's been a few months. Discontent diminished, I began to understand their advantages. A few years later, I can say that the car gives freedom of movement and pleasure from it. On foot - excellent, environmentally friendly and inexpensive. But slowly. It is possible on a motorcycle. But imho - not safe, and temperament is not suitable :-)

Myth 4. SharePoint - only for large companies and corporate sites.

Microsoft itself is to blame for this myth. Partly due to the fact that all the “heavy” features of SharePoint are more focused on corporate portals. Partly because of the marketing effort involved.

Indeed, there are not that many ready-made scripts and templates that can be used in the development of classic Internet portals or the social networking sites that are so fashionable today. But are there many portal platforms that offer this? Meanwhile, according to rumors, Microsoft realized the gaps in this direction and is actively working on the inclusion of appropriate features in the next versions.

This myth stems from the conviction of many customers of the type: “SharePoint must surely have templates for all occasions. Make me a website for a couple of days! I heard that with SharePoint this is a time to spit. ” Funny Rather sad.

Finally, my experience (probably yours is also) shows that the notion of a “ready-made template from Microsoft” is poorly applicable for serious Internet sites. Begin to develop your solutions in this direction - make your templates. And here we smoothly proceed to the next myth.

Myth 5. To create a site on SharePoint do not need web developers and designers.

The answer is short: not true, we need it and how! In the comments to one of the posts I read that Microsoft is short-sightedly ignoring designers in the design of SharePoint pages. Well, it is not true! Nothing prevents you from using your design. Layout of standard elements interferes - redefine it. Table layout on the master pages interferes - use your own. Trouble in SharePoint on expectations from it. Meanwhile, no technology in any serious web project cancels the need for good designers and web developers.

One thing I will say for sure. SharePoint must be understood by all team members. It allows a lot, but requires respect for some of its expectations from your design. And these expectations are most often dictated by security issues (oddly enough) and support for the entire rich functionality of the platform.

But in general, SharePoint, as I already said, is an ASP.NET application with its features and tricks.

Myth 5.5. SharePoint restricts creative freedom, and the imposed features often only complicate life.

This is a continuation of the previous myth, but we are talking about programmer misconceptions.

Often, developers (especially Russian) blame SharePoint for the strange features of the work of some subsystems. Take for example two - storing list items and the Business Data Catalog.

The lists are puzzled by the fact that they do not behave as tables in the database. Queries are more or less complex and do not support referential integrity. The answer is simple: lists are not databases. If you want to use SharePoint as a frontend to the database, then use it that way. There are simple rules for lists and document libraries:

1. Document libraries store files that users work with, as with documents . It seems to be simple, yes? But italics are often forgotten and plan to store, for example, distribution kits. Moving away from the “file balloon” is a good idea, but everyone needs common sense. A separate storage class is aspx page files. With them, questions usually do not arise.

2. The lists contain information related to the structures of the collective work of users, the direct publication of information (articles, news, etc.) and file metadata (from the first rule). Nothing else needs to be stored in lists. The rule can be broken if there is little data, but on large volumes you will quickly feel dips in performance and difficulty with data requests.

The second example is the Business Data Catalog. It seems to be a good idea to abstract data sources and link them to existing structures stored in SharePoint. But developers complain: a very complex description format. The answer is simple and is based on the idea behind the BDC. A complex XML-like description format is designed to solve two problems simultaneously:

1. Be flexible enough to describe all the necessary entities and operations, allowing SharePoint applications not to operate directly with data in the database.

2. Have a readable format that allows reading and editing without special software.

For some, not very convincing, but I will try to clarify. Initially it is implied that such a data source profile is created once by the developer of the original information system in order to provide access to it by SharePoint Server. This was pretty quickly done for systems like SAP, Siebel, or Amazon services. Also, the description format allows, among other things, also to specify objects in such a way that you can search for entities from your data source without developing specialized components.

When I think about this myth, an analogy with a car comes to my head again.

And tell me about your "Pasternak did not read, but condemn." Impressions of experienced people are all the more welcome. Good ideas, as you know, do not occur in the head, but “between the heads”.