Really Strategies Blog

Really Strategies Acquires SaaS XML Content Managment Platform DocZone.com

I am pleased to announce that Really Strategies has acquired SaaS XML content management platform DocZone.com. You can read the press release here.  This is an exciting day for the team at Really Strategies for several reasons:

1. DocZone.com is known for its DITA-based SaaS content management solution with a Fortune 500 client base.

2. Our combined teams have the most experienced content management engineering team of any product vendor.

3. We are now better positioned to serve publishers and technical publishers on a global basis.

4. We now serve over 100 publishing companies, media companies, and technical publishing organizations. 

5. DocZone and RSuite provide the market with a wealth of deployment options (SaaS, hosted, deployed, or build your own (using RSuite Engine).  We feel this breadth of solution offerings is unique and is what differentiates us from the competition.

We are excited by the addition of DocZone.com and look to continue building on our past successes.

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.

Working with XML in InCopy, InDesign, and RSuite

We've recently announced the availability of the next evolution of the RSuite CS3 Connector, which integrates RSuite with Adobe InCopy and InDesign CS3.

The Connector enables some very exciting features for publishers looking for full XML workflows with these Adobe tools:

• Publishers can manage their content in the XML flavor of their choice but enable creation and editing of that content within InCopy. This is done through a transformation between the publisher's XML and INCX, the native XML file format for InCopy.  We've enabled some tools to make this a simple process for the end-users, including the ability to navigate for content in RSuite from within InCopy (so users who want to stay within the Adobe application do not need to go to another app) and the ability to open the document in InCopy from the RSuite CMS browser-based interface (for users who are working within RSuite).
• And then publishers can link to the articles or images managed within RSuite from the InDesign document, also managed in RSuite.  InDesign users can refresh the links to update the content based on changes made to the content by other authors and editors.
• We've also been involved with a few projects in which RSuite is used to dynamically generate the InDesign document.  In this scenario, the RSuite user assembles the content they want into RSuite's "content assembly" construct and then pushes it through a workflow that dynamically generates the InDesign file with links to the content already in place.  

We've created a short screen cast that illustrates the CS3 Connector if you want to take a peek.

And what about CS4 I hear you ask?  So far, most, but not all, of the publishers we have talked with interested in this type of integration are using CS3.   We don't expect many needed changes in the actual plugins to work with CS4.  The biggest change in CS4 is the underlying Adobe content models, which have changed significantly between CS3 and CS4.  But, fortunately, they have changed for the better and are easier to work with.  So if you have any interest in seeing this type of integration with CS4, let us know.   

"Rolling your own CMS just doesn't make sense" by Ron Miller

Ron Miller from Fierce Content Management just wrote a pertinent editorial on why developing your own CMS is not the best approach. Take a minute and read the complete editorial here.

Nice, Ron. We agree completely and that's why we architected RSuite CMS so publishers can easily configure the CMS software to meet the unique requirements that we know all organizations have.

With RSuite's administration interface, power users designate what elements are manageable, re-usable, browsable, and versionable with a simple click. Additionally, RSuite comes bundled with 40+ out-of-the-box workflow action handlers that perform common editorial and production functions. And if they don't meet your needs, you can create your own action handlers with RSuite's extension framework

While I'm personally all about DIY, there's a pretty obvious line where I think you let the people who do CMS software day in and day out  do the work.

RSuite CMS provides loud and clear answer for Audible.com

We are often asked by publishers to describe the real business impact RSuite CMS has on our clients. Along with my previous post on Blood-Horse Publications, Audible.com is another client that has leveraged the power of RSuite to realize its business goals.

Audible, Inc., an Amazon.com, Inc. subsidiary, is the leading provider of premium digital spoken audio information and entertainment, on the Internet.

In early 2007 Audible.com launched an aggressive project to revamp their entire metadata program to better manage and process the metadata files they receive from their publishing partners.This program had the following business objectives to meet:

• Ensure error-free metadata by using publisher or publisher aggregators as the source of data, and by developing new tools to drive, search, browse, and publish to store functions off this sourced data.
• Ensure the ability to identify Audible products on partner sites by providing ISBNs that correspond to the downloadable digital binding with each product in feeds to partners, wherever and whenever possible.
• Reduce the occurrences of human error by automatically populating data into web site databases, from the sourced data.
• Improve findabilty, searchability, and marketability of products by standardizing keyword, category, authors, contributors, and publishers.
• Improve royalty systems by making contract entry a requirement for any product being pushed to an Audible site.

During a 4-week proof of concept (POC), RSuite was configured to prove out several use cases:

1. Leverage RSuite’s workflow tool to ingest ONIX feeds and audio files
2. Apply additional metadata (both manually and automatically)
3. Distribute the appropriate content packages to target delivery sites.

During this stage many business rules were also documented that were applicable to improving Audible's business opportunities. After a successful POC, Audible.com selected RSuite for its metadata and aggregation solution.

RSuite became the framework upon which Audible crafted solutions to meet all its requirements: workflow, business rules validation, content aggregation and delivery. In 6 months, RSuite was configured and implemented to become Audible's workflow tool, which enables seamless transfer of content from publisher feeds to web site-ready files.

Now after using RSuite for over a year, Audible has realized its goals of integrating a tool that would satisfy the business objectives and show a return on investment quickly. As Art Zegarek, director of data architecture told our team, “RSuite has become a very critical system very fast!" It is satisfying to know that RSuite is helping an aggregator such as Audible.com meet its business objectives every day.

RSuite CMS 3.1 Released: New User Interface and Web Forms Capabilities

The latest software release includes a new graphical user interface design, as well as changes in the underlying interface architecture, that improves all around functionality and usability.

Read more here about Really Strategies' content management system for publishers.

Strategies for successful XML content management initiatives

With a mandate to implement XML, and content management across your organization, how do you develop a strategies for a successful initiative?  And what are the pitfalls that detract from success?

In a large organization, does it make sense to centralize the effort?  For example, should you begin with alignment on XML formats and metadata across the organization, and then proceed to an across the board CMS implementation?  Or should you begin with alignment on a CMS technology?  Does it make sense to have one division or group pilot an effort so the organization as a whole can learn from the experience?  And then roll out to other divisions?  Or does it make sense to let all groups move forward at their own pace?

The answer, of course, is, it depends.  It depend on where your organization is at the moment, its culture, and your ROI period and expectations.  But, perhaps more importantly, it depends on the capabilities of the relevant technologies out there - how fast they can be deployed; how flexible they are once they are deployed;  how fast they are changing in the marketplace.  If you're implementation is expected to be rigid, or the tools you have require a certain level of rigidity, then it might be best to go top down and align the organization as a whole, then implement as a whole or in a unified manner.  But if you are expecting to be flexible, and your technology, formats, etc. can be flexibly configured, perhaps bottom up is the better route.

RSuite CMS places itself in the flexible category, which allows the flexibility of any of the possible implementation approaches. 

"Barbarians at the gate?" NFAIS Conference

I was highly interested with the title of the upcoming 51st Annual NFAIS Conference.  Quoting from the brochure: "Barbarians at the gate?  The impact of digital natives and emerging technologies on the future of information services"  Essentially the gist of the subsequent write-up is that those who were born in the digital era and have almost exclusively known digital communications, are getting ready to storm the world and start driving the information technology revolution from inside companies and organizations (presumably the way they have with consumer communications). 

How perfect.  This is what all of us in the publishing technology community have been waiting for and have started to see out there in the last few years.  It means that it is less and less important for the publishing technology revolution to be driven by the visionary technical whizzes.  Less problematic to convincing companies to adopt more and more advanced digital workflows and systems.  As the 'digital natives' come into their own, demand for better systems is beginning to drive things.  What a great thing to happen in publishing technology!  Of course this process proceeds differently in different publishing verticals, with more scientifically oriented (e.g. technical) companies already there.  But now we can expect the non-science oriented publishing to come aboard. Magazine and book publishers should be coming around, and goodness knows, we have been waiting for this moment in educational publishing - the slowest of publishing verticals to change. 

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.