English | EN 
Generally speaking, making data from one system useful in another is a requirement that comes up time and again. Such solutions could include:
- Data Migration
- Data Analytics
- Machine Learning
- Workflows
- Re-platforming
- General software solutions that collect user input or integrates with closed systems (i.e. systems that do not provide direct access to data, but may allow report exporting)
Often each of these solutions may include processes for data discovery, data preparation, data transformation and data ingestion (or integration). Whenever you begin such an endeavor, you may ask yourself “what is the best way to make my source data useful in the new solution?” You may find yourself weighing the benefits of a prescriptive rules-based approach versus a more declarative outcome-based approach.
There are certainly times, where 100% prescriptive solutions will be needed. These solutions, however, often require significantly more effort throughout the entire software development process. This increased effort could come from the additional complexity required to:
- Define requirements
- Maintain alignment to changing business requirements
- Write the additional lines of code needed to build each and every rule and requirement
- Test every rule
- Attend the additional meetings needed to discuss each rule and its implications
Though there are several designs and software architectures to reduce the complexity of these prescriptive approaches, another option is to look at introducing a more declarative solution design.
Usually, declarative approaches require a little extra effort upfront, in terms of design, but generally reduce the overall effort to develop the solution. The cost of this increased productivity may include sacrificing 100% certainty that your solution can handle all scenarios. However, the benefits of such an approach can include:
- Less effort to vet out every aspect of the requirements to translate them into rules
- Less rigid, more flexible, solutions able to adapt to changing requirement details
- Usually less lines of code, as you are not solutioning every single detail
- Less testing requirements to account for the negative cases of each rule
- Though there may be a bit more effort managing exceptions for edge scenarios, this effort is usually less than the maintenance of dealing with rules breaking, as a result of evolving business requirements.
The good news is that this decision is not always “all or nothing.” You can often find segments within your overall solution design that lend themselves to maximizing the benefits of a more declarative approach. Ensuring separation of data preparation and data transformation can often open opportunities to leverage more declarative approaches in the data preparation phase. This enables the ability to limit the complexity of rule-based transformations to a narrower segment of the overall solution.
Depending on your particular use cases and technology stacks you may have different options to gain benefits of a declarative approach. For instance:
- Mixed ML/Prescriptive solutions – You could leverage machine learning outputs (declarative) as input into a rules engine to generate prescriptive business decisions (imperative).
- Data Pipelines – You could simply endeavor to prepare and pipeline data from a variety of data sources exported as Excel or CSV files, utilizing Python Pandas and SQLAlchemy to pipeline that data to a new system/platform (… a use case that is more common than you may think)
- Attended automation – Automated workflows that may include steps that require human intervention to trigger the next automation
There are several other use cases that could be discussed, but the point is that there is a growing trend to increase productivity and decrease complexity by employing more declarative approaches. That is why I suggest, where possible and practical, code without rules!
