Really Strategies Blog

Principles matter

Interesting article on this topic by Eliot, here.

Such discussions might seem esoteric, but they absolutely are not. The success of a software project (like a CMS implementation) is ultimately determined by thousands of individual choices made every day by team members - developers, PMs, analysts, and so on. Many of these choices are based on design principles with which business managers might strongly disagree but of which they are often unaware. Occasionally one of these decisions has inordinate impact - a complexity of design that results in a complexity of implementation, testing, and maintenance that is radically inappropriate relative to the value of the feature in question.

Managers who aren't deeply engaged with their teams tend to over-simplify such discussions by saying things like, "So-and-so engineer always makes things more complicated than they need to be." It's true some engineers are hard to manage (and that some managers start almost every new project with unrealistic expectations, and that some users won't give up complicated requirements). But I believe this difference in philosophy is also in play, and a PM or other manager would do well to understand and talk about how a team's varying philosophies impact its members' choices, and where change might be in order.

Looking for acceptance

When implementing a new or improved content management system, I find that many teams don't have time or the staff to perform what is known as "user acceptance testing (UAT)". But let's face it: end users are going to either accept or reject the system components eventually, and it's much less painful to get through this process in a controlled manner during the project than during production.

During project testing, participants expect to find bugs and issues. The development team is still available to fix the issues. The team can take disruptions in stride, since issues only disrupt testing, rather than production schedules. Failures are part of the normal process.

After the system is released into the wild, system end users who were not involved in the project start working and expectations are high: "This system has been released, so I’m assuming that everything works", they're thinking. Newly discovered issues are upsetting and disruptive to production schedules. The project developers may have been reassigned to other work already, and a team may need to wait for fixes, which exacerbates the problem.

So how do we balance the realities of resource constraints with the obvious need to test?

Let’s look at it in terms of quality. A generally accepted definition of quality is that something meets specifications ("is it what we ordered?") and is fit for use ("is it fast and intuitive?").

The UAT process runs in a tightly controlled environment and excels in proving methodically that all specifications have been met. It helps in answering the general questions "how will we know we're done?" and "how will we know we're successful?" This is ideal from a systems vendor or IT department perspective; because it allows a neat line to be drawn between the project and handoff. The project is nicely wrapped and packaged for delivery. For the end users, the disadvantage here is that everything rests on how well requirements were defined in the first place. It’s very easy to miss something that can cause trouble later on.

A team can also release a system as a beta version or as a pilot. Instead of a few people running dummy content through test scenarios, a sub-set of actual system users can move through an actual workflow using actual content. This approach helps the group move forward on their production schedules, while maintaining a relatively controlled environment. And, because it's a smaller set of users, the group's expectations can be set so that issues don't freak them out. Since the team is operating in a live environment, they can identify critical issues that may have been missed during the requirements gathering stage. A live environment is ideal for proving fitness for use.

However, it may not provide a very thorough quality check against the stated requirements, since there may be exceptions in the process that won't occur during the beta period, such as an end-of-quarter rollup, report, or content delivery. The pilot approach works only if the end to end process is sufficiently short enough to get through within project timeline and cost constraints. 

Ideally, we’ll use both approaches. At a minimum, it’s smart to spend some time with at least a couple of team members to take the system for a "test drive" assuming multiple roles, to ensure that all specifications have been met and the pilot period starts smoothly. Then following that with a pilot enables the end users to determine fitness for use.

I'm always looking for the right balance. What's your experience?

The Onion and Drupal - A not-so-funny lesson

Seth Gottlieb from <!-- content here --> tells the story of why The Onion customized open source CMS, Drupal and ultimately moved to Django for managing its web content. You can read that story here.

This lesson is the main reason I hear our RSuite architects chant "configure rather than customize" from the corners of the office.

SharePoint: When did free begin to cost so much?

I ran across an interesting blog post by Stephen Arnold who is a longtime industry analyst and consultant that spells out the hidden costs of a SharePoint implementation.  The post is here.  While free always looks better than paying for software, I think Stephen hits the spot with his assessment.  A free software framework such as SharePoint is great if you plan to keep requirements very simplistic.  As we all know from our own experiences with implementing content management, that is easier said than done.  If you have more complex requirements, maybe a packaged solution such as RSuite makes sense.  Your company's approach to projects, culture to build versus buy, and several other factors need to be considered before selecting a technology and embarking on a content management project.  Whatever approach you take, just be cognizant of hidden costs as Arnold pointed out.  Free software does not always mean it will be cheap to implement and maintain in the long run.

CNN Reports on web revolt against IE6

My colleague Matt Pileggi, Senior User Interface Developer for RSuite, shared some recent news with me:

"CNN posted an article about a movement to get rid of IE6, I found it pretty interesting if not just amusing. I think Eliot can agree with Dan Oliver when he says, 'But with regards to IE 6 ... [it] is an awful browser and no one should be using it.'  The site itself is here."

RSuite Engine now available

For organizations that want to jumpstart development of content management projects on top of MarkLogic Server, the industry's leading XML server, Really Strategies now offers RSuite Engine.

RSuite Engine is the foundation of RSuite CMS and provides a robust API for technical teams to accelerate the development of sophisticated content management applications.

Read more about RSuite Engine here and here.

What is the difference between RSuite CMS and MarkLogic Server?

Publishers often ask us “What’s the difference between RSuite CMS and MarkLogic Server." Great question!  The most straightforward answer is that RSuite is a content management application and MarkLogic Server is a database. It’s that simple.

MarkLogic Server is an incredibly powerful XML repository on top of which many publishers have built fantastic applications, O’Reilly’s Safari U, Elsevier, and Congressional Quarterly, to name a few. These custom built delivery applications are just one way MarkLogic Sever has been used.

RSuite CMS is also an application built on MarkLogic Server. RSuite CMS sits on top of MarkLogic Server to leverage the native XML repository (i.e., database) and search capabilities. Without a database, RSuite would not be able to run – just like a car needs an engine. However, without a chassis, steering wheel, electronics, etc., the engine would be of little use. Therefore, think of RSuite as the ignition system and think of MarkLogic Server as the engine. Both are very important to content management.

RSuite conference - business takeaway

Ed and I have both discussed different aspects of the RSuite User Conference, here and here.  Here now are some key business points that I saw demonstrated at the conference and that are particularly related to our current RSuite CMS 3.0 release:

RSuite is a very flexible tool.  Not only can it fit a large and diverse number of publishing needs, as demonstrated by our installed base, but it is very easy to adjust implementations after they have been rolled out.  Configuration is big, custom coding of general purpose functionality is not generally required. 

This means faster deployment of RSuite, which means shorter return on investment.  It also means low ongoing costs for making significant adjustments to the system as business needs change.

Existing and growing asset management features mean that businesses can consider the option of one RSuite implementation rather than a CMS and a separate DAMS.  And though I don't think it came out as clearly at the conference, RSuite's ability to act in several ways as a WebCMS also allow businesses to consider further options in reducing the number of systems they have to manage.  Finally, the new CS3 Connector will provide several additional possibilities as we grow the system. 

Basically, RSuite might be considered a new type of CMS that is really content centric rather than content *type* specific - perhaps it is better called a UCMS - or Unified Content Management System.  As we branch outward, this means that businesses may not need a separate system for every content type or distribution channel, meaning less overhead and maintenance overall.

RSuite was designed by (very) smart developers who care passionately about fast and easy implementations.  I can't overemphasize this.  Why is this good for businesses looking at RSuite?  All developers worth their salt, truly despise coding the same thing over and over again, a major hassle with older tools.  So it follows that many innovations in RSuite are about making easier implementations and allowing changes with configuration rather than coding.  Each release has come closer to that objective up to 3.0, which, I think, has achieved much of that goal.  Further refinements will just make things easier. 

At the conference, we had a couple of examples of 4 month implementations (including analysis).  This time taken should go lower with 3.0 - how far, we're not quite sure yet, but it should be significant.  And a more iterative approach should allow implementations to roll out even faster (but that's another post).

Finally, RSuite is a very developer friendly tool.  With RSuite, developers' time will be well spent concentrating on specific integrations and customizations to meet your specific business needs, rather than building and maintaining generic functionality or building general APIs.  They will also appreciate the elegant way that they can add functionality to the system - some real power will be in their hands to provide your organization with what it needs to succeed.

Management to IT: "We don’t like you either"

I recently read a summary of an article from wsj.com under the Cubical Culture section that struck a chord with me: “Management to IT: We don’t like you either.” As evidenced by the title, the inherent conflict between IT and management is never ending; however, many people feel it’s getting to be an old story. Management today at many companies expect more out of IT organizations than in previous years. It is no longer acceptable to request an 18- to 24-month project life cycle and not show a return on investment quickly. This article suggests that if IT continues to do these types of things, they will render themselves useless and out of a job. In addition, the article points out that the old days of “we can build it better than any product on the market” is long gone.

For publishers I have seen a shift over the past 5 years related to this build-vs-buy mindset. If your IT organization is still touting that they can do it better, cheaper, faster by building a critical system (e.g., CMS) from scratch… run, run away as fast as you can. Given the wealth of tool sets available and the openness of many products on the market, why would an organization ever take the build-it-from-scratch approach?

I’m not biased when I make these statements. I’ve seen a renewed interest by publishers to license a product and show a return on investment quickly. This has been our mantra since day one with RSuite CMS. Our goal was to make a highly configurable CMS that can manage any content and be operational in a short period of time (under 12 weeks) to meet core requirements. Yes, there will be some organizations that require 12-month projects to migrate from one system to the next, but overall the trend has been implementing a new system, even for larger projects, in a much shorter time frame. The only way IT will be able to handle this shortened timeline is to license a software product that meets 70% of their core requirements pretty much out of the box such as  RSuite CMS.

Caution - sales and marketing pitch to follow

If you’d like to see how easy we can setup and configure RSuite CMS, please join us at our upcoming User Conference in October. Our theme on day one is “CMS in a Day” as we go from beginning to end and complete an installation and run a demonstration of the software.

End of sales and marketing pitch

I can certainly understand why IT organizations at publishers want to build their own CMS. First, it’s fun to build software. Second, it gives more of a feeling of accomplishment than integrating third-party software. Finally, a programmer can have a job for life just making endless changes to the software (ok, that was a cheap shot).

Management today needs to understand that IT does have value and IT needs to understand that management has the right to ask questions. Reducing the stress between these organizations is critical to publishers making the right technology choices and implementing new systems on time and within budget.

Why do CMS vendors exhibit at tradeshows?

I must confess out of the gate that I do not believe exhibiting at tradeshows is worth the money. I have been skeptical for years even prior to launching RSuite CMS. In the twelve plus years that I have been in the publishing and information industry with three different companies, I have never heard of a hot sales lead coming from a tradeshow.

Here’s what I do hear from my colleagues in the industry who exhibit regularly:

• If we don’t exhibit, people will think we are not doing well or we are out of business
• We have to exhibit to get a speaking slot at the show
• We committed to the event organizer for several years

Not one mention of actually getting a sales lead.

I am not here to tell you that Really Strategies will never exhibit to demonstrate our RSuite product, but we need to pick and choose very carefully. Just as publishers and other information companies want a quick return on investment when they purchase a CMS, a CMS vendor wants a quick return on investment from exhibiting at a tradeshow. Based on my unscientific study of the many vendors we work with in the industry, a return on investment from exhibiting at a tradeshow is becoming less likely.

So what should a CMS product vendor do? Should we risk not appearing like a viable company and spending our marketing dollars on other creative ways to build our brand or should we exhibit at every industry tradeshow at $5,000 per show with very limited success?

Software sales are not about booth traffic and cool giveaways anymore, it’s about networking and partnering. With all due respect to my friends in the industry who run tradeshows, let’s come up with a creative way to help CMS product vendors instead of offering an exhibition comprising of a 10 x 10 booth with one table, two chairs, a trash can, and a $700 internet connection. Oh, did I mention the black curtain you get behind the booth?