“Insights in SharePoint 2010” (featured article on Technet Flash Magazine, UK)

I was recently asked to write a feature article on the UK TechNet magazine, published in Feb this year.

Business intelligence has always been a key business problem for which Microsoft has sought to provide rich tooling. From a client point of view, Excel has been in the market since the early 1980s, and the SQL team released SQL Reporting Services in 2004. By acquiring ProClarity, and releasing Performance Point to the market with the Office 2007 wave, Microsoft’s dedication to the BI market has been clear.

2010 sees a clear step forward in making it easier to build business intelligence applications by unifying the technology stack. The Office, SharePoint and SQL teams have been working together to make it easier for end-users, developers and IT Pros to gain insight into how their business is running.

Familiar client tools
End users are creatures of habit, and thankfully the new Office 2010 suite of products includes enhancements to Excel and Visio to help users build their own self-service reports and dashboards, while leveraging data from line of business applications securely.

SharePoint investments
SharePoint has become the de facto corporate development platform to build business intelligence solutions on. As well as new features, within areas such as Excel Services, Visio Services, and the Chart Web Parts and Performance Point Services, the team has worked hard to make the process of deploying these solutions easier for IT Pros. How?

  • Simplifying management by providing Powershell interfaces for IT Pros to use to manage their deployments.
  • SharePoint now has a Secure Store Service which allows users to have confidence that their system credentials are well secured.
    Performance Point, Excel Services and Visio Services are all first class citizens leveraging the new Service Application architecture, and are configured from a central place within your SharePoint Farm.
  • Connecting to Line of Business applications is made easy and secure via Business Connectivity Services

SQL Server 2008 R2
The SQL team have provided some key enabling technologies for building more powerful BI solutions.

  • PowerPivot is a joint effort between the SQL, Excel and SharePoint teams to allow large amounts of data to be manipulated in pivot tables and reports.
  • Reporting Services Add-In provides a simple way of displaying Reporting Services assets within a SharePoint deployment.

The best of both worlds?
The 2010 wave of products is a major step change in creating business intelligence solutions. It gives end-users the power to create rich self-service solutions, while at the same time giving IT the governance and tools it needs to ensure quality of service and data security.

All of the products mentioned in this article are now in public beta, downloadable from TechNet.

Advertisements

SharePoint Evolution Conference

I’m really looking forward to the SharePoint Evolution conference next month in London. Last year’s Best Practice conference was a blast; not least because it is on my home turf. I’m really looking forward to seeing all my SP friends from around the world – the speaker list is mind blowing, featuring at least 5 MCMs, dozens of MVPs and representation from leading Microsoft partners and MCS. And it’s looking likely that the conference will sell out.

cScape are going to have a good presence there: not only am I speaking, but one of my colleagues (Ari Bakker) also has a session, and we are Gold sponsors.

SP Evolution 2010

SharePoint Designer 2010 as part of a ALM process

SharePoint Designer, and its predecessor FrontPage, has been much maligned by professional developers. Forced to step outside their comfort zone (Visual Studio), they resent the fact that they have to use a tool which is clearly targeted to Power Users, and not professional developers. Aside from various stability issues and missing functionality in previous versions, SharePoint Designer doesn’t even play lip service to the idea that you may not think it is a good idea to develop directly onto production systems. You might say that the tool’s designers completely missed that use case.

SharePoint Designer 2010 does go some way to fixing this. By changing the focus of the product to be more of a management tool, and providing high quality tools embedded within Visual Studio, developers will find that they will not need to use SPD much for development. Despite this, I still see a number of key scenarios where SPD will be used:

  1. As a Proof of Concept / Rapid Application Development tool. SPD has always been good at this scenario, but SPD 2010 is even better. The ability to create and manipulate content types, lists (including external lists) and other SharePoint assets in the same tool is fantastic for developer productivity. It is a huge step forward, and this will be a key mechanism to hit the ground running.
  2. To use the wizards and tools to build custom XSLT. SPD has some fantastic tooling for this, and if you lack the will to get your hands dirty playing with raw XSLT, SPD provides some killer productivity improvements. These tools are not available in Visual Studio.
  3. As a workflow creation tool. SPD 2007 had some key weaknesses for developing workflows, not least a lack of reusability once you had built your workflow. SPD 2010 solves this by introducing reusable workflows, and the ability to save workflows out as WSPs.
  4. As a way of increasing end user self-service. A tricky one this; giving end users the ability to mess up your deployment gave us issues when it came to governance and management. I’ve seen instances where there were 15,000+ customized web part pages in a single SharePoint site collection. Thankfully, 2010 brings us new ways of controlling this – and the best one is the ability to lock it down so that the end users can make use of the features of SPD where they need, but cannot, for example, go into the Advanced Edit screens. This increased granularity of control will make it more likely that SPD will be allowed to be used on production environments.

There are still some issues, though. The integration between SPD and Visual Studio is weak, and once you have moved from your SPD world into VS, there isn’t a clean way to move back into SPD. Furthermore, there is no integration with source control systems or continuous integration systems in SPD, so at some point on a professional project you should end up moving fully into Visual Studio.

Creating publishing sites in SharePoint using Visual Studio – Part 1

I’ve been looking into one of the core missing features from the Visual Studio tools for SharePoint 2010. A really common scenario I have is that you hack together a page layout, master page or site page in SPD (or the browser, for that matter) and then want to package that for deployment or integrate with your development processes in Visual Studio. This should be really simple to do; I do it on every publishing project I do, but it is not intuitive in the new tools.

One way to do this is to package up the library into a WSP, and then import that into a Visual Studio project. This isn’t ideal since it brings across a large amount of stuff you don’t need.

Another option might be to make use of the SharePoint Explorer in Visual Studio to bring that stuff over. But no dice. The server explorer doesn’t give you any useful interaction with a project.

The end game for this blog post series is to have that scenario played out completely. But in the meantime, how would you do this manually anyway? Becky Bertrum has a good post on this here, and as you can see, it’s a pretty manual process. Some key points are just not intuitive enough.

  1. Creating a module. This is fine, but having to manually update the module address to be “_catalogs/masterpage” is OK for people who previously had to create these by hand. For new developers, this is a pretty unintuitive step.
  2. Creating the page layout / master page. Having to create a text file and then rename it with a new (.aspx or .master) extension is pretty lame.
  3. Giving the page layout an associated publishing content type. While better than the old way [go and grab a query string from a URL on the Site Settings area], it is still too hard to get the content type’s ID via Visual Studio.
  4. Adding SharePoint assets to the page. Now you have to actually work with the page layout and make it do what you want. Again, this is easier said than done. Ideally, you’d be able to drill down in the Explorer to Site Pages, Site Assets and the Master Page gallery, right click and say “add this to my project”.

So, what’s to be done with this state of affairs. Thankfully, the SharePoint Visual Studio tools team bought into the extensibility framework that VS2010 delivers. We can change the behaviour of Visual Studio to do what we want to do.

There are a number of distinct tasks I think would be very cool extensions:

  1. Provide a new item type called “SharePoint Publishing Module”. This will automatically set up the correct paths for the master page gallery.
  2. Provide a new item types called “SharePoint Publishing Page Layout”, “SharePoint Master Page” and “SharePoint Site Page”.
  3. Provide a right click action on Content Types and Fields in the SharePoint Explorer to provide a “Copy ID to clipboard” function.
  4. Provide the ability to drag master pages, page layouts and site pages from the SP Explorer into VS modules.

The rest of this series will provide examples of how to do each of these.

Anti-patterns in SharePoint development

There are many anti-patterns in SharePoint development, but since I seem to be doing more and more code reviews at the moment, I thought I’d list out some key ones I keep coming across.

  1. People write way too much C# code. Developers tend to fall back to C# far too quickly, without using out of the box components. A common example is when 300 lines of code is used to do a simple query operation against a list. In almost all circumstances, a Content Query Web Part, a Data View Web Part or even a simple SPDataSource is enough, and can be built in declarative code. Each line of code introduces potential performance problems, and each line of code has to be maintained and tested going forward.
  2. Developers often fail to deal with how their solution is going to be deployed. I’ve seen developers use stsadm -o export/import as a deployment mechanism. That’s fine for an initial deployment but really fails to deal with ALM scenarios – even in the short term. They also rely on manual steps and configuration to deploy – which is fine, but is prone to human error and isn’t a good strategy for platform hygiene.  
  3. Exception handling is almost universally poor. You need to work through how you are going to trap, record and report error conditions in your code. Defensive coding practices are key here, as is proper use of the ULS. The Microsoft Patterns and Practices Group have released good guidance on this.
  4. Scalability is often overlooked. I’ve seen code examples where entire DataTables are pushed into Viewstate. This is clearly not going to be good for performance – a complex object like that will have to be serialised (and then deserialised), which will put a load on server resources, and add significantly to the page weight (it could add MBs to it depending on the size of the data set).
  5. General .NET best practice often goes out of the window – so I’ve seen really bad patterns in XSLT and XML development.

There is good guidance, both officially from Microsoft and unofficially from the community, so there is really no excuse any more. Happy coding!

ReBlog: SharePoint 2010 Beta Release Known Issues

There have been a number of issues in the SharePoint 2010 Beta Release that have been written down and shared by the documentation team:

http://blogs.msdn.com/sharepointdeveloperdocs/archive/2009/11/20/sharepoint-2010-beta-release-known-issues.aspx

Essential reading for anyone playing with the beta…

SharePoint Conference 09 is go!

Sitting in the conference keynote room brought home to me just how far SharePoint has come over the last few years. This conference has around 7400 attendees, which is pretty impressive given the overall economic climate, and the fact that this is a conference around a single product set from Microsoft. The exhibition was packed last night, and as far as I know this is now a bigger show than either  PDC and Tech.Ed.

So why have so many people come to this show? SharePoint 2010 is being unveiled today. Look out for a blizzard of blog posts from the community over the next few days on SP2010.

  • 300+ hours of brand new content
  • 240 sessions
  • 45+ hours of brand new Hands on Labs
  • 7.5 miles of network cable
  • 2 SharePoint Conference marriages
  • Biggest beach party ever at the Mandalay Bay

Some really key announcements were made today; too many really to get into detail now, but look out for some discussion posts about key functionality that has been built into SP2010.

Sessions at SharePoint Conference and TechEd Europe

Now that the agendas have been released, I can now share information about my sessions at SPC and TechEd Europe:

SPC:

  • Building high scale, high availability websites in SharePoint 2010 [4:30pm on Wednesday 21st October]

TechEd Europe:

  • Introduction to SharePoint Designer 2010: Top 10  great things to know
  • Microsoft Business Intelligence in Office Systems

Really looking forward to both these shows!

New blog

With the public unveiling of  SharePoint 2010 just around the corner, I thought it a good idea to start a new blog. My last blog, at the now defunct SharePointBlogs.com, was a constant source of amusement for other MVPs – it was pretty rarely updated.

Now I’ve got a job which, in theory, gives me a bit more time to write and comment about SharePoint in particular, and technology in general. So I’m hoping that this time I can manage more than a post a month…

So who am I? I’m CTO of a Microsoft Gold Partner – cScape Ltd, and for the past 3 years, I’ve also been fortunate enough to be given a “Microsoft Most Valuable Professional” award for SharePoint.