Applications in the electronic document management system. Part 1: Key Principles, Components, and Features
With this post I will begin a small cycle of articles devoted to various aspects of application development in an electronic document management system. Today, all more or less powerful and modern EDMS / 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, what problems we had while implementing the toolkit for their development, and about what we expect in the future. It will be interesting not only for those who work closely with Docsvision, but also will allow those who will implement or develop their corporate EDS to gain experience.
The application of modern SED. We define the terms.
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 creation of platform- based applications . The situation is somewhat similar to the situation with ERP-platforms (Enterprise Resource Planning), where each implementation requires substantial customization, taking into account the specific processes of a particular company. However, the level of variability of specific automated processes in the EDS is even higher than in the ERP: practice shows that the range of tasks for the implementation of which the EDMS / ECM platform is used is practically unlimited today.
We define the terms.
The application of the ERMS, we will call the automation of a particular isolated workflow to solve a specific set of tasks.
Despite the fact that there are no standards and sets of typical requirements for EDMS / ECM platforms, all more or less powerful platforms contain a set of components and tools for implementing applications. And the structure of applications executed on different platforms may differ significantly. In this series of articles, we will look at 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 engaged in the development of similar applications.
')
The concept of the application of SED. From idea to architecture.
I will go in chronological order and start with a couple of 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 close and completely rewrite the system (the new architecture, including the application model, which we will talk about , turned out to be much more adequate and is still evolving). It was this experience of working with various solutions that allowed us to identify several key ideas for the formation of the following concept of applications in an integrated EDMS.
These applications can be used in two scenarios:
- To implement 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 the initial base, modified with the specifics of the process in the organization in the case when reengineering implementation is impossible.
Of course, these requirements do not allow the application of the EDS 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 a new platform architecture, we already had experience working with systems of various classes:
These classes of platforms had a completely different ideology and application model, but all of them were more or less applicable for creating applications for processing documents that our customers needed. True, none of them was perfect. Group work platforms provided convenient navigation tools and good tools for working with structured information about documents; DMS systems made it possible to implement a complete set of mechanisms for working with unstructured data (files), and the Workflow toolkit was 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 to implement applications that meet the requirements (provisions) formulated above, a single 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 platform-based application (database) was informationally isolated, and organizing co-operation was essential for organizing interaction between applications.
As a result, the architecture of the new version of the Docsvision platform was based on the application model that combines the advantages of the application models of the listed 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 SED applications are document cards (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 a wide variety of background information, in particular, hierarchically organized.
Fig.1. Docsvision App Card
3. Process - an object that simulates the sequence of actions taken within an application, a group of interrelated applications, or at the system level. The process includes both manual steps (user interaction with cards or external objects) and automatic steps implemented by the service to provide process processing logic.
Fig.2. Docsvision process
4. Folder - an object that provides grouping of cards. There are regular folders in the system — group the cards that are created in them, or by physically placing labels on the cards (similar to the file system folders) in them — and virtual ones, which group the 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. In the cells of the table, the attributes of the cards, their aggregates and the results of the settlement operations are displayed.
Fig.3. Folders and presentation of the application Docsvision EDC
Fans of the Lotus Notes system probably saw a lot of analogies, this is true, Docsvision inherited a lot from this system. However, we developed the platform from scratch, which allowed us to avoid the many limitations of Lotus Notes and implement many useful and constructive ideas in Docsvision.
Any application is a combination of a specific set of the above elements. And to meet the above application requirements, the following features have been implemented.
Fig.4. Docsvision application structure
Application features of the new model
Client components (navigator, etc.) provide the user with a unified unified system of navigation, search and access to the data of all applications and reference data to which he has access rights.
The described capabilities of the new application model provided the foundation for implementing on the basis of Docsvision a wide variety of solutions for completely different industries, while at the same time solving the problem of placing all applications in a single integrated environment.
In the following articles, we will look at the individual components of the Docsvision application model in more detail and give examples of the implementation of specific solutions using these tools.
PS Recently, experts have begun to celebrate the integration of the ECM, BPM, Groupware markets and the birth of a new paradigm of platforms uniting the merits of these technologies. We observe these trends with satisfaction, since realized the need for this convergence 15 years ago, and, moreover, implemented it in a particular product.
The application of modern SED. We define the terms.
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 creation of platform- based applications . The situation is somewhat similar to the situation with ERP-platforms (Enterprise Resource Planning), where each implementation requires substantial customization, taking into account the specific processes of a particular company. However, the level of variability of specific automated processes in the EDS is even higher than in the ERP: practice shows that the range of tasks for the implementation of which the EDMS / ECM platform is used is practically unlimited today.
We define the terms.
The application of the ERMS, we will call the automation of a particular isolated workflow to solve a specific set of tasks.
Despite the fact that there are no standards and sets of typical requirements for EDMS / ECM platforms, all more or less powerful platforms contain a set of components and tools for implementing applications. And the structure of applications executed on different platforms may differ significantly. In this series of articles, we will look at 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 engaged in the development of similar applications.
')
The concept of the application of SED. From idea to architecture.
I will go in chronological order and start with a couple of 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 close and completely rewrite the system (the new architecture, including the application model, which we will talk about , turned out to be much more adequate and is still evolving). It was this experience of working with various solutions that allowed us to identify several key ideas for the formation of the following concept of applications in an integrated EDMS.
- The platform should allow creating applications not only for automating the purely specific tasks of the “Russian document circulation” (document management support 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.
- The processing of documents 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.
- The processes being automated by applications based on the SED platform have specificity in each specific organization, and, accordingly, require application adaptation during implementation.
- The processes in a particular organization are also not stable, and can be modified quite often.
- For the most typical tasks, the variability of which (and processes in them) in different organizations is not so great, the presence of ready-made "boxed" applications is required. (Today, such applications for our SED are "Record Keeping", "Contract Management", "Citizens' Appeals", "Meeting Management" and a number of others).
These applications can be used in two scenarios:
- To implement 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 the initial base, modified with 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 should be supported.
- Different applications may contain common functions, data elements and access components. For example, tools for storing and managing files, shared directories (contractors, employees), document categories, links between documents in different 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 common tools that provide navigation, search, aggregated tabular presentation of data, which provide access to documents from various applications. For example, the 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 the ERMS and may require integration with other subsystems of the corporate information system.
Of course, these requirements do not allow the application of the EDS 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 a new platform architecture, we already had experience working with systems of various classes:
- collaboration application creation platforms (Lotus Notes, Microsoft Exchange),
- Document Management System (DMS) class systems, ECM was not yet a concept,
- Workflow systems (the term “BPM system” was not yet so indiscriminately applied to any tools containing Workflow engines).
These classes of platforms had a completely different ideology and application model, but all of them were more or less applicable for creating applications for processing documents that our customers needed. True, none of them was perfect. Group work platforms provided convenient navigation tools and good tools for working with structured information about documents; DMS systems made it possible to implement a complete set of mechanisms for working with unstructured data (files), and the Workflow toolkit was 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 to implement applications that meet the requirements (provisions) formulated above, a single 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 platform-based application (database) was informationally isolated, and organizing co-operation was essential for organizing interaction between applications.
As a result, the architecture of the new version of the Docsvision platform was based on the application model that combines the advantages of the application models of the listed 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 SED applications are document cards (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 a wide variety of background information, in particular, hierarchically organized.
Fig.1. Docsvision App Card
3. Process - an object that simulates the sequence of actions taken within an application, a group of interrelated applications, or at the system level. The process includes both manual steps (user interaction with cards or external objects) and automatic steps implemented by the service to provide process processing logic.
Fig.2. Docsvision process
4. Folder - an object that provides grouping of cards. There are regular folders in the system — group the cards that are created in them, or by physically placing labels on the cards (similar to the file system folders) in them — and virtual ones, which group the 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. In the cells of the table, the attributes of the cards, their aggregates and the results of the settlement operations are displayed.
Fig.3. Folders and presentation of the application Docsvision EDC
Fans of the Lotus Notes system probably saw a lot of analogies, this is true, Docsvision inherited a lot from this system. However, we developed the platform from scratch, which allowed us to avoid the many limitations of Lotus Notes and implement many useful and constructive ideas in Docsvision.
Any application is a combination of a specific set of the above elements. And to meet the above application requirements, the following features have been implemented.
Fig.4. Docsvision application structure
Application features of the new model
- Each of their application elements (card, process, folder and presentation) can be modified without modifying the other components. For example, if the document approval sequence has changed, then the process can be restructured without affecting other components of the application. In the course of the emergence of new functional requirements in the application can create new objects and connect to existing ones.
- Interactive designers are available for all the listed components of the system, which allow both creating applications “without programming” and easily making changes to already running applications.
- Low-level software interfaces are supported that allow the implementation of functionality not available for interactive modeling tools.
- Separate applications are not isolated from each other, access to individual objects of the application is limited only by access rights.
- All applications in the system use the general structure of reference information.
- A single business process can work with objects created within various applications.
- One folder can group cards created in different applications.
- A single view can display data from cards created in various applications.
- Cards of one application can 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 unified system of navigation, search and access to the data of all applications and reference data to which he has access rights.
The described capabilities of the new application model provided the foundation for implementing on the basis of Docsvision a wide variety of solutions for completely different industries, while at the same time solving the problem of placing all applications in a single integrated environment.
In the following articles, we will look at the individual components of the Docsvision application model in more detail and give examples of the implementation of specific solutions using these tools.
PS Recently, experts have begun to celebrate the integration of the ECM, BPM, Groupware markets and the birth of a new paradigm of platforms uniting the merits of these technologies. We observe these trends with satisfaction, since realized the need for this convergence 15 years ago, and, moreover, implemented it in a particular product.
Source: https://habr.com/ru/post/252789/
All Articles