Skip to content

John Bennett's blog

Identifying the services within a service oriented CMS

Monday, July 26, 2010

Dividing the service pieIn my previous post I talked about avoiding a database oriented architecture (DOA) and choosing a service oriented architecture (SOA) for our content management system (CMS).

The next big question is: How do we divide our CMS into large-grained sets of discrete functionality – business services?

A good CMS cleanly separates content from presentation.  Even simple blog-oriented CMSs have this separation.  This blog is currently hosted in WordPress.  By simply downloading a different WordPress theme, I can change not only colors and fonts, but the entire structure of the site.  I can add widgets to the sidebar, change the header image, show either full posts or excerpts on the main page, add buttons to share on Twitter and Facebook, change URLs or move pages around into an entirely different hierarchical structure – all without touching the content of a single post.

With a large news-oriented CMS, this separation is even more important.  We deliver news not just to browsers, but to all kinds of applications and devices – from iPads to Bing Maps and Google Earth, from Microsoft Surface tables to a 70s-style arcade game machine in Rockefeller Center.  But our reporters and editors shouldn’t have to worry about – or even be aware of – all of that.  They just need to worry about crafting great stories.

Thus, the most obvious business services within our CMS are what we call Editorial and Delivery.

As a news organization, we not only deliver the news – we consume it in enormous quantities.  Feeds like the AP, UPI, Agence France-Presse, and hundreds of other text and photo sources all flow in 24 hours a day.  Then there are data sources like weather, stock market tickers, lottery results, etc.; it all has to be gathered, organized, searched, categorized, edited, and made available for publishing.  Elections produce enormous amounts of data that we need to sort, search, and aggregate.  All of this functionality makes up the Ingest business service.

One type of ingested content absent from the list above is video.  NBC News (a parent of ours) is one of the largest producers of video news content in the world.  We support the websites for msnbc.com, cnbc.com, todayshow.com, plus shows like Rachel Maddow, Countdown, Dateline, Nightly News, Meet the Press, and more.  Video is different from text and photo content in many ways:  sheer file size, bandwidth consumption, encoding standards (and the computing powered needed for encoding), editing tools, advertising model, etc.

As a result of this complexity, video is a technical and editorial specialty unto itself.  I’m no expert in video, so I’ll leave the detailed discussion to others.  But as a major functional area that has to integrate with everything else in our CMS, Video is a business service.

Our other parent (Microsoft) gives us access to a wealth of technology.  Not only the platform building blocks of Windows Server, ASP.NET, WCF, etc.; but also cool stuff like the ability to scan huge amounts of content and determine the most important people, places and concepts mentioned.  And to automatically determine which stories, photos, and videos are related to one another.  Check out the Related and Topics areas near the bottom of a story page to see what I mean.  Like video, we want this capability integrated with many other parts of the system, yet it is more or less a world unto itself.  This is the Topics business service.

With any non-trivial system, we also need to concern ourselves with day to day operations and maintenance.  How do we easily deploy to and configure all those servers in multiple data centers?  How do we monitor them and get notified when something isn’t working?  How do we get detailed troubleshooting data for a server or process gone awry?  While some of these capabilities need to be part of the implementation of every service, the data aggregation, monitoring and notifications are business functionality that forms the Operations service.

In future posts, I’ll dig into these services and their component applications, focusing first on the Delivery service.