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.
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.
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.
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.
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:
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?
Senior publishing managers: do you have a clear idea of your role in publishing systems projects? How about in requirements gathering for publishing systems projects? (By senior publishing managers, I mean the publisher and direct reports or the equivalent - print or web).
BAs & PMs: How clear are the lines drawn between your business requirements, your functional requirements, and your system requirements? Are you encouraging your senior publishing managers to take the appropriate project roles?
I'm thinking of two major projects I've come into contact with over the years where it was clear that the dividing lines drawn were wholly inappropriate to the intended constituencies, particularly for publishing managers. I've also seen one major project where the requirements gathering was rigidly compartmentalized by the consulting company, probably as a means to ensure that each constituency was dealing with the appropriate subject matter.
Some problem indicators:
1. Publishing managers reviewing quasi-technical diagrams in a functional requirements session (yes, we need to use XML; yes, we need a digital asset management system!).
2. Business/financial managers making top down decisions on specific systems. (Though there are cases where this could be appropriate)
3. Technical teams being left to determine how much time a task should take. (What’s the matter? it only takes 10 minutes to process...)
Each to their own:
- Publishing managers should be concerned with functional requirements, which determine the effects of a system on staff work, including how work gets done by editors, etc. They should also include setting standards for performance.
- Business/financial managers should be concerned with business requirements, or the overall financial effects of a system including related process changes.
- Technical teams should be concerned with systems requirements, systems, and architecture, to meet publishing manager needs (within financial constraints)
Publishing managers can have an important impact on a project. My advice is not to get your hands dirty with specific technology. Falling in love with a particular system or even a type of system, is a baaaad idea, trust me. Falling in love with improvements in performance and ease of getting work done for your staff is a much healthier idea.
Senior publishing managers often consider the following:
- We need to create this new online product
- We approve doing this publishing technology project.
They can more positively impact a project by making a few simple accountability statements and holding on to them like a pit bull. They might sound something like this:
- We need to create this new online product, and make content production for it take only this amount of staff time.
- We approve doing this publishing technology project. This project must reduce time spent on these non-editorial tasks, this amount, by this much, and decrease overall time in our production process, this amount, by this much.
This should set up a good interplay between subordinate publishing managers/staff and the technical team as they participate respectively in the creation of functional requirements and system requirements.
I recently attended the NFAIS conference in Philadelphia where Neil Roseman, Vice President, Digital Technology from Amazon.com spoke about their internal electronic product development methodology. Apparently Jeff Bezos coined the name “two pizza teams” to capture their philosophy regarding the size of a team. Bezos believes that a development team should be no larger than what two pizzas can feed for dinner. According to Roseman, any pizza team cannot be larger than 10 people (I guess that means each would have 1.6 slices of pizza for dinner using a normal 8 slice pizza). The main goal of this approach is to lower the hierarchical communication overhead.
The first step in the two pizza team methodology is to write a press release. Yes, that’s correct, write a press release. This step forces the IT team to articulate what the definition of success looks like for the project. This is no small feat in many IT environments. Personally, I find this step very interesting and one that is lacking on many project teams that I have encountered where they are either behind schedule or struggling to actually complete a project. Defining what success looks like is critical to any project regardless of the final form. A press release is a great way to focus on this step.
The second step is to develop all of the Frequently Asked Questions (FAQ’s) and answer them. This is an interesting step, but it should not be replaced by actually writing requirements.
The third step is to write a user manual. Again, the written communication helps articulate the requirements in a non-techie way which ultimately helps both business and technical team members.
And finally, the team actually gets to complete mockups or prototypes of the new product.
The overall takeaway that I gained from Roseman’s presentation was that rapid electronic product development needs to adhere to a loose set of processes while clearly articulating requirements and success. I believe this approach is something that many publishers who are developing electronic products could latch onto and be successful.
One final note: I was disappointed that Roseman never addressed the challenge of selecting toppings on a pizza by a group. I could see the decision making process around selecting a topping being a critical barrier to the ordering process and may actually be detrimental to the overall progress of the project.
On the eve of the State of the Union address by President Bush, I thought it would be fun to do our own State of the Industry address. I should note that a more in-depth look at this topic can be found in an article that I contributed to in the January issue of Information Today. Over the past year, we've noticed three distinct trends at publishers related to technology services:
Are there other technology service trends that you have seen in the publishing industry?
(Ok, first, I'm annoyed that everything is suddenly 2.0 - Web 2.0, Business 2.0, blah blah blah. So just had to get that in there. Unfortunately, Documents 2.0 might actually work as a descriptor for what follows, so I fear it could stick.)
This is a long one, you might want to grab a cup of coffee.
The unifying theme of XML 2005 was the connection between data and documents. This expressed itself in a number if different ways:
MODELING: Dr. Bob Glushko of UC Berkeley's Information School (what used to be the library science school) talked about "Modeling Methods and Artifacts for Crossing the Data/Document Divide." His bottom line: There aren't two clear types of content - data and documents. Instead, there is a continuum of content, and when we're analyzing it we should avoid thinking in terms of whether it will become XML or relational content until the analysis has been completed. This means, among other things, that we need modeling methods that support both relational and hierarchical relationships, and that can be translated into both XML and database schemas. We also need to apply the best practices of document modeling to data modeling, and the rigor of data modeling to document modeling. And we need to distinguish between the normalized form in which information is best captured for storage versus the ways in which it might be recombined for human consumption or delivery to other systems. You can read more about Dr. Glushko's ideas and his new book here: http://www.docengineering.com/.
STORAGE: IBM was present in full force at the show, which is a big change. They are promoting Viper, code name for the next version of DB2. It includes a native XML repository along with the traditional relational database, and the query engine has been made "bilingual": It understands both XQuery and SQL. And not only does it understand both, it understands combinations of the two - endless nestings of SQL inside XQuery inside SQL inside XQuery (looks messy, but not bad to read). It also allows for foreign key relationships between XML nodes and relational fields (a truly wonderful thing). Indexes can be created for XPath expressions (no predicates) to improve performance. IBM has produced some hard-hitting marketing literature regarding the superiority of their approach when compared to the options other relational vendors (umm, maybe Oracle and Microsoft?) have taken for XML storage. Presumably if they can make tough statements about the performance hit of those other approaches, it means that Viper itself will be relatively speedy at loading and querying XML. Apparently Viper also has some appealing schema management capabilities, including the ability to modify schemas without reloading content (sounds like a no-brainer, but other approaches can't do this). Viper is in beta right now (you can learn about the beta program here: http://www-306.ibm.com/software/data/db2/udb/viper/) and will be released towards the end of next year, but some partner firms are releasing support for Viper as soon as Q1.
EDITING: Microsoft gave a sneak preview of its next generation of Office, due out at the end of 2006. This is the first time since Office 97 that they're changing to a new file format, called "the Microsoft Office Open Format." And boy, is it a change. They are unraveling Office documents by storing their constituent objects (XML content in custom schemas, content in the Office schemas, images, charts, and so on) in independent files, each of which can be accessed, read, written to, and otherwise processed on its own. Relationship files describe how the objects fit together into a document. The objects, relationship files, and a file describing the file types are gathered together into a zip file with an appropriate Office extension (e.g., "docx"). (Apparently the compression significantly reduces file size, very nice.) Each Office application opens its own zip file format directly - most users will never even know that it's a zipped file. (Learn more here: http://blogs.msdn.com/brian_jones/.)
There's lots that cool about all this, assuming it behaves as advertised (big assumption, I know), but my main point in this post is that Microsoft clearly states that their purpose is not to create an alternative to native XML editors. Instead, the goal is to create an environment in which business users can more easily search data in back end systems and include that data in documents in ways that allow the data to be automatically kept up to date. For example, if a sales manager authors a document about her company's projected revenue, she can use an InfoPath form (XML under the covers, of course) that is embedded directly in the document she's working on (assuming a programmer did some work to set it up for her, presumably in a template) to report on the current numbers from all her salespeople, embed the result in her document, and refresh that number at will as the end of the quarter approaches. The data could also be delivered in the form of an XML document that is included in the document's zip package but not displayed directly - it just becomes a little data source living behind the scenes and traveling along with the document even when the system from which it was extracted is not accessible. (This is definitely cool.) From Microsoft's perspective, the goal is productivity gain through gluing data to documents. I'm trying not to get too excited given how disappointing the earlier Microsoft efforts to incorporate XML into Office applications have been, but this is looking really useful. And although they say they're not trying to replace XML editors, this approach could make it worth a publisher's while to re-think their DTDs/schemas - maybe the amount of structure and data integrity that can be achieved in this type of application is good enough for many needs, and the benefit of using Office applications doesn't need to be explained.
I have to say, I feel somewhat personally vindicated by all this discussion, as it's been an area of personal interest for many years. (I wrote a chapter for the XML Handbook in 1999 that talked about a lot of these very same issues, and presented a discussion on the continuum of data and documents at an AIIM conference a few years ago.) Of course, I'm not alone - most of us who have been working with SGML/XML for a long time ran into these issues a long time ago and have been waiting for technical solutions that would help solve them.
Now that the technology is almost here, there are some potentially even tougher challenges:
1 - When you have the choice of storing some content in XML and some in relational form, it means you have to come up with good rationales for what content is stored how. Turns out that's hard sometimes. There's a lot to say on this topic and I'll return to it another day.
2 - Second, this means that the practice of content modeling as described by Dr. Glushko (actually, he calls it "document engineering," which I think is unhelpful, see the next point) needs to mature, and someone will need to "own" the design and maintenance of the relational/XML models because they are too linked to be truly separate anymore. How will that work??? Are the people who control databases ready to inherit responsibility for DTD/schema maintenance? Could the reverse happen? No on both counts - today.
3 - Finally, we really need to stop using the word "document" for every XML instance we run into. Even Dr. Glushko used it for both stored XML documents - which presumably exist as an XML narrative in some permanent fashion and for some meaningful reason for the given system context - and for assembled documents that are created for more temporary purposes (presentation or delivery) by combining XML with data and other stored object types (like images). When discussing models, storage methods, and editing tools, it can be extremely confusing to use the generic "document" for both kinds of thing. We need more precise terms. Any suggestions?
