by Karl Schumacher President
Vice President, Global Business Strategy and Acquisition

Converging technology is at the forefront of an information revolution occurring across today's business spectrum. Convergence creates opportunities for corporations seeking a new wave of growth. But with those opportunities come potential pitfalls, the most vexing of which may be the incompatibility of the various technologies.

Several types of convergence are currently exerting pressure on document professionals, whether in IT, marketing or in mail creation and production. They are:

• The convergence of conventional, legacy print-streams with digital delivery
• The convergence of transactional with promotional documents
• The convergence of tasks and duties within the organization--ie, the blurring of lines between IT, Marketing and Print/Finish.

The obvious goal for customer communications today is to achieve effectiveness efficiently. That means producing customer focused documents at a reduced cost of production with reliable and more flexible delivery options that reduce cycle time.

A number of tools and technologies exist to help achieve this key customer communication goal.

Data Quality tools to ensure that the message is going to the right customer at the right place.

Distribution Efficiency tools to ensure that the message gets to the right place at the right time at the right price.

Document Composition tools to ensure that the right message is being communicated. Doc Comp tools can ensure that high volume transaction documents are focused and render high impact messages.

Print Stream Manipulation tools to enable users to parse and tag data elements and perform conditional operations based on the data within the document, including the capability to reprint.

Digital Delivery engines to allow for the document to be presented to the web and other electronic media.

Archiving and Retrieval systems that help store and utilize documents for broader purposes across an organization.

These solutions and technologies can combine to formulate a very powerful customer-focused, document centric strategy for an organization seeking a competitive edge. At the same time, two major issues have arisen due to their convergence: one relating to the infrastructure created by a lack of interoperability and an issue with standardized data formatting.

Convergence in the Document Factory
One or more departments within an organization may have access to and depend on these technologies. Convergence within the organization, spurred by the desire of businesses to eliminate organizational silos, has played a major role in the technology field since the early 1990s and has made it essential for departments that traditionally operated in isolation to work together.

Over time, organizations have built or bought software and applications to manage their document production processes. They strive to acquire the best technology available but technology changes over time. Therefore, at any point in time, companies will have a mix of technologies that need to work together to make the process run smoothly.

Fortunately, document production tools share many commonalties. They often require an understanding of the origin of the documents, in particular the legacy systems from which they came. Most involve some degree of parsing (i.e., an identifying, describing, or defining) capability. Some require an indexing or tagging capability. Others require conditional or rules-based engines to enable them to take certain actions based on requirements of the data within the document, the document itself, or the associated workflow.

In addition, a few require output drivers to help guide the documents through the different delivery modes. And some require the updating of information databases on the host system to include new information retrieved from these tools, such as updated names and addresses.

Unfortunately each tech solution was developed for a very specific purpose. What all these products lacked in the early development phase -- and what limits their capabilities for interoperability today -- was a common view of the fundamental or underpinning technology. Thus, although the best accomplish their mission very well, key performance issues arise when the vendor or customer seeks to increase the range of features and functionality of these technologies toward broader document processing capabilities.

The digital document delivery field, for example, is complicated by convergence as companies with diverse approaches try to stretch the range of their technological competence in search of a share in this highly touted "killer app." In any event, a key issue facing document production managers trying to meet Service Level Agreements (SLAs) is about how these tools interact -- or are unable to interact -- with each other.

Issues Impeding Progress
Fundamentally, expanding the range of document output capabilities is hampered by substantial limitations in the way they perform their functions:

• Too many document composition tools require data in specific formats as opposed to being able to create that formatted data for its own use.
• Many digital delivery products require a front-end tool to split the print ready files for routing to either hard copy or digital channels.
• A number of archiving and retrieval systems are unnecessarily rigid and lack the ability to flexibly render documents to a web environment.
• Print image manipulation tools often lack full awareness of the physical composition of the document, thus limiting choices as to what may be added and where it might fit.

There are additional issues in how these tools execute in the infrastructure in which they reside. The problem presented by a lack of interoperability among the tools emerges when we begin to combine these products in a continuous workflow process. It occurs because many of the products have been designed for specific operating environments, for example the MVS (mainframe) UNIX and Windows NT environments.

It all comes to a head when a work flow is established that requires a task to be performed by one product on a given platform, with the output of the process passed into an operating environment with a product on another platform. As a result of the lack of interoperability and messaging between platforms, it is nearly impossible to produce with speed and efficiency a clear understanding of whether everything is executing as expected.

Re-Inventing the Wheel?
The method most often used to overcome the infrastructure issue is to write your own highly customized scripts that thread one operating system to another, along with 'hooks' in the applications to report on conditions. These scripts are not based on a standard, nor are there common Application Programming Interfaces (API) in the application, which means that the same highly customized process must be developed for each new application.

Additionally, if there are revisions or changes to operating systems, and/or applications, there are significant maintenance requirements that also need to be undertaken to keep the flow going.

But what if we leveraged the client/server messaging that has solved so many problems found in networked computing. Standard message protocols are established between client and server code, and events are acted upon based on the messages. This architecture allows messages to dictate what gets executed where. With a pre-defined message protocol, all systems respond to the message commands sent to them. The "pieces" of the code to be written would be the client / server programs that will "pitch and catch" messages, and launch processes. The process launch architecture could contain a list of profiles to be launched, and rules which govern activity during expected or unexpected results of the launched processing. Essentially it would be doing the job of JES and the JCL processor on a mainframe.

The major downside is that a single client would not work for all operating system platforms. For instance, a message client that is structured to launch processes on a UNIX platform would be slightly different for the Windows NT operating system. It's technically feasible but requires further research, design, and prototyping.

Undermining the whole movement toward convergence is the fact that the key players involved--both in document management and with the vendors supplying the technology and solutions--are hindered by the inertia that comes from existing reliance on a given architecture, from which change will be very difficult. And to be fair, mainframe processing models have had 30+ years to mature, stabilize and weather the storm of applications that have passed through them. Any new system developed is going to be measured against that standard.

The Benefits of Data-Independence
With regard to the data format issue, many people in the industry would promote XML as the answer due to its ability to decompose the print stream and free the data for tagging and reformation. There is certainly some merit to this idea. Once data is independent from the tight integration of the medium it can be re-purposed to produce any number of data reports: management or finance reports or an audit track, for example. It can also trigger other applications--CRM for example. Customer data made independent from an invoice can provide a very useful well-developed snapshot of a customer.

So let's dream a little. To achieve data-independence, the foundation requirements for any product in the document output set should include capabilities in four key areas:

• The ability to ingest either raw data or print-ready data, with the ability to parse and tag and transform the data from one format to another while retaining its richness.
• A data repository capability to share data efficiently and in a structured manner and render it available for use within the entire enterprise, not only for documents, but for reports and other forms of analysis. The footprint of the format must be small to save storage and minimize bandwidth.
• The ability to implement rules-based decision-making as a key component within the core features.
• The ability to produce output in various forms, including both hard copy and digital delivery

Once this foundation is established, all the other value-added functions --such as composing a document, splitting print streams, building data files, consolidating mail streams, and storing and retrieving documents -- become applications that sit atop the basic functionality of the technology.

The benefits of such a flexible architecture are widely recognized and have been written about many times, and underscore the key attributes sought by print/mail finishing managers, marketing departments and IT.

Flexible output architecture presents a tremendous opportunity to boost the effectiveness of customer communications by creating a high-impact document. It gives us capability to use the document, when it is posted to the web, as a foundation to implement cost-saving and business-building e-commerce strategies.

In addition, we have the ability to integrate the document with existing customer support activities to lower costs and boost effectiveness. And we can use the document to initiate or increase the levels of 1:1 marketing. Implicitly, there is an immense opportunity to succeed in both the hard copy and digital world, which includes historic savings in postal discounts and mail piece consolidation and newer benefits such as web-based customer self-service.

Yet this approach is far from perfect. I've heard it said that XML should stand for Really Hard Work. The utter lack of standards and the pushback from vendors trying to keep their data structures proprietary means that each individual using XML has to write what could amount to about a ton of code to accomplish fairly modest goals. Employing a roomful of developers writing XML code can not be the answer. A de facto standard may eventually emerge, but that won't help you reach your SLAs tomorrow.

Proceed With Caution
Given this reality, what are the potential remedies? We can stop where we are, halt all forward progress, scrap what we have, point fingers, and wait for someone to come up with a solution. But that wouldn't be practical for all the most obvious reasons. No one knows for certain how long that might take for a remedy to emerge. And competitors might develop and implement a proprietary solution without fanfare.

On a go forward basis, my best advice is to not cobble a document output technology together without a clear understanding of how various products need to integrate and which are the best platforms to optimize their complementary performance. For the time being, the answer isn't software--it's a convergence of logic and caution. The simple application of rational sequencing, procedural training and platform selection can do wonders for enhancing opportunities for success and eliminating blind alleys. Success requires careful planning and selection of technology and services.

Conquering Convergence
If the goal is to master the convergence of the various document output technologies, then we need a clear and in-depth understanding of how the various products and technologies integrate and which platforms and data structures best optimize their respective and complementary performance. That may take time and effort, but it is the best way to maximize opportunities for success.

Managers who keep their options open, and can commit to new foundation technologies that feature value-added layers for document output capabilities as they emerge in whatever form they may take, are poised to reap significant rewards. In conclusion, the solution to these problems can be approached in a number of different ways, all requiring the innovation to create a system that is flexible and dependable, requiring further research and development, which will be a priority for Pitney Bowes as we move ahead.

Return to List of Articles