Content Management Server and SharePoint
By now many people have heard that the upcoming version of MCMS 2002 (which I’ll refer to as ‘CMS’ for the sake of this post) will be built entirely on the Windows SharePoint Services architecture (with SharePoint Portal integrating the new CMS publishing features). I wanted to give some insight into how we went about making this decision.
Going into the release cycle, the CMS team faced a set of challenges: Should we continue to iterate on the code base that the current CMS2002 product was built on or take a more radical path by switching to the Windows SharePoint Services infrastructure?
A few key individuals in the team took on the challenge to work out how an re-implementation of CMS would look like, working across teams with both the ASP.Net 2.0 team and the WSS team as the combined platform this would be based on. The driving force for this effort was derived from the developer and customer feedback we had received, some directly, some through the Microsoft field. This feedback provided the backbone for the goals that have defined the work for this release. Note that these goals are intentionally high-level, technology-agnostic in nature.
- Provide much deeper integration between CMS and SharePoint functionality.
- Make creation of dynamic, highly customized, content-centric websites dramatically faster and easier
- Address the miscellaneous collection of 2nd order (compared to the call for integration) feedback that had collected up
I’ll expand on all three goals briefly because each one contributed to the ultimate decision what technology platform to build on.
- The first goal came through loud and clear in many conversations with developers and customers ever since the MCMS 2002 release. This was phrased many times as: ‘Don’t make me pick between CMS and SharePoint every time I start a new website’. Other times, it was expressed as requests for more expansive versions of the MCMS 2002 Connector for SharePoint Technologies (codename “Spark”) which we had released as a first response. It was however becoming increasingly clear that continuing down a path of patching over the technology gap between the stacks scenario for scenario wasn’t a suitable long-term strategy to address the customer needs.
- The second goal boiled down to lowering the amount of costly (to design/code/maintain) custom code all CMS users had to write: Why did everyone have to code to get site navigation? Or search integration? Or workflow flexibility beyond what was hard-coded into the product? Surely there was a better line to draw that would free customers from most of this routine work.
- Thirdly, looking at the list of existing customer pain points was painful: add a security API, remove the scale limitation around the # of pages/channel, offer versioning and rollback for all assets, add search (seen a website without search lately?), figure out more flexible authentication, create a better workflow story, improve content deployment tools and reliability, eliminate client-side installs for the HTML editor as well as the site manager -- the list was long and distinguished. None of the requests were unreasonable and each clearly was driven by a valuable scenario. But the list was long. Too much to do in one release for the team. Well, assuming we had to do all the work, anyway.
At this point, it became very interesting to work out what it would mean to build the web content management product natively on Windows SharePoint Services. It would get the CMS team out of the business of worrying about repository services like check-in/check-out, versioning, backup/restore, DAV support, security etc. It would also lay a very strong foundation for goal #1: integration. Furthermore, the WSS team had plans to make authentication pluggable via the ASP.Net 2.0 provider model and they were working on integrating a complete workflow engine (Windows Workflow Foundation). The storage system had been designed to handle hundreds of thousands or even millions of items so scale wasn’t really a concern. And integrating on top of WSS would simplify integrating with SPS so published sites could use personalization, search, line-of-business integration and other capabilities.
The key question was whether the fundamental work of integrating the concepts of a web content management system into the larger SharePoint family was a) possible in principle and then b) effective enough from a development cost perspective to leave us room to improve the WCM application and take care of the pain points that would not already be addressed as part of the integration itself. Phrased another way, would the sum total development work to add template-based page rendering, web-based and client-based content authoring experiences, performance improvements to support Internet scale reliably, content staging, schedule trimming etc. still allow us to deliver a release in a reasonable timeframe AND leave room for much-needed feature adds to get a much more complete and reliable content staging feature (a pain point) and support for multi-lingual web sites?
It took several months of design and costing effort with several iterations to arrive at a feature list that achieved all these things with reasonable risk trade-offs. In the end, it turned out to be attractive enough to finalize an architecture based on the new and improved WSS “v3” platform.
At all times, we had tracked the amount of work required to ensure a smooth transition for existing customers as a “P0” (meaning work in this area would be considered even more important than the many features labeled “Priority 1”). Data formats would be different so we designed a data migration feature that could be run repeatedly and also offered incremental content migration. The custom code that made up the actual site application that each CMS customer created needed migration so we set out to make the APIs equivalent and kicked off work streams to create guidance for developers that would make whatever porting work was required as easy as possible. It was during this time that we also had a LOT of discussions on whether to attempt a shim for the CMS Publishing API. We ultimately decided against that route for a set of reasons: Despite a lot of design work and testing, it was likely that the shim would not work in 100% of cases as the underlying semantics of the SharePoint store and business logic were pretty different. We had looked at quite a few real-world examples and had to assume we would not succeed at 100% compatibility. The conclusion indeed was that it was likely that the shim would work for 80% of the code for 100% of customers (which would compel everyone to code changes and thus satisfying no one) rather than working 100% for 80% of customers (which would have been a better indication to go forward). In addition, we had plans on the books to REPLACE much of the need for the “standard” custom code as part of the second goal, e.g. for site navigation, deployment scripts, authoring console customization and workflow. In the end, we picked a path of 100% automated data migration coupled with assisted (but ultimately manual) code and template migration. Targeted call-downs to key customers met with approval so this became the plan of record.
Having built an overall plan that seemed to satisfy the constraints, we then started in on the work. And now, a little more than two years after the work began, we have shipped the first beta of what has turned into a very compelling overall Office 12 servers story of which WCM is now an integrated and fundamental part of to a limited audience of early adopters. We’re indeed heading for a much broader Beta 2 release that will let everyone have a look at the full web content management system that is built on top of WSS “v3” platform.
I’ll end this first chapter of the story here. We’ll be posting a ton of details on what is actually in the product, who would want to use the feature set and in which scenarios, how things work under the hood (starting with the ‘page rendering model’) and occasionally even why. We’ll also go into details on how the migration from existing, CMS-powered sites will work and how SPS sites will benefit from the enhanced publishing features.
Gerhard Schobbe
Group Program Manager – CMS Team
