FAQ‎ > ‎

Integrators with frameworks

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.


Increased Margin

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:  
  • Conventional: 2,000 days
A typical Domain Object may require 1,000 lines of code.  Let's presume there are 100 such objects: 100k lines of code.  If a developer can deliver 50 lines of code / day (most estimates are more like 12-25), this represents 2,000 days of work, or about 10 staff years.
  • @Logic: 20 days
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.

Sales Advantage per enhanced value

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.

Transparency: readable logic, Logicdoc

The initial contact with a customer begins with the sales cycle.  A key factor here is to communicate clearly what the framework does, both to convey its value, and as a basis for determining what features must be added.

Conventional documentation is a poor answer.  Seasoned veterans know it is expensive, and typically drifts away from the implementation.

Logic Annotations, on the other hand, are totally transparent to Business Users as well as Developers.  And Logicdoc enables you to communicate the actual implementation in a clear business context: processes, Use Cases and Requirements.

Maintenance: automatic ordering and optimizations

It is well known that the bulk of costs are in maintenance.  Automatic Ordering means you do not have to spend huge amounts of time unravelling the ordering of existing code - you simply alter the logic as required, the dependency management ensures proper execution order.  Similarly, automatic optimization means that the execution speed does not degrade as it does in manual systems where optimizations are deferred due to time pressures.

Compliance: automatic re-use

Compliance verification of 100k lines of code is a daunting task.  Perhaps an impossible one.

But automatic re-use means that you can be certain that all Hibernate-based updates obey your logic.  Even when there are "back door" changes behind Hibernate, Recompute enables you to find all discrepancies, and, in many cases, repair them.

Architecture Automation

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.

Automation addresses not only the logic, but its architecture.  As noted above, this ensure that logic is used, ordered and optimized - on an ongoing basis.  One might argue whether this is possible by hand.


Reduced Risk

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:

  • Transparency reduces Requirements 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.
  • Automatic Re-use reduces endless Integration Cycles
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.

Automated re-use ensures that all of your Use Cases obey the same logic.  So integration testing avoids interminable iteration cycles, which are actually design work in disguise.
  • Automatic optimizations reduce Performance risk
Systems can fail due to poor performance.  Automated optimizations such as pruning and adjustment are designed to eliminate and optimize SQLs, a prime cause of performance issues.


Comments