As I mentioned in the introduction one of the primary drivers towards low-code development is increased velocity and a lower bar of entry. Both of these are good things, however, as we saw earlier the lower bar of entry might not be enough. Additionally, the increased velocity (due to more contributors from a non-technical background) has serious implications around lifecycle management. To demonstrate this let’s take a non-fictional example. In this example I have a low-code portfolio management tool and a user comes to me asking to put corporate cost center mappings into my low-code tool. It makes perfect sense, now you can track the cost centers associated with your portfolio, and the user is quickly able to implement the feature. It’s the perfect way to demonstrate the value of low code with a fast delivery and meaningful business value. Here’s the catch… the individual who created this functionality is sick, on vacation, or leaves the company, and now you are the team responsible for this feature which is apparently very critical. What do you do now?
This scenario isn’t fictional, and to be blunt you’re going to run into it a lot if you accept low-code development with a completely hands-off approach. In addition to that you’re going to run into scenarios where User 1 breaks User 2’s preexisting functionality, maybe without even knowing it. Who do they call? You of course… Or, to take a more security focused viewpoint, how are you going to ensure that User 1 isn’t creating a nifty feature that accidentally shares protected information across the company. Or worse, publicly. How are you going to handle these scenarios? I humbly submit our current approach for your consideration.
Understand Your Role
I won’t say much here since we covered it in depth in The Road to Low-Code | Will (and Should) They Come?. However, you should understand what role and audience your tool is going to appropriately service. If a use-case comes to you that doesn’t fit appropriately, kindly assist them in finding the proper home. Maybe the timing just isn’t right; then work with them to figure out when you can meet their desires. Don’t think of low code as a free-for-all sandbox, it’s not.
Ultimately you as the service owner will be accountable for the contents, regardless if we like it or not. Think of it more as you are now running your own Platform-as-a-Service offering and manage it accordingly.
Feature Catalog
Your feature catalog can be as robust as is required, however, I would encourage you to make it simple enough that it can be completed without much effort; yet through enough that you can manage the feature without any outside assistance. Some key areas for your consideration might be:
- Business Requirements and Ownership
- Processes and Process Maps
- Data
- Data Confidentiality
- Data Lifecycle (when does it get deleted)
- Data Migration and other Syncing Processes
- Underlying Data Sources
- Data Flow Diagrams
- Approval Processes
- Low-Code Object (Table) and Field Configuration (High-Level Only)
- Data Sensitivity
- Compliance Catagorization
- Data Owner
- Associated Retention Controls
- Intended User Audience
- Support and Troubleshooting
- Runbooks
- Logging
- External Ecosystem
- Upstream Sources
- Known Downstream Consumers
- Development
- Functional Test Coverage
- API Coverage and associated Specs
- Functional Validation and End-to-End Testing
Setup a cadence to make sure that your Feature Catalog is up-to-date and has relevant contacts. If not, identify a new owner and if none exists be prepared to manage the feature until you can deprecate it.
The move to low-code shifts the burden in the engineering team from the developers to the architectural body. Less writing code, more reviewing other features and generating safeguards.
Testing
Stay tuned for more on this… Right now we’re not mature enough to have an automated testing suite in place. That said, we’re aware of the criticality as well as the implications of having a modular testing suite.