Applications in the electronic document management system. Part 1: key principles, components and capabilities
In this post I will begin a short series of articles on various aspects of application development in the electronic document management system. Today, more or less powerful and modern EDS / ECM platforms contain a set of components and tools for their implementation, and it is the applications created on the basis of the platform that automate the whole variety of client workflows. I will talk about the application model of the Docsvision platform, about the components and development tools (settings) of these applications, about what problems we encountered when implementing the tools for their development, and what we look forward to in the future. This will be interesting not only for those who work closely with Docsvision, but will also allow those who have to implement or develop their corporate EDMS to gain experience.
Application of modern EDMS. Let's define the terms.
The modern EDMS / ECM platform is a tool for automating a wide variety of document processing processes in companies of various sizes. In fact, the platform itself does not contain complete client functionality, but provides a set of services, components and tools for accelerated application creationbased on the platform. The situation is somewhat similar to the situation with ERP-platforms (Enterprise Resource Planning), where each implementation requires significant customization, taking into account the particular processes of a particular company. However, the level of variability of specific automated processes in EDMS is even higher than in ERP: practice shows that the range of tasks for which EDMS / ECM platforms are used is practically unlimited today.
Let's define the terms.
By application of EDMS we will call automation tools for a specific isolated workflow for solving a specific set of tasks.
Despite the fact that standards and sets of typical requirements for EDMS / ECM platforms are not yet available, more or less powerful platforms contain a set of components and tools for implementing applications. And the structure of applications running on different platforms can vary significantly. In this series of articles, we will consider the structure of applications created on the basis of the Docsvision platform. As I noted above, this information can be useful to business analysts of companies involved in the development of similar applications.
EDS application concept. From idea to architecture.
I’ll go in chronological order and start with a few words about what preceded the development of the current platform architecture (which began in 2000). We already had quite a wealth of experience in implementing applications: first, on the basis of different platforms, then there was the experience of the Docsvision 1.0 project, on which about a dozen projects were implemented and which had to be closed and completely rewritten (a new architecture, including the application model, which we will talk about , turned out to be much more adequate and is still developing). It was this experience of working with various solutions that allowed us to highlight several key ideas for the formation of the following application concept in an integrated EDMS.
These applications can be used in two scenarios:
- For the implementation of AS-IS (reengineering implementation, when the organization is ready to change the existing structure of the business process in accordance with the functionality of the application);
- As an initial base, modified taking into account the specifics of the process in the organization in the case when reengineering implementation is impossible.
Of course, these requirements do not allow to implement EDMS applications in the traditional way (independent coding of individual applications). Obviously, a platform is needed that integrates all applications and tools for their rapid development and modification of applications.
Platform architecture
Fortunately, at the time of the formation of the new platform architecture, we already had experience working with systems of various classes:
These platform classes had a completely different ideology and application model, but all of them were, to one degree or another, applicable for creating document processing applications that were required by our customers. True, not one of them was perfect. Group work platforms provided convenient navigation tools and good tools for working with structured document information; DMS systems made it possible to implement a full set of mechanisms for working with unstructured data (files), and Workflow tools were well suited for organizing document routing and processing sequences for files and electronic forms.
The trouble was that to create a platform that would allow us to implement applications that meet the requirements formulated by us above(regulations), just one platform was not enough. For example, the Lotus Notes system at that time had extremely weak capabilities for processing unstructured information (the ability to store files in RTF fields), it completely lacked a process modeling tool. In addition, each application based on the platform (database) was informationally isolated, and the organization of interaction between the applications required significant efforts of developers - coders.
As a result, the architecture of the new version of the Docsvision platform was based on an application model that combines the advantages of the application models of these systems.
Docsvision application model, 5 components
The Docsvision application model includes the following main components:
1. Card- the main object of the system, which allows you to simulate any application application object. The most typical objects in the EDMS applications are cards of documents (incoming, outgoing contract) and tasks (task for execution, task for approval).
2. Directory - a special type of card that exists in the system in a single copy and allows you to save the most diverse background information, in particular, hierarchically organized.
Fig. 1. Docsvision application card
3. Process- an object that simulates the sequence of actions within an application, a group of interconnected applications, or at the system level. The process includes both manual steps (user interactions with cards or external objects) and automatic steps implemented by the service to ensure the logic of the process processing.
Fig. 2. Docsvision process
4. Folder - an object that provides grouping of cards. There are regular folders in the system - group cards that are created in them, or by physically placing labels on cards in them (similar to file system folders) - and virtual ones that group cards according to certain criteria (search results)
5. Presentation- group presentation of a set of cards in the form of a table or a set of rows. The cells of the table display the attributes of cards, their aggregates, and the results of settlement operations.
Fig. 3. Folders and presentation of the Docsvision EDS application
Lotus Notes system lovers must have seen a lot of analogies, it really is, Docsvision inherited a lot from this system. However, we developed the platform from scratch, which avoided many of the limitations of Lotus Notes and implemented many useful and constructive ideas in Docsvision.
Any application is a combination of a specific set of the above elements. And to meet the application requirements described above, the following features were implemented.
Fig. 4. Docsvision Application Structure
New Application Features
Client components (navigator, etc.) provide the user with a unified system of navigation, search and access to the data of all applications and reference data, to which he has been granted access rights.
The described capabilities of the new application model provided the foundation for implementing on Docsvision the most diverse solutions for completely different industries, while allowing to solve the problem of placing all applications in a single integrated environment.
In the following articles, we will examine in more detail the individual components of the Docsvision application model and give examples of the implementation of specific solutions using these tools.
PSRecently, experts began to note the integration of ECM, BPM, Groupware markets and the birth of a new paradigm of platforms that combine the advantages of these technologies. We observe these trends with satisfaction, as realized the need for this convergence 15 years ago, and, moreover, implemented it in a specific product.
Application of modern EDMS. Let's define the terms.
The modern EDMS / ECM platform is a tool for automating a wide variety of document processing processes in companies of various sizes. In fact, the platform itself does not contain complete client functionality, but provides a set of services, components and tools for accelerated application creationbased on the platform. The situation is somewhat similar to the situation with ERP-platforms (Enterprise Resource Planning), where each implementation requires significant customization, taking into account the particular processes of a particular company. However, the level of variability of specific automated processes in EDMS is even higher than in ERP: practice shows that the range of tasks for which EDMS / ECM platforms are used is practically unlimited today.
Let's define the terms.
By application of EDMS we will call automation tools for a specific isolated workflow for solving a specific set of tasks.
Despite the fact that standards and sets of typical requirements for EDMS / ECM platforms are not yet available, more or less powerful platforms contain a set of components and tools for implementing applications. And the structure of applications running on different platforms can vary significantly. In this series of articles, we will consider the structure of applications created on the basis of the Docsvision platform. As I noted above, this information can be useful to business analysts of companies involved in the development of similar applications.
EDS application concept. From idea to architecture.
I’ll go in chronological order and start with a few words about what preceded the development of the current platform architecture (which began in 2000). We already had quite a wealth of experience in implementing applications: first, on the basis of different platforms, then there was the experience of the Docsvision 1.0 project, on which about a dozen projects were implemented and which had to be closed and completely rewritten (a new architecture, including the application model, which we will talk about , turned out to be much more adequate and is still developing). It was this experience of working with various solutions that allowed us to highlight several key ideas for the formation of the following application concept in an integrated EDMS.
- The platform should allow creating applications not only for the automation of purely specific tasks of the “Russian workflow” (documentation support for managing and creating an archive of electronic documents). It should provide automation of a wide range of so-called document-centric processes - those in which documents are the central object of processing.
- Document processing processes can include various types of documents (including structured and unstructured data having a complex life cycle and business processing logic). During processing, information can be transferred from one document to another.
- Applications are not isolated. Information generated in one application can be transferred to others.
- Processes automated by applications based on the EDMS platform have specifics in each particular organization, and, accordingly, require adaptation of the application during implementation.
- The processes in a particular organization are also not stable, and can often be modified.
- For the most common tasks, the variability of which (and the processes in them) in different organizations is not so great, the availability of ready-made “boxed” applications is required. (Today, such applications for our EDS are “Clerical work”, “Contract management”, “Citizens' appeals”, “Meeting management” and several others).
These applications can be used in two scenarios:
- For the implementation of AS-IS (reengineering implementation, when the organization is ready to change the existing structure of the business process in accordance with the functionality of the application);
- As an initial base, modified taking into account the specifics of the process in the organization in the case when reengineering implementation is impossible.
- The ability to create applications that are deeply specific to a particular industry or organization from scratch must be supported.
- Various applications may contain common functions, data elements, and access components. For example, storage and file management tools, shared directories (contractors, employees), document categories, links between documents in various applications, notification tools, etc. The system should support common mechanisms for working with these functions and data for all applications.
- It is necessary to have uniform tools that provide navigation, search, aggregated tabular representations of data that provide access to documents from various applications. For example, search for all documents containing a link to a specific counterparty, regardless of the application in which they were created.
- Applications are not isolated within the framework of EDS and may require integration with other subsystems of the corporate information system.
Of course, these requirements do not allow to implement EDMS applications in the traditional way (independent coding of individual applications). Obviously, a platform is needed that integrates all applications and tools for their rapid development and modification of applications.
Platform architecture
Fortunately, at the time of the formation of the new platform architecture, we already had experience working with systems of various classes:
- collaboration application development platforms (Lotus Notes, Microsoft Exchange),
- systems of the Document Management System (DMS) class, the concept of ECM did not yet exist,
- Workflow-systems (the term "BPM system" was then still not so indiscriminately applied to any tools containing Workflow engines).
These platform classes had a completely different ideology and application model, but all of them were, to one degree or another, applicable for creating document processing applications that were required by our customers. True, not one of them was perfect. Group work platforms provided convenient navigation tools and good tools for working with structured document information; DMS systems made it possible to implement a full set of mechanisms for working with unstructured data (files), and Workflow tools were well suited for organizing document routing and processing sequences for files and electronic forms.
The trouble was that to create a platform that would allow us to implement applications that meet the requirements formulated by us above(regulations), just one platform was not enough. For example, the Lotus Notes system at that time had extremely weak capabilities for processing unstructured information (the ability to store files in RTF fields), it completely lacked a process modeling tool. In addition, each application based on the platform (database) was informationally isolated, and the organization of interaction between the applications required significant efforts of developers - coders.
As a result, the architecture of the new version of the Docsvision platform was based on an application model that combines the advantages of the application models of these systems.
Docsvision application model, 5 components
The Docsvision application model includes the following main components:
1. Card- the main object of the system, which allows you to simulate any application application object. The most typical objects in the EDMS applications are cards of documents (incoming, outgoing contract) and tasks (task for execution, task for approval).
2. Directory - a special type of card that exists in the system in a single copy and allows you to save the most diverse background information, in particular, hierarchically organized.
Fig. 1. Docsvision application card
3. Process- an object that simulates the sequence of actions within an application, a group of interconnected applications, or at the system level. The process includes both manual steps (user interactions with cards or external objects) and automatic steps implemented by the service to ensure the logic of the process processing.
Fig. 2. Docsvision process
4. Folder - an object that provides grouping of cards. There are regular folders in the system - group cards that are created in them, or by physically placing labels on cards in them (similar to file system folders) - and virtual ones that group cards according to certain criteria (search results)
5. Presentation- group presentation of a set of cards in the form of a table or a set of rows. The cells of the table display the attributes of cards, their aggregates, and the results of settlement operations.
Fig. 3. Folders and presentation of the Docsvision EDS application
Lotus Notes system lovers must have seen a lot of analogies, it really is, Docsvision inherited a lot from this system. However, we developed the platform from scratch, which avoided many of the limitations of Lotus Notes and implemented many useful and constructive ideas in Docsvision.
Any application is a combination of a specific set of the above elements. And to meet the application requirements described above, the following features were implemented.
Fig. 4. Docsvision Application Structure
New Application Features
- Each of their application elements (card, process, folder, and presentation) can be modified without modifying the remaining components. For example, if the document approval sequence has changed, then you can rebuild the process without affecting other components of the application. As new functional requirements arise, new objects can be created in the application and connected to existing ones.
- For all of the listed system components, there are interactive designers that allow you to create applications "without programming" and easily make changes to existing applications.
- Low-level programming interfaces are supported that allow you to implement functionality that is not available for interactive modeling tools.
- Individual applications are not isolated from each other, access to individual application objects is delimited only by access rights.
- All applications in the system use a common reference information structure.
- One business process can work with objects created within various applications.
- One folder can group cards created in various applications.
- One view can display data from cards created in various applications.
- Cards of one application may contain links to cards of any other application to which the user has access rights.
Client components (navigator, etc.) provide the user with a unified system of navigation, search and access to the data of all applications and reference data, to which he has been granted access rights.
The described capabilities of the new application model provided the foundation for implementing on Docsvision the most diverse solutions for completely different industries, while allowing to solve the problem of placing all applications in a single integrated environment.
In the following articles, we will examine in more detail the individual components of the Docsvision application model and give examples of the implementation of specific solutions using these tools.
PSRecently, experts began to note the integration of ECM, BPM, Groupware markets and the birth of a new paradigm of platforms that combine the advantages of these technologies. We observe these trends with satisfaction, as realized the need for this convergence 15 years ago, and, moreover, implemented it in a specific product.