PROBLEM-SOLUTION MATRIX

How Elyse solves common document management system challenges

Subject Symptom Cause The Elyse Solution References
Version Control Users get confused between draft and approved versions. Drafts are not clearly separated and differentiated from approved issued documents. A user searching for a procedure might be presented with an edited draft-in-progress for the next version. File searches are automatically filtered according to status so that only files with status of Current and type of Published will be presented to users, unless they have elevated privilege and are performing a unfiltered search. Unprivileged users cannot see source files, drafts or superseded versions. [1]
Version Control Release identifiers from historical documents cannot be migrated. The old release identifier system that has been in use for a long time cannot be transferred to the new software. Version or revision numbering systems are rigidly dictated by the software. Version or revision numbers are free format. Elyse does not impose a numbering system. [2]
Version Control Documents must be relocated to a different view or folder when they published. Visibility or status of a document is determined by the folder or view where it is located. Visibility is automatically determined by metadata, not location. Changing the status of a document automatically changes the visibility. [2], [1]
Version Control Documents can be moved and hence a hyperlink to the document will become broken, causing frustration for users who have saved a one-click link to the master copy of a document. Files are stored in a path location and can be moved. A hyperlink to a document within Elyse will not break when metadata is changed. There is no 'path' where a document is 'stored'. A link to a given document ID will always point to that document ID. [3]
Duplication, Compliance Duplicate files proliferate. It is very easy for users to load duplicate files. The software is not capable of detecting and rejecting duplicate files. All files are fingerprinted. If duplicate management is enabled then uploading a duplicate file will be rejected. [35]
Duplication, Compliance A document edited outside of the system becomes detached from the master source of truth when it is uploaded, leading to workers working from outdated or fragmented information. The system lacks the structure defining the relationship between a document ID and the various releases and renditions of the associated files. Each document ID is unique and has a parent-child relationship with associated files. It is impossible to create an orphan copy of a document. [3], [16]
Duplication, Compliance Duplicate document IDs can be readily created, breaching compliance requirements. The system may permit creation of multiple separate ID registers where the same ID can be created in different registers. Preventing duplication of document IDs is not inherent to the data structure of the system and is either not possible or requires custom coding. An Elyse database maintains a single document ID register where duplicate prevention is natively enforced at a low level. [3]
Identification System Legacy document IDs cannot be migrated to the new system, breaking all of the cross references printed on existing documents. The entire document repository must be re-numbered. Document IDs are system-enforced. The Elyse document ID system is format agnostic. The system can be configured to use automatically generated or indexed IDs or any unique string of characters. Any legacy set of document IDs can be migrated. The only constraints are that every document ID must be unique and no longer than 50 characters. [11]
Identification System Document IDs are prohibited from including particular characters, e.g. '/', or '#' etc. This prevents the registering of document IDs matching those on externally-supplied documents such as vendor manuals or drawings. Document IDs must meet strict rules. The Elyse document ID system is format agnostic. Document IDs can be any unique string of characters. [3], [11]
Identification System The unique document ID is a human-unfriendly GUID which cannot be readily transcribed or verbally communicated. The human-friendly parallel ID is not enforced to be unique. The system does not maintain a single table of document IDs but instead relies on GUIDs for unique identification. An Elyse database maintains a single document ID register which contains the same human-friendly ID which will be printed on the document. The register natively enforces ID uniqueness. There is no parallel or proxy document ID system under the bonnet. [3]
Ease of Use Frontline staff and contractors tend to push back and create satellite repositories because the master system is too clunky, difficult to use or difficult to learn. Or every person requiring access must undertake a special training course just to learn how to find documents. The system was designed around the interests of document creators. The ease of use for document consumers is an afterthought, leading to poor usability, or the user interface layer was originally built a long time ago and has never been modernized. Elyse is designed to make basic searching by document consumers a zero-training experience. The search interface is very simple and easy to use, but includes all essential search features that a document consumer needs. The user interface is also an open ecosystem and can be re-designed by any developer. [5]
Ease of Use, Searching Cannot search by 'Document ID Equals'. A search by document ID returns a long list of documents which contain the ID only as a cross reference. It can be difficult or even impossible to make non-text files such as scanned images and drawings locatable directly via only the document ID. Searching is primarily by internal content search. The system does not have a searchable single document ID register. Document identifier is a primary entity, not merely a bolted-on metadata attribute. Searching by exact match of document ID is a native feature. [3], [31]
Ease of Use, Searching A global search by document ID is not possible. Separate searches must be made across multiple registers. The user must first have knowledge of which register to search in. The system is architecturally fragmented into multiple separate registers. An Elyse database maintains a single global document ID register. Groups of documents are segmented by metadata, not separate registers. [3]
Features The system has an enormous range of features, and a high price to match, but is totally unsuited for meeting basic controlled document storage and publishing needs. The system was designed for a high overhead, high revenue business model -- not for meeting simple controlled document management storage and publishing needs. Elyse is designed for efficiently managing fundamental controlled document storage and publishing needs, while at the same time providing an open API to allow the adding of limitless application layer functionality. [5], [9]
Interoperability The document management system cannot be integrated into other enterprise systems. The software is a closed ecosystem or has an inadequate API. Elyse supports an open and transparent ecosystem, with a comprehensive API. [9]
Entity Focus Cannot reserve a document ID without uploading or creating a template file. The software is file entity-centric rather than document entity-centric. It lacks the structure that maps the real-world entity relationship between documents and files. Elyse is structured to specifically map the real-world entity relationships that are inherent with controlled documents. Document IDs can be created and reserved without any reference to a file or template. [3], [11]
Deployment and Implementation Getting the system up and running becomes a complex, costly and time-consuming nightmare. Deployment requires specialist vendor support and heavy customization to achieve essential requirements. Out-of-the-box functionality is extremely limited. The system was never designed with self-service deployment as a design criteria. Elyse is fully functional out of the box. Further customized configuration does not require any developer or vendor support. [12]
Audit-Readiness Determining precisely who downloaded a document and when is either missing or difficult to extract. The system does not include adequate audit logging of file access. Elyse natively supports an option to enable millisecond logging and precise user identification of every file opened. [14]
Audit-Readiness Editing of files is restricted to in-system editing, but tracking of exactly who modified the document and when is inadequate. The system is collaborative editing-focused and ephemeral document-focused rather than compliance-focused for high-stakes controlled documents. Once stored within Elyse, a file cannot be changed. This rigorously prevents undocumented changes from occurring. Elyse natively supports the storing of documents which have been collaboratively created, with fine-grained change tracking and digitally signed, all on a separate platform before being loaded into Elyse. [16]
Permission Controls Subfolder permissions 'inherit' rights that were not intended. Permissions are based on folder structures which allow for inadvertent creation of inherited permissions. Elyse permission structures are fine-grained, flat and exclusive, rather than hierarchical folder-based. A list of all of the permissions granted to a given user can be easily generated. [18]
Trust and Transparency, Pricing After a lengthy evaluation process the quoted price is far beyond initial expectations. Pricing is opaque or predatory. Elyse pricing is completely transparent and simple. [20]
Licensing Framework Licensing is on a named user, or per-user per-month basis. Hence the net present cost for providing entire workforce access is large and difficult to contain, particularly when a fluctuating contractor workforce is included. The business model is based on extracting the maximum revenue from customers and to grow the revenue as the customer's organization grows. The Elyse licensing framework is a per database instance basis, with no user or data restrictions. [22]
Upgrading and Maintaining The vendor is unresponsive to the need to fix critical issues with the user interface. The entire system is closed and proprietary. The user is entirely at the whim of the vendor when issues arise. The application layer for Elyse is Apache 2.0 licensed and hence can be modified by anyone. [25]
Upgrading and Maintaining The purchaser will be forced to pay whatever service and support fees are demanded by the vendor for future upgrades to fix bugs and issues. The vendor's business model is based on a continuous revenue stream from the purchaser. The Elyse EULA is a pay-once license where the original license fee grants rights to all future upgrades. [22], [20]
Upgrading and Maintaining The purchaser will be exposed if the vendor is unwilling or unable to fix security vulnerabilities or make changes to accommodate unavoidable underlying platform environment changes. The license forbids the purchaser from making any changes to the software whatsoever. The Elyse EULA includes a Right to Maintain clause which guarantees that the purchaser can maintain the product into the long-term future no matter what. [24]
Security The system is vulnerable to SQL injection attack. The application layer has direct access to database tables and uses dynamic SQL queries. Access to tables in an Elyse database is only possible via fully parameterized stored procedures, preventing SQL injection as an attack vector. [25]
Security A compromised application layer can gain access to the underlying data. The application layer is trusted with user authentication. Elyse operates on a zero trust relationship whereby the application layer is a dumb pipe which has no user authentication responsibility, has no direct access to data and has no rights in itself. It can only have rights which are delegated by the connected user. [25]
Logging In The system requires every user to have an application-specific login and to separately log in to the system. Pass-through login is not supported. Elyse leverages Windows Integrated Security to allow pass-through login. [25]
Metadata Fields Additional fields cannot be created without developer support, or fields are permanently rigidly fixed and cannot be edited. The system was not designed with user-customization of fields as an architectural feature. Elyse is designed from the ground up to permit end-user customization of fields. [2], [5]
Data Displaying Data is displayed as cards, or as a limited number of rows per page, severely restricting usability for large data sets. The system was built using archaic user interface technology. The Elyse application layer uses a spreadsheet-like data display table format which makes very efficient use of screen space and allows for large amounts of data to be effortlessly viewed and scrolled. [29]
Referential Integrity Files can be orphaned from the associated metadata. This has the potential to allow access to sensitive documents for example if a database transaction was not completed successfully. Backups of files and associated metadata can become unsynchronized. Files are not under the control of the database which stores the metadata but are stored separately. Elyse is fully ACID compliant for both the files and the file metadata. [16]
Tagging Documents require a comprehensive set of tags to be linked to the document. If a tag is missed then the document cannot be found using that tag. Document to tag linking is via a simple relational link. Elyse uses a hierarchical tag relationship system which drastically minimizes the number of tags which need to be linked to a document. For example, a relationship can be created to define that nuts and bolts are both fasteners. Hence a document tagged only with 'nuts' will be listed when a search is made using the tag 'fasteners'. [31]
Filenames Downloaded files are named with an obscure system-generated name. The name of the originally loaded file is discarded because the system must create its own filename to support the internal referencing system. When a file is stored in Elyse the file will be returned with exactly the same name as when it was uploaded. [16]
Purpose Fit The system is a 'square peg in a round hole' and requires very heavy customization to meet basic requirements. The system was originally designed for a purpose other than managing controlled documents, or was designed to attempt to do 'everything'. Elyse is purposed-designed from the ground up for storing controlled documents. [5], [3]
External Access Interfacing Providing public access to unrestricted documents requires creating a separate parallel repository. The system was not designed to allow for providing public access to unrestricted documents while keeping other documents secure. The Elyse architecture allows for unrestricted documents to be made publicly accessible from the same database while keeping restricted documents secure. [32], [12]
Demonstration Viewing a demonstration requires either formal registration or arranging a personal demonstration. The vendor wants to capture details of every prospective customer. Silkwood Software provides an online read-only interactive demonstration of Elyse that does not require registration. [33]
Security Air-gapped deployment is problematic or impossible. The licensing system is designed to 'call home' and hence cannot support air-gapped deployment, or a special license agreement must be negotiated. Elyse is designed for air-gapped deployment out of the box. [34]

What Elyse Is Not

Elyse is specifically designed for controlled document storage and publishing. Elyse is: