Content Deployment – Whats the Best Way?

Content Deployment – Whats the Best Way?

Bunch of my friendly architects chatting over a significant number of beers and spirits, telling rather silly jokes got into a heated discussion on SharePoint Content Deployment. Hrm… Sounds like a punchline building up here – Anyway, it all went a bit like the ‘I went fishing and caught one this big but it got away’ scenario; highly amusing. After recovering I though mmm… sounds like a blog this; so here’s my take…

Before a little chat about what Content Deployment is, lets look at the options available to you:

1: Content Deployment Method

Using the Central Admin, create content deployment jobs to schedule the content that you wish to copy into the production environment.

http://blogs.msdn.com/jackiebo/archive/2007/02/26/content-deployment-step-by-step-tutorial.aspx

2: Third Party.

There’s a mass of products for doing this for example Quest , Content Deployment Wizard on Codeplex – the content deployment wizard is good (and its free ):

  • http://www.quest.com/sharepoint/migration.aspx
  • http://spdeploymentwizard.codeplex.com/Wikipage
  • http://www.codeplex.com

3: Coding.

You could write a web service or delve into the land of SharePoint Object Model coding, that scans the content of your staging environment and maps it into production – this is a big deal and a lot of work. If you’re not a developer be prepared to learn about SPSite, SPList, SPFolder and much more. If this grabs your fancy, and pretty keen to going it alone, check out the below link:

http://blogs.technet.com/stefan_gossner/archive/2007/08/30/deep-dive-into-the-sharepoint-content-deployment-and-migration-api-part-1.aspx

Of course, you may have your own methods, but these ones work well for me!

The problem with Content Deployment – what do you deploy? Whats the scope? From where to where? Whats the reason for Content Deployment.

  • Use it to synchronise a Staging Environment with Production. For example, you have some new master pages you want to push into the new environment following a succesfull client test
  • You have some stuff on Production but want to test it so you push back that content to Staging
  • You want to ensure you have a backup of Production (yes some people do this) so you sync Production to a Backup SharePoint box (which sounds even crazier because that would have to be really really controlled <another blog thought>)

In any case, a lot of careful thought needs to go into the provision of Content Deployment and Best Practice would be to analyse the requirements with the client (even if the client happens to be another tech team), trial it in a test environment then apply it to your staging / production environment.

Some links?:

Video: http://www.youtube.com/watch?v=8_Vy6a1sI_Y

Technet: http://technet.microsoft.com/en-us/library/cc263428.aspx

A Best Practices Blog: http://blogs.technet.com/stefan_gossner/pages/content-deployment-best-practices.aspx

Developers View

Developers View

A poster to advertise Sharepoint 2010. Software developers can use the SharePoint 2010 developer platform to build business collaboration applications for the enterprise and the Web using familiar tools and a rich set of integrated, out-of-the-box features. SharePoint 2010 includes new extensible framework features for building business collaboration applications, including Silverlight™ web parts and Client APIs, LINQ to SharePoint, Business Connectivity Services and Sandboxed Solutions.

(more…)

SharePoint – The Land of the Planner, Architect, Systems Analyst

SharePoint – The Land of the Planner, Architect, Systems Analyst

If you’re a SharePoint Architect, there are a number of areas you want to focus on in your career. Personally, I decided long ago that implementation, structure, automation of the business process in SharePoint is my focus. To do that, I combine my technical knowledge of SharePoint with the project planning, business and planning skills that I’ve gathered through over 20 years of Systems Analysis and Design.

SharePoint is a collaborative technology. But, after all, it’s simply a system, a software product. That system is subject to the exact same laws in terms of management as any other. Therefore, in terms of deploying it the processes and procedures followed will be exactly the same as any other system in that the planning, implementing, deploying and supporting processes will be ‘standard’.

This system needs to be fully understood by the relevant Solutions Architect, and as you will have guessed, for SharePoint this is a SharePoint Architect. This person understands the nature of the beast (deeply) and that also includes the format and application of any connected technologies to this system. And, that person would know how to implement features of the product using not just technical knowledge, but traditional Systems Analysis skills.

What?

You can’t be serious Geoff – The SharePoint Architect is a System Analyst?

Well, let’s look at the key tasks of a Systems Analyst and see how this ties in with the tasks of a SharePoint Architect:

  1. Detailing and Understanding Current Business Processes
  2. Defining Requirement Specifications to match with defined User Requirements
  3. Designing, Planning and Producing a System Specification, including rules for management
  4. Creating the Solution – Yes – the Systems Analyst could be a Programmer too (in some circumstances)!
  5. Implementing the Solution, working the lifecycle (3, 4 and 5 again and again)

 

So, we could assume that:

  1. A Programmer is not a Planner
  2. An Architect combines Support, Configuration, sometimes Planning, even Developing
  3. But, an Architect is not necessarily always the planner

 

So, let’s go to the Planning….

Let’s say that you have been appointed ‘SharePoint Dude’, and are about to embark on installation of SharePoint to an organisation. The organisation will definitely adopt SharePoint. That organisation wants to go down the route of applying a ‘trial’ platform which is intended to eventually migrate into a full platform.

Here are the very basic things you would need to do. So, making this look scary (but pretty real), lets say that you are the only person going set to do this (meaning, that you would be the planner, supporter, programmer – hey I’ve seen this happen!):

  1. Gather requirements from the users e.g. site premise, structure, information analysis, data content typing, organisational structure, stakeholder management
  2. Design the Solution e.g. Wireframes, Taxonomy, Metadata, Content Formatting, Capacity, Logical and Physical
  3. Define the Implementation Process e.g. Procedures, Guidelines for use, Governance, Testing, Verification, Validation, Customisation
  4. Design Support; SLAs, Backup and Restore, Disaster Recovery and Business Continuity, Staffing, Training
  5. Installation, Configuration of SharePoint
  6. Testing, Verification and Validation
  7. Educate, Train and Educate the users

 

Hey that looks suspiciously like the Systems Analyst work?

So, as you can see doing this as one person is no mean feat – and if this is not communicated to the business from the outset there would be serious issues concerning the planning and implementation because no one would know the risks involved. Even if the SharePoint Architect is also the Planner that person would need to be able to prioritise all the tasks because the Architects hat will be changed very often! This means frequent confirmations with the business stakeholders again.

Additionally there is a split between what is perceived as technical (server and software configuration) and business driven (user requirements) needs. Whilst it may be prudent for the SharePoint Architect to gather, design, document and implement these some would argue that not only is it very time consuming and difficult to plan, but it means all eggs in one basket and again, without this being communicated back to the business there will be serious problems ahead…

See where I’m going with this?

The bottom line is that the SharePoint Architect is not the planner in a large installation project or a project where there is a requirement to gather lots of information. However, for a small pilot install where the risks are low it could be perceived that the SharePoint Architect is also a planner, though the definition of medium would have to be stressed to the business. And, in my view, there is no such thing as a SharePoint Architect in a small office / company installation …

Bold statements, Yes?

But, I think its key to understand that a SharePoint installation will go out of control without someone to drive the targets and meet time objectives. That’s where the planner / project manager steps in – and guess what – they would know SharePoint.

So, in summary. Organisations new to SharePoint who need to improve collaboration, information management and online web based communication need to ensure that a SharePoint Architect is provisioned to make it happen. The SharePoint Architects’ task is to ensure that the platform is resilient, performs, meets user requirements, is future proof. The Planner is there to ensure that its implementation takes place on time and in most cases to budget. Hence, ensuring there is control and standard systems analysis will ensure that SharePoint is not perceived as a silver bullet but as a tool that enables the client to be more data productive..

Email Distribution Groups – Document Library Governance

Email Distribution Groups – Document Library Governance

Sharepoint has the ability to take incoming emails via Microsoft Outlook into a document library or calendar. For example, one could setup meeting requests via Outlook and send these into a calendar on SharePoint. Also, an email could be sent directly into a document library from Outlook. The reasons for this is from a document library perspective that there is a method of capturing key emails and storing them for policy / retention / compliance reasons.The email address used for these document libraries are created by the users – there is no ‘support helpdesk’ involvement – additionally, SharePoint doesn’t carry out cross-checking to see if an email alias has already been taken in another document library in the current or another site.
My Spin on Defining Site Structure in SharePoint

My Spin on Defining Site Structure in SharePoint

Was asked today whether there were guides available that walked someone through building a site structure – a kind of click here, click there guide.
So, my thoughts and after discussing the client requirements boils down to this:
The question concerning creating SharePoint site structure is based on the reasoning and cause for having a sharepoint presence in the first place – and its not technical, its business. Its questions regarding your audience, who does what, the content, the teams internal processes, how they store content, how you work together as a team, how they communicate.
Of course, we know that People wanting to have a sharepoint site do so because they wish to engage in working together as a team – and its understanding that which gives you site structure.
So, the bottom line? Sharepoint is not about creating some document libraries putting some navigation tabs and then telling your team to adhere to it, its about defining a collaborative area for your team based on what they do and how they do it. This means that I don’t think anyone would find any ‘golden goblet’ or ‘Holy Grail’ on defining site structure because everyones needs are different. I would also advise anyone on trying to do it for that very reason. Can you imagine trying to build a ‘click here’ – ‘click there’ guide that walks you on setting up a ‘structure’ to suit anyone’s direct requirements?
That means that people who ask this question be advised to have their business needs analysed;  get them to understand what kind of content and functionality goes into SharePoint site makeup,  and get them more involved with knowing more about SharePoint.  As well as my two books there’s absolutely piles of links on this site alone concerning ELearning, Training, Education.
I always advocate that the best way for someone to get into SharePoint is not diving in without pants on because that way you’ll get embarrassed! Its about having an awareness and seeking specific training. That then describes about what, how, why, and when you use sharepoint to meet challenges. So, once you have a better understanding of that you will be able to define your site structure.  In book, I describe the methods of ensuring that your SharePoint presence has this in mind so that it is easier to get the user to help themselves as well as getting centralised support.