Why Would You Want to Integrate?

In a lot of cases, companies that are going to implement CMS for one Web application have several others that may or may not be migrated in the future. Often, these "legacy" Web sites have a great deal of functionality or are meant for one purpose, as opposed to an intranet that may be a collection of a number of different sites. Given how CMS operates, it's difficult to decide why and how you might consider rewriting these legacy sites using CMS. In some cases, it won't make sense to rewrite these applications; in other cases, it will. How do you decide?

CMS provides a rich environment for creating and maintaining Web sites. Conceptually, it's based on the idea that a developer will create a template, which will then be used by multiple authors to create some number of pages. Ideally, these templates will be used more than once across the site. A press release template, for example, could potentially be used for hundreds of postings. A summary template similarly could be used multiple times across the site. However, what if you had a phone directory application, for example? A very common interface for a phone directory is one ASP or ASP.NET page that allows a user to look up the phone number of a fellow employee. Do you write a template to replace the stand-alone ASP or ASP.NET page?

One of the basic questions of whether to convert an existing application involves reuse. Since CMS uses templates to create pages, the question really becomes, Does it make sense to develop a template for one posting? Further, if that template doesn't use any CMS functionality, is it worth the effort? Both questions are very relevant to the decision process; CMS is good for a lot of functions, but it doesn't fit in every circumstance. Here are some basic guidelines that you can use to help you decide whether to rewrite your existing applications or keep them outside of CMS.

How many times could you reuse the template(s)? Integration of an existing application really means that you'll create templates in CMS that contain the rewritten application's functionality. In other words, if you have a phone directory application that allows users to look up employees, you'll have to write CMS templates that perform the same function. Once you've built the templates, postings will have to be created within your site. Can you use those templates elsewhere? In this example, probably not. If you find that it's not possible or practical to reuse the templates you would create for the application, you might consider leaving it alone. However, if you could create one template that could be used across your site, it might be worth the effort. For example, instead of having one phone directory page for the entire company, perhaps you could create a template that allows a content contributor to specify a scope for the search. Maybe the template you create will be deployed for a divisional microsite instead of the whole company. This way each department could have its own employee directory page that searches just that department's employees. The same template could also be used at a higher level in the intranet for a more global search. Although this is essentially adding more functionality to the page, the additional functionality enables that template to be reused across the site, potentially providing needed flexibility as you turn over site management to content contributors. Also, instead of having a dedicated page for the phone directory, you could create a reduced interface that consists of just a first and last name field, which would be implemented as a user or server control. This new control could then be added to all templates in your CMS application.

How much could you leverage from CMS? Frankly, if you're going to rewrite your application in CMS, you should get benefit from it. At a very basic level, you can inherit the design of the site as well as the navigation. Your application can look just like all the other pages in your site. Plus if it moves or other pages in the site move, CMS will handle updating the navigation without your having to rewrite any code. Is there anything else? If we use the phone directory example, there could be some introductory text or field labels that could be turned into placeholders, allowing contributors to customize the form. We're not suggesting that you should "force" some change to the application to leverage CMS, but you do have some opportunities with CMS that may not have existed before.

Are content contributors going to create instances of the application? Sometimes, an application can exist in more than one place, or perhaps the application always produces one result, based on parameters. Our phone directory application is one example of potential reuse of the code across the site. However, suppose that you have code that creates a pie chart based on sales data from an ERP system or a database. If you have a number of groups wanting to include that kind of functionality in your site, it may be a good candidate for a template. You can build a template that allows content contributors to specify the parameters they want to use during the authoring process. At runtime, the code produces the appropriate pie chart. A variation on this would be to create a custom placeholder, which can be used across a number of templates.

Would it be useful for content contributors to browse to the application? If your application is a posting inside of CMS, users not only have the ability to create a hyperlink to the posting using the browse feature, but the application will automatically be included in the navigation. In this way, if the application moves, content contributors don't have to worry about modifying their content; CMS will automatically update all the links. This is true of "manually" created links or links that may have been programmatically rendered. This feature is especially useful when multiple links to an application may exist within your Web site.

How much processing does the existing application do? CMS necessarily adds overhead to a site. No matter how efficient any tool is, there is always additional processing that's required. That said, will the overhead of CMS be outweighed by the benefits it brings? If your existing application is processor intensive, you may not want to add an additional load. This is especially true if you're not able to leverage CMS in the application itself.

If you're integrating data with CMS, how often does the data change? CMS is indeed a dynamic solution. It dynamically generates a posting, based on the content in placeholders and the template. However, placeholder content doesn't usually change from view to view of the posting, unless an author changes the content. The data from this other system or database, conversely, may change frequently. Integrating data from an external system could mean programmatically filling placeholder values with the content from that external system or simply displaying the data as you would in any other Web application. If the data doesn't change that frequently or your business users want to have some workflow process to approve new content being published on the Web site, it may be appropriate to programmatically fill placeholder values. If your business users don't want to approve data changes or the data changes frequently, you may want to create a template without placeholders and simply place a data grid on the design surface, which will be filled at runtime. Again, you should consider template reuse. If the template you create for this data is only going to be used once, you may just simply want to leave it alone.