Porting Legacy Web Apps to Sitecore Quickly

Have you ever had a client request where they’d like to have any of their Web apps to be ported over to Sitecore?  And, why not, it looks like Windows and it’s .NET, it can’t be that hard.  Well it can be easy and it can be hard depending on what level you want to port the application.  For this post, we just want to see the legacy app in the Sitecore Shell.  Sometimes, that’s all is needed since the Web app already works pretty well.  Plus, it just looks cooler when your app is within Sitecore.

So, to show the app within Sitecore, we just need to create a Start menu item that invokes the remote Web app.  Let’s start.

Power up Sitecore and login.  Click on the Sitecore “start” button > All Applications > Sitecore on the Net > Sitecore Homepage.  That’s just the Sitecore corporate site.  I’m guessing you’re following what I’m getting at.  You can easily encapsulate (frame) any Web apps that you have created. This is really important because Sitecore let’s you incorporate legacy Web applications especially when it takes a while to port a complex application.  This gives your CMS users a way to access the legacy app through the Sitecore shell provided that the app doesn’t interfere with Sitecore’s windowing mechanism.  There might even be a way to pass data from Sitecore to the app through the URL because that’s essentially how the Web app is invoked.

You can quickly do this by going to the Core DB.  Open the Content Editor and go under Documents and Settings. Traverse the nested folders until you get to Programs.  Inside Programs, you can create a Start menu folder, or the “shortcut” that invokes your legacy Web application.  To create the “shortcut”, which is really a Start menu action, select it from the Insert ribbon.  The most important piece of data you need to assign is under the Message field.  Enter:

RunExternal(\"<URL>", \"\", \"Software/32x32/application.png\", \"<WINDOW TITLE>\")

where <URL> is the Web address to your Web application, <WINDOW TITLE> is the title that is shown on the Sitecore window that appears.  You can also change the icon that appears on the window if you’d like.  Just make it the same icon that you specify in the Icon field of the menu item.

To see the new menu item, refresh the Shell or switch to the Master DB (which refreshes the Shell), and notice that you’ll find your new menu item in the Start menu.  Clicking this item should invoke your remote legacy Web application.

This is the quickest way. Obviously, you can’t do much with this since the Sitecore and the app are not really integrated.  There is only one way communication, if even any from the URL.  But, you can actually use Sitecore’s security to restrict access to the Start menu item, thus making it seemingly secured  Of course, you still have to keep the app secured somehow but at least there’s another level of security that can be used on top of the Web app itself.

There are other two ways to port apps into Sitecore.  With moderate complexity, you can use Sitecore as the app’s data storage.  This means that you’ll have to figure out how to port DB tables to templates (which is pretty simple since that’s how they initially taught us during Sitecore training to explain the concepts).  You can still just use straight ASP.NET controls to do your UI and just use Sitecore APIs to update those related Sitecore items.  I actually created one like this that essentially converted the ASP.NET generated site into PHP files and published the site to Linux with Apache complete with uploaded images, etc.

The most complex way is basically creating a XAML app.  That’s essentially how the native Sitecore apps you see now are developed such as Content Editor, Workbox, etc.  This has been the case since v5 so I’m not sure now how compatible Sitecore’s XAML with the Windows Presentation Foundation (WPF) (Anyone from Sitecore???).  This way of porting the legacy Web apps benefit from the separation of UI from logic, which is what XAML was supposed to achieve.  XAML is intended to be device-independent.  This method is the most lightweight and you can use all the readily available Sitecore-specific XAML controls already created by Sitecore.  You also benefit from the UI’s performance techniques such as AJAX and others without thinking about them.

Anyway, I’ve given you 3 ways to port your legacy apps.  Sometimes it just as easy to port an app than to only integrate them especially when it requires administrative UI.  One of the main reasons that Sitecore is so powerful is its UI, so leverage that with your legacy apps and future ones.

Sitecore OMS vs. Sharepoint….hmmmm

I had an initial reaction from my VP of Marketing, Aaron Branson, regarding my take on Sharepoint as being great on audience-profiling, targeting, personalization, and workflow in my previous post.  Aaron says, “What about OMS?”, who, by the way, is one of the first OMS Certified Professionals.  I just want to quickly clear things up that I have not misspoke since I think that Sharepoint is good for these.  I never mentioned OMS because I wasn’t trying to make that connection.  Note: For the workflow feature, it’s more between Sitecore and Sharepoint.

Well, now I would like to make that connection.  The Online Marketing Suite (OMS) is an evolutionary product that changes how a CMS can display marketing-appropriate content to particular users.  Its foundation is its behavioral engine that allows it to analyze how to best show particular content and target the correct audience.  OMS is marketed as an analytics tool, which compared to Sharepoint’s audience targeting, personalization, and targeting is totally different.  How so, you ask?

Although both products may be using similar words/phrases to market their products, they actually have different purposes and basis on how they do it.  There’s a reason why the OMS product name has “Marketing” on it.

Audience Profiling
OMS Sitecore OMS profiles its users based on the visitor’s site behaviors.  The keyword is “behavior”.  I’m sure there’s a way to incorporate additional user information to fine-tune the profile but that’s when you know who the users are.  This means, OMS profiles anonymous users  to be able to deliver better contextual content.	Sharepoint Sharepoint profiles is based on “known” information about the user.  As I said before, it’s initial intent is for internal sites where users are in some database.  For Sharepoint, it’s the Active Directory (AD).  The AD contains organizational, demographic, departmental, and others that help content authors deliver appropriate content that pertains to them.
Targeting
OMS OMS targets based on its behavioral analysis of the user.  It does its analysis using tests such as classic multivariate and A/B splits.  Whichever combinations perform better, the marketer can fine-tune particular pages or areas of the page.  Targeting in OMS sense is meant more to improve conversion rates.	Sharepoint As mentioned before, Sharepoint uses stored known information about its visitor because they are logged in.  With this information, Sharepoint can target content appropriately.  For instance, a St. Louis picnic outing announcement will not likely show up for someone who lives in New York.
Personalization
OMS OMS’s personalization is a “push” from marketing.  It makes the site seemingly personalized to the user because of his/her site behavior.  For instance, if I visited a particular camera, I might see tile ads pertaining to that camera in the future (similar to the Nicam demo).  So, OMS personalizes the content for me instead of the other way around.	Sharepoint As a portal software, one of it’s strengths is giving the user control over what content he/she sees.  This is the basis for Sharepoint personalization.  Unlike OMS, it’s personalization is dictated by the user’s preferences and not necessarily by behavior.    Thus, the user “pulls” the content instead of marketing or whomever is “pushing” content.
Workflow
Sitecore Notice I changed this to Sitecore and not OMS.  The main thing to consider is the type of date stored in each of these systems.  For Sitecore, it’s primarily Web content.  The content goes through various department staff and reviews, approve, denies, or publishes them.  The primary “work” involved is reviewing the content.  Sitecore’s workflow mechanism is great for this.  It’s highly customizable and flexible to a point to where it’s possible to have Sharepoint-like workflow (not necessarily better, but has more out-of-the-box features).  We’ve done workflow where content actually goes out of the CMS into a preview server for outside approval.	Sharepoint Workflow in Sharepoint is a totally different monster.  It’s not just for reviews although in the end, that’s essentially what people do.  But, it’s more on the type of data that goes through workflow.  Basically, anything goes through its workflow such as (of course) simple Web content.  But, Web content is only one type of data it supports.  An organization can create workflow that adheres to its business processes and allows business users to collaborate on documents, although Sitecore can certainly be extended to do this. By the way, Sharepoint is essentially a host for Windows Workflow Foundation (WWF), thus making it pretty customizable and very powerful.

I’ve cited differences between OMS and Sharepoint (and with Sitecore as well) and the main concept to consider is that OMS is behavioral while Sharepoint fact-based (at least on these features).  I know each one can be retrofitted somehow, but out-of-the box this is what you have.  I hope this clears up any misnomers that I may have mentioned before in my previous post.

Sharepoint vs. Sitecore

This should really be: “When not to use a portal-centric solution.”  I’ve been asked before by a client/prospect why not use their internal Sharepoint implementation for their corporate site.  The simple answer is because it’s not meant to be.
I think that Sharepoint is a great product.  We even use it internally and it makes our internal processes go a lot smoother.  It helps us manage our documents.  It makes collaboration in our projects possible.  We are able to connect various business models into one system.  And, we can integrate it with other nifty Microsoft products we have access to as a Gold Certified Partner.  In brief, we love Sharepoint and I don’t know how we can manage our information without it.
With that said, it’s not always the best solution.  It can, however, be retrofitted to be a solution but that’s when more work is involved and thus not leveraging features that the product has.  When it comes to Sharepoint vs. Sitecore debate for external sites, there’s no sure winner…except when you know what the site is for. 
To me, Sharepoint is great for portal-based sites especially those that requires audience profiling and targeting, personalization, document management, and workflow.  But most sites don’t need this especially corporate sites.  So, why pay the licenses and the services to get it done?
On the other hand, Sitecore is great for content-based (instead of data) sites where the presentation is also a big deal.  Because of its “true” separation of content from presentation (where Sharepoint can’t really attest to), it allows for more control on the presentation.  Although Sharepoint can certainly be skinned, it’s not that straight-forward…remember using FrontPage at one point…and now Sharepoint Designer.
Here are my top reasons why Sharepoint is not the best solution for most external-facing Web sites:

• Licensing
  Sharepoint costs about $50k minimum to be used for external facing sites and that’s not including the Enterprise Search Server.  Compared to Sitecore’s entry point of $15k, Sharepoint is way too expensive. The main reason is because of MOSS for Internet Server (MOSSFIS) license which allows external anonymous users to access the site.  Hmmm…what if you want an extranet?  What would the licensing look like?  It’s just too complicated for this scenario.  Here’s a Sharepoint calculator if you’d like to see: http://community.bamboosolutions.com/blogs/sharepoint-price-calculator/default.aspx. UPDATE: See comments below for some discussion on this criteria.
  
• Developer vs. IT
  I think we can say that Sharepoint is enterprise-ready, but that' doesn’t mean Sitecore isn’t.  It’s just that the tools and how it’s deployed differs.  A lot of IT shops like Sharepoint because they can easily install it and maintain it.  Essentially, they have more “control”.  Sometimes, it’s a matter of politics.  But with politics aside, Sitecore CMS is geared more towards developers.  Sitecore really focused on making the software easy to customize and more open for complex functionalities…thus, more developer-friendly. I’m not sure what’s in store for Twin Peaks release, but I hope corporate can market it being more “IT-friendly”.  I think IT would like to to have inherent monitoring capabilities, backup tools, automatic updates, etc. 
  
• Development Environment
  We have several experience on developing on both platforms. As I said earlier, Sitecore is more developer-friendly and it starts with the development environment.  Essentially, Sitecore is just an ASP.NET application.  So if you know ASP.NET, you can develop using Sitecore.  I can’t easily say that for Sharepoint.  It’ll require more work.  Here’s a great blog on how to setup a Sharepoint environment (http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx).  Of course, this is just one of them but it should give you an idea.
  
• Deployment
  I guess this depends on perspective.  IT may say Sharepoint is easier to deploy than Sitecore because it has a set of instructions it needs to follow.  Remember, IT folks are not necessarily programmers, so they don’t like “exploratory” trial-and-error types of deployment.  To me, having deployed both, I say Sitecore is much easier to deploy the first time and follow-up updates to the production server(s).  The main thing is that you just need to have a very specific deployment process.  The only difference between Sitecore and Sharepoint is that Sharepoint created tools and written instructions, while Sitecore needs to have their partners define what’s appropriate for the client.  I think that you’ll agree that not every client has the same infrastructure, so allowing Sitecore partners to define it is a big plus.
  
• Content Separation
  Sharepoint markets itself having Content Management.  I can’t say that they are lying.  But, the only thing I can say is that they have a level of content management that can’t match up with Sitecore.  Sitecore has a true separation of content from presentation allowing for better content sharing and re-usability.  You can do that with Sharepoint but you actually have to really plan for it and if you don’t, you’re screwed.  Sharepoint’s CMS basically has the same concept as it did with MS CMS 2002…and where is that now?  Try creating a mobile or print-version of you Sharepoint-based pages…and let me know how easy that is…I can do that quickly in Sitecore.

What’s your take on Sharepoint compared to Sitecore?  Let us know.