Suset Acosta
Aug 25, 2019
Development and Beyond
This is the third in a three part series. (See Part 1: Before you Start and Part 2: Design Stage Considerations.)
In addition to all the normal things that need to be figured out during development (task assignments, resource leveling, detailed design / implementation issues), here are some things that are typically missed or done incorrectly in a WCM implementation:
Content loading after 80% template completion
Under pressure from Executives, Project Managers will typically look at their Gantt chart and try to find ways to compress their timeline by doing more things in parallel. Something that typically looks easy to do from the Gantt chart is to start content loading (automated or manual) early in development. A typical question that gets asked is "when are our first 'input templates' ready for editors to start loading content?" My answer is that you can't do content loading until the templates are 80% complete. There is too much refactoring (both code and content) during the WCM template development. Starting content loading any earlier results in:
Developers being slowed down because they need to be careful not to mess up content loaders
Content Loaders having to work in a volatile environment
Lost work because templates change and are refactored during development
Starting too early results in content loading taking more total time. Of course, the way to guarantee there is no lost work is to wait until template development is 100% complete. Short of that, I typically recommend you start no earlier than before templates are 80% complete. More on this and other content migration tips can be found on my recent post.
Good process for Code & Content Deployment
/p>
Figuring out which parts of templates and code get stored where is one challenge not addressed correctly on many WCM implementations. The above diagram is an example of a content & code lifecycle that Oshyn designed for one of our clients. Some WCMs ask you to store your template code in their system as if it were content. Sometimes they even ask you to store compiled assemblies/jars into their system for proper publishing. Developers will typically want to edit code in an IDE (Integrated Development Environment) which will naturally be hooked into a proper source code Management system. Figuring how your code will get compiled, packaged, tested and released is key to your development cycle and it's unique for each WCM.
In the ideal scenario, content can be stored in source control and loaded in automatically from your CI/CD pipelines. This way prior to end user content loading, the content is treated the same as code.
Once Content Loading starts, you need to make sure you have a stable place for content loading. The environment must be backed up properly, but typically, it will need to start before the fully fault tolerant production environment is available. Therefore, you will typically need to create a content loading environment AFTER code templates are 80% complete, but before the final production environments are fully configured, load tested and ready to work on. Then you will have to determine how to move your content from the content loading environment multiple times prior to launch. Don't believe it when someone tells you that it will only happen once to production. There will be multiple content deployments; you need to plan for a repeatable process. Following launch, you'll then need to determine how to "back release" the content from Production to the QA and development environments to assist development and testing of future code releases with current production data.
Maintaining Old URLs - something that you think would be minor is maintaining old URLs. The business team doesn't ever tell you it's a requirement, but it IS. You will have to figure out how to determine all the existing URLs and how you will maintain them. You are in good shape if the previous system had some "Alias URL System" in the form of a previous CMS, Apache Rewrite rules, IIS virtual directories or some custom database solution. If you are not so lucky, they are not all in one spot and you've got to resort to looking through physical marketing materials to find URLs that are printed on pamphlets.
This can be an immense effort in the worst of cases and is something you want to ask the business team to organize early on in development cycle. Your new WCM may or may not have capability to manage these URL Aliases (which hopefully you determined during package selection if it was important). If it does not have the capability, you may be stuck creating some Frankenstein URL Alias add-on to the WCM in the form of some Web Server add-in or an enormous rewrite rule catalog.
Editor Training
Another major aspect of WCM projects that is typically not given enough attention is editor training. Editors are the key to the success of your WCM implementation. If they are not happy or find the tool slightly, partially or majorly unusable, you will have major issues achieving success. Of course, that means you need to involve them early, especially in decisions around editing granularity. It also means, you need to spend time creating proper manuals and proper training.
A good idea is to have them train during content loading. Yes, it's boring, and more than one will likely fall asleep, but it's essential. This is typically difficult to do on projects with a tight timeline where the emphasis is on launch, not on making sure editors know how to edit the content in the system. Keep in mind, if you choose that route, you sacrifice the learning that your editors will require for the system to be a long term success. It will need to be made up elsewhere or it will soon catch up with you in the form of an initiative from the business team to find a new WCM that better suits their needs.
You need to make this THEIR TOOL as early as possible so they work to improve and customize it to their exact needs. Anything less and you'll be paying for another implementation before you want or need to.
If you think through some of these factors, in addition to all the normal issues and best practices that you'd do for a typical web project, your WCM implementation will go much more smoothly.
Related:
Part 3: Development Stage Considerations (this post)
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.