TSG has successfully implemented multiple solutions for third party/remote approval for different Documentum customers. In each case, the solution focused on bringing outside approvers into the client’s Documentum environment. Based on discussions with several customers, TSG is beginning to develop a new solution to address several different business issues and take advantage of additional technical options. This post will discuss our initial approach to solicit feedback on the proposed solution.
Third Party Approval – Business Justification
With a focus on being “lean and mean”, most of our clients are building working relationships with outside third parties for assistance with approval activities. TSG has built solutions where third parties can initiate a review or approval process as well as participate in the approval process. Issues with a typical approach of letting third parties within Documentum include:
- Security – VPN access for a third party can be a security and maintenance nightmare. Someone has to grant and maintain the appropriate access for the network and Documentum over time.
- Timing – relationships can be built very quickly and can also end quickly. Getting access to the system and being removed from the system on a timely basis can be difficult given the different security and infrastructure components that might be affected.
- Cost – Granting new access can involve additional Documentum licenses even if the approver is only granted access for a short time. Sometimes VPN requirements might require a dedicated PC from the client for the vendor.
To address the above issues, the solution has to contain three basic components:
- Minimal Network Involvement – a solution that does not involve VPN access would be better than a solution that relies on the cost, timing and maintenance of a security group.
- Minimal Cost – the solution should try to avoid additional license charges and focus more on a transactional cost model.
- Documentum infrastructure – clients want to leverage their existing infrastructure within the firewall. While it might be on the horizon, the idea of placing Documentum in the cloud outside the firewall is something that most clients are not considering.
Remote and Mobile Approval – Business Opportunity
As clients have looked at third parties’ ability to approve documents, the logical step of asking “Can my internal people approve from outside the firewall as well?” In most cases, clients may have VPN access already installed on their laptops for home access. We increasingly see clients that want the ability to approve items from devices that are not equipped for VPN access, such as other PC’s or mobile devices (tablets and phones).
Business Approach – An Approval “Hyper-Cloud”
The solution we are developing focuses on using our existing customer deployed solutions in a unique configuration. The solution leverages traditional Documentum “behind the firewall” but adds an Alfresco repository outside the firewall in the cloud.
Components include:
- Active Wizard – Our dynamic form and workflow infrastructure will run inside the firewall as it does currently with access to Documentum to identify documents that need workflow approval as well as supporting documents. A Documentum user will specifying email addresses in the form for third parties or remote approvers rather than Documentum user-id’s. Active Wizard will build the approval packet (workflow form as well as workflow documents and supporting documents). Active Wizard may kick off a small workflow in Documentum to do typical pre and post processing (lifecycle, security) so that Documentum users will see that documents are attached to workflow approval processes. We have also discussed a mixed approach where we may be able to leverage some internal Documentum workflow as well as external workflow in the cloud.
- OpenMigrate – Our migration framework will push the approval packet out to the cloud for the approval process when required. We are proposing using Alfresco to route and approve the approval packet based on previous success with Activiti and Alfresco.
- Email will play a huge part in this solution. Third parties and remote approvers will receive email alerts that they have a packet to approve. Upon clicking on the included link, the users will be prompted for passwords or brought through a new user set-up if this is their first access to the system.
- High Performance Interface (HPI) – Users will be able to leverage our HPI product for approval from either a Mobile or PC device without VPN access to Documentum.
- OpenMigrate – Once the workflow is complete (either approved or rejected), OpenMigrate, which is monitoring the Alfresco instance from behind the firewall, will pull the updated workflow package back into Documentum and complete the workflow activities. A signature document will be related to the signed document similar to current client efforts. We are currently evaluating how to store this signature document (Encrypted Adobe PDF?).
- Admin – We are working with clients to identify how much of the workflow package remains in the cloud and for what duration. We are also working on how users will see where a workflow package is in the approval process.
Business Continuity
One component we discussed early on was whether to use OpenMigrate to push/pull the solution over the firewall or just integrate our ActiveWizard to be able to post the package directly to the cloud. We ended up deciding on OpenMigrate based on the benefits of having more of a push/pull infrastructure component to provide some of the benefits of business continuity. In this manner, if connectivity between the two systems is interrupted, the solution can “catch-up” when connectivity is restored. We have found this approach very successful with our search and retrieval cache approach and wanted to leverage the same approach here.
Summary – Give us your thoughts
Overall, we think the approach is fairly elegant in that it allows instant and cost-effective third party approval based on proven components without the pitfalls of the typical behind the firewall approach. We think it gives clients a little taste of the cloud and mobile access without the cost, risk and concern of having the complete Documentum infrastructure in the cloud. It allows mobile access for approvers without having to worry about VPN connectivity from a variety of consumer devices.
One question for readers: should we consider our Alfresco instance as a multi-tenancy offering or should we allow it as a type of “private cloud” where the client would own the infrastructure in the cloud? As this is the initial stages of our design efforts, please add your thoughts below.
TSG Dave says
Posting on behalf of a client:
While I don’t see us having this need at this time, it is very interesting.
As you can image, security will be the biggest concern. The company’s security team is going to have some input on how your secure the Alfresco in the cloud (Company currently does not use public clouds at all). Would this security be completely different but yet managed by the security team or would they elect to somehow use the current LDAP/AD/WSSO solutions already in use.
I wonder if the documents may not need to be secured themselves like with EMC’s IRM solution.
Of course, I could see really this model used for when external vendor/contractor/customer/etc. approval is needed. In this case, the security could be completely contained within the Alfresco/cloud
solution since those users are most likely not in the companies security system anyway.
TSG Dave says
Thanks for your feedback – some thoughts:
– in regards to security, thoughts are the Alfresco Cloud could be a private cloud for just a client or a public cloud with multi-tenancy (like SalesForce). We wanted to keep security different to accommodate third party users that would never need Company network ids. Thinking is that we would do normal user-id/password stuff with forgot password type logic. We are relying on the email being successfully delivered to the right person.
– for internal folks that want to access outside of the network – we could work on a separate solution, with LDAP and passing user-ids. Some concern that the “synching” required might open up a new security concern.
TSG Dave says
One last one after discussion with client surrounding leverage of Email addresses:
Client liked solution, brought up the idea that “we wouldn’t just want any type of email to be entered”. Solution was to have the Active Wizard form provide a list of approved vendors (company names) that would automatically generate the @companyname.com part of the email and users would only have to put in the user-name. Obviously could extend that to having a list of approved users at that company as well. Would want to avoid the maintenance of company approved names if it got to the point of being as hard to add as VPN access.
Client also brought up the idea of “what happens if an email bounces” – we would process that the same as if the workflow was rejected. Working on adding that piece to the scope.
Peter T says
A few other thoughts, in no particular order:
* Could this be used for informal review as well as approval, either supporting PDF annotations or redlining?
* Would this mean that TSG would get into the hosting business, or would this be hosted by amazon or some other established service? I’m wondering with whom our company would need to have an agreement for hosting services, which would almost undoubtedly be required.
* Consider how this might accommodate digital signatures as well, with either Adobe’s solution or SAFE.
* For us, most of the people that would need to approve documents would have internal Active Directory accounts but not all of them so it would be good to have that AD authentication option but not require it.
* How long would the cloud accounts, so to speak, be active? It may be useful to fix the duration of these types of accounts, as companies in regulated industries may not want to have yet another system to review security on once a year.
* Document identifiers – I imagine you would want to leave this as flexible as possible and not visibly assign any Alfresco-created IDs on the documents, but depending on how the signature page is manifested there may be some need to create an association. If you’re only dealing with PDFs and it can be fused to the end of the document, there should be no issue. Just something to consider depending on the format and complexity of the document being approved and how it is stored in the original system.
* Source system – in many cases the internal Documentum system is indeed the system that manages signatures and thus matches what you’ve described here. But I can see the need for the same type of globally accessible approval process for documents that are not in Documentum yet. So it would be helpful to have some sort of system-independent approach for getting the documents to this cloud solution in the first place.
TSG Dave says
Peter,
Some great points. Thanks for the feedback – some follow-up thoughts:
– We are designing the approach so the solution could be used for both review and approval. First phase will focus on approval but adding the review cycle with OpenAnnotate and other tools is in our plans.
– In regards to hosting, we have been considering two options. One would be a mult-tenancy solution that TSG would provide hosted in the Amazon cloud. A second approach would have the client procure their own cloud, whether with Amazon or elsewhere, for just their own use. The thought is both options provide different benefits. If we are going to sync user-id’s with AD, I would think we would have to leverage the client’s own cloud.
– Digital Signatures are on the plate. We have discussed trying to keep the signature “content management platform neutral” so Adobe is on the short-list of solutions.
– In regards to the cloud accounts being active, we are initially thinking that we would not expire them but rather limit what they can access. For example, since the application is only review or approval, once a document has been reviewed or approved, can the user still see it? One client gave us feedback that they think external approvers should be able to see documents they have approved. We might put a timeframe on how long they can see the documents from their inbox. We are not planning search and retrieval application specifically due to the security concerns.
– In regards to Document Identifiers and Source system, you are right that we want everything to remain content repository neutral. Any specific properties that might be required would be added in the client’s environment – for our examples that would be Documentum but we would like to provide this capability to a variety of repositories.
Thanks for the great points – if anyone has more to add – please comment below.