Skip to content

December 24, 2011

My 10 Years in SharePoint

I vividly remember working in publishing in 2000. We had just survived what was supposed to be the cataclysmic events of the millennium. Of course, we were not plunged into some dark abyss where power plants stopped functioning and traffic lights started showing green in all directions. Microsoft was talking about moving Microsoft Office to the server. They wanted to play in the document management space. They also had a rag-tag group of folks from Vermeer Technologies who were demonstrating interactive web sites with FrontPage extensions. The result was Microsoft releasing SharePoint Team Services (STS) and Microsoft SharePoint Portal Server 2001 in relatively short succession.

The problem was that STS and Portal Server were as different as night and day. Portal server was built around the Exchange database engine and STS was built around SQL server. Portal server was focused on documents and had versions. STS was built around lists of items and didn’t have versions.

Ten years ago there were expensive document management systems were expensive. You only implemented them if you had a major process to automate. Lists were being created with Microsoft Access – or more commonly Microsoft Excel but sharing and managing that list data was difficult. Inside an organization the spreadsheets would fly back and forth. The lists were shared externally via email as well – sometimes unintentionally. Coordinating changes was a huge challenge.

I started building on SharePoint in 2001 with a project designed to improve the ability for a packaging company to communicate with its partners. It was innovative at the time – and it meant struggling through the development on a platform that wasn’t really ready for people to program on it. The version of the Exchange database engine that SharePoint used had issues – and it wasn’t really designed for what it was being used for so we found quirk after quirk. I vividly remember that none of the monitoring tools would tell us that SharePoint was down because deep in the core SharePoint would send an HTTP 100 Continue message if it ever couldn’t respond quick enough. That’s great if you’re waiting on the database to return a record but horrible if you’re in a deadlock situation where the resources are all consumed. It meant that we had to write custom tools to plug into the monitoring tools to detect if SharePoint was down.

The 2003 versions of the software moved Portal Server to a SQL database engine but lost versioning in the process. The net result was organizations that really couldn’t upgrade because they had built processes around the versioning – sure there were the backwards compatible document libraries in 2003 – but that was just the same as leaving 2001 around since they still ran on the Exchange database engine and had a completely different set of features which served to create confusion.

By about 2005 my entire world became SharePoint. Instead of doing ecommerce development I was building intranets and integrating systems into SharePoint. Mostly it was moving from a system designed to support external folks to supporting internal folks. The real benefit was that I was used to high-activity web development which most developers of the time weren’t used to – and in many ways high volume web sites is still a rarity.

In 2007 portal server was dropped from the name and Office was added. This reflected the much stronger integration to the Office client applications than had ever been possible – but the loss of the word Portal was the definite signal that the world had changed. It used to be that everyone wanted a portal, a place from which everyone would launch into the corporate resources. However, by 2007 it was clear that the word portal was too fuzzy and confusing to be useful. After all, we were in the age of search, not the age of portals. Yahoo had lost to Google.

In 2007 we were finally back where we started with versioning with a few enhanced features along the way, like our new workflow engine. However, the big change was less about SharePoint and more about the transformation SharePoint had caused – or at least participated in. By 2008 the document management market was starting to soften. People realized that the big systems for document management weren’t needed so much anymore. SharePoint 2007 might not handle large organization document management needs but most organizations could see value by using SharePoint.

By 2010 we finally had the set of tools in the product to support larger scale document management scenarios. Development tools were integrated into Visual Studio so we didn’t have so much heavy lifting. No longer were we hand-crafting XML, Text files and creating CAB files. Finally we can focus on getting things done rather than dealing with the mechanics of SharePoint development.

I had the honor of spending 10 months working on the Microsoft patterns and practices SharePoint Guidance – so we’ve finally got some good guidance for SharePoint development. In short, I believe we’ve finally got a platform for development.

Today, we’re thinking about enabling corporate developers to create solutions by developing code in the Sandbox. We’re looking at enabling organizations to have SharePoint hosted in the cloud. Strangely while I’m having conversations with clients about Sandboxed solutions and the cloud very little of what I do fits in either of these categories.

It’s a pretty different world than 10 years ago when I started – but I believe it is honestly a better one – at least when it comes to SharePoint.

Article: Strategies for Integrating SharePoint into Your Learning Strategy

Like it or not, 2 out of every 3 organizations are using SharePoint, Microsoft’s unstoppable platform for communications, collaboration and information management. SharePoint can be a great tool for learning organizations and it represents potential competition for a learning portal. The good news is that SharePoint’s array of options for integration that make it an ideal platform to marry up with an existing Learning Management System (LMS).

Without an LMS
Perhaps you’re just starting to get your programs off the ground and you don’t have an LMS in place.  SharePoint has a series of options for you.  You can start with the SharePoint Learning Kit ( ) which supports SCORM 1.2 and SCORM 2004.  The basic features such as managing assignments, individual classes and training programs are supported.  While there are certainly richer for-pay options which bolt on to SharePoint, you can get your feet wet with a SharePoint based LMS virtually for free.  The SharePoint Learning Kit (SLK) is free and will even run on SharePoint Foundation so you don’t need a separate license to use it.

The for-fee SharePoint based LMS tools add more types of quizzes, surveys and better administration tools for a price.  The good news is that from a price-perspective the SharePoint based LMS solutions tend to have lower costs because they do not have to make investments into basic document and list management, security or portal features – all that comes “for free” from the platform.

Read More…

Pouring Concrete around Your Development in SharePoint

Several times over the last few weeks I’ve been confronted in one way or another with the need to protect coding from the interloping of the user and site administrator in SharePoint and conversely I’ve seen attempts to pour concrete around development that could be better left in sand so that it could be changed and moved. Through this I realized that there’s a need for better understanding around the model shift with SharePoint and its impact on software configuration management (SCM).

SharePoint’s a Different Kind of Animal

It’s often been said that SharePoint is a desert topping and a floor wax – paying homage to Shimmer a fictional product from Saturday Night Live. It’s also been said that SharePoint is like the proverbial elephant discovered by five blind men – each having a different perspective of what the animal is. Even within SharePoint you can see very different parts of the platform, however, some of the most interesting changes aren’t about the product itself but in the things that it enables organizations to do.

By removing the barriers to creation (what Microsoft calls composites) the tool allows business users to create solutions to their problems. They dynamically create storage for new kinds of information – which in the past required a database administrator to create a table or add a column. The business user can string together a list, a workflow, and some alerts and create a system for managing or supporting some business process. The agility afforded by this toolset means that changes can be made at any time. In SharePoint many of these changes are version controlled so if a mistake is made the user simply reverts to the previous version.

This agility is in stark contrast to the structure of a large scale development effort. Organizations spend an inordinate amount of time building structure around the software development process so that systems can be recovered and recreated. This effort is necessary in a world where specialized skills are necessary to create and maintain systems. You simply can’t have the payroll system changing everyday – and changing in ways where it’s difficult to explain to an employee – or the government – why a person was paid exactly what they were paid. So there are source control systems where code is maintained and controlled. There are configuration management practices which are used to govern changes to the system.

All of this leads to both repeatability – you can restore to any point in time and replicate it anywhere at any time – and control. This is desirable from a recovery perspective. These two outcomes are very desirable in a traditional system – and since traditional systems don’t allow users to create solutions on their own their relatively limited flexibility and need for coordinated activities is not a major barrier.

The real question comes when the rigidity of a SCM meets the agility of SharePoint and we have to answer hard questions about whether something should be treated as traditional code or whether it should live in the user world of agility.

Mapping the Extremes and the Middle

Even in SharePoint there’s some level of clarity that some things are software development and need SCM. If you’re deploying farm based solutions there’s a need to have a brief outage as the software is deployed – this is a clear reason to control the rate of deployments of solutions. Equally clearly if you are adding a contact to a contact list, you know that this is content and therefore should be handled like content – instead of being handled like code. That’s the easy part. Where it gets more difficult is when you look at items which are markup languages and non-compiled languages.

Consider that Cascading Style Sheets (CSS) controls the look and feel of the web site. It’s a language for expressing how the display should look. Most folks don’t consider CSS to be a programming language; it’s a markup language much like HTML. However, there is a sense that CSS should be protected like code because it has a great potential for causing issues on the site. Yet, many new web parts need their own snippet of CSS to work, sometimes overriding the behavior of the code CSS for the solution.

Like CSS, eXtensible Stylesheet Language Transformations (XSLT) isn’t a programming language. It’s a markup language with potentially huge power to change the appearance of the site. With that sort of power it “feels like” it should be a part of SCM and managed. But what about the XSLT used to format search results, or the results from a Really Simple Syndication (RSS)? It seems like our rules break down when the same technology is used for core system things and for user controlled formatting of resulting data.

JavaScript is the language for manipulating objects in HTML once it’s at the client. It’s a programming language, no question about it. This would lead you to believe that it should be a part of the SCM – but again with SharePoint we often have JavaScript that is a part of a web part that a user might add to a page. Do we restrict all JavaScript to being a part of the SCM process?

In SharePoint we also have the unique challenge of SharePoint features and the XML they contain. XML can tell SharePoint to create a content type, a list or even to create data. So does the XML that sets up your list and the sample data count as code – or content? Making the situation more challenging is the user code host – sandbox execution – which allows compiled code to run in a restrictive environment.

Does your head hurt yet?

Criteria for Decision Making

It used to be that we could make a simple decision. If it was compiled it was code – and if you didn’t have to compile it then it wasn’t “real” code. However, over the years the lines have blurred to the point where making the decision based on the file type doesn’t work. Instead we need to make decisions based on the intended use of the file.

Breaking down intended use a bit there are two key things to think about. First, what’s the worst that can happen? In other words, if the file gets modified, out-of-sync, or destroyed what’s the worst case? Second, how are changes going to be managed?

In the case of what’s the worst that can happen, you might have a style sheet that drives the rendering of the entire site. In this case the impact of the file being modified or deleted is pretty large. As a result you would want to protect against that. Conversely, if there’s a style sheet that is responsible for a minor part of the web site – it might be OK to treat that as content. SharePoint has built in version control and a recycle bin so recovery should be as simple as reverting to a previous version or recovering the file from the recycle bin.

The other side of the coin is how the changes are going to be managed. If you go the code approach to management you have to go through the configuration management process to deploy the code to controlled environments. This can add weeks and weeks of time to the deployment cycle. If there’s any need for agility you can’t treat it as code. Conversely, if the item never or rarely changes it might be acceptable to treat it as code. When making the decisions you should consider how many variations of the same thing that there may be – if there are many variations it’s harder to manage them as code.

Of course, some items, those items which are compiled code that can’t be deployed to the sandbox must be treated as code and managed through the software configuration management process so the decision has been made for you due to technical or design limitations. For everything else, the question is how you’re planning on using it.

Making it Concrete

Treating anything with a configuration management process is like pouring concrete around it. It’s certainly possible to remove something buried in concrete by breaking the concrete out and starting over – but it’s not nearly as easy as pulling up stakes and moving on. There are some things you need to pour concrete around. A backyard basketball goal needs concrete to steady it. However, Pouring concrete around the stakes of your tent may not be the best choice. Pour concrete when you need to – and avoid pouring concrete when you don’t need to.

Recent Posts

Public Speaking