DEC's LinkWorks is an open design for multiplatform work flow
Ben Smith
The promise of groupware is greater productivity through collaboration. Few products embody this ideal better than DEC's LinkWorks, a multiplatform (Unix, OpenVMS, PC, and Macintosh) work-flow system. If groups in your organization collaborate on the creation and development of documents, images, or data, LinkWorks delivers an effective set of tools for automating your most complex work-flow tasks.
The Local View
On a local desktop, LinkWorks appears as a window in your graphical environment, with each icon representing an object. LinkWorks objects can be just about anything, but they fall into one of three general classes: information (text or data), containers (e.g., folders), or actions.
The information objects are typically files associate
d with application programs--for example, an Excel spreadsheet, an Ami Pro document, or a bit-map image file. Unlike in the basic file system, LinkWorks information objects (analogous to files) and containers (analogous to subdirectories) have wrappers that contain far more information than just owner, creation date, and permissions. They have full text names, like those on the Mac; associated icons; application programs; descriptive text; an extensible list of permissions; and even work-flow paths.
Some of the actions show up as toolbar buttons; others are accessible only from drop-down menus. Click on an object icon in the window, and the icon launches an action or application that is appropriate for the file type on your workstation. Drag an object icon to the mail outbox icon, and your mail is sent automatically.
Despite its rich structure, the LinkWorks environment is not intimidating. You'll find the usual elements of any GUI file manager with just a few additions, including an In box, an
Out box, and a Pending box. These containers are crucial to the work flow; you send and receive your work through them. The Pending box is for the inevitable projects that are held up for one reason or another.
If an object doesn't have a default routing path, you can still route or share it. You choose points in a routing path and recipients for mail by selecting from an organizational chart. You can share the object by mailing a link to other users, thereby creating a collaborative work environment. LinkWorks includes built-in E-mail that can gateway with other, dedicated mail systems.
Whenever you create a new object, you need to specify what kind of object you want, give it a name, and designate the access rights for it. For example, you might create an Address Book object with the name Local Contractors and give it For Information access rights. A For Information designation gives other recipients read-only access to the object; only you can modify it.
You can use any object as a tem
plate by placing it in the template box. Dragging an object from the template box back out onto the Desk window copies the object but, unfortunately, without copying any of its LinkWorks attributes.
The object types that are on your system and the associated application programs for each workstation are defined by the LinkWorks administrator. In fact, just about everything about LinkWorks can be customized by the administrator.
Configuration and Administration
The true nature of LinkWorks is apparent only to the administrator. LinkWorks' paradigm is that of an object-oriented database. LinkWorks objects are very much what a programmer would expect, with base classes, subclasses, inheritance, and instantiation. The entire structure of LinkWorks hides within two deceptively simple-looking objects on the administrator's Desk window: the System Configuration and System Administration desks.
From the LinkWorks Configuration desk, you define object classes and subclasses that you'll be usi
ng in your operations, and you associate tools (i.e., application programs) with data objects for each different user environment. You can also define menus and workspaces for different classes of users from the Configuration desk. It is the most complex and the most static of the two administrative work areas. If you've worked with object-oriented systems before, you will find LinkWorks' Object Class browser very familiar.
From the System Administration desk, you create your organizational chart (it even looks like a tree-structure organizational chart), set user accounts, and administer workstations and working environments. You also define the keyword list from the administration area. The keyword list works like a miniature document management system by organizing and retrieving documents and other objects. Many of the objects that you need will probably have a predictable work flow. The administrator can define work-flow blueprints and attach these blueprints to objects.
The Ins and Outs of
Work Flow
Whether you, as an administrator, define a work-flow blueprint for an object class or, as a user, build a work flow for an individual object, the process of defining the flow is the same: You select the work-flow stages from the organizational chart. As you make your selections, you are building a graphical design of the work-flow process. Dragging and dropping stages creates the paths of work flow. A simple path would resemble a list with lines connecting the positions that the object passes through during its processing.
In addition, you can define branches, points when the object gets simultaneously distributed to several recipients. You specify what you consider ``processing'' at any stage. It might be as simple as the recipient opening the object when it is received, or it might require one of the three levels of signature: Initial, Approve, and Sign off. The signatures require password verification.
Any path or branch in work flow can be conditional--that is, dependent on the
status of any of the object's attributes after processing at the source stage. For example, you might require that the recipient modify the document or image, thereby changing the date stamp. In that case, the work-flow test would check for a new date stamp and would allow the file to be passed on only after the date stamp had been changed.
Any stage in the work flow can be associated with a mode--an indication of what the recipient should do with the object (e.g., ``For comment''). Any stage can also have a deadline and a more verbose description. In the current version of LinkWorks, these object attributes are little more than text fields, but in the next release some of these fields will be able to trigger actions.
Not all organizations need work flow. If your organization's operation (or a particular class of object) is more collaborative than state- and stage-oriented, you may find that LinkWorks' shared objects still fit your needs. A shared object can exist on several desks at once. Sinc
e LinkWorks maintains all its objects on the server, simple shared objects can be modified by only one person at a time, whereas compound objects (e.g., file folders and boxes) can only be added to or deleted from. You can ``register an interest'' in a shared object, prompting LinkWorks to notify you of any changes to the object.
Objects and the Database
Despite the object-oriented nature of LinkWorks, the infrastructure is an RDBMS (relational database management system). You can select your database choice from a supported list: Ingres, Oracle, Informix, or DEC Rdb.
The RDBMS points to where the objects are stored on the server. The objects reside in their native format in subdirectories deep in the LinkWorks directory tree. The only protection from curious eyes is the server's file-access control. Since the server can be an OSF/1, OpenVMS, Ultrix, SCO Unix, HP PA-RISC/HP-UX, or IBM RS/6000 running AIX, the security can be anywhere from pretty good to very good, provided that the server is
well protected from attack. Only the superuser and the RDBMS have read permission on the files.
Because LinkWorks manages all kinds of objects--binary images, sound and motion files, and compound documents, as well as simple text documents--the version control consists of complete copies of each version of a file. This design makes it nearly impossible to corrupt an earlier version of a file when retrieving it, but it has the distinct disadvantage of consuming huge amounts of storage if your objects and documents tend to be large.
LinkWorks has no utilities for automatically archiving older versions, so it is the user's responsibility to delete older versions of documents. You could solve this problem by backing up the system with software that supports file migration, a feature that moves dated files to off-line storage.
An Open Architecture
The controlled fashion in which LinkWorks maintains all its files and objects might suggest that it is not an open architecture. This is not the
case; it is as open as you wish to make it. LinkWorks has provisions for importing from and exporting to foreign file systems and mail systems.
On the other hand, you can turn off these features and require that all documents and other objects within the LinkWorks system be created, revised, and retained only on the LinkWorks server--even if programs external to the server are modifying the files. The obvious loophole is that most application programs let you make copies of documents to more than one storage device. The only sure stopper is to deny client machines any write permissions except through LinkWorks.
Using a common SQL RDBMS system as the infrastructure lets you extend LinkWorks by writing your own SQL operations and reports. For instance, the operating system's scheduled batch processing could generate a status report of all projects that are in the queue. Since the SQL source statements that make LinkWorks run reside on the system, you can hack copies of them to process your own fi
les automatically.
The RDBMS infrastructure also makes it easy to scale up to a LinkWorks site. You aren't limited to a single LinkWorks database (internally referred to as a cell) or server. A single LinkWorks administrator can manage several cells from the same interface. The one extension that you cannot make is out over a store-and-forward WAN (wide-area network) stream. LinkWorks needs TCP/IP.
On the downside of the RDBMS design, the object-oriented model doesn't map efficiently to a relational model. Any operation that changes the hierarchical structure requires updating the database structure, not just the data. LinkWorks locks you out of doing any other operations until these are complete.
Modeling BYTE
I evaluated LinkWorks using a DECstation 3000 (64 MB of RAM and 2 GB of disk space) running OSF/1 as the server. As client machines, I had four 486 PCs with 8 MB of RAM (the minimum memory recommended for this application) and a Mac Quadra 950. Engineers from DEC installed the s
oftware, including the RDBMS and the TCP/IP stacks in the PCs and the Mac.
The installation was not trivial: It took three worker days. The most difficult part of the task was installing a second network protocol stack in each of the client computers. The DEC engineers also configured LinkWorks for each of the client machines, associating application programs with object classes on each client.
After an afternoon of training, I was on my own. I started simple: I designed a BYTE logo for the log-in window. Once I had established a feel for the menus and general operations, I was ready to begin a model of BYTE's editorial process.
At first, I became disoriented in organizational chart design. I didn't understand how to optimally model our organization. I found that it was important to group users together in departments or workgroups. A group of people, any member of which could complete a specified task, often represents a work-flow stage. It took three tries before I had a decent model of
the organization and an article (a compound object that I defined from the Configuration desk).
I spent roughly 40 hours developing this working configuration, but I still had to develop work-flow blueprints. Different kinds of articles follow different paths and have different requirements for text and graphics. Properties such as deadlines also differ from article to article.
DEC (or a VAR that sells LinkWorks) will be glad to do the configuration and administration for you, for a fee. If you don't have technical people in-house or if your technical staff doesn't have the time to manage yet another system, using DEC or a VAR is your best bet. All in all, the configuration and administration were complex and tedious, not because of the complexity of LinkWorks, but because modeling work flow is complex.
The Long and Short of It
Shrink-wrapped work-flow systems have been slow in coming to market. There are hundreds (if not thousands) of custom-built systems--in-house, proprietary, and
requiring large dedicated staffs to maintain the programs and systems they run on. Most work-flow packages that you find at groupware trade shows are limited in one way or another. Either they run in only a single environment (e.g., Reach Software's WorkMan works only in the PC LAN, MS-DOS/Windows environment), or they only move documents of a limited type. Some are only tracking systems, independent of the documents themselves. DEC's LinkWorks supports clients on the three most common corporate computing environments--Unix workstations, PCs (albeit running Windows), and Macintoshes--and at the same time contains, controls, and routes data objects (and collections) of any type.
Of course, there's always room for improvement. The most obvious, and most difficult, improvement would be enhancing performance by moving from an RDBMS to an object-oriented database. But this move would result in a considerable loss of openness, and the net benefit is questionable.
The other improvements that I would li
ke to see are in the details. For example, LinkWorks doesn't fire off a notice when a deadline is approaching or past due. If you have the same user in a work flow more than once, the path becomes confused and looping. There are far too many verify-process notifiers; for that matter, far too many windows are necessary to do many operations. The menus (particularly the system configuration and administration menus) are poorly organized and almost primitive in design.
It is a long list of little details. You can handle some of them by simply reconfiguring LinkWorks to your own tastes, but some will require in-depth, source code changes. For example, LinkWorks requires TCP/IP or DECnet. It will not run on an IPX/SPX (NetWare) or AppleTalk/EtherTalk network. Improvements in these and many other areas are in the works.
To the user, LinkWorks is deceptively simple. To the manager, it is deceptively inexpensive, costing just $299 per client or server (not including the DBMS license and potentially hig
h training costs). You can even save on that by $30 if you don't need printed documentation for any of the licenses.
LinkWorks is extremely complex, but then so is managing work flow manually. Before you even consider installing an automated work-flow system, spend some time making sure you understand the various forms of work flow in your operations. If your organization can be diagramed in a few boxes, you probably don't even need LinkWorks.
If your organization has groups that need to collaborate on the development of documents, images, or data, or if your work flow is complex enough that you need to automate, track, and control it, then LinkWorks is as good as it gets. But if you don't have the in-house expertise to study operations and to model work flow using LinkWorks' object-oriented paradigm, you'd better budget some serious consulting money.
The Facts
LinkWorks...................$299 per client or server
Digital Equipment Corp.
LinkWorks Marketing Grou
p
110 Spitbrook Rd.
Nashua, NH 03062
(603) 881-6146
fax: (603) 881-2550
Illustration: The entire structure of LinkWorks hides within two deceptively simple-looking objects on the administrator's Desk window: the System Configuration and System Administration desks. The administration and configuration menus are poorly designed.
Illustration: The organizational chart is an intuitive way of pinpointing stages in the work flow. The (hidden) work-flow diagram follows the same model. Unfortunately, you cannot resize the chart window.
Ben Smith is a testing editor for the BYTE Lab. You can reach him on the Internet at
ben@bytepb.byte.com
or on BIX as ``bensmith.''
Blazing the Path
