ECM blog

2008-05-10T01:07:00Z

Hi everyone, it's been a long while since we've posted here. However, we've been doing a lot of posting on the Enterprise Content Management blog not only about Web Content Management and SharePoint, but also topics around Records Management and Document Management.

If you haven't already, head on over to the ECM blog to get your latest news from us in this space. Note that this WCM blog will eventually be deleted, so it's safe to unsubscribe.

Thanks!

--George Perantatos, ECM Program Manager

Content Management Server and SharePoint

2006-01-22T08:19:00Z

[posted first on the Sharepoint Team Blog -- we'll continue to post CMS/WCM focused content here]

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

CMS2002 SP2 ships!

2005-11-09T09:01:00Z

Whoa, weird, the first real content entry is not about Office "12" WCM but about CMS 2002: We've released CMS2002 SP2 today!
I thought that was worth a quick note.
So: We've added support for SQL2005 and ASP.Net 2.0 (Master Pages as well as the authentication and navigation provider models, the rest is coming in the Office "12" timeframe).
The VS2005 IDE works as well (please follow the instructions in the readme file).
Full regarding the list of QFEs rolled up details will be in the official communciations.

This release has been eagerly awaited all around, let the downloads begin:

English: http://www.microsoft.com/downloads/details.aspx?FamilyId=3DE1E8F0-D660-4A2B-8B14-0FCE961E56FB&displaylang=en
Japanese: http://www.microsoft.com/downloads/details.aspx?FamilyId=3DE1E8F0-D660-4A2B-8B14-0FCE961E56FB&displaylang=ja
French: http://www.microsoft.com/downloads/details.aspx?FamilyId=3DE1E8F0-D660-4A2B-8B14-0FCE961E56FB&displaylang=fr
German: http://www.microsoft.com/downloads/details.aspx?FamilyId=3DE1E8F0-D660-4A2B-8B14-0FCE961E56FB&displaylang=de

It's alive!

2005-10-05T08:43:00Z

Hello World!
Hallo Welt!

My name is Gerhard Schobbe and I'm the Group Program Manager for the Content Managment Server team. I have the honor to produce the first entry for what is to become the team blog for a bunch of folks working on web content management features that (drumroll -- well ok, the cat left the bag at PDC) will be based on the Sharepoint stack in the next version of Office '12' servers.

As a quick aside: What does a Group Program Manager do? Most days, I'm wondering about that too, but the shortest meaningful answer is that a GPM @ MS is reponsible for a team of program managers who write the specifications for a set of capabilities, in my case centered around web content management.

Anyway: It's a super-exciting release for us with and boy, is there a lot to talk about: what did we do, how did we do it and of course WHY did we do it?
I'm sure there are many questions out there, both from customers and users of the current Content Managment Server 2002 product and from audiences interested in Sharepoint technologies. We'll make an attempt at providing both overviews and drilldowns on those topics that caused the longest and toughest discussions as well as on the topics that are the most critical (in our humble opinions) to get clarity around IF one were to embark on deploying a website based on what we built.
And if we're neither complete nor too strucutured about that task, hey, that's why this is a blog.
We'll read all the comments and react to the ones that move the discussion forward into fruitful directions.
We'll try to post relatively frequently but when we're not, rest assured we're working hard on something that's important for the release and we'll be back soon.

So much for the first post.
Enjoy!

Web Content Management in Office "12"

ECM blog

Content Management Server and SharePoint

CMS2002 SP2 ships!

It's alive!