When Does the Software Vendor Matter?

Recently I wrote a post discussing the importance of the selecting an implementation Partner in the success of a Content Management project. I even went a little off of the proverbial deep end by stating:

Software is Secondary

…

For the first project, assuming you pick a vendor doesn’t significantly mislead you, success isn’t going to be defined by the product you select.

For someone who works at Alfresco, a Content Management vendor, this seems a little crazy even if it is true. The key words in that statement are “first project”. The reality is that the Content Management System (CMS) you select is going to have a much longer life than the time it takes to implement your first project.

Life in Five Years

Whether you are buying a Content Management System for a single project or as a platform for multiple solutions, you have to think long-term. If you assume that the first project is successful (and who doesn’t?), you will be living with your chosen CMS for years to come.

You may know how good your CMS is when you select it, but

  • How good will it be in three years? In five?
  • How is your chosen vendor innovating?
  • Are they even innovating?
  • Are they seeing the same market shifts that you are seeing?
  • Are they following others?
  • Are they just sitting still?

You need to ask these questions. While they may not matter in the short-term, they will define whether or not you have to go through another selection exercise sooner than you would like.

Surviving Five Years

Even if the vendor is going in the right direction, there are more questions to ask.

  • Will it be easy to move forward with them?
  • Are they committed to supporting your architecture in the future?
  • How easy will the upgrades be in order to stay on a supported stack?
  • Are they going to rewrite their Application Programming Interface (API)?
  • Have they already done so?

When staying current becomes so complex that it turns an upgrade into a migration, that is the time to reevaluate your CMS. It isn’t that much more complicated to migrate to a new system than it is to migrate to a new version of a CMS with no upgrade path.

Make sure your vendor understands that.

It Really DOES Matter

Contrary to my initial statement, the CMS product DOES matter. It doesn’t impact the success of the first project but it will have a dramatic impact on the long-term program.

When I first started touted “best practices” for Content Management, I talked about understanding that you don’t have Content Management projects, you have Content Management programs. It isn’t just a solution, it is also a way of life.

Successful projects are hard. Without a solid CMS vendor that meets your long-term needs, programs are impossible.

One thought on “When Does the Software Vendor Matter?”

  1. Lawrence, in my opinion (that of a software vendor) each and every software product you install becomes immediately a legacy problem. Therefore chosing a CMS ONLY is really a huge mistake, leading to substantial integration and customization efforts. So based on analyst recommendations businesses buy best-of-breed CMS, BPMS, CCM, CRM, BRM and a few more products — each with their own software stack — and then they get an implementation partner and ask them to code it all into a hardwired straightjacket that will restrain progress for years to come. With three to seven products that have to be nailed together with APIs, you can’t simply upgrade one of the components.

    Applciations are not something that is created by the business, but goes through a normal development cycle, agile or not. The more mature enterprise software change management is in a business, the less changes to its applications they can manage within a year, simply because of the immense change bureaucracy.

    What businesses need is a consolidated solution that supports inbound and outbound content in the context of cases and processes, driven by event management and constrained by business rules.The business user smust beable to create their own content and related processes without a programming project. Therefore the solution is a single platform for content and process and the only integration allowed with the world is through REST or SOAP calls that can be parameterized. It must support a multi-tenant setup for different applications and embedded DEV, TEST, and PROD change management for the content, process and rules driven applications.

    The problem is that these products are chosen by different departments with different budgets, rated by different analysts, sold by different vendors but still they ought to be used by the same user with seven products going to a single consolidated UI.

    While Cloud seems to be appealing to get rid of the versioning of each product, getting such a consolidated application to work across multiple SOAP interfaces and still having a user interaction that will bring substantial adoption is not yet happening. Maybe in five years? Until then the short-sighted product selection, buying and implementation will continue …

    Like

Comments are closed.