Wednesday, September 22, 2010

Sitecore for President (well for Government Sites)

Roundedcube will be featuring Sitecore at the National Association of Government Webmasters (NAGW) to be held in St. Louis, MO from Sept. 22 – 24. We’re definitely excited for being part of the show because I think we definitely got something to show. One of the highlights will be our work for the City of Ogden, UT which was released last year (a Sitecore case study is also available if you want a copy).

One of our goals in the NAGW show is to feature how Sitecore’s capabilities match up with government sites’ needs and processes. This is not just in the technical point of view but also with its user-experience, deployment scenarios, maintenance, and multi-site/multi-language capabilities. I think these are some of the most important factors that government entities look for. So, let’s take a look at them one by on in summary form. This is by no means the complete list but I’m highlighting what government sites may be looking for.

Technical Capabilities

I can’t tell you everything about Sitecore here so go to sitecore.net to get more details but here’s a quick synopsis. It’s built on .NET (primarily ASP.NET). If you know .NET, then you should know that Sitecore takes advantage of .NET capabilities and enhance upon them such as provider model, reflection, XML/XSLT, and others. Programmatically, if you’re a C# or VB.NET shop, you’re good to go. Sitecore has a rich set of API from content creation, workflow invocation, security, to just about anything else you can do with .NET. It supports .NET 3.5 and up, so if you like lambda expressions, LINQ, entity framework, and other enhancements, go for it. One of the most complex systems we built with Sitecore was integrating JD Edwards on AS/400 through a SOA-based middle-tier using Web services as Sitecore integration points to expose customer-based pricing, product configuration, and others. In government sites, you could be talking about several disparate custom/off-the-shelf systems. Having a common platform to integrate them and manage them can be a key factor in realizing your ROI. So, in short, Sitecore is so open that you can do whatever you need to do in .NET. I consider it a development platform not just a CMS.

Multi-site/Multi-language Capabilities

If you’re looking into Sitecore to fire up your city site, then you might also consider using it for other sites. Sometimes, it’s hard to justify having a commercial product when open-source options are available. But, if you start thinking that you can have several sites on one instance of Sitecore, you can start lowering the cost/site. Even if you only have an Intranet, that’s using Sitecore twice. In Sitecore, you can create different security domains similar to Windows. That means, you can set up different domains and security access per site. There’s also the UI, Sitecore uses the Windows Explorer paradigm for traversing your Website. That means that you can make your Website root nodes be like your C and D drives. Of course, everything else in Sitecore can be multi-site aware and group content, workflow, media files, users/roles, and others together. You can also share them between each site if you need to. If you really need more advanced multi-site capabilities, consider looking into Sitecore Foundry which is built on top of Sitecore CMS.

Some government sites have multi-language needs. Sitecore’s architecture accommodates basically any languages. You can either have a per-content translation if all your site requirement is that the site have a language translation. Or, you can combine Sitecore multi-site and multi-language capabilities to have a very flexible content-managed site. For instance, you have an English-based site but also want a Spanish translated version of the site but not the entire site. So, you can create another site and have Spanish be its default language. Remember that a content’s language can be versioned as well. This means that your English version can be in version 5 while your Spanish version can still be in version 3. Not the same version has to be published at the same time.

User-Experience

I quickly mentioned earlier that Sitecore uses Windows Explorer paradigm. That’s just for the Content Editor (which is a built-in Sitecore app). Sitecore has several user interfaces (UI) but its main one mimics your Window desktop. This means that a Sitecore app runs inside a Sitecore window. Can you say multi-tasking?

The coolest feature is obviously the Page Editor which allows you to update your site within the site’s design. It’s old news of course, but just remember that a Sitecore solution should have content reusability. This means that if you update content such as a news item’s title on the news listing page, then it better be updated in the related news areas or even on the news details page without anymore than saving and publishing the content. Other CMS systems unfortunately do not have the level of content/design separation that Sitecore has so even if they have the in-page editing capability, it doesn’t necessarily mean that it’s easy to update content.

Sitecore also has UIs for designers, developers, and administrators in addition to typical author/reviewer/publisher UIs. This makes the Windows paradigm much more effective. If it’s worth it, imagine creating your own Sitecore apps to manage external systems or data. This gives everyone a single point of site administration…all browser-based.

Deployment Scenarios

City/town/county sites are normally on a one-server deployment scenario. That’s why hosted CMS solutions are one of the more popular commodities out there for government. But there are those that would like to consolidate systems together and when you do that, you sometimes need in-house servers. And if you have in-house servers, security and performance become factors to consider. Sitecore can accommodate separate function-specific servers such as an authoring, publishing, and delivery server. You can cluster these servers when needed. Since Sitecore uses your database (SQL Server or Oracle), it’ll run on whatever clustering you have on those. Sitecore can even run on Azure (cloud-processing/computing available from Microsoft) but I’m sure it can maybe even run on your own cloud if you have one. Obviously, clusters and separation of roles contribute to the overall performance of the system. It also contributes to the solution’s security since now each layer (or environment) can be protected in different levels. You can put your delivery servers outside your firewall while keep the authoring server internally.

For disaster recovery (DR), you can have your load-balancer control that if you like. You can have Sitecore publish to a DR server at the same time the delivery servers are updated. So, when the regular servers go down, the DR server can kick in immediately. Or, you can use the DR server in a load-balanced environment to help performance. Yes, it sounds easy because it is.

If you have only one server, then you can still separate the server roles if desired because remember, Sitecore is built on top of ASP.NET which makes it just another ASP.NET application. So, you can have multiple instances of it in one server (or virtualized if you like). Just make sure to talk to your Sitecore rep on what this entails in terms of licensing.

Anyway, Sitecore’s deployment capabilities is one of the factors that I consider it as an enterprise-ready CMS but flexible enough in a one-server environment.

Maintenance

Government sites normally means a limited IT staff, even less when it comes to the Web site. So, having a CMS that make administration easy should be on top of the requirement needs. With Sitecore’s UIs, all the day-to-day site operations are readily available such as security.

There was a question on LinkedIn regarding Sitecore maintenance on the type of staff member that should be an administrator. Basically, I recommended a technical person who has experience with security, audits, applications, and other technical stuff. I added that separating Webmaster roles from site admin can sometimes be crucial but if that’s not possible, then you need to have both the marketing and technical skills to administer Sitecore. The CMS addresses both the marketing and IT responsibilities when it comes to Web sites.

In terms of the Sitecore’s performance and availability, remember that since this is built on ASP.NET, it’s just an ASP.NET application. There are no additional server components that are installed on the server(s). This means that you should plan the same way you would with another ASP.NET application.

Bottom line though, the administrator should attend a Sitecore Administration training and see how easy it is.

Summary

Government sites pose a different level of challenges for Sitecore such as budget, staff, and processes. At first glance, Sitecore can be extravagant if you consider open-source or hosted alternatives, but if you consider the above factors, you may be able to determine how to maximize your ROI. I know our clients have.

*EDIT October 28, 2010. We have moved our blog to http://blog.roundedcube.com and you can now comment on this specific post at http://www.roundedcube.com/WhatsNew/Blog/sitecore-for-president