Let's imagine an Integrator, perhaps using with a framework that has been successfully deployed in the past, and pose the question: does it make sense to use ABL?
The first question is the business model. If it is to maximize billing of attractive rates, then ABL might not fit into your plans. But, if your business model is based on delivering value, and fostering a long-term customer relationship, then ABL is well worth considering as described below.
With ABL, over 95% of your business logic is expressed in annotations, each of which represents around 100 lines of code.
This adds up fast:
Studies have suggested that a line of code requires the same amount of time, independent of language. Since a rule represents 100 lines of code, our code base is 1k lines - 20 days of work
Even if you presume that most of the code is written and just needs to be extended, the numbers are still daunting, because the archaeology to understand the ordering of that much code is an immense undertaking. With ABL, ordering is automatic, so you simply add/alter logic as required.
These reduced costs can be shared with your client. Even if you retain most of them, the client still gets a decisively better result, as described below.
Offering a less expensive solution is always attractive, but perhaps even more important is delivering significantly better results for your client, both instantly and over the life time of the project.
Delivering a significantly better result - in ways that are clear and demonstrable - can lead to landing more business, and more repeat business.
Architects responsible for acquired systems need to understand how they work. 100k lines of code is inevitably written by many individuals over an extended period of time. Given the complexities of multi-table logic (service layer? Data Access Objects), architecture quality is likely to be uneven.
Better margins and results are good, but only if they are delivered. It is no secret that many implementations fail, even when starting with an existing framework.
Business Logic Automation can reduce risk:
A significant cost of failure is requirements risk: misunderstood or undiscovered requirements. Logic transparency can reduce misunderstandings, and Logicdoc makes clear exactly what is delivered.
Integration testing is a key point of failure, where every test reveals more bugs. These are often due to lack of re-use - the system applied the required logic in Use Case 1, but it was overlooked in Use Case 2.