The Unspoken CMS SaaS Dilemma


This is the last of my “drafty” posts that I’m shoving out. This one was a lot more evolved. I do want to say that this post was inspired by a chat I had with Andrew Chapman at a conference a few months ago. This is the first of at least two posts. No promises if/when the next one will surface.

Once more into the abyss…

There is a lot of attention being paid to the up-and-coming cloud-based Content Management providers. The reason why is obvious, Content Management offered as a SaaS offering has the potential to solve many of the problems faced by the system integrators of today. There is the problem is that they don’t have the features required today and their ability to add all of those features is limited by their SaaS nature.

More Than a Feature List

If you take time to look at all the rising vendors in this space, you will find various gaps in each product. Most of them will actually acknowledge every gap and then either tell you when it is going to be addressed or talk to you to learn more about why it is important.

Here’s a big feature that I have in most of my on-premise Content Management Systems, back-end customizations. There are some business rules that you absolutely have to enforce. This is often done in code.

Here are some very simple examples.

  • Depending on various conditions on a piece of content, it may need to be assigned a retention policy. This would need to be re-checked every time the object is altered.
  • Relationships are important between pieces of content. If something happens to one piece of content in the relationship, things may need to change on the related content.
  • If I change an approved piece of content, maybe I need it to trigger a workflow process to get it approved and to initiate a review of related content.

You can see the need for lots of these rules. Some could be dealt with through advanced configuration, but others may require code. The problem is that code crashes.

image I know, shocking. I myself once wrote a piece of code that not only sent my workstation into a bottomless pit, but I took down the entire university VAX system. The cloud is home to much larger and robust systems, but I can create much larger errors than I could back when I was in school.

This is going to lead to a dilemma for the SaaS providers. Do they offer the ability to embed business rules where they can’t be bypassed or to they stick with simple and limit their market reach.

Not an Obvious Choice

One would obviously argue that anything that could impact simplicity and stability in the SaaS world should be put aside and not implemented. Before we close this book there is a twist.

Larger and older companies are more likely to have complex business rules. In fact, I have found that the more content/iterations in a given process, the odds of some sort of complex business rule, and the importance of the rule, increases.

This leads to the dilemma. There is a lot of content out there that requires these business rules. If the system won’t support the rules, that limits the content that can be stored there. If content for an organization has to be stored in multiple places, headaches are bound to follow. These headaches are very much like the ones that necessitate the need for CMIS.

Through all the years, one thing has been constant. Users hate switching between applications. They do it when they have to do so, but they don’t like it. If SaaS vendors want to break into the Enterprise space, they are going to need to do more than offer basic Content and Collaboration Services. They are going to have to find a way to accommodate the rules without sacrificing stability or reliability.

I have some thoughts, but that is for another day.

6 thoughts on “The Unspoken CMS SaaS Dilemma

  1. I think this would depend on the type of content you want the SaaS offering to manage. Something like email would be easy, Google mail is already an example of what can be achieved with it. Other types of content, invoices or project documents will have to be offered differently.

    The SaaS offering will have to sell the full service, probably with indexing in the background to bring content together. If they do bring out content management as a SaaS offering I think it will be vastly different from the content management systems that we see in the enterprise today.

    Just my 2 cents worth 🙂

    Like

  2. Pie’s assertion of SaaS Dilemma is not only applicable to ECM/CMS silo, but its effect is relevant to the entire current in-house computing environments. What we learned from the previous legacy system, namely Cobol, the legacy computing environment doesn’t suddenly disappear because it is outdated. Rather, the legacy environment stays around for a long time because it is cultural rather than technical. That said, the in-house computing culture, where you need to change the code to fit into the giant and bureaucratic computing environment, is the next legacy computing system we will see in the not-too-distant future. As Nico Pretorius suggested, new paradigms such as Cloud Computing/SaaS will work completely differently. As consultants, however, we should have no fear. There will be some new consulting paradigm soon, which will evolve with this new platform. One thing is clear, it will not be like the in-house consulting model. Interestingly, within the Cobol legacy environment, we used to write an exit to OS to accommodate individual customer’s computing needs. Not anymore. Well, we now write all sorts of custom codes to fit into the customer’s in-house environments. I am not sure this paradigm will fit into the up-and-coming next generation environment. This goes with the big companies as well as the government that are banking on in-house IT infrastructure as well. They will follow the trail of Cobol culture eventually. They may not die but will fade away. Who knows whether the different silos like ERP, Social Media, Hardware, Software including ECM/CMS will all mesh together finally leaving a fresh, but lead us to silo-free new paradise…

    Like

  3. Good comments on bad code. Bad code means not stable, not scalable. This is bad in and of itself, but on the cloud it will be more pronounced. Where I see the cloud falling down is in high availability and process isolation. If somebody (a platform or an app) deploys a bad app, what are the mechanisms in place to keep that poorly behaved app from negatively impacting others on the same, shared infrastructure? Everybody always leaves out that piece.

    Like

  4. Interesting perspective in your recent piece entitled, “The Unspoken CMS
    SaaS Dilemma.” As a start, I’d humbly suggest that the problem isn’t about solving systems integrator problems, but delivering business value to the customer. One of the key barriers to this is the cost and complexity inherent in the on-premise ECM model that you describe well in “CMS Tech Making Life Harder. ” The SaaS, or cloud, model is designed to address challenges in getting new capabilities to business users through feature upgrades and maintenance by making them seamless and backwards compatible with no customer IT support required.

    Leaving that aside, however, you paint SaaS CMS with a broad brush, and I’d like to clarify the facts here. Without getting into each of your points, at its core one thing you identify is that SaaS solutions – and I would clarify some SaaS solutions – lack robust rules engine and BPM capabilities.

    Underlying this is that lighter-weight ECM, really document management, SaaS providers use meta-tagging (tags) functionality. Meta-tagging is useful as users are able to add keywords or descriptors about a piece of content; the downside though is that they have to be added on an ad hoc basis and lack the ability to enforce policies, e.g. a tag for document type must be added to all content. Additionally, tags are inadequate when it comes to data validation and look-ups, and are very difficult to interrogate to trigger events.

    By contrast, SpringCM has a robust metadata model provides users with structured
    label:value pairs (e.g. Case#, Customer #, State/Status) and can used to enforce policies around what metadata is require or optional on a piece of content. Additionally, business logic in the form of user-defined rules or advanced workflow can be applied to validate and/or look up data from other data sources (e.g. Vendor master data based only on the Vendor ID). In addition, it is also necessary to interrogate metadata to evaluate conditional logic and trigger events. For example, if the vendor is Acme Corporation and the amount is greater than $5,000 then route to Bob for approval, otherwise route to Sue.

    So maybe your theme should be The Unspoken Dilemma for “Some” SaaS CMS. Your fellow bloggers Big Men on Content noted this difference in a recent post. If you’re inquisitive, I’d welcome the opportunity to show you more.

    Like

  5. Jeffrey, thanks for the comment. I’ve had SpringCM on my radar to catch-up with for a while. In the past, my concerns weren’t technological but directional. I’ve seen enough information in the past few months to know that I need to look again.

    However, to say that these challenges don’t apply because they have been met seems a little off. This is an ongoing challenge. Even if enough capabilities have been created to meet the “needed” requirements, as opposed to “desired”, there is still the challenge of upgrading over time.

    These are challenges that apply to all SaaS CMS vendors. Some may be meeting them, but if they are met and forgotten, that is a recipe for failure in a few years.

    Like

Comments are closed.