SharePoint 2007 Enterprise versus Standard Edition

I was talking to a Technical Decision Maker at a customer of mine, and we were talking about the differences in SharePoint 2007 Enterprise versus Standard Edition.  The customer already owned and deployed SharePoint 2007 Standard for their Intranet, so this summary below is what I sent to them as my interpretation of the differences. 

SharePoint Enterprise provides 3 main features over SharePoint Standard. 

1) Web Forms and Workflows (Form Services – Ian’s Summary)

Microsoft Office contains an application called InfoPath.  This is the Office tool to allow for both the creation and filling of forms.  In the same way Excel is to spreadsheets, Word is to Documents, InfoPath is to Forms.  Any user with InfoPath may create a smart interactive form for their own use – such as Invitation to Team Christmas Party, Surveys, T-Shirt order form, Marketing Bill of Materials Order and gives the ability share/email that form in a similar way to a word document.  A user simply opens the form in InfoPath, fills it in electronically and saves/submits/emails the form back.  It is a fantastic tool for broad paper form replacement.

Equally, InfoPath has the ability to include very complex logic, data connections, etc to automate your most structured and business centric forms processes.  For example the Expense form, Leave Request, Travel Approval, Access Request forms that integrate to your systems can be achieved and developed.  In fact – developers actually like creating complex forms because InfoPath integrates with Visual Studio and allows those people with developer skills to write managed .NET code in the form logic (not just JavaScript like some other common form design technologies)

Because the forms (.xsn files) are treated like other Office document files, SharePoint is a natural tool to manage the form versions, permissions, auditing, and the workflow processing of the form.  SharePoint acts as the Form Management tool.

InfoPath, however, has a legacy of being an Office Application.  Historically, to interact with a form to fill it in you need to have InfoPath installed – just like you require Office Word to view a Word document.  Some organisations may not have InfoPath deployed to the desktop yet, or want to have forms public facing.  In this case – the requirement is to be able to fill in the form, submit it into a workflow and process the approvals without a dependency on the InfoPath client.

SharePoint Enterprise includes InfoPath Form Services.  These form services render the InfoPath .xsn form file into a web browser without the need to have the InfoPath client.  The web version of the form provides a very rich experience for the user – maintaining dynamic growing of the form as conditional sections are filled, data connections remain, logic, calculations and validations still are enforced to ensure data is accurate.

The combination of Office InfoPath and SharePoint Enterprise including InfoPath Form Services provides customers with a single, Office based form process management environment for all forms.  The benefits of this are:

i) As new form processes are proposed to be automated, there is simplicity in what tool to use and no decision or procurement for each project

ii) Internal Skill sets are developed and the creation of Office based forms becomes a standard business activity (like creating spreadsheets)

iii) The design environment caters for the average business user, all the way up to Developers who prefer to write managed code for the logic of forms.

iv) The forms can easily be embedded in other web sites and applications.

v) SharePoint is used to manage the form templates and also the submitted forms.  This allows customers to leverage the significant investments already made in SharePoint infrastructure, Administration skills, and end user training and skills.  If you already have skilled people in the use of SharePoint for document management – the InfoPath form is simply another document type in this model.  Because it is part of Office, there should be high adoption of InfoPath forms solution if it is made available.

A classic example of how InfoPath and SharePoint Enterprise is used to create a consistent forms platform is ports company DP World based in Sydney.  Their public case study is found at https://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000002583.

2) Business Intelligence and Reports (Excel Services – Ian’s Summary)

In a similar manner to InfoPath Form Services, SharePoint Enterprise includes Excel Services.  This allows an Excel Spreadsheet that is saved in SharePoint to be viewed in a Web Browser, while still maintaining rich views, charts, pivot tables, filters, sorting and conditional formatting.

The usefulness of Excel Spreadsheets in a browser is many fold.  Consider these advantages over a normal Excel Spreadsheet .xls or .xlsx file.

i) If the spreadsheet is large in size, to be able to view the data the spreadsheet does not need to be emailed or downloaded to somebody’s PC to simply view it.  Looking at this spreadsheet in the browser is a lightweight and fast Web version of that spreadsheet.  This alone can save storage space in File Shares, Hard Drives and Email storage by not emailing large spreadsheets around or downloading.   My team at Microsoft has a large 51MB Excel spreadsheet and viewing it in a Browser is much easier than downloading that document each time we want to view it.

ii) The data in an Excel Services spreadsheet is protected, and can’t be altered by those who don’t have permission.  Because end users only have access to a view of the file, it may be that some tabs of the spreadsheet are not even published.  Additionally – there is a single point of truth for the spreadsheet in SharePoint.  If a spreadsheet is emailed around – somebody may have changed the data, or filtered on something which could change the intent of the data.  Decisions could then be made on incorrect data.  Consider Gray Knowlton, an Office Product Manager, who was monitoring the download volume of a specific component of Office from the Microsoft.com website.  The volume of this download was very important to some people – including the top executives of Microsoft who were making strategic decisions based on it.  Gray decided to publish the download volume data in an Excel Services spreadsheet.  In this way – executives could look at the data whenever they wanted, could not inadvertently change it, and be confident that the data was correct because only Gray was able to publish and edit that data.  From a Risk and Compliance point of view – Excel Services can assist with hardening the decision making confidence of your company.

iii) Some spreadsheets have significantly complex calculations and models built in.  I’ve seen spreadsheets that take 30 minutes to recalculate on a PC – which ties up the PC and person for 30 minutes while it runs.  Consider if the processing was happening on a powerful Server.  The time would be reduced significantly and the load would be on a server and not a PC.  This would be particularly important for any users that model financial situations in Excel for planning and analysis purposes – your finance team or treasury would find this useful.

iv) Finally, when a Spreadsheet is published into Excel Services – all the calculations can be accessed as a Web Service call.  This means that other applications and web services can call that calculation.  This allows somebody at your organisation to maintain the logic and financial models in a spreadsheet, and simply save it to SharePoint.  Traditionally – the model would need to be documented and interpreted by a developer to convert to Java or .NET code – leading to longer deployment and maintenance complexities to involve a developer every time the model changed.  In this model, whoever owns the model can actually change it in the spreadsheet –publish it to SharePoint and have the online calculations in a web application updated automatically.

A fantastic example of this ability to manage the logic of web applications in a spreadsheet is South East Water who run the Water Savings Calculator in an Excel Services Spreadsheet.  Check it out live at https://www.southeastwater.com.au/watercalculator/

While the interface to this is a custom .NET application hosted on their public website, it calls an Excel Services spreadsheet for calculations on water usage, cost, savings etc based on the questions answers.  Indeed – if South East Water ever updated their rates the only thing that would need to be changed would be the relevant cells in the spreadsheet.

3) Enterprise Search and Integration (Business Data Catalogue – Ian’s Summary)

The Business Data Catalogue (BDC) is essentially the middleware used to integrate other data and systems into SharePoint Portals and SharePoint Search.  Considering that you may be using SharePoint for the Intranet, there will likely be needs to expose data from other systems into the Intranet.  Some common or likely use cases for a cuatomer might be:

i) Integrating SharePoint with your CRM system entities.  This allows you to search on your customers, suppliers and business partners CRM information from SharePoint.

ii) Integrating SharePoint with your Asset Management system.  This would allow you to enforce document meta-data of asset related files/documents to be only those known assets in your Asset Management System. 

iii) Thirdly – you might decide to create applications in SharePoint that use CRM, Sales, and ERP data.  This is a way to have the data from those system exposed in SharePoint to allow people to manage and take action on them

A customer that I work with has SharePoint Enterprise, and uses the BDC to link Contract Numbers from the Contracts system into SharePoint.  This allows their employees to search on Contract details, and also use the Contract Numbers as a  meta-data field for documents managed within SharePoint.

iv) Finally, I’ve also recorded a video that shows a demonstration of integrating SharePoint Enterprise into Finance and CRM systems, and how a finance person could move a Sales Opportunity in CRM to an Invoice and Accounts Payable Management all using SharePoint as the interface.  (It uses a 3rd party tool to wrap LOB systems in Web Services as well – but that part is option to expose other systems as web services).   This video, I think, is good use of how the BDC connects data and actions from LOB systems into your MOSS portal. 

https://cid-e7db9bf957528709.skydrive.live.com/self.aspx/MOSS%20BDC%20with%20SAP%20CRM/MOSS%7C_BDC%7C_WITH%7C_SAP%7C_AND%7C_CRM%7C_DATA.wmv  (45MB)