MOSS 2007 Workflows and Enterprise Document Management V1...

MOSS 2007 Workflows and

Enterprise Document Management V1.3

Boyd R. Collins

Table of Contents

1 EXECUTIVE SUMMARY 3

2 PURPOSE OF THIS DOCUMENT 4

2.1 DOCUMENT REVISION HISTORY 4 2.2 ABBREVIATIONS AND ACRONYMS 4

3 SHAREPOINT DOCUMENT LIFECYCLE MANAGEMENT 5

3.1 MAINTAINING CURRENCY 5 3.2 SHAREPOINT WORKFLOW BASICS 6 3.3 WORKFLOW FUNCTIONALITY 9

4 WORKFLOW AND REGULATORY COMPLIANCE 12

4.1 ENSURING AUTHENTICITY AND ACCURACY 12 4.2 DIGITAL SIGNATURES 13 4.3 RECORDS RETENTION AND WORKFLOW 14 4.4 EMAIL MANAGEMENT 17

5 MOSS 2007 BUSINESS PROCESS MANAGEMENT 19

5.1 DESIGNING BUSINESS PROCESSES 19

6 COMPARISON MATRIX OF WORKFLOW CAPABILITIES OF MOSS 2007 AND EMC DOCUMENTUM 22

7 CONCLUSION 24

Microsoft Office SharePoint Server 2007 Workflows and Enterprise Document Management

Microsoft Office SharePoint Server 2007 Workflows and Enterprise Document Management 3

1 Executive Summary

The release of Microsoft’s Office SharePoint® Server 2007 (MOSS 2007) represents the emergence of a major new competitor in the Enterprise Document Management (EDM) space. While the previous SharePoint versions offered affordable, easy-to-use document management with effective collaboration tools which were well-integrated with Microsoft’s Office suite, it was not positioned as a player among the EDM leaders. Despite this lack of enterprise-capable features, it has achieved considerable success as a supplier of basic content services and has been found suitable for mass deployment in organizations large and small. The new version can no longer be considered simply as a basic content service, but implements many of the features of fully integrated EDM suites. As many industry observers, including Gartner, have predicted, this product presents a significant challenge to well-established EDM technology providers. EMC’s recent announcement that Documentum will be licensing the Vorsite technology for Microsoft SharePoint 2007 for distribution with the EMC product line is a potent indicator of this embrace. In addition to basic facilities for document management such as check-in/check-out, version control, security and library services, and collaboration tools, the new version adds Web content management, records management, email archiving, and a highly extensible workflow engine. Thus the new SharePoint now encompasses most of the features typically associated with full-fledged document management systems. The purpose of this paper is to explore one of those features, the new workflow engine, to explore how it compares with the features of more mature EDM products, in particular EMC Documentum. In what follows, we will explore how the concept of document lifecycles might be implemented with MOSS-based workflows, as well as investigating the basic functionality that informs such workflows. Document lifecycle management is critical to a fully-developed document management system. However, lifecycles need to be clearly distinguished from workflows, which are actually the building blocks from which lifecycles are constructed. Documentum has defined lifecycle and workflow as two different concepts: lifecycles -- which defines and manages the stages a document goes through over the course of its existence and workflow -- which are the sequenced tasks that are performed by users and/or automated processes in order to promote the document from one lifecycle stage to another. As we will see later, MOSS can construct such lifecycles from a special type of workflow known as a “state machine.” We will begin by defining the fundamental document workflow concepts and studying the workflow capabilities of MOSS 2007, and then compare that functionality with the major elements of the EMC Documentum workflow services. Our conclusion will be that while EMC Documentum provides the more mature and sophisticated workflow services that large enterprises often require, MOSS 2007 provides the basic workflow elements suitable to the needs of organizations in the beginning stages of implementing EDM solutions. Finally, we will recommend architectures that combine the strong points of each platform in optimal configurations.



2 Purpose of this Document

This document describes the workflow features of Microsoft Office SharePoint Server 2007 and compares them with EMC Documentum workflow features and to a lesser extent, K2.net workflow software. Though gap still exist, MOSS provide workflow features that are comparable to the those available from high-end EDM packages. DOCUMENT NAME & LOCATION: Microsoft Office SharePoint Services 2007 Workflows and

Enterprise Document Management

DOCUMENT VERSION: 1.2

DATE: April 27, 2007 READERSHIP: Mark Davidson

Louis Pasquale Christy Dupree Chester Greenman Richard Graff Mark Davidson

CONTRIBUTORS: Christy Dupree Chester Greenman Richard Graff Mark Davidson

SUMMARY: Whitepaper comparing MOSS 2007 workflow with Documentum workflow

2.1 Document Revision History

Ver. Date Comment Author Approved 1.1 27-Apr-07 Release for review B. Collins 1.2 03-May-07 Final Review B. Collins 1.3 26-09-07 Final Approval B. Collins

2.2 Abbreviations and Acronyms

Abbreviation Definition MOSS Microsoft SharePoint Server 2007 EDM Enterprise Document Management ECM Enterprise Content Management BPM EMC Documentum Business Process Manager EAS EMC Documentum Email Archive Services



3 SharePoint Document Lifecycle Management

A document lifecycle encompasses the different stages a document goes through as it is created, edited, approved, and, eventually, retired. For example, an engineer might create a new process diagram, a senior engineer might review it and return it for revision, and a manager might give the approval necessary to make the file available to all engineers contributing to a project. The lifecycle defines which stage the document is in at each point in the process. In SharePoint, there is no formal concept of a “document lifecycle” such as exists in EDM products such as Documentum. However, the functionality normally associated with the concept can be implemented using built-in SharePoint features such as event handlers and workflows. SharePoint can implement each of these stages through workflows which can be combined and nested to accomplish all the tasks related to a particular phase of a lifecycle. These workflows are a combination of user-initiated and automated tasks, both of which can be managed within the MOSS workflow framework. While EMC Documentum provides tools specifically designed to define document lifecycles, SharePoint provides workflow tools only. For example, a Documentum lifecycle can be assigned to a document and that lifecycle can operate on the document based on criteria such as the document type or attribute values. To emulate this functionality, SharePoint could implement a series of workflows. But additional features are necessary to fully implement lifecycles. Along with the new workflow features, the new SharePoint version adds the concept of content types to its feature set. A content type is a collection of attributes that you can apply to a certain type of document, similar to document types in Documentum. Workflows can be associated with content types in such a way that they can be automatically triggered by events in the document’s lifecycle such as its upload to a document library. Such workflows could be made dynamically customizable by examining the attribute values of a content type and making execution decisions about the workflow based on those values. In this way, SharePoint can implement much of the functionality contained in Documentum-style lifecycle processes.

3.1 Maintaining Currency

One key factor in defining lifecycles is to assure users that the version they are accessing is the “current” version of a document. Though not directly related to MOSS workflows, this feature impacts document lifecycles, one of whose goals is effective version control. The system must properly identify the approved version of a document that may be used in a production environment, but allow an update and review process using draft versions without interfering with that use. SharePoint implements this by defining “draft” and “published” versions of documents in libraries that have versioning enabled. Drafts can be minor document versions (typically documents currently being edited) or files that are not yet approved. When a user checks in a document, the version type selected (major or minor) determines the status of the document. Document versions are numbered using a decimal notation scheme (for example, 1.0, 1.1, 1.2, 2.0, 2.1, and so on). If the user chooses a version number ending with .0, it is considered a major version and all users that have Read permissions can view it. If the user chooses a minor version such as 1.2, then the version is considered a draft and the site administrator can control which categories of users can view the document — those with Read permissions, those with Edit permissions, or only those with Approve permissions and the author of the document. As with Documentum, users can choose to overwrite the same version even if changes have been made to the document, but this ability is only available to users with permission to delete versions. SharePoint defines the current version of the document as the one most recently checked in. The document that will be visible to users, however, is the one that their permission level allows. In most cases library administrators will configure permissions so that users with Read permission only will be restricted to the most recent major version. As with Documentum, SharePoint users with the appropriate permissions can check in a previous version of the



document and declare it to be the new current version. SharePoint does not implement the concept of branched versions as does Documentum, but does ensure that the major published version is the most current one.

Another aspect of versioning that helps control document lifecycles is the preservation of change history. The versioning feature of SharePoint Server 2007 can be used to preserve the change history of a document as it moves through its life cycle of edits and revisions. To view previous versions of a document, select Version History from the document drop-down menu. From the Version History page, you can view and delete minor document revisions while retaining approved versions. You can also use the Restore command to roll back to a previous version of the document by making a copy of it and setting it as the current version. This functionality is programmatically accessible through the object model exposed by the workflow foundation as well.

3.2 SharePoint Workflow Basics

A workflow can be seen as an executable representation of a work process. As an example, Documentum includes the ability to create object relationships between original and translated content. Documentum lifecycle management can automatically trigger a globalization process to update translated “child” documents when their original content “parent” has changed. SharePoint 2007 takes this concept farther by automating the complete process with the built-in Translation Management Workflow which manages the translation of a document into one or more languages. Rather than merely triggering alerts, it routes copies of a source document to designated translators for translation. The workflow takes charge of the entire process by assigning and tracking translation tasks for each language version of the parent document. Whenever there are changes to the parent document, the workflow assigns tasks to the appropriate translators to update the translated versions. Other examples include:

• Approval: A frequent need with respect to document-oriented business processes is to get approval from multiple participants. Documents needing approval could be marketing plans, financial reports, or proposals. In each case, participants must review the information, perhaps add comments or pass comments in defined pathways. Rules for approvals or rejection must be defined and enforced.

• Collaboration: Processes such as creating a proposal usually require people to work together in a coordinated way, while making intensive use of online resources. By establishing the rules of a process in an automated workflow, the group’s work can be made more efficient and the result of the process more predictable.

This translation workflow illustrates a more general MOSS 2007 feature known as content types. In leading EDM systems, child documents can automatically inherit the business rules of their “parent” document. SharePoint embeds this functionality in what are known as “content types” which are essentially a collection of attributes that can be applied to a certain type of document or list item. Besides associating the metadata with a certain type of document, content types also incorporate process functionality such as workflow and auditing. By associating workflows with content types, documents can automatically inherit the business rules of their own or their parent content type, thus allowing multiple categories of “child documents” to share the same basic workflow processes. These workflows implement business rules to carry out common tasks such as managing access, emailing approvers, or assigning tasks. Unlike some EDM systems, this functionality is available without the need for writing complex scripts. A codeless designer environment provides tools to build workflows using visual tools with SharePoint Designer (SPD). Documentum also provides the Workflow Manager that allows visual workflow design and adds several features not available with SPD, as we will describe below. Using workflows, each step of the typical document lifecycle can be addressed.



Illustration 1. Document Lifecycle Steps SharePoint workflows allow document-centric processes to see order-of-magnitude leaps in efficiency over manual processes, while adding key business benefits such as regulatory compliance, auditing, and built-in reporting tools. For instance, an oil and gas company can ensure that a request for proposal is efficiently handled from the creation of the request until the final acceptance of the proposal. MOSS workflows can make certain that every person involved in handling the RFP uses the correct and most current document versions. Each step can be sequenced to take maximum advantage of available resources, ensuring that each role successfully completes his or her part before allowing the process to advance to the next step. SharePoint includes a set of built-in sequential workflows, which constitute a procession of steps that execute in order until the last activity completes. These workflows can receive external events and include parallel logic flows so that the order of activity execution can vary as needed. MOSS also includes state machine workflows which can represent a set of document states, lifecycle transitions, and responsive actions. Later, we will describe in detail the advantages and disadvantages of these workflow types for document management, as well as how they are supported by each product. The process begins with the start state, and then, based on an event, a transition can be made to another state. Different events can trigger the transition to different states. The transition to a final state determines the end of the workflow. Each state can incorporate changes in item accessibility, library or folder location, and information policy such as expiration or auditing. Unlike most EDM products, MOSS 2007 is directly integrated out-of-the-box with the Office products which most employees use to carry out their jobs. Users can start workflows from a Word document or Excel spreadsheet and interact with workflow tasks using the task pane. They can even use Outlook to carry out their tasks completely through email. In addition to the usability factors of Office tools, no complex Office integration processes need be developed to allow users to interact with the document management system. For instance, a user can start a workflow by creating or updating a Word document (both Word 2007 and previous versions), and configure the workflow, specifying a list of approvers, setting how long each one has to perform his task, and track document changes made by fellow team members. In other words, users can input information into a running workflow directly from Word, Excel® or an Outlook® email. With Documentum, it is also possible to initiate workflows from within Word, Excel, and Outlook. This built-in and codeless Office integration with SharePoint workflows should lead to rapid adoption rates in many common enterprise scenarios. To create workflows, MOSS offers two development tools. Office SharePoint Designer 2007 allows information workers, as well as application developers, to create a workflow by using a visual diagramming tool which includes the ability to declare rules in multi-step workflows without coding. The workflow can then be associated with a list or library. The range of activities that can be used to compose these workflows is fairly broad and includes such jobs as creating a task



item, sending an email, or pausing the workflow until some condition is met. Designer allows you to assemble these pre-existing activities into workflows, but you cannot create your own activities without using another tool nor can you add code to activities. To address these gaps, Visual Studio® 2005 Designer for Windows Workflow Foundation is used by application developers to create more complex workflows that can be deployed across multiple sites and contain custom code. It also includes the ability to create custom activities that can be used with SharePoint Designer, extending the range of its built-in activities. InfoPath® or ASP.NET forms can be used by the workflow creator to allow interaction by participants to initialize workflow and to reconfigure it while it runs such as by adding new participants or re-routing tasks. Another key advantage of using Visual Studio Designer over SharePoint Designer is the ability to create workflows that can be applied across multiple sites, site collections, and Web applications, rather than having to configure each one individually. The following illustration shows the products that work together in MOSS workflows, including the tools used to create workflows along with the architectural elements on which this functionality is based:

Illustration 2. SharePoint Workflow and Development Tools Architecture



3.3 Workflow Functionality

High-end EDM products offer workflow design models with flexible task sequencing tools. As an example, MOSS 2007 allows activities to continue executing while a condition remains true – for instance by waiting for a user to signal that part of a process is complete. Such sequences can be made cyclical by means of tasks that can be repeatedly executed until some condition is met. As the sequence progresses, executed tasks can be dependent on the values of attributes, as well as user- or administrator-supplied variables. An issue tracking workflow can forward specific issues to particular experts depending on criteria entered into the issue’s content type metadata. In this way, a SharePoint issue can be forwarded to a specific SharePoint expert depending on the attributes initially assigned by help desk personnel. In addition to following different paths depending on such criteria, workflows can execute simultaneous processes in parallel to maximize the use of resources. Using our example, a SharePoint issue could be simultaneously assigned to several experts. Once an expert responds, the issue could then be assigned exclusively to that participant to resolve it and removed from the other experts’ queues. Lifecycle processing is implemented in MOSS 2007 by combining workflows which define the stages the document must follow. The lifecycle will normally have stages corresponding to uploading/creating the document, a review and approval process, release to production, modification and updating of published documents and final retention scheduled according to regulatory compliance policies. For example, financial plans may consist of several parts that need to be approved in a particular order. Though MOSS 2007 does not support the concept of virtual documents (allowing documents to be assembled from other documents), it does allow all of the documents that collectively form part of a single process to be promoted to the next stage according to a well-defined sequence. The review stage, for example, could contain a combination of workflows that combined would result in several documents being promoted to production. Changes in specific permissions for roles can easily be incorporated into the workflows associated with this stage by using the SharePoint object model. As an illustration of the enterprise capabilities of MOSS workflows, we will describe a state machine workflow that automatically switches states according to which tasks have been completed. The workflow has three participants: the creator of an engineering drawing who initiates the workflow, a senior engineer who reviews the drawing, and a manager who provides the final approval. The workflow contains three primary states of operation:

• Creation: the state where the original drawing creator has a task to incorporate feedback from the reviewers and approvers and revise the drawing,

• Review: the state where the senior engineer can review the drawing • Approval: the state in which the manager can approve or reject the final drawing.

The workflow initiates and immediately enters the Review state. If the senior engineer approves the drawing, the workflow forwards it to the manager and it enters the approval state. If the manager approves, the workflow completes by publishing the drawing to its correct library. However, if either the senior engineer or manager rejects it, the workflow reverts to the Creation state and the process resumes. At any point, the senior engineer or manager can post comments. When the original engineer completes his revisions, the workflow enters the Review state once again. The Visual Studio Designer allows us to compose this workflow visually, as is seen in the illustration below:



Illustration 3. State Machine Workflow MOSS provides an extensive set of built-in workflow reports, including workflow performance, errors, and customized reports that can focus on particular workflow events. The workflow history display allows each workflow to be monitored as it executes. Summary reports which include participant comments, and tasks complete and incomplete can constitute a thorough audit of the execution of a particular workflow. Creating tools to summarize data from a series of workflow instances is straightforward for any developer who is familiar with the SharePoint object model. Very often the way a process executes must be modified according to new circumstances that arise. A participant may be absent or temporarily unqualified to carry out a particular task so it is critical to provide the ability to escalate tasks. For example, it is often essential to assign a specific time limit to a task so that if the allowed period is exceeded, the item can be automatically escalated to a supervisor or another available user. These and other rules can be configured in many workflow tools to modify how the process executes. The ability to escalate tasks is included in Documentum’s workflow tool. However, while MOSS 2007 provides the foundation for such functionality, a developer or third party ISV (Independent Software Vendor) must actually implement it. Typically, a modification form would be added to the configuration pages for the workflow so that administrators could specify escalation parameters. Behind the scenes, the workflow would redirect tasks to the appropriate user or role. In contrast, Documentum Workflow Manager allows tasks to be configured for rules-based delegation, which permits tasks to be automatically reassigned to another user if the original participant is not available. This can also be done manually by a supervisor. However, neither Documentum nor MOSS 2007 allows escalations to be manually configured by business analysts as do business process management products such as K2.net. By taking advantage of the event handling model, MOSS workflows can be as simple or complex as business processes require. Workflows can follow sequences determined by user-driven events such as creating new documents or react to events such as the addition, change or removal of list items. The SharePoint event model has been enhanced to allow before and after



events so that the flow of actions can be customized through managed code. A timing service is also included to support a variety of timed processes.



4 Workflow and Regulatory Compliance

We have seen how workflow can ensure that documents can be managed through the stages of a well-defined lifecycle. But workflow is also the key to enforcing procedural rigor on business processes subject to regulatory compliance. In this section, we will explore MOSS capabilities with respect to a critical focus of EDM functionality - supporting regulatory compliance throughout a document’s life cycle. In this way, we can explicitly gauge the enterprise capabilities of MOSS in this area.

4.1 Ensuring Authenticity and Accuracy

The primary MOSS 2007 feature which ensures the authenticity and accuracy of the documented processes is its ability to automate manual workflows. Industry surveys have found that 67 percent of data loss in records management is directly related to user error (Craig Rhinehart, ILM Summit 2006). Automated workflow guarantees the security and accuracy of document processing and ensures the process visibility which is required to prove compliance. The more automatic and unobtrusive regulatory compliance is, the more likely it is to actually be carried out. Shortcuts that bypass requirements become irresistible when these requirements force managers to lose time following procedures that appear to be busy-work mandated by bureaucrats. The automation of workflow replaces manual steps with smooth and effort-free execution of compliance requirements. As previously described, users can start a workflow either manually or automatically using familiar Office tools. For instance, a user can use a Word template to start the process of composing a new contract which automatically triggers a new workflow to track the review and contract approval process. Rather than using email to send copies of the draft contract to participants, the workflow can notify each participant using whatever means is most appropriate and keep track of new versions so that there is no confusion about which is the draft and which the published version. The workflow manages the sequence so that each worker is notified as soon as the previous user has completed his or her assigned task. Escalation rules can help guarantee that each step is completed in a timely and verifiable manner. The out-of-the-box workflows for MOSS include basic delegation functionality. In the built-in Approval workflow, for instance, a user can decide to reassign a workflow task to another user who might be more qualified or available. In fact, it is straightforward for a developer to extend a workflow with the ability to delegate a task to another user either automatically according to business rules or by means of administrative utilities. To make keeping track of compliance tasks easier, SharePoint can list these tasks and automatically synchronize them with the user’s Outlook tasks so that the user gets to work with a single list of tasks. Users can also access the task list using the Office Tasks pane rather than having to navigate to the SharePoint site. In fact, if required, workflow tasks can be executed using Outlook 2007 emails, since InfoPath forms can be represented as the content of emails. One of the primary advantages of the SharePoint workflow tools is ease of use compared to many competing EDM offerings. Information workers can create automated business processes for approval and other common situations without requiring developer intervention through the use of pre-defined workflows that address many common needs. These pre-defined workflows include the following:

• Approval: Implements basic document approval workflow functionality. The workflow initiator chooses which users or roles will be included in the list of approvers, each of which is sequentially assigned a task. Approvers can approve or reject documents,



reassign the approval task to a more appropriate user, or directly request changes to documents from the owner. Each must respond in order for the workflow to complete.

• Collect Feedback: Essentially a variation on the Approval workflow, this one adds the capability of collecting feedback which is sent to the document owner when the workflow has completed. Rather than sequentially assigning participants, this workflow demonstrates parallel task assignment which can be more efficient and allows feedback to be returned in any order.

• Collect Signatures: Implements a business process that involves sending a document to a group of users to collect signatures. To meet compliance requirements, it provides a record of the signature process after it is complete. By default, the signing task will be sent to all the designated signers at once, illustrating the value of parallel workflow processing. One limitation to be aware of with the built-in implementation is that it can only be started and completed from within an Office client. More details about using digital signatures in SharePoint can be found below.

• Disposition Approval: Provides organizations with document retention capability by allowing them to manage and track the process by which expired content is evaluated and deleted. A unique feature of this workflow is that it does not assign tasks to individual users, but just records tasks that can be carried out by any of the approved users. This can be a real advantage to this type of process since it is likely that a high volume of Disposition Approval tasks could be generated. This allows a form of bulk task processing since approvers can complete these tasks by approving or rejecting several items at once.

Each of these built-in workflows can be extended using SharePoint Designer or Visual Studio to create additional rules for the process. Another key characteristic of compliance is visibility, which means that organizations must be able to show a record of the procedures carried out in order to prove that technology controls were in effect and that they were active during the compliance period. Though Documentum does include basic workflow reporting, the built-in MOSS 2007 workflows include a detailed “Workflow Status” page that keeps a complete record for the execution of a specific workflow, including which tasks were performed by whom and when, how long it took, what the final status was, along with direct access to the forms values provided during the workflow. In addition, administrators can quickly determine which workflows are currently running along with their status. They can also intervene in running workflows in order to add additional approvers, change due dates or cancel the workflow. If necessary, developers can use the SharePoint object model to quickly create reporting tools to extract required workflow values. In this way the MOSS 2007 workflow capability addresses some of the principle requirements of regulatory compliance through guaranteed execution, configurable recordkeeping, and encouraging adherence through automated processes integrated with familiar Office tools.

4.2 Digital Signatures

In an EDMS, digital signatures assure the identity of approvers and, most importantly, that the appropriate decision maker has authorized the document, which is a key requirement of many recent regulations. Another feature ensured by digital signatures is integrity, which provides assurance that the content has not been modified since it was digitally signed. Nonrepudiation is another important feature which means that authors cannot repudiate their authorization of the document in question. The technology used by Office digital signatures guarantees identity through the use of digital certificates, one of the most secure ways currently available to guarantee identity. Because digital signature functionality is built into Microsoft Office, there is no need to purchase add-in products, though it is important to realize that this is a client-side technology. Documentum provides a more rigorous signature implementation controlled from the server and includes



guaranteed auditing that cannot be switched off as well as authentication of the signer. However, this option requires a Trusted Content Services® license. It should also be noted that Documentum and other EDMS can use the digital signature formats provided by Office products. By using digital certificates, the signature can be verified in the future as long as the certificate remains has not been revoked. Using Office digital signatures, once signed it becomes read-only to prevent modifications. By incorporating digital signatures, workflows can be built that ensure that approvals are fully verifiable when required for compliance.

4.3 Records Retention and Workflow

One of the primary motivators for implementing standards-based EDMS are the proliferating regulations governing which electronic records must be retained, how long they should be retained, and how accessible they should be made to regulators or courts. In a number of well-known cases, organizations have been required to produce copies of electronic documents and emails deemed to be relevant to a lawsuit or prosecution. Not being able to produce such documents has significantly damaged the company’s ability to defend its legal position in a several cases. The more automated the control over their documents and e-mail messages becomes, the more assured the organization’s position is likely to be in future litigation. To meet compliance regulations, policies must be created to securely archive records for definable periods of time in a safe and unalterable state, and these terms are often subject to precise definition. These policies can be enforced through document lifecycles that are implemented through a series of workflows. Unlike some EDMS, MOSS 2007 requires no additional products to be installed in order to support retention policies. However, though the built-in site templates and workflows may be adequate for some situations, in larger companies considerable modification and customization will often be necessary. Integration with third party products such as Meridio® will be necessary for certain scenarios. Documentum provides complete records management services through the Records Manager module. The Records Manager documentation from Documentum describes its feature set as follows: “Records Manager is ideally suited to manage all aspects of records management requirements which include file plans, security, immutability, access controls and finally the retention requirements. Using RM, you can qualify a record for promotion within RPS lifecycles as it moves from one phase to the next. You can also prevent a record from reaching disposition if necessary.” Many of these features are available in MOSS in one form or another, but Records Manager has a far more robust and mature set of records management capabilities. Though this would be an interesting topic for further exploration, it is out of scope for the current whitepaper. The centerpiece of the MOSS 2007 records retention capabilities is the Records Center site template, which allows information management policies such as expiration and auditing to be defined. Once created, this site serves as the storage area for documents that are subject to the company’s records retention policies, whether active or archived. Active documents are those that are still in use and may be updated with later versions. The retention policy must spell out how this versioning will be handled – for instance which versions will be retained for how long and which deleted. Archived documents are those that not expected to be further revised and are thus in their final format which can be treated as the “official” version. Since this versioning functionality may raise alarms among experienced records managers, we should examine how the Records Center maintains document integrity. In the first place, records must not be automatically modified by the system. Though we can implement workflows or other automated procedures, safeguards have been built in to assure compliance officers that the document that was originally uploaded will always be a byte-for-byte equivalent to the one retrieved. Records Center document libraries can also be configured to audit specific types of



changes, such as any editing or restoration activities. Finally a clear separation is maintained between metadata used for retention purposes, such as a generated record number, and the record’s original metadata which is always preserved intact. Once again, nothing that could affect the integrity of the underlying record can be modified. One of the major purposes of workflow in retention policy is to ensure that the documents are routed to the correct library. The Record Routing Document Library accomplishes this by routing each incoming document according to a set of business rules. These rules are known as “record series” and they match the content type of an incoming document to a single document library to which it is directed. The routing rules are controlled by the content type of the document and since content types can inherit from base types, entire classes of documents can be routed by configuring their base type in the record series. The illustration below displays the main elements of the retention process:



Illustration 4. Records routing elements Before treating the workflows used in the Records Repository, it is critical to understand that the record content type controls most of the routing functionality. As described above, a content type is essentially a set of attributes that can be applied to a type of document or list item. It serves the purpose of classifying the item by describing its key metadata, and controls many other document management features in MOSS 2007. The Records Center uses a document’s content



type to copy the document to the correct document library. Effective enforcement of retention policies requires a well-thought-out set of content types which are the elements which guide workflow, organization, and information management. With respect to records retention, content types act as the controlling factor for workflow, routing actions, expiration, and other information management policies. Well-designed workflows make it easy for information workers to classify information accurately without the intrusion of complex decision factors as information is produced. In order to automate the records routing process, the ideal method would be to use a workflow that would copy the file to the Records Repository. Unfortunately, SharePoint does not provide an out-of-the-box record submission workflow. However, it would be straightforward to create such a workflow using Visual Studio 2005. It could route the document to the Records Repository based on a series of review and approval operations or configure it to deposit the record in the repository when it expires. The workflow can also use the Records Repository Web service to submit the document to the library as a record along with the original metadata and audit history associated with the file. As a Web service, this functionality can be called from custom applications or other EDMS in order to automate the batch transfer of documents into the repository. To handle the common scenario of handling an expiring document, you can use the Disposition Approval Workflow. This ensures that files are not deleted without the review of a records manager. You can configure the expiration policy to start a workflow when the expiration time arrives. Instead of deleting the file immediately, the Disposition Approval workflow places the document in an In Progress status when it expires. The document remains in that status until a records manager reviews it and decides whether to retain it or allow it to be deleted by the workflow. Some regulations specify that that the content must be immediately and irretrievably purged from the online system, but the default behavior of the delete operation is to move the item to the Recycle bin. The repository can be configured to permanently destroy the information by selecting the Delete Record And Submission Information option.

4.4 Email Management

Automated email routing is also included with MOSS 2007. Users can drag e-mail into a managed email folder in Outlook in order to submit it to a Records Routing document library as long as they are using Outlook 2007 and Exchange 2007. Exchange 2007 introduces a new feature called Managed Email Folders that can support policies such as content expiration or automatically forwarding a copy of an email message to a document library through Simple Mail Transfer Protocol (SMTP). Messages can also be routed to the Records Center based on fields such as subject line or any other commonly used field, including text from the body. The workflow infrastructure allows considerably more flexibility than those EDMS that simply route email into an archive according to domain or email address. MOSS has automatic journaling that can be configured based on email fields, but it only works for Outlook out-of-the-box. As might be expected with new functionality from Microsoft, certain aspects of the e-mail retention functionality are immature compared with systems from more experienced EDM providers. When journaling email messages, users will often want to have access to them after they’ve been submitted to the records repository. Unfortunately, there is no current facility for setting user-level permissions on messages that have been submitted to the Records Repository. Naturally, groups of users can be assigned Read permissions on the Repository, but there will often be a need for more granularity. For instance, you may wish that only users in the From: or To: field have permissions to read the email. No policy configuration is available in MOSS 2007 to enforce such policies. If such requirements exist, custom event handlers can be written to automatically assign permissions based on the values in frequently used text fields in the messages. Users may be reluctant to use email journaling if they find out that they have no access to the email once it has been submitted to the Records Repository.



Due to the limitations in the number of documents that can be held in a document library, folders must often be created to extend their capacity. SharePoint document libraries have a practical limit of 2000 files per folder and 2000 folders per document library. However, folders cannot be used as destination locations in the record routing entries. Instead, folders are automatically created as the document library limits are reached. These folders are named according to a date-time naming convention that users will probably find difficult to navigate. However, many experts believe that this is not a significant issue considering the volume of email most systems will handle. In addition, if Exchange Server 2007 managed folders are available, Outlook users can have an entire corporate classification system exposed within their Outlook environment. Users can organize managed folders according to their needs, then drag and drop emails into the folders to archive their contents. Nevertheless, in the repository itself, users are forced to depend on search to find emails they need for research or to comply with legal requirements. This suboptimal foldering mechanism could be addressed with custom event handlers, but a solution that allowed definable folder submission would be far superior. The Documentum Email Archive Services (EAS) also depends on search to identify emails for compliance, but also offers a limited degree of Outlook integration. The Office integration is much more convenient to users with the Microsoft product. When submitting email to the Records Repository, it is highly likely that different users will submit the same messages for journaling. For example, Documentum Email Archive System allows duplicate email messages and attachments to be detected. Currently, MOSS 2007 offers no built-in capabilities to detect and remove duplicate email submissions. To deliver this functionality, custom event handlers used in conjunction with the Records Router to detect and discard duplicates. In order to comply with integrity and availability requirements, the system must guarantee the delivery of email messages to the repository. However, SharePoint offers no method of monitoring delivery so that lost messages could be detected and resent. Compliance requires the auditing of delivery so that the custody of the item can be assured. Otherwise one of the fundamental tenets of records management is violated. Without this capability, an email could be accidentally deleted before it was submitted to the repository. Workarounds exist, but records managers need to carefully evaluate whether this lack of functionality justifies the amount of custom coding that would be required. Each of these issues needs to be carefully considered when evaluating whether the records retention capability of MOSS 2007 can fully address compliance policies.



5 MOSS 2007 Business Process Management

MOSS 2007 offers an elegant integration model that allows straightforward and rapid production of adapters to retrieve information from LOB applications such as SAP, Siebel, or PeopleSoft, as well as any information retrievable from a Web service or DBMS. This functionality is contained in the Business Data Catalog service. Using the workflow designers for SharePoint Designer and Visual Studio 2005 Extensions for Windows Workflow Foundation, developers can integrate SharePoint applications with external applications. In addition to allowing access to data from line of business applications, the Business Data Catalog allows the quick generation of adapters for indexing the content of these applications. This allows the seamless integration of MOSS unstructured content (documents and list items) with structured data from external systems. These applications can also make use of application integration frameworks such as BizTalk® and Message Queuing to gain enterprise-level integrated functionality. Through the use of these frameworks, business processes can be made transactional. The full array of tools can combine structured sets of transactional tasks (for example, the steps involved in processing invoice payments) with unstructured and collaborative processes (for example, negotiating a contract deal), and thereby bring together people and information to accomplish their objectives.

5.1 Designing Business Processes

While MOSS 2007 contains the tools to build virtually any of the business processes that one finds in EDM systems such as Documentum, the tool with the most flexibility, Visual Studio 2005, can only be used by experienced developers, not business analysts or other information workers. However, the SharePoint Designer (SPD), while limited compared to Visual Studio, offers similar functionality to and in some cases improves on, the Business Process Manager in Documentum. The Business Process Manager also offers significant advantages over SPD workflows in that it allows reusable state machine workflows to be composed visually. However, Visual Studio also offers the ability to design reusable state machine workflows to be created visually, though the interface was not designed for business analysts, but application developers. For instance, the Documentum Business Process Analyst allows complex decision paths such as the following to be designed:



Illustration 5. Multiple Decision Paths (from Methodology for Business Process Collaboration) Here, multiple sets of outcomes can be associated with different decision values. Each decision consists of rules. One rule might trigger the assignment of a metadata value to a document and an email to the legal department. Another rule might trigger four activities, including the first two plus routing the document to a SME for approval and the assignment of a pending value to a custom variable. In contrast, SPD workflows can define If…ElseIf logic as illustrated in the following screen shot from an SPD workflow:

Illustration 6. Multiple Decision Paths Defined in SharePoint Designer While it would be possible to imitate the multiple decision path logic found in the BPA sample using SPD, the tool is not designed for that functionality and it would be much more straightforward to implement this type of logic in Visual Studio. On the other hand, business analysts may find the verbal logic in SPD more intuitive than the visual representation of the logic in the BPA and BPM (Business Process Management, a graphical modeling environment that provides business users with an interface for designing business processes without coding.) As you can see from Illustration 6, users design SPD workflows by choosing Conditions and Actions which are easy to read and understand. BPA joins allow several activities to converge into one or more downstream activities. In BPA there are two types of join: those in which only one activity results from multiple inputs or those in which multiple activities result. This logic can be implemented in SPD in a straightforward way by using multiple AND clauses in the If conditions and assigning one or more activities to the



outcome. However, the XOR logic which can be programmed in BPA would be more problematic. The business process tools in Documentum have a notion of roles for activity performers. In SPD, roles within a workflow are a function of what groups are available in the underlying list. One of the most important limitations of SPD workflows in comparison with those possible with BPA is that SPD workflows are list-specific, whereas BPA workflows can be assigned at many different levels. Another limitation of SPD as compared with BPA is that SPD does not support state machine workflows, but only sequential ones. With Documentum, the concept of a state machine workflow is fundamental to document lifecycles. Though described above, we’ll once more illustrate the concept to emphasize its importance. Imagine the process of processing a bug report in a software company. The bug report will be initially created and logged by a member of the support team. The workflow will then assign the report to a “Waiting” state. At that point, it will probably be placed into a document library and assigned to a role such as Support Team Member. When one of the members of this role accepts the task, then it enters the “Assigned” state. As soon as the team member has addressed the issue, the report moves into the “Test” state, where it is assigned to another team member who carries out testing activities. If the result confirms the fix, then the task moves to the “Complete” status, at which point it is most likely published to a document library for fixed bug reports. If the fix is not complete, then the workflow will re-enter the “Waiting” state and the process begins again automatically. Thus the distinguishing feature of a state machine workflow is that it consists of a number of states and a set of defined conditions which cause transitions between states. These states represent points of stability during the execution of the workflow. When new conditions arise, they are evaluated by the workflow engine and their values checked to facilitate transitions to new states. This usually conforms more closely to the needs of document lifecycles, but is not supported by SPD. In contrast, sequential workflows consist of a series of steps executed in order until the final step is completed. These are the only type supported by SPD. Visual Studio 2005, however, fully supports state machine workflows and permits the same level of lifecycle functionality as BPA and BPM. Unfortunately, there is no Document Lifecycle editor in MOSS 2007 to supply a visual design environment for defining states and transitions specifically for such lifecycles. In addition, the ability to create exceptional and normal activities is not built-in to MOSS workflow. All activities have the same status, though certainly rules could be created to modify the workflow as soon as exceptional circumstances took place. However, this is not modeled in a lifecycle design tool with predefined states and modes such as suspension and resumption. In enterprise applications, maximum use of available resources can be supplied through configurable queues which can assign tasks to specific workers according to current load. When large numbers of users are carrying out similar document tasks, queues allow workloads be balanced among end users so as to manage large volumes of tasks automatically. This can also help ensure compliance with service level agreements. EMC Documentum BPM also includes the ability to increase the priority of items as they age in the queue, thus ensuring the timely processing of items that would otherwise lack resources. MOSS 2007 does not include such functionality out-of-the-box, but the tools to create work queues are readily available without the need for investment in third party components. Unfortunately, no pre-existing components are available in SharePoint to expedite such queue management.



6 Comparison Matrix of Workflow Capabilities of MOSS 2007 and EMC Documentum

Before examining the following comparison matrix, some key qualifications are necessary. First, it is difficult to make a one-to-one feature comparison because the products differ in fundamental ways. A prime example is comparing the features of Business Process Manager with MOSS workflow features. BPM is an add-on module that must be purchased separately. It is a highly specialized product that requires EDM experience to implement and administer. MOSS workflow, by contrast, consists of a set of tools such as SPD and Visual Studio that can be used to design workflows, along with a few prebuilt workflows. So when examining this matrix, be aware that what is being compared in some cases are the features of a mature, specialized product add-on with the out-of-the-box features of a portal product. Microsoft Office SharePoint Server 2007 EMC Documentum 5.3 Workflow fully integrated into portal solution Full workflow capability available with Business

Process Analyst and Business Process Manager which are a separate add-on modules

Document lifecycles must be implemented with custom workflows

Lifecycle management built-in to the product

Email journaling and archiving policies available through Exchange Server 2007. Available with earlier versions of Exchange with custom programming.

Email archiving and journaling available across many email servers through the purchase of a separate Email Archive Services module

Email journaling with Exchange Server 2007 allows users to drag and drop emails to managed folders from Outlook

Email journaling with EAS does not allow users to define managed folders, but uses built-in folders

Workflows can be associated with content types, libraries and lists

Workflows can be associated with document types and assigned at many different levels

Documents can have major and minor versions and revert to previous versions

Documents can have major and minor versions and revert to previous versions. Version branching is provided.

Translation workflows can raise alerts and route documents to translators

Update process alerts translators whenever a parent document is changed

Workflows created by Visual Studio can be configured to allow tasks to be delegated

Workflows created by Workflow Manager can be configured to allow tasks to be delegated

Detailed reporting for each workflow Generic reporting for workflows Codeless workflow design using SPD only allows sequential workflows

Workflow Manager allows state machine workflows

Codeless SPD workflows can only be used with a single list or library

Workflow Manager provides reusable workflows

Basic records retention functionality is included out-of-the-box but with no pre-built records submission workflow

Full records retention functionality is available with the purchase of the Records Manager module

Codeless SPD workflows do not allow multiple parallel decision paths (Visual Studio does allow this)

Business Process Manager allows multiple parallel decision paths

Visual Studio allows reusable state machine workflows to be designed by application developers

Business Process Manager allows reusable state machine workflows to be designed by business analysts

Client-side digital signatures supplied by Office products

Server-controlled digital signature implementation. This option requires a Trusted



Content Services license Office integration is built into the product without the need for client configuration

Each client must be individually configured to allow Office integration

Workflows can be triggered directly from Office applications without client configuration

Workflows cannot be triggered directly from Office applications without client configuration

Exceptional conditions must be programmed using Visual Studio

Exceptional conditions can be handled using the Business Process Manager visual design tool

Suspend and resume modalities must be programmed using Visual Studio

Process modalities such as suspend and resume are configurable out of the box

Queue workload balancing must be purchased from a third party or custom developed

Queue workload balancing are available with the Business Process Manager tool



7 Conclusion

The built-in functionality of MOSS 2007 includes many key features of mature EDM packages. However, a number of immaturities remain which could, in some cases, be serious enough to forestall implementation. These include the lack of built-in document lifecycle management, no version branching, and the absence of built-in workflow functionality such as exceptional conditions, escalation, and task queuing. MOSS also lacks server-side digital signature services. In addition, state machine workflows cannot be implemented with the SharePoint Designer (SPD) visual design tool but only with Visual Studio and the same applies to the ability to initiate multiple simultaneous workflow processes. The workflow developer will often face a difficult choice when creating MOSS-based workflows. If the SPD tool is used, workflows can be rapidly designed and advanced business analysts can be trained to use it, but the resulting workflows will be sequential and associated with only one library or list. In a corporate portal where common workflows may be needed by hundreds of libraries, it may well be worth the expense of automating workflow deployment across libraries, but this would involve custom programming or third party tools. Another severe limitation is that SPD workflows cannot be associated with content types. Content types will likely soon become one of the major objects managed by SharePoint, rapidly replacing its current library-centric orientation. Therefore the developer will often choose Visual Studio as the best environment to develop workflows, but this choice introduces a more complex visual design environment that will require training for most application developers and will certainly be out of reach to business analysts. Once this environment is mastered, workflows can be created that implement all of the advanced functionality of mature EDMS, but at the cost of considerable development time or third party purchases.

Records retention is one area in particular where reliable and secure workflows are needed to manage the content migration process. In many cases, the resulting workflows will implement a set of pre-configured business rules that move, copy, or link content from MOSS to an ECM repository when the document meets a given set of criteria. Among many others, these criteria could include document age, metadata values such as attributes marking it as a legal document, or record status. These workflows would enable MOSS to automatically ingest business critical documents into the repository. The absence of such functionality in a records repository marks this version of SharePoint as significantly underdeveloped with respect to records management. These automatic records retention workflows could be supplemented with manual workflows to address the exceptional situations that inevitably will arise.

Though major EDM vendors may highlight SharePoint’s deficiencies, some of the gaps turn out to be minor. Lacking explicit document lifecycle management may not be a critical issue since workflows can easily implement the functionality. An effective argument can be made that workflows and lifecycles are so tightly interwoven in any case that packaging them as two separate features is not necessary. Given the array of tools for creating workflows in MOSS, this issue can be quickly addressed for most common document lifecycle workflows. The MOSS email journaling and retention facilities, though exhibiting the gaps noted above, seems to be moving rapidly toward a feature set competitive with that of the major EDM vendors. However, the lack of automated retention workflow processes is a critical gap in email functionality. In addition, full capabilities such as submitting email messages directly from Outlook or using managed folders which implement records management policies requires Office 2007 or custom programming. Once these conditions are met, MOSS offers email archiving abilities that should address most companies’ major concerns.

In the final analysis, not only is much of the functionality offered by mature EDM packages available in MOSS 2007, but the Office integration features provide a unique value proposition for the majority of corporate clients. This integration has now been extended to the level of synchronizing document metadata between Office tools and SharePoint. Moreover, unlike the



major EDM products, the SharePoint to desktop integration requires little or no client configuration since both products are part of the same Office family. The ability to collaborate, manage documents centrally, and administrate sites securely using familiar Office tools effectively overcomes one of the main barriers to widespread adoption of EDM.

According to a recent article in AIIM E-Doc, “Gartner predicts that BCS (basic content services) will become a ‘birthright’ collaborative tool within the majority of enterprise organizations over the next three years.”1. What’s the Deal with Basic Content Services? AIIM E-Doc). With the significant functional and architectural enhancements found in MOSS, many hard and fast distinctions between the portal product and the underlying ECM that were true of the prior version have become blurred. One of the SharePoint architect’s most pressing concerns in implementing EDM will be to determine how MOSS will interact with existing EDM platforms. The overlaps in functionality will likely push mature EDM products toward greater specialization as SharePoint takes on more and more of the common document management tasks, while providing an integrated interface. Given the history of Microsoft APIs, it is also highly probable that the development tools included with MOSS will lead to a wide array of reasonably priced workflows that will rapidly supplement the current offerings.

Given these realities, our recommendations revolve around the two dominant configurations for using MOSS as a document management system. The first involves MOSS as the user experience acting as the primary client into an EDM repository offered by one of major EDM vendors such as EMC Documentum. In this case, the EDM repository would manage document lifecycles for those documents determined to be business records, while MOSS would be leveraged for its strength in supporting collaboration as a work-in-progress (WIP) repository. Industry experience demonstrates that most documents (perhaps 80 percent or more) do not require full records retention facilities. For these, MOSS can provide information sharing facilities, including security, information architecture, content types, and basic approval workflow necessary to manage these non-business record document tasks across the entire enterprise. For those 20 percent of documents that can be deemed true business records, we recommend the robust workflow facilities of EMC Documentum or a comparable product. This could provide the advanced capabilities for processes such as change management for engineering drawings, as well as acting as the “single source of truth” for business records and discovery purposes. Third party Web parts, as well as custom Web parts and administrative applications can provide a fully functional view from MOSS into the primary repository for more advanced capabilities. This additional cost would be part of the price paid to leverage the advantages of both platforms in an integrated fashion.

For companies with lower level requirements, MOSS can act as the primary EDM repository. Businesses that already use SharePoint as the primary collaboration tool for their company and are starting to address basic document management and discovery issues can use the EDM features available now with MOSS 2007 and grow into more robust functionality as Microsoft continues to add functionality. Industry experience demonstrates that most mid-level corporations do not need the features of a full-fledged document management system, but are eager to take advantage of the ability to collaborate on and centrally manage business documents. It is likely that the Microsoft product will strongly encourage the move away from file shares and provide feature-rich support for common discovery needs such as email archiving and records retention. In those cases where companies have already implemented EDM solutions, most likely in the siloed fashion which is still the dominant configuration, the .NET APIs exposed through MOSS allow straightforward integration with most of the major players. This approach allows companies to take full advantage of new features such as business data integration using the Business Data Catalog, shared spreadsheets with Excel Services, and cross-linking that would likely have to be foregone in the scenario depicted previously. With MOSS, full workflow 1 Julien, Janelle, “What’s the Deal with Basic Content Services? AIIM E-Doc Magazine, March/April 2007.



capabilities are part of the built-in functionality, not an additional module that requires another license. Added to this, the ability to carry out most document creation, approval, and archiving tasks using familiar Office tools that are tightly integrated with the MOSS platform will make this a compelling solution for a majority of mid-level corporate clients.

SharePoint, Excel, Outlook Visual Studio, InfoPath and BizTalk are registered trademarks of Microsoft Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation in the United States and/or other countries. Meridio is a registered trademark of Meridio Ltd. in the United States and/or other countries. Trusted Services Content is a registered trademark of EMC Corporating in the United States and/or other countries.

Date post:	20-May-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times