The problem has the following aspects:
- Information for the website updates is not centralized.
- Metadata for updates is not centralized or even captured in a system. Some of it is in the head of developers like me.
- The house template solution is deeply embedded in the workflow, but is not very flexible.
- The content updating is spread amongst multiple web editors and coordination is handled via scheduled workflow rather than any scripted process.
- A variety of clever workarounds can obfuscate the purpose of some weekly update items.
Along with this list of challenges is the knowledge that our vendor is working on a next-generation CMS. The question becomes, should we try to fix our legacy workflows? The answer is, maybe.
Changing processes is costly. First, there's the cost of researching the existing process and its solution. Second, there's the development cost. Finally, there's the cost of implementing the new process.
For me, with my hacker mentality, it's easy to see opportunities for improvement without taking into consideration the implementation cost. But what good does it do to make something "work better" if the people who are meant to benefit from the improvement have to climb a learning curve to take advantage of it? In the long run the tradeoff is probably worth it, assuming the long run is sufficiently placed in the future.
The real challenge is not the existing workflow hiccups, it's knowing whether they're worth the expense to fix. The "can we do it" part is already obvious. Yes, we can streamline processes. Can we do it in a way that serves all the stakeholders? That's the real heart of the question.
Sometimes it is best to leave a legacy process alone until the foundation can be replaced. As a developer my duty is to notice these opportunities and bring them to the attention of my team, and then to be sensitive and responsive to the other stakeholders. Just because something is possible doesn't make it right to do.