No Code was popularized by Salesforce and other SaaS vendors as a means to deliver business functionality without the requirement of developers, allowing users to configure specific capabilities and start using the application quickly. This post will present a background and the benefits of No Code as well as present how the OpenContent Management suite can be used with Alfresco to realize these benefits.
No Code – What Business Issue that it solves?
As businesses look for more agility, development operations are a complex challenge, particularly in regards to the hiring and retention of software developers. In an environment where there is a high demand for development skills, it can be difficult for large companies to hire and retain developers especially when competing against software startups. Combined with the pressure from business to develop more business capabilities quicker, IT departments are struggling to meet business needs without the expensive costs of outside resources. In many markets, the demand for business applications outstrips IT’s ability to deliver them by a factor of five or more. The U.S. Bureau of Labor Statistics sees 1.4 million developer jobs currently open and growing in the United States, but only 400,000 computer science students currently in education – creating a serious developer skills gap.
No Code could be described as providing an administrative interface to configure particular functions and positioning within the interface construct. Compared to custom development, No Code approaches provide the following benefits
- Quicker time to market
- Easier Support
- Less developer and support costs
The most major drawbacks with No Code approaches surround the ability to finely tune the user experience to the specific user requirement with custom code or low-code approaches.
Content Services Platform (CSP) – Why No Code, Low Code and Custom Code are all important
Content Services Platforms typically demand a combination of No Code, Low Code and Custom Code capabilities for different scenarios. Relevant scenarios include:
- Custom Code – for unique user interfaces or integrations where “out of the box” document interfaces will not achieve the business benefits, capabilities or user experience required. For these scenarios, the ability of the CSP to provide interfaces or development environment support is critical with the maximum amount of flexibility for developers. We typically see Service Orientated Architectures (SOA) with REST based APIs as the current best support for a variety of development approaches. See related post for comparison of OpenContent with other Alfresco Development Options.
- Low Code – for user interface requirements where “out of the box” document interfaces lack the capability to add specific logic or functions that will require “IF THIS THEN….” where programming is required but not a complete interface development. Low code allows the developer more quickly develop the required capabilities but still leverage “out of the box” components to reduce the development time.
- No Code – for user interface requirements where “out of the box” requirements can be met with small tweaks and configurations for specific use cases.
CSP platforms have a long history of leveraging “out of the box” interfaces for common document capabilities.
- Users – Initial usage typically focused on “do all” interfaces that provided file/cabinet type capabilities while showing off the benefits of document management over typical File Manager capabilities. These application were tremendously popular as businesses would adapt to the interface and developers would look to configure small changes, typically with code or code like configurations like XML, to provide for specific functions, object models or security requirements.
- Administrators and Developers – Needed an interface that would allow them to review all documents in the repository to properly administer the system and problem solve for custom development and low-code approaches.
As an example, with Alfresco Share, customizing search is not straightforward. See a TSG post on comparison of Alfresco Share with OpenContent from 2018 for additional details, but in order to make this change, a developer would need to:
- Edit multiple configuration XML files on the server to set up the custom search page. Separate XML files are needed to set up the search form for the custom type.
- Test the search in a development and QA environments
- For each environment, Stop Alfresco, deploy the changes via an AMP, and restart Alfresco
Alfresco No Code Approach
The OpenContent Management Suite (OCMS) takes a no code approach to building the search application. Instead of a development framework, the OpenContent Search module is configured in the administration components using a GUI interface. Configurations that an administrator can make in order to build a search interface:
- Object Type Config – Tells OCMS what repository object types are to be exposed in the application. Per type, the administrator can change any attribute labels as well as filters.
- Search Form – Configure the form for a particular object type search. The administrator can choose particular metadata fields and controls, whether or not full text search is available, and whether or not saved searches should be exposed.
- Search Config – Configure the search sort order and results processing. This is where the administrator can choose how the results table should look, any actions that can be performed on the documents, as well as what happens when the user clicks on a search result.
- Trac Config – The concept of a ‘Trac’ allows OCMS to segment the application based on business function. For example, an Invoice trac could be used for Accounts Payable, and a separate Legal trac could be configured for contracts. Security can be applied to ensure that these two tracs are separate if desired. Once the Search config is configured in the previous step, we assign it to a trac.
In our example use case, the update steps are trivial:
- Login to the OCMS application as an administrator
- Edit and save the necessary search configuration changes
Changes are immediately reflected in the user interface with no application downtime. Since the above concepts can be difficult to envision, here’s a demo video that shows how to configure a search in OCMS from scratch:
In utilizing the OpenContent Search application to build our search interface, no development time is required. Once OCMS is installed, a configuration-only approach is taken to build the interface. If users want updates to the search (additional types, metadata, etc) or new departments want to come online with new document types, no additional development is needed. The application can be configured and updated with no downtime since no deployments are necessary to update and apply configurations.
OCMS provides the other no code configurations including:
- OpenContent Case Management – Allows for configuration of views, documents, departments, groups and other common interface components. Specific configurations include how documents are added to the case folder, what properties are available for view and edit, advanced actions such as combining/splitting documents, sending emails, case notes and more.
- OpenContent Form Management – create dynamic forms that flow based on your business scenario. Users are only presented with the relevant pages and questions. This configuration approach extends to review and approval workflow as well. Administrators define rules that turn form answers into a business workflow process. When the workflow is started, the rules are evaluated on the fly – there’s no need for a static workflow template.
For additional detail, see our Building a Case Management in 20 minutes post with the below video.
There are major differences between custom, low-code and no-code approach to Alfresco deployment. Clients should look to understand their needs and evaluate all options to consider which approach makes the most sense for their application deployment efforts.
From Alan Pelz-Sharpe of Deep Analysis
“Deep Analysis would predict that, as clients move away from the cost, complexity and difficulty of support for custom code development, vendors that offer no code and low code capabilities will be able to differentiate themselves with a lower cost of development and support and a quicker time to deployment”.
To see examples of No Code versus Low Code or other approaches see our series on both Alfresco Development Comparisons and Documentum Development Comparisons where we compare multiple interfaces for similar functions.