| A functionality inventory, like a content inventory, is a way of taking stock of what your Web site does. Too many times, developers are given an existing application and told, "Here, build this." Unfortunately, even the most gifted developer would not be able to discover every feature or function within the application. At best, they may be able to discover half the features in the existing application. Imagine being handed Microsoft Word, never having worked with the application before, and being asked to re-create it from scratch. This situation is often where developers find themselves, and it often leads to failed implementations. A functionality inventory is a collaborative effort between the business folks and the IT/development staff. The inventory serves two functions: review of the existing functionality and a road map for the new site. The review is helpful in knowing what the site does today. In the same way that a content inventory can help point out content that everyone may not have known about, the functionality inventory provides the baseline functionality that your converted Web site must have when the project is finished. Does the site have a "contact us" page? How many contact pages? How can customers order products and services? Is there one way or many ways to download white papers? Over time, Web sites tend to collect functionality as they collect content. Different developers, different managers, changes in technology, and changes in technique all lead to situations where a Web site grows functionally sometimes inconsistently and often sprawling. Once you've identified what your site does, what is your new site going to do? This is the other important benefit of the functionality inventory. After you have identified what your site does, you can effectively plan for what you need to develop. This is not necessarily a straightforward exercise. Do not think that once you've finished your functionality inventory, you're done. The inventory will tell you what features your site has and, in some cases, what you can potentially eliminate. The "Already Built" Syndrome We have, on more than one occasion, been presented with an existing application and told to simply "convert" it to some new platform. In this context, the word "convert" seems to indicate that there is some process by which an existing application can be morphed, upgraded, and/or magically transformed into a new version of itself running on the latest technology with little or no effort, since "it already exists." The truth, however, is that most applications can't simply be "converted" they have to be rewritten. This means that no matter how much of the application already exists, the existing application will have to be rewritten, from scratch, to yield the "converted" application. Consider this: If the government wanted to convert all asphalt-based roads to cement-based roads, they would literally have to rebuild, from scratch, every road. It's true that some of the work necessary for a brand-new road has been done (cutting down trees, clearing land, and so on), but it doesn't diminish the fact that the old asphalt road must be torn up and the new cement road laid in its place. In the same way, it's true that users will expect the application to operate in a particular way, and the application's functionality should be well known (although that's not as true as we'd like). However, it still doesn't mean that it's any easier to convert to a new technology. Keep this in mind, since many of you will be "converting" from ASP-based applications to ASP.NET. |
Beyond what we've identified here, there are other benefits to the functionality map: Traceability for QA: Once you've built the new Web site, what do you test and how should it operate? The functionality inventory will provide you with a way of tracing functionality in your new Web site back to what you had in the older version. Resource and effort planning: Many companies engage in a development effort without fully understanding what the work effort will be. We're not suggesting that the functionality inventory will provide you with a complete picture, but it will give you a start. By understanding what features the current site has, you can better plan what resources will be necessary to help build or rebuild that functionality in the new site. In addition, very few companies are likely to have the original developers available to them; the functionality inventory will help the new developers understand the site better. Removing duplication: Are there multiple "contact us" forms? How about ordering processes? Is functionality implemented consistently? A functionality inventory will expose all these issues. Since you're re-creating your site, this is the opportunity to do some housecleaning. Guidance for template design: In CMS, the templates will house the functionality in your site. If you know what functionality exists and how it operates, you can more effectively design the templates that support your site. In general, a goal of CMS is to try to leverage one template for as many pages as practical. If you understand the functionality within your site, you may be able to create more robust templates to support multiple sections of your site. Without this information, you will probably create more templates than are necessary, thereby increasing the development effort necessary to rebuild your site.
|
