There is some thought among analysts who track this space that the next step for SDL would be the acquisition of an XML editor as part of a fully integrated solution. This seems like a low-probability event; part of SDL’s success comes from its agnostic approach to vendor authoring tools (similar to Astoria’s). Once you commit to one vendor, you’ve pretty much shut out the rest of them, and with XML capabilities becoming an integral part of most authoring offerings, there’s no reason to do this.

The other technology implication in this acquisition is SDL’s move toward SaaS as a delivery method; Idiom has a strong SaaS offering (better than SDL’s), so if their intention was to accelerate the ramp for a SaaS product, snapping up Idiom just saved SDL 18 to 24 months of development effort for a very reasonable price. As mentioned earlier, this is another in a series of acquisitions for SDL as they try to 1) reposition to become a serious contender in the global delivery of on-demand component content management and 2) position defensively against LionBridge, the only player in their immediate ecosystem that is bigger and potentially a threat. Tactically, Idiom will be a jagged little pill for SDL to swallow, but strategically they’re definitely well positioned for the future.

Most importantly, this is another in a long series of validations of the increasing acceptance of both DITA as an authoring standard, and on-demand as a delivery mechanism, both areas where Astoria has long been a driving force in the market. From our point of view we’ve had very good working relations with both SDL and Idiom, having the two entities combined into a global, SaaS-enabled partner who has deep DITA knowledge is not only a boon to Astoria’s SaaS offering, but to the entire documentation function across multiple, global industries as well.

If you agree or disagree, or would just like to comment, please feel free to visit my blog at http://www.astoriablogs.com/rich-media/ , or drop me an e-mail at dortega@astoriasoftware.com.

Given this predisposition, it’s interesting to watch the social networks dance around the enterprise domain. The socialization of the enterprise does not mean introducing the consumer version of a social network into an enterprise framework, but rather taking the baseline concept of collaboration and anchoring it around a dynamic content paradigm with a specific objective in mind. Projects that are enterprise-wide in scope, such as a new product launch, cut across multiple divisions within a company. In theory engineering, marketing, sales, training, and customer support should be tightly coupled.

The current best in class performers can provide a tight integration for this type of production workflow, but in nearly every instance the application of the process is linear. This approach would be ideal if companies produced one product, one time. This, of course, does not happen; companies are constantly introducing new products and/or services, as well as expanding their existing offerings with feature enhancements, new services, etc. Because the nature of development and release of new products is inherently dynamic, the processes that drive and support this cycle need to be dynamic as well. Large groups of people are constantly collaborating to create better/faster/cheaper products, and more often than not they’re slowed down by the lack of a true collaboration solution that allows dynamic functional integration. That is where the collaborative aspect of social networks comes into play, and the catalyst for this is the associated integration of dynamic content management.

How do you socialize existing content resources within a corporation? A really great example is currently playing out with the British Library. The British Library recently extended it’s presence into Facebook, by taking a vast repository of information that had been “hermetically sealed” and making it available to a wide range of users, with information delivered in the context of a social exchange that can be on-going or event driven. This is a very cool, very forward-thinking approach to managing your content resources, and allows a new generation of users to breath life into a content repository that might have otherwise become marginalized. So what is the corporate corollary to this? Think about the vast content resources that are sitting in most corporations, all locked up in tight little silos. Imagine if all those content resources could be re-purposed dynamically in response to collaborative requirements that are inherent in any product development cycle. Allowing full access to content repositories in the context of a fully integrated collaborative workflow could bring the same re-energizing benefits to major manufacturing companies that the British Library is currently enjoying.

So what is next? There is of course, the need to go mobile in a hurry, which has already been covered by a number of other bloggers, as well as the need to move their massive desktop applications into an on-demand delivery model. Adobe has already stated their intention to do so (over the next ten years), and took an opening foray by acquiring Virtual Ubiquity and making Buzzword available for free.

Another area that will require a strategic focus is not only taking the company’s applications off the desktop, but embedding them deeply into the production workflow of their customers. An on-demand application set facilitates this, but offering a product like Buzzword as a SaaS product is a long way from offering an enterprise grade product like Framemaker as a SaaS product (which could explain the ten year time frame).

So how to shortcut a ten year conversion process?  The real issues revolve around use and perception. Astoria, for example, offers a product that operates both as a perpetual and as a hosted (SaaS) product. From an end users usage point of view, the products are indistinguishable (the SaaS version costs significantly less and deploys in weeks rather than years, but that’s a separate argument). Assuming that Adobe want to transition their application set into the cloud, an interim step could be to provide a seamless integration into a SaaS CMS that is optimized to deal with rich media applications. This enables re-use across the enterprise (create once, re-use lots of times) and would allow them to jump their conversion process forward by years, at least from the perspective of the majority of users of the application’s output.

Rich media applications are already in play on some level in nearly every corporation, and although rich media has already made good inroads, its use is still siloed due to the way sophisticated rich media creation tools are used. The biggest footprint here is probably Adobe. Right now most of their apps are installed on a PC/Mac, and while they are good at sharing information between Adobe applications, they still lack an effective integration strategy into production workflow systems. Because of this, most of their deployment remains at the desktop. They have announced a move to SaaS over the next 10(!) years, so at least they’re moving in the right direction.

We’re also starting to see large corporations moving into the social networking sites, primarily as a means to gain due diligence on a prospective employee, as well as to reach into a demographic target for sales, recruitment, etc.

What I’m not seeing a lot of (yet) is thinking about how to design and implement the corporate equivalent of a social networking site. Social networking sites exist for information and entertainment, they have great collaboration tools, and millions of people who aren’t geeky enough to build their own website can create something quickly, easily, and for free. The same type of rich media and collaboration tools applied to a large group of people with a specific objective, e.g launching a new product, could have a huge impact on how manufacturers build, ship and support their products.

The true gating factor is how all of this fast changing information is going to be created, managed, and delivered across multiple media types. Rich, dynamic media is well-suited toward management by an object-based Content Management System (CMS). All data elements, regardless of media type, can be stored as objects accessed through pointers. Unlike a relational-based CMS, there are no referential integrity limitations, the system scales seamlessly, and it is designed for constantly changing content. The fact that rich media content is created in a silo becomes a non-issue once it hits the CMS.

What ties this all together is on-demand delivery. Any product going through a complex production lifecycle requires component-level integration of information across multiple functional groups, and ongoing distribution of updated information across internal and external touch points. This is an ideal business model for an on-demand environment. Functional groups that are spread out or outsourced can easily collaborate on specific objectives, providing detailed information (across any media type) into a repository that becomes the single source of truth. The repository subsequently assembles rich media information on the fly to employees in support, training, sales, and marketing, as well as to channel partners and customers. This way, the company speaks to its customers and channel partners with a unified voice, ensuring information is always current and consistent, regardless of touchpoint.

Adobe appears to understand the concept of an on-demand product offering but fails to connect at an operational level with the process requirements of their constituency. It was presumed that this was a shot across Microsoft’s bow, targeting the Office Suite, but as others have pointed out, it is highly unlikely someone is going to ditch Word and go with Buzzword. However, if their target is the Facebook crowd, this then starts to look like a headfake. Feint towards Microsoft (the obvious target), while sneaking up behind Google, and make a move towards the consumer market.

While the market for SaaS-based content management is smaller than the traditional (that is, rack-mounted, behind the firewall, “supported” by IT) CMS system, the overall trend we see is that the SaaS model is growing very quickly, while the traditional model has slowed down significantly. More importantly, the growth we’re seeing is not only in the historical SaaS buyer market (small and medium business), but in Fortune 500 companies; 90% of our SaaS customers are in the Fortune 500, which clearly indicates this is an enterprise-grade play. It also indicates that SaaS as a delivery model has come of age, companies in the F500 are all multi-billion global players, and the decision to switch to this model is not made lightly.

Information on market trends and players can be filtered and categorized any way you want, but the bottom line is the one with a dollar figure on it, and in that context, SaaS-based content management has definitely arrived.

After years of evolution, growth, and major acquisitions, Adobe still appears to be focused on a desktop paradigm.  The Technical Communication Suite press announcement references FrameMaker 8,  RoboHelp 7, Captivate 3, and Acrobat 3-D v8, however, when they reference workflow, they  refer to workflow integration between the products in the TC Suite.  This is not to be confused with documentation workflow integration that tracks the production lifecycle that is found in most major manufacturing companies. 

For example, all of Astoria’s customers are heavy users of technical documentation products, and a significant percentage of them are FrameMaker users.  The problem for FrameMaker users is that they work in isolated silos, which is one of the characteristics of a desktop solution.  They may have workflow integration with other Adobe products, but they lack integration into the broader production workflow.
 
Astoria’s customers are Forbes Global 2000 companies, and these companies routinely deal with global manufacturing issues.  The technical documentation team for any product line produced by any of these companies is typically spread out across the world. What is required is full visibility into the documentation production process for teams that may be spread out across 24 time zones, operating in 30 languages, and delivering documentation to over 100 countries.  The desktop-centric model just doesn't work in this context.
 
If Adobe plans to succeed in the enterprise, they have to take a much broader view of how technical documentation teams work by moving beyond the creation perspective.  They need to adopt a perspective that encompasses the entire production cycle, which by default means they need to incorporate a robust, muscular content management system that is delivered on-demand and optimized for rich media.  Once they make this leap, they will move from ruling the desktop to ruling the documentation production flow. 

A number of large companies with reputations for being otherwise innovative in terms of their products are hard-wired to the notion that the application that manages all the rich media content needs to be rack-mounted, behind the firewall, supported by IT, blah, blah, blah. A very 90s view of how technology should be deployed.

Considering that most product information for large corporations is produced by teams that operate all over the world, how could they not adopt an on-demand model? In the old world, ten people working on a document would work sequentially (make my edits, attach the document to a e-mail, on to the next person in the chain, etc). In the on-demand version, all ten people are working simultaneously on the same document (which can include all the cool rich media input), everyone sees what the others are doing, as a result they all arrive at the end-point at the same time and in a much shorter period of time.

On-demand delivery of a rich media content management system can also increase consistency in terms of how a company communicates with their customers. Everyone agrees on the need for a corporation to deliver a consistent customer experience. What information is available at the point of contact and how effectively it’s delivered define that customer experience. If all customer touchpoints have the same, constantly updated and integrated information source this synchs up Training, Field Services Support, Customer Support, Sales, Marketing, Engineering, etc.

On-Demand makes this model possible. Six key reasons to look at this:

- End-users get a steady stream of upgrades, delivered invisibly
- No more being held hostage to the whims of IT
- Expand or contract usage as needed, no more shelfware
- WAY lower cost of ownership, like 75% lower
- The entire industry is moving in this direction, whether they realize it or not
- Deployment time is measured in days, not months

The bottom line is that the entire market is already moving in this direction and it’s a huge upgrade no matter how you look at it. This will also allow companies to focus on their core competencies rather than on infrastructure interactions.

The world of technical writing is a sunny beach about to get hit with a rich media tsunami. It’s easy to imagine what happens to those who freeze in place. Those who high-tail it to “safer ground” might get through (or not). Those who embrace what’s headed towards them and turn it in their favor will be in for a totally excellent ride.

Several years ago a similar wave hit the software development beach when outsourcing became a viable option. The company I was working with at the time told its software developers their jobs were going to India, and they had two choices; leave the company (look for higher ground), or make the move from software developer to software architect and manage the new crop of software developers in India (grab that board and get to it).  A lot of them, oddly enough, ran towards option #1, and ended up having the exact same conversation with their new bosses about a year later. A few ran towards option #2, and now they’re out there catching righteous tubes.

The technical writer has always been at the core of a company’s communications effort because they deliver the highest value content-information about the company’s product and services. While the shift to alternate (and perhaps more effective) media types including video, Flash, voice, etc. is accelerating, text will always be the underpinning of complex, detailed information.

The extension of basic communications mediums to include rich media provides the technical writer the opportunity to focus on managing overall information creation, rather than just writing text. Instead of worrying about being displaced by video or graphics, the technical writer needs to reach out and assimilate new media types into their on-going creation and production management efforts.

Something else to think about; the technical writing function is starting to get outsourced, so that wave is getting bigger and moving faster.

If we shift this dynamic into a more structured setting, e.g. user generated content that becomes part of a major corporation’s document repository, we are dealing with an entirely different set of circumstances. The flow of information, regardless of its end destination (marketing, customer support, operations, etc.) is normally under incredibly tight control. The first loosening of this control was the rise of blogs; however, most corporate employees who blog also have the good sense to realize that what they say is getting blasted out across the web (specifically, across their bosses desk), so career preservation tends to be a good content regulator. Compare this to personal blogs (particularly the anonymous ones), where anyone with an opinion can yell at the top of their lungs about anything with no consequences. Corporate blogs are a whole different animal, and much more tightly caged.

So if you take the notion of a corporate blog and loosen the filters to "evolve" it to a wiki, is this the equivalent of letting a pack of hyenas into your living room? A lot of pundits seem to think so, however, with the proper review and approve mechanisms there is no reason to assume you can’t maintain the same level of control. The benefits of a wiki as an input mechanism to a documentation process that had previously been behind an information firewall are vast. The people who are most likely to come up with good suggestions to improve a product are going to be 1) people who are out in the field servicing the products day to day and 2) people who are using the product and wish it worked better/different. This is a huge, untapped resource for any manufacturer in nearly any vertical; as long as the wiki input is pushed through a review/approve cycle. In fact, once this technology is deployed, your biggest challenge is going to be keeping up with all the good ideas that start streaming in.

The web is in fact going through a very strong growth phase right now. As one limited example, look at the broad and rapid rise of social networks like myspace, facebook, hi5, etc. The most interesting part of the social networks? People who would never create their own on-line presence suddenly have a web page that is, for the most part interactive, heavily populated with photos, blog entries, etc.

As far as I can tell, anyone under the age of 25 seems to spend more time socializing on-line than in real life. This type and level of engagement can only help the long-term growth prospects for the web.  Plus, unlike the irrational exuberance of the dotcom boom, the current crop of web application start-ups is solidly grounded in best business practices, which means this phase will be sustainable.

Yes, rich media applications will fuel more rapid adoption of web technologies. However, the true growth engine driving technology is adoption at the enterprise level. Unlike consumers, corporations do not make impulse purchases. Everything has to be cost justified. By the time a company makes a decision, it has been well grounded to serve the company’s business needs, whatever those happen to be. Rich media applications are getting piecemeal traction within larger corporations (mostly in the marketing and communications areas), but the gating factor to widespread adoption is not where they’re used, but how they’re used.

Corporations are all about production workflow, whether the end product is an automobile, a home mortgage, investment services, etc. Any large company is geared to follow a process that needs to be followed from start to finish. That’s how they create, manage, and deliver products and services that bring in revenue.

For rich media applications to really take off, they need to be integrated into this workflow. Beyond content creation, rich media apps need to integrate and enable the group collaborations that drive revenue – demonstrated by metrics and analytics, of course. For companies that create rich media applications, that type of perceptual shift will take them from being a point solution to becoming a critical and strategic component of their customer’s success.

The problem I’ve always had with Google is that it provides tremendous depth, no breadth, and very siloed information. I can get millions of text returns, or I can get millions of image returns, or I can get millions of query returns for video. And don’t forget all the advertising I also receive as part of my “experience.”

As it stands now, the vast range of search returns forces me into browse mode, which is fine if I have the time to cruise around the web. But I don’t. Like most people, I’m in a hurry. Browsing millions of returns just slows me down.

So what’s going to help me cut down my Internet search work load and celebrate Labor Day as Wikipedia intended? Search alternatives that are taking a stab at more integrated (or clustered) search returns. One is a company called Grokker, which was spun out of a company I worked for several years ago. They offer a very cool mapping interface, and a very nice clustering of information that pulls out relationships that are often not obvious. Another interesting site I just came across is Tafiti, which has a beta version of a Silverlight-based rich media search tool, which tried to combine books, news, RSS feeds, and images – but no video – into a single user experience.

Let me point out I am not criticizing Google. Any company that can go from zero to a zillion dollars in revenue almost instantly (in relative terms, of course) has obviously done something right. But there is always something new and interesting lurking around the next corner. Rich media and clustered search are the next corners. How will Google and the established search engines respond? Anything can happen. Remember, not that long ago, Google was a tiny shop, and Alta Vista (remember them?) was the king of the hill.

Or better yet, if the answer you seek can be illustrated by an image (still or moving), why read 1000 words when you can get the same information from looking at a picture or diagram? Is it reasonable to assume that if someone is creating visual content that can be tagged to a specific product in terms to explaining a process or methodology, is it also reasonable to assume that the information is going to be created in small, usable elements?

The interesting aspect of all this is that most people who work in departments that require information resources as part of their end deliverable would be able to repurpose this information to additional uses. The basic concept then becomes repurposing information across the enterprise. A number of our customers are already doing this with traditional text content and have found savings in the neighborhood of as much as 70% (this actually translates to millions of dollars in most cases, click here for an example).

It is therefore reasonable to assume that if you can save that kind of money with pure text, what kind of savings are possible if you could apply the same metrics to media formats that conveys much more information in a more efficient style (if a picture is worth a thousand words, that implies it's a more efficient information delivery mechanism), so presumably a more efficient delivery mechanism would have a higher rate of return once you begin to repurpose the content that is being delivered.  If you start doing the math, the numbers get really large, really fast. 

So first question, how does rich media information get to a location where it can be useful? Delivery of rich media information into a content repository is going to be driven to a great extent by the enabling technologies the applications vendor provides with its solution. To begin, the information has to be well organized from a contextual and a topical point of view. Most information creation applications support XML as a means of structuring content, so as a baseline reference, this is a good start. The problem with XML is that it’s so adaptable it becomes widely used for nearly anything, so much so that the original intent (structure and context) becomes lost once it becomes widely deployed across a large enterprise.  This conundrum is what lead to the rise of DITA (Darwin Information Typing Architecture), an XML-based standard originally developed by IBM for software documentation, and then (wisely) passed to a standards body (OASIS) for wider ratification and dissemination.

So while most major authoring systems such as a FrameMaker, Word, ArborText, or XMetaL already support DITA as an authoring standard, a number of non-text information creation applications are also looking at DITA as a standard for organizing information so their output can also be found in a topic-based search. There are rumors that Adobe InDesign, Dreamweaver and Flash are moving toward DITA. Once that crossover occurs it means that as Rich Media information is created it can be tagged using DITA to create a topic reference. When information is subsequently entered into a content repository it’s already primed to be found either by somebody searching for information on a specific topic, or by people who are browsing information structures such as an FAQ table.

A longer-term implication is that eventually consumers, field service technicians, call center employees, educators, essentially anybody looking for information on complex technology will be able to access data repositories that include not only text, but also full motion video, graphics, voice walk-throughs, etc. All of this will be accessible as a search return to a topic-based query, or delivered as part of a “browse” function, which means if you go into a well-organized document database you’ll be able to get the exact results you need, delivered in a variety of rich media formats.  Adobe is in an ideal position to exploit this potential market once they begin thinking along the lines of process flow and true enterprise information integration.

Assuming most information (particularly about technology-centric products) is created and delivered in a digital format, it’s also reasonable to assume it’s delivered over the web. It’s also reasonable to assume the ubiquity of the web (it is essentially as widely available as wireless infrastructure, which you can get nearly anywhere, anytime).

So if it’s possible to provide information without delivery limitations, the question is how to provide precise product information; that is, not millions of answers to a query, but provide the correct answer to a question. Or take it up a level; not just provide a text response, but include query results in a variety of rich media formats that may be better suited to the end-users need for information.

It is now possible to provide a precise text response to a product query; assuming the text has been rendered in XML, or better yet, the text reflects documentation standards such as DITA (Darwin Information Typing Architecture) where all technical information is organized by topic down to a very fine level of granularity. This standard is what allows companies to provide an exact answer to a technical question (e.g. a Field Service Technician asking (how do I upgrade the motherboard on a Siemens MRI Scanner model # blah, blah). The docubase for that particular machine is stored in an object database, and organized by topic. Since the query is specific to a procedure (or topic), the query engine pulls out the relevant references across the entire database, and organizes the information by topic and sub-topic, on the fly. This is referred to as Filtered Publishing. No more thumbing through a 10,000 page manual (literally, at least—the flight manual for a Boeing 747 is over 1.2 million pages long). This is a huge improvement over the hard copy experience all of us have suffered through, but we are still one step short of the promised land: one question, one answer, delivered anywhere, anytime, in any relevant media type, to whatever form factor is most convenient to the end user.

So how do we get there? I’ll start on that on the next blog.