Saturday, September 08, 2012

SharePoint Saturday Cape Town Presentation

Thank you all who attended my session, as promised, please find my presentation slides below.

For those who missed it, my talk was on SharePoint and Maturity, I talked about the importance of the maturity assessment, and what maturity assessments models are available.

This presentation is focused around SharePoint, but I am sure the information here can assist you with other types of maturity assessments.

 

(You can download it here : http://www.slideshare.net/nadirkamdar/oh-grow-up-a-look-at-share-point-and-maturity-2012-final)

Sunday, July 22, 2012

SharePoint 15, the BETA review

I remember the excitement when SharePoint 2010 came out, us developers and architects saw this as the solution that will resolve ALL the flaws found in SharePoint 2007.  The SharePoint 2010 demos were, well, to narrow it down to one word, seductive!  We were convinced that this would be the best product to sell, deploy, use and support. 

But SharePoint 2010 is not perfect.  Sure, it kicks 2007’s butt!  But some of the issues identified from SharePoint 2007’s time was carried over to SharePoint 2010 and some new issues were “invented” when added functionality and complexity was added.

SharePoint 2010’s approach in providing us with a web solution is already dated by about 5 years.  Remember that SharePoint may have been available to the public in 2010, but the magicians in Microsoft started designing, planning and building the solution from 2008 at the latest.  That’s when Silverlight still had a future, Social Networking has no place in the business world and the explosion of mobile and tablet devise has not even started, in fact, the iPad wasn’t even invented then!

Therefore, times have changed, and so should your web-based solution.  Based on online videos and demonstrations performed by my team, I’m going to provide a beta review on certain areas of SharePoint 15, these areas has been identified as potential problem areas in SharePoint 2010.  So I am very interested to see how well they were tackled in the new SharePoint.

I don’t want to rush through each area – so I will publish this post while its incomplete and place the titles of the areas I plan to review, and will update the post when I have done the analysis – add comments if you want me to add more areas.

General Appearance and Usability

SharePoint 2010 looks great when compared to SharePoint 2007.  But its “busy” when compared to todays standards, when we deploy solutions to our clients, our most successful deployments involves simplifying the interface so its easier to understand and use. 

Let’s back this up with an example.  Below is an image of a team site created in SharePoint 2010.


The first thing I see is many things many of my users will not necessary use:
  • ·         That large image that means nothing to anyone
  • ·         The “Welcome” message Place Holder.
  • ·         The “Like” and “Tags and Notes” button

These components are not needed for the team site, yet they are there by default.  This clutters the site too much and it confuses the end users.  These components are usually removed or ignored.

I won’t start with the navigation right now, (saving that for a later section of this blog).  I will add that the “Getting Started” section is a great idea to assist users in getting started with this site, but it’s not intuitive or user friendly and is typically ignored or removed.

Let us check out the SharePoint 15 team site. 


(Video walkthrough of SharePoint 15 is available here : http://www.sharepoint-videos.com/walkthrough-of-sharepoint-2013-team-site/)

I am seeing less clutter, useless images and text are removed, important “Getting Started” links has a greater prominence and is more inviting, thanks to Metro Style navigation. 

This is a much more inviting, intuitive and user-friendly interface.  It even supports drag and drop and a new feature that hides the navigation so the focus is on the content only. 

I see good use of “Share” and “Follow”, which is more professional than “I Like it”, and has a more subtle presence that in the previous version.  I don’t know right now, but I hope those buttons can be easily removed if requested by my client.

They seem to have tackled all the issues I have identified in SharePoint 2010.  5 out of 5 for this section!


Changing he Look and Feel

[SECTION UPDATED on 29th July 2012] 

Every single SharePoint project I worked on has one consistent requirement, that’s to make the SharePoint site not look like a SharePoint site.

Creating a site that is inviting and represents the corporate brand is important, buts its not an easy thing to do, since you need tools like SharePoint Designer to do a decent job.

Microsoft’s best practice approach involves limiting your design to themes, and unfortunately, that approach was very limiting, and more often than not, the designers are forced to open up designer and tinker with the master pages to get that better design.  This approach is a workaround that bypasses all the limitations of themes and gives you amazing looking sites but it also affects the stability of the solution.  Nevertheless, a visually appealing and inviting site that represents the corporate brand is important – so this has to be done.

What I am looking for in SharePoint 2013, is an easier way to change the appearance, with fewer limitations and no risk of destabilising the environment.

Did SharePoint 2013 deliver?

Well, this, http://www.sharepoint-videos.com/changing-the-look-and-feel-of-sharepoint-2013-team-site/,  impressive video shows how easy it is to change the style of the site.  You don’t need SharePoint Designer, it has great preview facilities, you seem to have a greater range of templates to get started and also a good range of options when modifying the styles.  Seems like they did an excellent job in improving the ability to change the appearance of SharePoint.

Looking at SharePoint related press releases from Microsoft (http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=1012 – near the end of the article).  It is clear that Microsoft is recommending us to stick to the tools mentioned above to modify the look.  Anything done beyond these tools (like tinkering with the site templates in SharePoint Designer) will affect the complexity, performance, upgradability and stability of the solution. 

So its still (and now officially) NOT a good idea to move beyond the tools provided to change the look, but is the tools provided enough?
SharePoint is cleaner, simpler and faster by default, so there are fewer reasons to move beyond the tools provided.  But the visual element sells the products and gives the client that warm fuzzy feeling when its done with flare, so in order to impress, I see the developers forced to push the limitations and bend the rules to make that client say “WOW”!  Sadly, at the cost of performance and stability. 

I would have preferred Microsoft to not prohibit us from going beyond the tools, but rather supporting it with guidelines, templates and additional, more advanced tools made for skilled designers.



Navigation

[Section Updated on 3 August 2012]


The navigation provided by SharePoint has always led to difficult conversations with the client.

Navigation menus is important, it needs to have a logical structure that allows the user to navigate to their desired area, and what SharePoint lacks was the flexibility to adjust the menus to fit the structure the end users will find logical.

One problem was SharePoint was adding their own headings like “sites” and “libraries” to the current navigation; these are SharePoint terms that are not familiar to the end users, thus confusing them.  Users also expect different types of navigation like fly out menus or tree views, these options were not available in SharePoint (well, the tree view is, but it’s not user friendly, flexible or attractive at all, so as far as I am concerned, it’s an unusable feature).

Other points worth mentioning was friendly URL’s were not used (making it more difficult for search engines to pick up) and navigation did not go past two level unless you edited the code in SharePoint Designer.

So, what I am looking for is greater flexibility in controlling the Navigation in SharePoint 2013.  Did they deliver?

This post, https://www.nothingbutsharepoint.com/sites/eusp/Pages/SharePoint-2013-Navigation-using-Managed-Metadata-Term-Store.aspx, covers SharePoint 2013 and navigation pretty well.  I see that term sets are now been used to source the menus.



That’s great, in the past when SharePoint navigation sources were not sufficient, we had to create site map files, which gave us the results we needed but really made the support and maintenance of the solution more complex.

So the flexibility of controlling the menus content has improved, friendly URL’s are now available and term sets allow for multiple levels of navigation, and also I see that the confusing terms like “sites” and “Libraries” are no longer there by default.  This is fantastic.

The only thing I have not found was the ability to change the menu type to a tree view or fly out menu out of the box, but I am not too worried about that, that’s an easy fix with a little coding and 3rd party products, it was the menu source that gave me the biggest problems.




Mobile Access

[Section Updated on 12 August 2012]


The one big thing that SharePoint 2010 lacked was good mobile support.  Sure SharePoint works on a tablet, but not 100% (and for some features, like BI reports, not at all), and today, you expect 100%. 

I'm not expecting much when it comes to mobile, all I am asking for is good HTML5 and CSS3 support.  With that in place, I’m expecting a good future proof environment (well, until the next SharePoint release at least) what will work on all devices worth mentioning.

Looks like SharePoint delivers, the screenshots below shows good support for HTML5 with the classic options for devices that do not support HTML5 and of course the standard full screen option.



SharePoint 2013 exceeds my expectation by providing push notification support.  That’s when a mobile device registers with SharePoint and then receives notifications via Microsoft Push notification services and other similar services, very nice.

My expectations are exceeded even further with location-aware services, where the SharePoint content can be more location aware and can use services like Bing Maps to display information relative to your location.

Also, SharePoint 2013 has improved the ability for apps to interact with the content in SharePoint, allowing for a greater range of mobile apps to be created. 

So, I am seeing a lot of new features made specifically for mobile devices, and I also see exciting times for developers who now have more options available when it comes to mobile development, its really hard to find any fault here.



Custom Development

[Section Updated on 26 August 2012]

I have mixed feelings on this one, custom development is very important when deploying SharePoint solutions, but I always tried to sell it as a last resort and then place a lot of control measures to the custom approach to help maintain an acceptable degree of stability on the environment.

In short, I don’t like custom development, it seems to eventually be the root cause to more problems, it dangerously creates a SharePoint environment that does not behave like a SharePoint environment that leads to unpredictable results in scenarios that you may have missed during testing.

What I am looking for when reviewing this component is a set of tools and processes that will give my developers a better “guarantee” that the custom component …
can be easily created
Will work as intended
Can be easily deployed
Will not affect the stability of the environment

Also, right now, when we create a functionality or feature, be it custom or OOB, we have to deploy it to the Testing server and, once approved, deploy it to the Production server.  To do this in a way that that agrees with company policies – we build installation scripts and installation manuals, this document and script creates all the necessary sites and sub sites, the content types, term sets, workflows, configurations, workflows.

It also applies all the necessary configurations.  Building this script and manual is takes a lot of time, it’s difficult to build, needs to be frequently tested and it’s difficult to troubleshoot and update, and we do this because there isn’t a good installation package type feature available from SharePoint that can package ALL the necessary components for easy deployment to different environments.

It looks like SharePoint 2013 did not focus on this much needed feature, instead, they focused on Apps and the Apps market so new features and updates are more centrally available and controlled.  But these apps has limitations where they can only use client side code and the SharePoint components like content types and term sets that may be needed to make the app work well, will need to be manually created and configured, something that should have been avoided with an installation package.

I can see they are discouraging custom development, and while I know the apps will be a hit.  The limitations will be frustrating and more importantly, I wish Microsoft provided a way to more easily package and deploy solutions WITH all its necessary counterparts.



Conclusion

SharePoint 2013 has met my expectation in many ways, managed to find ways to exceed my expectations and in a few yet critical situations, it failed to meet my expectations.  This is a BETA review on a BETA product, so things may change once I get to know the product better or get involved in some early training and official demonstrations.  Do you think I missed the mark?  Let me know



Monday, June 04, 2012

Paperless Trail - Going green with SharePoint

A paperless office is a work environment in which the use of paper is eliminated or (more realistically) greatly reduced.

 

You achieve this by converting your documents and other papers into digital form.  By “going paperless” you can …

  •          Save money (paper, printers, inks and toners)
  •          Boost productivity
  •          Save space
  •          Make documentation and information sharing and searching easier
  •          Keep personal information more secure
  •          And, of course, help the environment.


We are now more environmentally aware, we see the production of paper as a significant contributor to deforestation and climate change.  We have added measures like recycling and tree-free paper to help reduce the environmental impact, but online document management systems like SharePoint is seen as the strongest contributor in reducing the need for paper.

A solution like SharePoint provides a paperless alternative to …
  •          Business cards, Index cards and Rolodex
  •          Typed/written letters and faxes
  •          Diaries and schedules
  •          Training material
  •          Reference books
  •          LOB documentation for sharing and collaboration
  •          Record keeping
  •          Paper-based processes

Providing an alternative to paper-based processes that rely on forms, applications and surveys provides a solution to the biggest hurdle in having a paperless office.

Also, our behaviour is changing.  Thanks to the popularity of digital mobile devices like e-books, tablets and smart phones, we are finding it more acceptable to read documents and other information over these mediums – this means that the advantage that paper use to have about being mobile is now phasing away so this paperless office concept is truly possible.

So how do we use SharePoint to achieve a paperless office?

Back scanning (with 3rd party solutions like http://www.kofax.com/) and migrating all your existing records and LOB content into one SharePoint environment is a great first step.  Right away you will see the cost saving of phasing out all your existing paper – also when you consolidate all your document storage environments to one digital environment, there are added benefits in having one central point for the users to find and store information, that’s one learning curve and one infrastructure to support and maintain.

Next, you want to convert your manual paper-based processes to more automated SharePoint workflows.  The biggest obstacle many organisations face when phasing out paper based processes is the fact that documents needs to be signed to acknowledge acceptance or approval.  Tools like InfoPath that integrates well with SharePoint, provides digital signature capabilities with additional security features like making the signature become invalid if the information on the form has changed.

Once the workflows are in place, your business will produce less paper, and the processes would have better control and faster turnaround time.  So that’s a saving on cost and time.

I mentioned earlier how the main advantage of paper, i.e. the mobility of paper, is slowly phasing away due to electronic mobile devices.  SharePoint is a web based solution, making it easily accessible to these mobile devices – also, doe to the popularity of this product, there are plenty of apps available for iOS and Android, while the Windows 7 devices come with strong integration features by default.

The only real unavoidable use of paper would be around compliancy around the external companies you will need to interact with, companies and government organisations that follow paper-based processes that needs to be followed for compliancy reasons – maybe in time, when the paperless approach is more mainstream – this can be avoided.

Saturday, April 21, 2012

The problem with small companies

Up until the start of this year, I have been working for small consultancy companies.  While I have always enjoyed the flexibility of this environment, I have never really had strong exposure to large organisations until now.

The company I work for has been acquired by a much larger organisation, meaning that I am now part of a big company.  It’s been three months since the acquisition, and while the transition is still taking place, I am already noticing a shift in my thinking.  I would like to share this with you, and maybe add on to this post as more differences are identified.

Before I continue, I just need to add that the points below are not necessary points from the company I work in.  I have been in this industry for a long time, and have built relationships with all kinds of people in different positions and companies (including my competitors) and have managed to pick up some consistencies and facts worth mentioning.  Some of these points are negative, which is why I believe people are afraid to talk about it, but I also believe that these points are too important to keep to myself.  I hope you enjoy.


Small companies NEED work to pay salaries

As a small company, your biggest expense is salary.  If you don’t get enough work, you don’t have a good enough cash flow to pay salaries and other debts.  So, as a small company, your number one objective is to get that sale, no matter what!

“No matter what” may be a bit strong, but there is a lot of pressure to get that sale, and as a small consultancy company that specialise in Microsoft Web Solutions, you will know that competition is tight, and to make things worse, its tight against other small companies who also NEEDS the sale to improve their cash flow.

So what does this mean?  Small companies in a highly competitive market tend to over promise, and cut down prices to secure that deal.  After all, a little revenue that can make you break even, is better than no revenue, right? 

As a larger company, the cash flow is not a problem.  Salaries are paid by HR and no matter how much sales you get, you can rest assured that the salaries will get paid.  This does not mean that we can rest on the sales component and do less work.  No, while we still have the responsibility to be profitable, and to meet certain sales targets, the cash flow component is not 100% dependant on the sales we get. 

This is great, better cash flow provides more options.  More cash can be dedicated to infrastructure, training, staff morale and a few other perks that was not available as a small company.

Large companies are more focused

When you are responsible for a division of a small company, you are in charge of every single thing related to that division. You are fully involved in the hiring, the training, the social events and not forgetting the actual service delivery. 

When you are part of a large company, many of these tasks are “outsourced” to other divisions of the organisation that specialise in these things.  Things like social events are no longer your problem, your involvements in the hiring are training are also drastically reduced, allowing you focus on the things that are important – your service delivery.

And even on the service delivery side, you can focus on a specific service (like only SharePoint projects) while another division can focus on other services (like ASP.NET projects).  This focus provides huge advantages on the delivery quality side because your focus and training and strategising is focused and on a specific service, which is a huge adjustment when compared to small companies.

Small companies try to have as little staff as possible that can do as much as possible, or alternatively, they get a lot of junior staff that they task with more senior work (preferably mentored by a senior), either way, the objective is to keep their biggest cost down, the salaries.

Now in order to keep salaries down, and yet be able to deliver on whatever sales has over promised, small companies need staff that have a variety of skills, they don’t have to specialise in anything just be able to know a variety of things well enough to come off as a Subject Matter Expert and be able to Google the rest.  This sounds cruel, and may be a bit exaggerated, but sadly, not by much.

Small companies are more flexible

Being part of a large company, I must say that the processes for action and decision making are stricter and even a little longer.  There is a lot more paperwork that one has to go through to achieve the results.   It makes sense when you consider that there are more people involved, meaning that more can go wrong if we are working in a more chaotic state.

In a smaller company, you can get away with it because you usually have full control of the situation.  This lack of processes allows you to deliver faster but it also means that more can go wrong.  In the Microsoft Service Delivery space, clients are placing a high priority on speed so the smaller companies will have a big advantage here.

This “advantage” leads to another point.  Smaller companies are willing to accept higher levels of risk.  The faster delivery comes at a cost, and that cost is increased risk because processes are not strictly followed.  When you are part of a larger company, especially a listed company,  you have a greater responsibility to deliver well, after all, somebody’s retirement fund may be indirectly dependant on your performance, and because of that, a more risk averse approach is necessary.

Large companies has more available for less

As a small company, I have an internal design team that I use primarily for website designs, then team is skilled in designing marketing material like posters and banners, but whenever I get that type of work, I have to outsource the printing component to a printing company who charge normal market rates.  The same goes for software licencing and acquiring hardware.  While these services greatly complement my service delivery I just don’t have any skills, experience or equipment to deliver on this (and I don’t plan to build on this, because the demand isn’t there) forcing me to find alternative companies to assist me, who will offer there service at full price.  Over time, you can build a relationship with these 3rd parties and get the price reduced, but you get the point I am trying to make.

As a large company, these complementary services are more easily accessible (chances are, there is another division in the company that provides that service) and the cost is less because these divisions has built great relationships with their supplier and the work is not outsourced to a 3rd parties.  This allows the large companies to deliver more with less dependency on others and less cash.

This advantage goes beyond service delivery.  Benefits such as medical aid, RAF, etc.  are now available at better rates.  As a large company, you have more buying power with these insurance and medical aid companies and can form better relationships when compared to smaller companies resulting in better rates and cover.

Conclusion

Right now, I am very positive on what large companies can offer.  I say this from a point of view of a client looking for a service from a outsourced company or as a skilled individual seeking employment.  

They seem to tackle most of the disadvantages that exists in smaller company’s very well, especially the cash flow problem.  While the cost of this is stricter processes and longer turnaround time, this does create a more governed or less risky environment.  I also like the fact that the service delivery is more focused, thus resulting is higher quality output. 


UPDATE : The feedback I am getting on this post indicate that many think that I am wrong in my findings (something about be identifying common problems and not necessary the difference between small and large companies), this may be true, since I have only been part of the large organisation for about 3 months now and may be jumping to conclusions here.  So please think of this as my initial findings, and if my point of view changes, I will update this post - Thanks.

Saturday, March 10, 2012

How to write good technical documents


Developers love to code and hate to write documents, but documents are important in IT.
 
We need documents to define how the solution will be built so that coders who enter the scene later in the project can easily catch up.  We need operational and training manuals so the people who are looking after the solution are aided in doing it right, we also need numerous project management related documents but today, I want to focus on those documents that are more technical in nature, and somehow ends up on the coders lap, who usually has no idea how to handle this responsibility.

Firstly, let’s start off by saying that document writing is a skill; it’s a valuable skill that coders should embrace rather than avoid.  It may take you away from your comfort zone, but building this skill alone will helps you advance your career to the next level.  So give this responsibility proper attention and you will see the rewards.

But how does one write good technical documents?  Project managers tend to give this responsibility to coders without guiding them.  It’s a common mistake, and I hope this post will provide the guidance you need.

Get a template

The first thing you should do when given this task, is ask for a template or a similar document from a previous project.  If your company has a good capability maturity, then these templates should be easily available.  If you work in a company that is less mature (or a nastier way to put it, “more chaotic”) and you will need to build the document from scratch.  Its more work, but don’t freak out, the main purpose of the template is to provide a tried and tested format, that’s it, you should not see a document from a previous document as an opportunity to copy and paste 70% of the work, that’s messing up the quality of the document and you are robbing yourself from the opportunity to build up on your document writing skills.

So yes, you need to have a format of the document.  If the document is well formatted, it will be well organised so it’s easy to read and easy to understand.  If your company does not have templates for you, there are plenty of templates on the internet; many of them are free so you may want to go there for a little help in getting started.  Look at multiple documents, and come up with an outline that works for you.

Know your audience

As a coder, it is natural for you to use IT jargon in your everyday language, you talk to other coders in that language, and they understand you and respond appropriately.  When you approach a non-coder and communicate with them, you make that extra effort to use words that “normal” people use so they can understand and respond appropriately.  Writing a document works on the same principle. 

So if you are writing a technical document that will assist other coders in installing that brilliant add-on you created, you can keep the IT jargon.  But if you are building a document for managers or end users, then cut down on the jargon, use simple English and add think about adding a few more pictures like screenshots or wireframes, they love that.

Why is this document important?

Ask yourself what value you are adding, by creating this document.  What’s the purpose of this document?  Once you have an answer to this question, you can draw of a draft and then ask yourself if this document is achieving its intended purpose.  If it is, you on the right track.

Gathering Information

Make sure you have collected all the information and facts needed for the document, use the template to assist you in what type of information you need.

Gathering information may involve digging in the code built by you or other people, but don’t forget to ask other people for information as well, it may be quicker that figuring it out on your own.  Even communication is a skill, it’s a skill that many coders avoid, and this is a good opportunity for you to step away from your comfort zone and work on those skills.

First Draft

With the information above, you should be able to draw up your first draft.  The first draft is really filling out each section of the template with the facts and information it needs.   After that is done, you can focus on the writing.

And now the writing, finally

The first draft does not consider writing style and formatting, at that phase, it’s all about the facts.  Now you need to up the quality with proper formatting.  here are some points to help you:
  •   Don’t try to be too fancy with the language.  Keep it simple, clear and unambiguous so there is little room for confusion and misunderstanding.
  •  Be consistent.  If you are using the words “Power User” to describe a particular role, don’t change it to “Business Administrator” later in the document.
  • Use bullet points and images where ever possible.  it’s easier to read, and important information isn’t lost in the paragraphs.
  • Avoid contradicting yourself.
  • Keep the document honest with truthful facts, even if it’s bad news.
  • Use numbering system so your document can be easily referenced later.

Well, I hope that helps.  If you have any more helpful points, please add it to the comments.  And to those coders writing a document – Good Luck and embrace this opportunity.

Sunday, February 19, 2012

What Are SharePoint Architects?

When we look at the minimum resources needed for a SharePoint environment, we think SharePoint administrator and maybe the “can-do-it-all” SharePoint Developer.
  
Don’t get me wrong, these resources are great and are vital for the stability and growth of the SharePoint environment, but they are essentially the workers, or the term I like using, the brick layers (don’t take it as an offensive term, that’s not my intention), they have a strong focus on the technical component of the SharePoint environment, and although they can achieve greatness on their own, they can achieve so much more if they had guidance from someone with a broad understanding of SharePoint (not necessary focused on the technical side) with the ability to map a business problem to the SharePoint technology, that can engage with the business user and plan an approach that will achieve the greatness that SharePoint can provide.  They are the SharePoint Architect.


The reason why I am focusing on this role right now, is the fact that this role is truly misunderstood (This role is typically given to the SharePoint Developer), and regarded as not important in SharePoint deployments.  It’s also a rare skillset, there isn’t decent SharePoint Architect training out there, well, nothing officially from Microsoft from what I can see.



I also looked around on who is providing this skillset, and noticed a disturbing commonality.  People that play the role of SharePoint Architect are not dedicated to this role, I met a few SharePoint Consultant companies, and noticed that there “SharePoint Architects” are also the “Accounts Manager”.  This means they are from sales with the primary objective to sell SharePoint (i.e. bias towards using SharePoint) but they call themselves Architects.  The problem with this is that Architects needs to match the business problem to the SharePoint technology and if the technology does not match the problem, i.e. too much customisation is required to achieve the desired result, then the Architect needs to say no and recommend an alternate/non-SharePoint approach.  Can the people from Sales do that?  I don’t think so.

So, what makes a good SharePoint Architect?  

The Architect has …
A broad understanding of SharePoint, the Architect understands the building blocks of SharePoint (IIS, ASP.NET, Virtual Directories, AD)
A good understanding of what functionality SharePoint can provide, the types of configurations that’s available, the limitations of the functionality, and what can be achieved via OOTB (Out of the Box) or Customisation.
Sufficient knowledge in capacity planning and performance monitoring
A good understanding of SharePoint advanced features, like Business Intelligence, FAST and what SharePoint license is required to use these features.
Knowledge on how to integrate with other systems
Good communication and documentation skills
Best Practice approaches in defining a strategy for SharePoint and other common tasks like Migration

The Architect is heavily involved during the planning phase of your SharePoint deployment, the Architect’s skillset is more focused on achieving the business objective,  by using best practice approaches and building proper plans that are achievable by the SharePoint administrator or SharePoint Developer.  

Without them, you essentially have brick-layers and plumbers, eager to build, without anyone drawing up and approving the plan.  This will eventually lead to an unstable environment, with no capacity planning, and solutions that built solutions that do not resolve the business problem.

Sunday, January 01, 2012

SharePoint in the year 2011

While a new version of SharePoint did not come out in the year 2011, it does not mean that nothing happened in that year.  This post will highlight the key achievements of SharePoint in the year 2011 and also my predictions in the year 2012.



The phase out of SharePoint 2007:  SharePoint 2010 was introduced in the 2nd half of 2010.  The year 2011, started the phase out of SharePoint 2007 and the phase in of SharePoint 2010 – this is evident when you look for SharePoint training currently available.  At the start of 2011, Good (or any) SharePoint 2010 training was few and expensive, and now, at the end of 2011, SharePoint 2007 training has been completely phased out.

Using SharePoint better:  People loved SharePoint 2007, but they were not using it correctly, which introduced many pitfalls, as mentioned in my blog post written exactly one year ago  (http://nadirkamdar.blogspot.com/2010/12/common-pitfalls-in-sharepoint-projects.html) .  The year 2011 shows that we are starting to use  SharePoint better, we know the potential risks and pitfalls are have taken the additional steps to mitigate it.  This is evident as more emphasis/training/articles is now placed on planning and governance.

Improved stability, performance and security:  The latest Service Pack for SharePoint 2010 was released in November 2011.  The service pack included the following improvements:
Improved support for Internet Explorer 9.
Recycle bin: Lets you restore a site collection or a web that was deleted.
Remote Backup Systems (RBS) and shallow copy can decrease downtime and increase efficiency by moving pointers to databases instead of moving databases.
You can see which folders are taking up valuable space with the improved Storage Management feature in site settings.
Support for Microsoft SQL Server 2012.
A more robust Search Host Distribution service that improves error recovery and performance during the search crawl.
Adds backup and restore functionality to recover deleted site collections and webs.

Microsoft Launches Office 365 and places SharePoint in the Cloud:  In June 2011, Microsoft officially launched Office 365.  This includes the launch on the cloud based version of SharePoint 2010 (called SharePoint Online).  This positions SharePoint as an essential productivity and collaboration tool, placed in the Cloud making that is affordable and appealing to any businesses.



SharePoint matures with BI and Visio 2010:  While BI functionality was available on SharePoint 2007, great improvements were introduced in SharePoint 2010 with the much needed integration into Visio 2010, but we only understood the power of these advancements in 2011, when Microsoft introduced BI and Visio specific Demo VM and videos.  Theses Demo VM’s can be sound here : http://mssalesdemos.com/ .

SharePoint designs are better:  A very common request when deploying SharePoint solutions is to make SharePoint not look like SharePoint, achieving this compromised the functionality, and I complained about this in my earlier blog posts ( http://nadirkamdar.blogspot.com/2010/07/please-dont-pimp-your-sharepoint-site.html ).  Today, I’m not complaining.  As a balance can be reached where there site is fully functional with a strong look.  This balance is achieved after a years’ worth of lessons learnt and new design related articles and guides.  A good showcase on what can be achieved can be found here: http://www.topsharepoint.com/

So what’s in store for SharePoint in the year 2012?

Well, Office 365 will receive better adoption, and the shift to the Cloud will be more prominent.

The new SQL Server will launch, resulting in better BI functionality, which will directly affect SharePoint.  Maybe improved speed and better functionality in features like Reporting Services and Power Pivot.

Better support for mobile devices:  I don’t believe they got this quite right as yet, as seen in the video below (its good, but not perfect), and mobile support is just too big to ignore.



What I am expecting is a service pack that provides site templates that makes better use of HTML 5 and CSS 3 or at least templates that make better use of W3C compliant code and JavaScript so it works well on these devices.

The end of SharePoint 2007, If you or your corporation are using SharePoint 2007, it will most likely reach its end of live in 2012, which means upgrade/migrate or use what people will soon call the “Old SharePoint”.  Due to the reduction (or complete removal) of SharePoint 2007 training, there will soon be no resources available to support the environment.  No support means no growth and if your technology cannot grow, its becomes a liability.

While 2011 was about strong awareness on how we are destroying the world, 2012 is about us doing something about it.  2012 will see SharePoint as a strong paperless option for collaboration and productivity.

So that’s my take on SharePoint in the last year with a few predictions in the year to come.  Tell me what you think?