I chatted with a friend yesterday about Sharepoint.
My friend is the project director of a medium-sized software company. He has a good technical foundation (both Java and. net) and has certain business capabilities. However, he hated SharePoint for the following reasons:
- SharePoint features are limited. Compared with self-developed systems, many functions of SharePoint cannot be implemented, especially the personalized requirements of customers.
- SharePoint development is difficult. To develop personalized solutions based on SharePoint, you must first understand the architecture and interfaces of SharePoint, which are difficult to learn and difficult to develop and debug.
- SharePoint talents are hard to retain. There will be technical talent in Sharepoint, the ratio of job-hopping is too high, the temptation outside is big, can't stay.
- SharePoint-based applications are bound by Microsoft and the software company's own market is squeezed. It is better to develop its own application framework.
Different people are located in different locations and different problems are seen.
If you are looking at the problem from the perspective of a technician, then the 3rd point mentioned by a friend is not a problem at all. On the contrary, it is a chance: if the salary for Sharepoint is higher, isn't learning SharePoint right? haha!
I don't want to refute his opinion, because it makes sense to stand in his position. However, I am also throwing out my point of view for his reference and other people, which can improve understanding of things.
- SharePoint features are limited. I agree. Only one user's access authorization is complicated and imperfect.
So we need Sharepoint to do what it can do. Sales People may exaggerate the effect of SharePoint, but we should not lie to them, instead, give our views closer to facts.
- SharePoint development is difficult. It depends on your development method.
If you want to develop SharePoint for a computer with less than 6 GB memory, it is really difficult!
If you do not use SharePoint's own object model and storage mechanism and use application page to write another one, it is really difficult!
If you do not use events, feature, and other functions to help you achieve automatic deployment and event processing, it is really difficult!
The most important thing is that you are fooled by sales and think that Sharepoint is omnipotent. Then you can develop functions that are not available at all... Wait for the day and night to work overtime!
- SharePoint talents are hard to retain.
As I said just now, this is a good thing for Sharepoint talents.
What about software companies?
Can you think like this: why do SharePoint talents have a high salary? My opinion is from supply and demand: SharePoint projects have high profits and few talents. Sharepoint is a large-scale customer, and the project amount is certainly not low, while Sharepoint is a product. Many out-of-the-box functions reduce the project implementation cost, therefore, the profit is generally high; on the other hand, there are few talents, because it is necessary to find out too many things SharePoint needs to know, what ad domain, DNS, SSO, IIS, SQL Server ,. net, HTML, CSS, and Web Service. In addition, it requires you to jump out of the programmer's perspective and think about problems from the perspective of IT architecture, O & M, and business personnel (for example, application, site collection, web site, managed path, how to plan authentication, and so on ).
In this case, CAN software companies consider turning to the SharePoint market rather than resisting it? This is of course not easy, but it is an idea for your reference. Think about it. If you deploy and configure Sharepoint to make money, why do you have to develop it on your own?
- Develop your own application framework. Of course, the technical framework is a meal guy from a software company. You can control it on your own.
However, there is competition between frameworks. In the case of high salaries for Sharepoint technicians, it is worth considering how to keep talent on its own framework.
Moreover, Sharepoint is not just a framework, but can be used directly. This is different from spring, Ruby on Rails, Django, ASP. net mvc. It is not easy for the company to implement the SharePoint framework and ensure its security and stability.
In addition, it is no less difficult to retain core framework R & D technicians than SharePoint technicians.
- Think about it for the customer.
Suppose you want to buy a car. Two manufacturers recommend their car to you. One warehouse contains all parts, then sells them to you with several design drawings, and makes sure that once you choose them, they can quickly assemble a car with these parts. Another manufacturer, I want to show you how many models they have already completed. You can even test drive, but it is not suitable for no interior and sound, and the seat height. However, they promise that you can install it later, but there is little room for changes to the entire vehicle. How do you choose? Different people may have different choices at different stages. But I think the latter is a trend.
The first is a software company that engages in its own technical components, and the second is a software company based on existing product platforms (such as SharePoint.
I am not doing SharePoint ads here! I mean, since the software industry has evolved to the present, if you don't have a few platforms to develop your own crud, it will be difficult to mix them up. Whether the platform is SharePoint or anything else, you must have one. This is my intention. The emergence of SharePoint provides us with research and learning opportunities, right? You can reject it, but study it first :)
After reading comments, let me add a few more points:
1. There is another infopath. Don't forget it. This tool can help overcome many of SharePoint's own shortcomings.
2. Analyze the business first. Whatever the customer says, no matter what technology you use, it is a "Dead End ". Although I may not be able to do it, try to fight for it.
3. It seems that foreign companies have a higher degree of acceptance of SharePoint. You can allow them to manually manage user groups and configure simple approval processes. Domestic Projects ~
After seeing the comment, add:
1. This is what I think is the "ultimate" learning material. Using Sharepoint, if you can figure out these images, it's almost the same:
Http://technet.microsoft.com/en-us/library/cc263199.aspx
2. The position of SharePoint in the entire software process:
It is the practice of many software companies that I have seen that it is difficult for developers to develop applications at the same time; using SharePoint (or sap, self-developed platform, etc.) is equivalent to doing application Consulting, which is closer to users and has higher value-added.
Further Supplement:
In fact, it projects have requirements on whether the organizational structure and management functions are in place. Just like an airplane, the airline doesn't just buy the plane from the manufacturer. It also needs to be equipped with crew, flight plans, maintenance personnel and parts. Cannot someone who creates an airplane Help You With repairs?
In this regard, the BizTalk document has inspired me a lot. It tells you at the beginning of this article: To Play BizTalk, you must first have roles in place. Refer:
Http://msdn.microsoft.com/en-us/library/cc296799%28v=bts.10%29.aspx
