Technology

For many software projects, a choice must first be made between the deployment of a standard solution or building customised solutions. The first may be cheaper, but it requires concessions on functionality. The second may provide a more fitting solution, but it is often more expensive and often lacks certain basic principles or handy features.

In our philosophy, we combine the best of both worlds by building our software in modules around defined functional areas such as invoicing and accounts receivable management, but also by dividing all possible functionalities into 3 layers:

• Generic: this is functionality that every customer needs, such as authorisation, auditing and logging, or a table with country codes.
• Domain-specific: this is functionality that customers need within a certain functional domain, for example order types within a logistics domain or age analyses within accounts receivable management.
• Customer-specific: this is functionality that only a specific customer needs, for example a specific link or report.

With every request we receive from a customer, we think about ‘the question behind the question’ and whether we can best meet the request with a generic, domain-specific or customer-specific solution. When we do not opt for customer-specific, we also immediately improve our platform for other customers and customer groups.

In addition, we think carefully about which module should accommodate certain functionality, with an eye from a technical perspective for ‘dependencies‘ and ‘separation of concerns’. This increases the maintainability.

The great advantage of this approach for our customers is a feature-rich, standard solution that can be seamlessly expanded with customisation, and which also feels ‘productised’ and can be well maintained.

The Abillity^® platform is based on a Service-Oriented Architecture (SOA). Frontend and backend exchange information securely, with encryption, via a Backend-For-Frontend (BFF) API. The backend is developed in.NET Core, the frontend in Angular.

The system is ‘Code-First’, where the entity model is first defined in code. Microsoft Entity Framework (EF Core) is used, and no logic is implemented on the database. MS SQL Server is largely used as a datastore. If desired, data can be stored ‘encrypted at rest’, for which key management is set up. Where necessary and useful, other types of datastores, such as document databases, can be used.

For backend logic, developers write unit tests, which are performed while building versions. These automatically test that nothing has ‘broken’ as a result of changes. The frontend is also tested automatically, using Cypress, with various end-to-end tests predefined. This results in optimal reliability of new software versions.

Deployment takes place automatically via build pipelines and Docker containers, making the application easy to host in various cloud and other environments. Logging and the monitoring based on it, including health checks, are also automated.

For low-threshold integration into an existing system landscape, the Abillity^® platform offers a full-featured REST API. This makes it possible to quickly integrate Abillity^® with other systems – for both the incoming and outgoing data streams – even if this goes beyond the standard available calls. If desired, we can expand generic API calls with domain-specific and even customer-specific fields and logic, or implement API calls entirely ‘to the point’, if that is the best solution.

Especially in landscapes with somewhat older (‘legacy’) systems, we encounter situations where an API link is one bridge too far. In such cases, we can also link via file exchange (typically secured FTP). Our CV includes an impressive list of systems with which we have successfully realised links. We also bring this experience to the table with new customers.

A clearly distinctive feature of the Abillity^® platform is that it can efficiently handle very large amounts of data. Our solutions are designed to handle high input data volumes, sometimes tens to hundreds of millions of transactions per day.

Performance requires constant attention, because both the size and the composition of customer and other databases can change. We safeguard performance through monitoring and – if necessary – pay timely and proactive attention to ‘tuning’ the performance.

Thanks to the architecture of the application, it is always possible to scale up ‘horizontally’, by engaging more (instead of heavier) hardware. Especially in cloud computing situations, this can also be very cost-effective with the current state of the art, by switching resources on or off ‘on demand’. Suppose, for example, that the peak load of processes within your organisation is on or just after the first day of the month. Then we can automatically activate sufficient resources around that time, and those resources will be released again (so that they are not an expense for the entire month).

The above is mainly about the performance of data processing on the backend. In addition, a fast and well-functioning graphical user interface (GUI) is of course of great importance. We also pay a great deal of attention to the performance on the frontend within our software development process, for example by thinking carefully about the ‘caching’ of certain information versus moments when data need to be refreshed on the frontend. This leads to a very pleasant user experience, little waiting time and thus high productivity.

We set up a DTAP street (Development, Testing, Acceptance and Production) for each project. We use the first two environments internally; Acceptance and Production are for our customer.

New functionality first arises in the development environment. Our analysts write user stories (specifications) for developers based on customer requests or as a result of autonomous product development. Developers build the new software, using at least a four-eyes principle: at least one other developer reviews the code of the responsible programmer, also testing the correct application of standards and the readability (i.e. maintainability) of the code.

Developers also write automatic software tests, independently or in collaboration with test automation specialists. After successfully completing the automatic tests, a test version can be built so that the new functionality can also be checked by our testers. If all lights are then green, the new software goes on to the next stage. In this process, we strive for ‘first time right’, and where rework is required, we try to learn from it in order to further improve our development process.

As soon as a new ‘product increment’ has been created, often after a development sprint in which several user stories have been included, and after this has passed with 100% through the automatic and manual tests, we can deliver a version to our customer’s acceptance environment. Based on release notes, users can then try out and test the new functionality.

After approval by the customer, the new release is promoted to the production environment on time slots that are often coordinated with each other in advance, and the new software is ‘LIVE’.

Within this cycle, not only is the testing (of both backend and frontend) automated, but the delivery process (deployment) is also fully automatic. This saves time and minimises the chance of errors, thus improving quality. Thanks to modern techniques such as containerisation, downtime during upgrades can be minimised, and there is actually continuous integration and continuous deployment (CI/CD).

Where we deliver our software depends on the customer’s wishes. Various scenarios are possible, ranging from directly to the customer (‘on premise‘) to ’in the cloud‘ and all kinds of scenarios in between (for example to a private cloud). The type of cloud (for example Azure or AWS) does not matter; our solution is cloud-independent. We can also completely handle things for our customers in this area by deploying our own hosting facilities or those of various partners.