I'm trying to figure out the best way to set up our extranet site which is used to communicate with the various organizations we contract with. We partner with about 30 different organizations on a contract basis, and all the contracts, documentation, payment requests, etc. are uploaded by these organizations to our SharePoint extranet site. Here's the basic rundown of the setup we currently have:
One Document Library per organization. This means we have roughly 30 separate libraries. We've discussed the option of just using one library for everything, but there does seem to be a benefit in having the work we do split this way.
We have one List we use as sort of a master contract tracking tool. Each list item is one contract. This is helpful in keeping things organized, but each individual contract can have a large list of requirements in itself. I've been experimenting with InfoPath in creating custom form views that include project checklists within that single item, but haven't yet learned how that tool might help me tie it all together.
I need to learn how to fully capitalize on SharePoint 2010 in order to tie together the documents that 3rd party organizations upload into their separate document libraries into a project list that will track progress as efficiently as possible.
Any advice would be helpful! Thanks!
Related
We're starting to use SharePoint 2013 to manage our department's process documentation and I have some questions about best practices for site structure. I'm a little surprised I can't find the answers via web search, since this seems like a basic question every new SharePoint user must deal with.
Moving from a file share environment, I'm trying hard to get out of that mindset and I understand the many benefits of SharePoint over file shares. I also understand why creating folders in SharePoint forces arbitrary divisions on files whereas one large set of documents with metadata lets you filter and group the files based on different needs.
What's confusing me is that I also read that it's better to have too many sub-sites than not enough. It seems like sub-sites can easily become pseudo-folders and I'm not sure where that line is crossed.
Here's an example.
We have a SharePoint site devoted to our department. We've create a sub-site dedicated to an application we developed to load data into our business systems. It mainly holds technical documentation about the application. This application supports many different data sources, each with its own set of user instructions for loading, its own schedule (calendar), contact lists, supporting files, etc. There's no compelling reason to separate them to restrict access. However, there doesn't seem like a lot of value in having them all in the same sub-site, either, since someone working on a job will only want to see the docs and supporting files for that data source. I just can't foresee someone wanting to view supporting files across all data sources, although, I could see someone wanting to see the schedule for all data sources combined.
My question is, should I create separate sub-sites under the application for each data source or do I just store everything in the application sub-site and use metadata and views to group things by data source? Putting all the items for a specific data source into its own sub-site seems to be much simpler to manage and present than having to specify metadata for every new file and creating a lot of views. However, I can't shake the feeling that I'm still using file share thinking. Or maybe I'm just missing some basic concept of SharePoint.
Any advice or links to good discussions of this topic would be greatly appreciated. Thanks.
I would recommend that you use metadata and views to separate data in one repository/site.
My reasons are as below:
In SharePoint, it is recommended to use metadata than "evil"
folders(or subsites in your case). Keep in mind that maintaining
multiple subsites requires big administrative efforts in long term,
for example, some sites will be inherited while others unique
permission.
As time passes by and people rotate, it becomes vague
that where the data was stored and where the new data should go to,
especially with large volume subsites.
Since confidentiality is not concerned in your case, keep data centralized and open to people working in related field increases sharing and collaborating phenomenon. In contrast, using subsites increases the possibility of data silos.
people are all lazy :). Taken me as example, I dont want to remember all those xyz URLs, I want to go to one place and be able to fetch everything that I need.
I am new to share point and still learning all the best practices, but I have a parent site called "Clients" and a sub site for the each of the clients i.e. Walmart, Kmart, Target. Is it a best practice to have a unique document library for each of the sub sites and the parent site. Or to use just one library for all of them. And if I were to use just one how would I set that up?
Thanks
Sites and Pages are not the same!!!
I wish that was more clear. In this case I want a SITE with the customers. Then each customer will have its own page. This way I can use the same apps across all the customers. I will probably need to learn how to create a customer template next.
to start with you need to answer few questions first, and these questions will help you to decide on an approach.
Do you have unique documents per client
will you control access to your users, that is each subsite will have unique permission, users for one client say for instance walmart should not access documents of Kmart
what would be tentative size of each documents and how much will that grow over the year
above are few question which will help you to get started, being said that, I will start creating a site and if the look and feel are the same for my other clients with little changes, then save the site as template.
This template will be my base for other client subsites/ sites.
will also create a global document library, which will store relavant documents which can be sharable across subsites
If required, each client will have their own subsites and own libraries for maintainabilty. this will also help to move subsite to its own site collection if there is hugh growth in data for a particular client.
You can also plan to use search, and webparts like content search query webpart to mashup data from subsites.
Another area to explore is metadata and Information architecture.
When you ask "Is it best practices" for the multiple Libraries or a single Library. From what you have described and Ramakrishnaraja was trying to say, you need to figure out what would work best for the situation. I don't know if you mean to have a different group called "customers" or if that is the same as "Clients" I'm going to respond assuming you mean both parties are the same.
Ramakrishnaraja points out that you have one central log on page "Clients- 'Main'" which leads to the other pages. If you want to the users to be divided into groups that have access only to the documents within their repective page then you should create multiple Document libraries. If you want the users to have access between the sub pages and use/edit files between the sites then best practices would be to have one Library for the Site.
I hope this helps you. Ramakrishnaraja makes a lot of good points and approaches it from a design overview rather than a specific response to your situation so try to use his post from that perspective.
I'm looking at designing some core information systems at a new company I'm working at (described one of my ideas here Workflow system)
I've thought a bit more, and am strongly considering using sharepoint for a lot of the heavy lifting seeing as it comes with so much out of the box.
However, I'm not sure how it will handle the high volume of data we'll be throwing at it. I read the MS whitepaper (http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409), and it says about 2000 items in a list is about the limit using traditional design methods.
But first a bit of info on my plan and data structures :
We have multiple clients. Each client has multiple applications. Each application will have multiple, ongoing jobs (or process runs).
Each application will store significant correspondence and documentation. Each job represents the processing of a data file on a single run, and stores information about the job such as the postscript file, postal manifests, etc.
Job volume will be about 50 - 100 a day. Each job will have a workflow, triggered by external programs. Then, say on a "job scheduler" page, production staff can schedule the jobs and perform custom actions on the job (written as plugins).
I was thinking the jobs would sit outside and accessed via the BDC, but I would still like them represented in sharepoint lists, to add in sharepoint functionality and reporting, and they'd be accessible in multiple places
e.g.
Application portal - see jobs for application
Production scheduler - see lists of upcoming jobs, assign to resources, trigger other functionality (e.g. copy print file to printer, produce mailing machine file)
Invoicing view - view completed but uninvoiced jobs, export to accounting package
Client view - client portal displays jobs, invoices, stock levels (from external warehouse system), documentation, change register / helpdesk
So basic info about the job would sit in the BDC, but then sharepoint would capture additional metadata about each job. Also, down the line we might put in more advanced workflows using WF or something like K2 blackpoint / blackpearl.
Is this feasible? Any resources you'd recommend to read to get up to speed?
To use SharePoint, you should concentrate on what SharePoint is good at and what it is designed for.
SharePoint is a great collaboration portal, it is not so good as a simple high volume database. So...
You can setup a small site for each client and subsites for each job. The goal of the "job site" is to display (using a webpart perhaps) the relevant upcoming jobs, a list of job errors/exceptions and relevant team documentation on each job.
Separate sites can be created to give a particular "view" of the jobs. E.g an "Invoicing" site can be created to give a view again from BDC webparts of what is requiring invoicing.
https://iwsolve.partners.extranet.microsoft.com/SDPS/ may provide some help.
Don't try and store huge amounts of information in a SharePoint list, just because it may be possible to "tag" it with meta data. A database table is perfectly able to include columns supplying additional information if required.
Think about it this way. If you are creating 50-100 jobs a day, putting that data into a list pre-supposes your sites users are going to want to enter metadata on those jobs manually. I thought not, so create systems you need in order to get the metadata stored correctly at source, or store metadata about the "types" of jobs within a SharePoint list and allow SharePoint to match the job type with jobs in the BDC.
SharePoint will help you to integrate all your systems information together, but unfortunately it looks like you have a lot of work to do just planning what information should go where and how each type of use will view it.
Please take a look at this blog post I wrote on managing large SharePoint lists for better performance- it might offer a bit of an explanation for the 2,000 items issue, which is not actually a hard limit on the number of items in a list, as SharePoint will support up to 5 million items per list. One way around this would be to create and maintain different views that filter by an indexed field to show you different items, up to 2,000 at a time. Hope that helps.
Dina Ayoub
Program Manager
Windows SharePoint Services
SharePoint is probably quite a good fit for the UI side of things, though you'll need to think carefully about which parts are stored and modified in SharePoint lists and which parts are stored elsewhere. That's not so much a SharePoint issue as something you always have to deal with when you have multiple data sources.
I'd probably use a SharePoint list as the primary store for jobs, to avoid any sync issues and make editing easier. The volume of data shouldn't be an issue - just make sure you aren't trying to display 2000 items at once - it's the view, not the list itself that runs into performance issues on large numbers of items.
Tough question Dane... I would like to know a little more about your design / vision before giving an opinion.
Based on what I read in your question I would not use SharePoint 2007 as a development platform for this application.
1) Development experience in SharePoint 2007 can be painful and unproductive at times.
Hard to debug
Steep learning curve
2) Easy to get in trouble with performance
Data Layer is complex and can require expert SQL / SharePoint Admin skills to make platform scale.
Content databases should not exceed 100 GB.
3) Deployment can be extremely difficult depending on what you are doing.
4) New version will be released in the next 12 months.
Just my .02.
My workplace will be starting to use Sharepoint internally during the coming months. I'm pretty excited about the possibilities of having more structured data on our intranet. A key part of this is allowing related data to be spread across the site hierarchy.
I'm currently experimenting with a list of Committee Members, with the idea that somewhere on the site you could see a list of everyone on every committee. Then in other parts of the site, you only want to see members of a single committee. From the various articles and blog posts I've been reading, it seems like there are three accepting ways to approach this:
Roll Up - Subsites have their own lists (optionally from a list template). Content types are used so the instances can be collected into a Data View Web Part on the parent site.
Pull Down - A master list is defined in the parent and each subsite contains a view of that list, filtered
Purchase or create a custom rollup webpart.
What are your experiences in different situations? What are the tradeoffs of these techniques and are there other (good) ways I've missed?
BTW, the committee members example is what I'm currently experimenting with to try out different possibilities. I'm more interested in the general tradeoffs, not necessarily specific to this example.
Having done this a number of times on different sites, for your situation, I recommend:
1.Roll Up - Subsites have their own lists (optionally from a list
template). Content types are used so
the instances can be collected into a
Data View Web Part on the parent site.
This gives more flexibility, not only can other sites in your site collection get this information, you can use the search query webpart to roll up the information in other site collections (the CQWP and DVWP do not work across site collections).
The only time I have used a Pull Down model is when there logically is only one list that I site collection will go to. Such lists for us have always been functional in nature, e.g. A list of content query definitions for a some custom functionality or a list of customers that ALL sites rely on and is used to populate an installed custom field control.
I would say that both will work equally well but the advantages of one over the other really come down to whats more convinent for how you'll have your intranet site collection structured.
You might also want to consider using the Content Query Web Part (CQWP) in combination with a complimentar site collection structure so that you can surface the committee member data.
With a little customization, the CQWP can do some amazing things - and it has been fully optimized under the hood by the product group team for managing all kinds of queries. It's easy to configure and use, and there are plenty of examples on how to use them on the web.
At our company we are currenty trying to define the basic things our software architects have to know about SharePoint for them to architect and/or lead a SharePoint implementation project. Many architects in our company have a .NET developer background and know a lot about .NET development and the various framework components and tooling. However, they currently lack SharePoint knowledge. In fact they don't even want to know the nitty gritty details. They want to know just enough about it to make the right architectural decisions and apply proven patterns. If more specific knowledge is required they'll ask a SharePoint expert.
So What would is the basic set of SharePoint knowledge / skills that an architect would need to have?
Skills such as list, documents, workflow, permissions... are a bit too basic and are requirement for a SharePoint DEVELOPER.
I'd argue that perhaps site (and site structure) is an area that would fall under the architect's plate.
There are more areas that a SharePoint architect can help with:
Capacity planning - running multiple servers in a farm. Scalability and other magic words.
Knowing the capabilities and business scenarios of using SharePoint - this is a very common one.
The manager asks: what can SharePoint do for me?
The developer asks: well, what do you want it to do.
The manager then asks: well, I don't know what it can do for me so how do I know what do I want it to do?
Closely related to SharePoint capabilities are the various licensing costs related to each component.
As well as familiarity with development and customization costs. Take the same project time that would have taken in ASP.NET, then multiply it by a large coefficient, and then add an additional constant.
And closely related to what-can-it-do, and how-much-does-it-cost, is the all important question of Return-Of-Investment. All hail supreme ROI!
SharePoint deployment can be a massive issue and a lot of pain.
SharePoint upgrade from v2 (MOSS 2003) to v3 (MOSS 2007). We should be seeing a new version of SharePoint in 2010(?). Well soon after the next version of Office goes out the door. So past upgrade experiences may be useful.
Knowledge of 3rd party webparts. I believe a SharePoint architect should be able to give you at least 5 webparts that they've tried from CodePlex and tell you what they think about them. These are free and easy to grab and play at your own leisure.
Some knowledge of commercial webparts. Because they are still cheaper than writing your own.
Have at least 5 SharePoint blogs that they follow religiously (know the community). If not having their own SharePoint blog (give back to the community).
If they are on StackOverflow they must try to answer SharePoint questions (such as this one).
Attend local SharePoint usergroups. I think communities are a huge deal. Especially what you'd learn from talking with people directly and learning what they are doing with their SharePoint installation. You may just surprise yourself.
Experiences with SharePoint Integration - this comes in two equally important flavours - both from SharePoint accessing existing systems (business catalogs, webparts, etc), as well as other systems accessing SharePoint content via webservice or API.
In addition, SharePoint works with (or works well) with Office, OCS, reporting services, performance point, project server.
SharePoint hosting arrangements - Microsoft SharePoint online services can be a popular and cheaper option to start using SharePoint. It can be hosted inhouse, or with a 3rd party company. Knowing the options is always useful.
Must have read SharePoint code using reflector (and preferably still having hair).
I think it takes at least a couple of years to be a SharePoint architect (your mileage may differ). Your .NET architects need to want-to-be a SharePoint architect, otherwise I agree with other's summaries before me - find someone who already is a SharePoint architect.
An architect should have quite a good understanding of our a product works, from a functional and technical viewpoint.
So in my opinion, an architect should:
Have been involved in at least 2 Sharepoint deployments, from design to roll-out.
Have knowledge of our the major sharepoint components can be used using the API.
i.e. Sites, Lists, Documents & Workflow components.
As none of your architects have this knowledge, I would pair them with a Sharepoint expert in an existing Sharepoint project, so they get the knowledge they need.
Ideally SharePoint Architect Skills fall into the below mentioned categories
Infrastructure Level/Operational
Capacity Planning
Physical Architecture (Farm Setup, Network, OS, Licensing)
Application level (Functional and Non-Functional)\
Requirement and Feasibility Analysis (Custom Vs OOTB Development/Implementation)
Techno-functional Mapping of requirements
Information Architecture
Logical Architecture
Conceptual Architecture
Detailed Design
Database design (not in terms of traditional Database design), this is with respect to Number of content Databases for Site collections/web apps.
Deployment
Best way to go for deployment, first time and incremental
Some other activities that an architect will collaboratively work is the Project Manager in Planning, Estimation, Execution/Implementation, Risk Management (assessment, mitigation).
Apart from his daily tasks of working with technical teams, testers, User Interface professionals, Vendors, Clients (Business and IT teams).
Interacting with Enterprise Architect groups if any.
In my not so humble opinion I think the entire "Sharepoint Architect"/"Expert" thing is over-played.
Sharepoint is a tool to centralize an organizations digital resources for centralized collaboration or working together in a centralized way.
The best explanation of What Microsoft Sharepoint is and does
from the WROX book "Beginning Sharepoint 2010 - Building Business Solutions"
"Because computers play such an integral part in any business, not surprisingly, more and more
of the information that is created, consumed, and shared in an organization is digital. The more
business that you conduct and the more successful your business becomes, the more information you
have to manage. Usually, you have some form of document for just about every process and transaction
that plays out during the day-to-day operations of your company. From proposals to legal
documents, from sales receipts to human resources policies, the amount of information required for
a company to function is staggering.
To manage your information overload, SharePoint offers tools with which you can build business
applications to better store, share, and manage digital information. With it, you can create lists,
libraries, and websites for your various company teams to help run your business processes more
efficiently. By locating your organization’s important business data in a single location, it becomes
much easier and intuitive for users to find the right information when they need it rather than
searching through disparate locations such as email, computer hard drives, or file shares.
WHAT IS SHAREPOINT 2010?
SharePoint 2010 is an extensible and scalable web-based platform consisting of tools and technologies
that support the collaboration and sharing of information within teams, throughout the enterprise and
on the web. The total package is a platform on which you can build business applications to help you
better store, share, and manage digital information within your organization. Because you can build
with or without code, the package empowers the average business user to create, deploy, and manage
team websites, without depending on skilled resources, such as systems administrators or developers.
Using lists, libraries, and web parts, you can transform team websites into business applications built specifically around making your organization’s business processes more efficient."
Creating a schema for an organizations Sharepoint deployment is not rocket science. 1. Determine the structure of the organization 2. Determine what Sharepoint can do as far as centralizing the organizations digital resources. 3. Create a Sharepoint construction plan. 4. Build it, test it, refine it. 5. Maintain it, test it, refine it, add onto it. There! Not so tough.
Sharepoint can be a nasty beast to work with if you don't know the ins and outs of it (they should be experts with it to architect it). At a minimum, they should know how lists, sites, and permissions work. Ideally they should also know how all the web parts fit together on pages and how they are supposed to interact. Really if the architects don't want to learn about sharepoint, they are going to create a .net web application and force it to run on sharepoint. It won't really follow the paradigm of how a sharepoint app is supposed to work.
I would look at a company called Mind Sharp for guidence as to what they should learn.
My advice is look for a doer that doesn't just reads PowerPoint to much in the Sharepoint world is just based on what other people have said.
We have been having issues with crawling 500000 items in a Sharepoint farm and everyone gives another story how to get better speed... Normally people refer to not more than 2000 items in a folder, but that does not change the crawl speed....
So a good architecture is someone who is able to do POC proof of concepts himself of his design and not just refers to some vague stories.....
I have seen to many Sharepoint Architects that hasn't had experience from real life....