Topology Presentation
I carried out a presentation the other day on sharepoint topologies and what you need to understand to develop and define those topologies – people asked for the presentation doc to be made available, so here it is!
20 Design Decisions for SharePoint
A great PDF from Ben Curry at Mindsharp, describes 20 Design Life Cycle concerning Sharepoint and poses questions concerning business, functional, technical, techniques for gathering and much more.
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:
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
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.
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:
- Detailing and Understanding Current Business Processes
- Defining Requirement Specifications to match with defined User Requirements
- Designing, Planning and Producing a System Specification, including rules for management
- Creating the Solution – Yes – the Systems Analyst could be a Programmer too (in some circumstances)!
- Implementing the Solution, working the lifecycle (3, 4 and 5 again and again)
So, we could assume that:
- A Programmer is not a Planner
- An Architect combines Support, Configuration, sometimes Planning, even Developing
- 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!):
- Gather requirements from the users e.g. site premise, structure, information analysis, data content typing, organisational structure, stakeholder management
- Design the Solution e.g. Wireframes, Taxonomy, Metadata, Content Formatting, Capacity, Logical and Physical
- Define the Implementation Process e.g. Procedures, Guidelines for use, Governance, Testing, Verification, Validation, Customisation
- Design Support; SLAs, Backup and Restore, Disaster Recovery and Business Continuity, Staffing, Training
- Installation, Configuration of SharePoint
- Testing, Verification and Validation
- 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
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
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.
Prepare for SharePoint 2010 – get some free training
Well, things are hotting up nicely….
Microsoft have provided some pretty nice items for SharePoint 2010 and as such makes it easier to learn the platform.
The first item you must check out is the SharePoint 2010 Content Free Training & VPC from MSDN.
You can download the SharePoint 2010 Virtual Machine from here:
There’s also a the What’s New in SharePoint 2010 for Developers clinic; a free 2-hour e-learning course – make sure you print out the certificate at the end though!
More information about the What’s New in SharePoint 2010 for IT Pros clinic; it’s a 2-hour free e-learning course, is here:
All very good stuff!
SQL Log Shipping in Sharepoint – A Disaster Recovery Strategy
Defining a disaster recovery plan using collaborative tools which have a database backend is not an easy thing to achieve. The issues are technical and yep, you guessed, non-technical…
Site Management – Support, Education, Training
As a SharePoint Architect, you’ll define a policy concerning the management of sites or at least will have an input to it; and whatever policy or process that comes from that is not called Tech Support – it’s called Business Content (content hierarchy) Support – meaning management of content and structure.
Effectively, I would assume that it is the responsibility for those who own sites to own sites. So, if you are Site Owner and there are subsites, you own those subsites. This means that users of those sites would seek you first if there is a problem on that site concerning say access permissions etc. However, you are an owner of the parent site and that parent site includes the subsites under your direct control and others. You are therefore responsible in the same way for that root site and that cascades to every site in that tree whether you ‘control’ them or not.
Top level root management of a site means you are responsible for the subsites. Hence, if a user in a subsite has a query concerning site administration they could of course seek your aid or you would pass it up the tree to me for advice and resolution.
As site owner you carry out the responsibilities concerning content structure for your sites and subsites. The knowledge you cascade and/or the aid you provide is based on the agreement you set with those who need to collaborate on your sites.
Some sites have adopted a rigid approach where they have defined people responsible for looking after the site. Some have left a more open approach where they have a large number of people accessing the site and only one looking after it. The key thing here is that those who originally requested the site are still there either (a) looking after it or (b) have defined the rules as to who is looking after the site.
As a SharePoint person, you will face queries concerning How Do I and Can SharePoint Do and What Rules does SharePoint pushed to you. One way you may have combatted that is to produce a centralised FAQ, but, at the end of the day its always best to show a face to Sharepoint and to answer questions that are beyond the reach or would take a while to get to. From a human perspective, that’s one of the purposes of what I call SharePoint Third Line. Why? Because SharePoint is unlike other applications in IT – it is a collaborative technology – it’s there to address collaborative and information challenges – it’s there to centralise what groups of people do. It’s there for people to Share content. Its only right they have shared knowledge in building that content. Therefore, IT people in applications are not the same as IT people in SharePoint.
However, as you may have guessed, no one knows SharePoint in its entirety; and it’s impossible for someone to know all of it. So, designing training sessions to ensure that those attending have confidence in doing the things that matter to them on their sites for their company, and emparting what they know to others as required. So, if they wish to learn HOW TO something all they need to do is drop a help desk call, and/or ask their site owner. If it hasn’t been asked before and valid it ends up, guess where, in you’re FAQ.
Of course, there will always be someone who can answer those questions beyond your remit or reach from SharePoint land who are there to help people create sites using best practice (not to actually do it for them). And in my view there’s no point in giving technical advice to solve business problems, because it will not benefit those trying to learn how to apply Sharepoint to their sites. Additionally, there’s no point in having a ‘person who designs sharepoint sites’ as a resource, because there would be no end and no beginning to the kinds of requests that person would get.
The key is education and training. Education; to ensure that those using your sites, are aware of the boundaries for your group of sites in terms of support. What they can expect and how. Training; because there is no point having a site if you don’t know its purpose or how it should be used in the company it lives.
