November 28, 2006

What is the future of software as a service

I’m not at the conference this week (we do have several people from our shop there), but to answer a question posed by Frank Gilbane:

What is the future of software as a service, and is it appropriate for enterprise content applications like content management, authoring, etc.?

The SaaS model seems to have been proven to the point where it’s hard to imagine that it won’t keep growing. We recently posted a whitepaper on SaaS myths, which debunks most of the common arguments against SaaS. In addition to that discussion, I’d offer the following four points:

1) SaaS is a proven technology. It arguably extends to the early days of the web with software ASPs. I guess you could even argue the lineage goes all the way back to mainframe apps! :-) Certainly, though, the existing SaaS companies have been working successfully with this business model for more than six years now.

2) Web technologies have reached a point where SaaS is an out of the box solution. You can now count on fast network connections for users both in the office and home. Security systems are complete from SSL with web browsers up through terminal services like Citrix which allow even HIPAA compliance. For web apps, browser technologies like IFRAMES and AJAX allow apps to be easily integrated on a page (mashups).

3) SaaS provides much more robust server management and security, especially for small and medium sized businesses. As web applications grow more complex, SaaS allows much more convenient, rigorous and cost-effective control over hosting. By centralizing and focusing, the best resources can be brought to bear on fewer hosting environments.

4) This one is a bit of a prediction, and is specific to web sites. Currently, you have a couple options when adding components like blogs, rss, ecommerce, polls, surveys, and search to web sites. You can install apps for those services, which allows you to control ad placement and design. The alternative is to use free hosted apps where the ad revenue goes to the SaaS company. So, the logical next step is for high quality hosted apps where the ad revenue is shared with the web site. This is already appearing with sites like MetaCafe. For an advanced CMS, though, I am not sure this will happen since the CMS tends to be the hub for all the other web apps, but it is certainly possible for a basic CMS.

Posted by Carl Sutter at 6:16 PM | Comments (0) | TrackBack

September 19, 2006

The Future of DITA

DITA (which stands for “Darwin Information Typing Architecture”) is the hottest new technology in the technical publishing market. While still early in its adoption cycle, it has the potential to become the future de facto standard for not only technical publishing, but for all serious content management and dynamic publishing applications. Whether this happens, however, will depend on the vision and creativity of the DITA standards committee, DITA vendors and DITA consultants.

While IBM originally designed DITA for technical documentation, its benefits are potentially transferable to encyclopedias, journal articles, mutual fund prospectuses, insurance policies, retail catalogs, and many, many other applications. But will it really be flexible enough to meet these other needs?

At Flatirons Solutions we’ve been testing the boundaries of DITA’s extensibility, taking DITA out of its comfort zone and thereby creating some interesting proof points for its flexibility. So far, the results are very positive. Four specific applications illustrate this:

* User personalized documentation – designed to support a variety of enterprise content libraries out of a single set of specializations, this application involved the use of 15 conditional processing attributes to drive dynamic production of personalized documents. An initial DocBook-based prototype was later re-designed for DITA.

* Scholarly research database – this solution involved marrying DITA with the venerable Text Encoding Initiative (TEI), a nearly 20 year old scholarly markup standard originally written in SGML. DITA was used to split the historical material into searchable topics; TEI provided the rigorous scholarly markup and annotations.

* Dynamic web publishing – designed for a large brokerage and business services firm, this application combines a single-source DITA-based authoring environment with an optimized dynamic processing pipeline that produces highly-personalized Web pages.

* Commercial publishing – we are currently exploring the use of DITA for encyclopedia, journal, and textbook publishing, for clients who have traditionally focused on print, but who are now also moving to increasingly sophisticated electronic products.

Of course, in pushing the boundaries we’ve also found issues. A classic example is the restriction in DITA’s “task” specialization that each step in a procedure must begin with a simple declarative statement. To make it as readable as possible, the procedure cannot begin with a statement that includes a list or multiple paragraphs or a table or a note. But what do you do if your content breaks these rules? DITA’s answer is that you rewrite your content.

Rewriting content is not unreasonable if you accept that you’re moving to DITA in order to adopt industry best practices. However, what if you don’t agree that DITA’s built-in “best practices” are the only way to write good content? Or what if you have 500,000 pages of legacy content, all of which need to be rewritten before they can conform to DITA? Would you still consider it practical?

You can solve this by making up your own “task” specialization, bypassing the constraints of the built-in “task” model. That’s an advantage of DITA. But if you do that, you’re taking a risk that you won’t be able to leverage future vendor product features based on the standard “task” specialization. And in other cases, such as limitations in handling print publishing, workarounds can be harder to find.

DITA 1.1 has made great progress toward resolving some of these issues. To be truly extensible, however, I believe that future versions of DITA will need to:

* Add more “out-of-the-box” specialization types which DITA vendors can build into their tools (for example, generic types for commercial publishing).
* Further generalize the existing “out-of-the-box” specialization types (for example, allowing more flexibility in procedure steps).
* Better handle packaging of content into published books, rather than focusing primarily on Web and Help output, and adapting this model for books.
* Simplify the means to incorporate reusable content, handle “variables” within text, and link to related content.

At conferences I’ve heard it suggested that if people don’t want to obey DITA’s particular set of rules, they should consider using another standard. I’ve even heard people say that DITA doesn’t need to focus on book publishing because print is “old school.” In my opinion, this kind of parochial thinking needs to be seriously reconsidered.

Today, DITA stands at the crossroads. If it can be aggressively generalized and extended to meet the needs of commercial publishers, catalog and promotional content, and financial services and other vertical industry applications, then it has the chance to be “the” standard in XML-based dynamic publishing. If this doesn’t happen, DITA runs the risk of being relegated to a relatively elite technical publishing standard that’s only useful if you meet its particular set of assumptions and rules.

As an industry, which way will we go?

Posted by Eric Severson at 7:25 PM | Comments (1) | TrackBack