Software for large companies, alongside the systems already in place

An external supplier is one more way into your systems: into the data, and into the code that will end up in production. Before signing, you ask who gets in, with which credentials, where the data ends up and who answers for it if something breaks.

For companies within the scope of NIS2, the EU directive that Italy transposed with Legislative Decree 138/2024, it is also a legal obligation: among the security measures in article 24 of the decree is the supply chain, including relationships with direct suppliers. In slides presented on 27 November 2024, the Agenzia per la cybersicurezza nazionale (ACN), Italy’s national cybersecurity agency, turns this into two practical things: assessing suppliers, and writing security into contracts.

On a certificate, four things are worth reading: the number, the body that issued it and who accredited that body, the expiry date, and the scope, which says which work is covered.

dotenv is certified to UNI CEI EN ISO/IEC 27001:2024, the standard for information security management: certificate IIS-1225-06, issued by Dasa-Räegister, a body accredited by ACCREDIA, valid until 15 December 2028. The scope is «design, development and support of software and application solutions», which is the work you would have us do.

Alongside it there is UNI EN ISO 9001:2015, certificate IQ-0721-08, since 2021. In the customer satisfaction survey carried out for the 9001, the average is 4.8 out of 5. The PDFs of both certificates can be downloaded from the certifications page.

If your rules go beyond the standard, for example on health data or industrial property, they are agreed in the contract and written into the project.

The certifications, in Italian →

The new software reads from and writes to the systems you already have: an ERP, an MES, an internal database, sometimes an AS400. It takes the orders from one system and writes the deliveries back into it. It is the part of the work that takes the most time, and in a quote it is the item to read most carefully.

How to connect is decided by what the system allows: exchange files, direct access to the database, middleware, or APIs we write ourselves when there are none. Our software already talks to an AS400, where we wrote the APIs ourselves, and to Navision, which it reads from and writes to. With Dynamics 365 and the other commercial management systems, it reads and writes through their interfaces.

What a connection costs becomes clear once the systems are opened up, and that part is included in the quote.

A question to ask any supplier: who maintains the connection when the ERP moves to a new version. With us it is an item in the agreement. If nobody has written it down, on the day of the upgrade it is not clear who has to get the connection working again.

Web apps connected to company systems →

If your company has an off-the-shelf ERP, such as SAP S/4HANA, Oracle Fusion Cloud ERP or Microsoft Dynamics 365, or a CRM such as Salesforce, there are two jobs to keep apart.

Customising the product from the inside, with its own modules and tools, is the job of the vendor or one of its partners, and dotenv leaves it to them.

Ours is integration. We write the software that works alongside those systems and talks to them through the interfaces they expose: the ERP stays as it is, and whatever else is needed goes into the new software. It might be a supplier portal that reads orders from the ERP, or an app for production that writes into it what has been produced.

An application with its own users and passwords is one more list to keep in step every time someone joins or leaves the company.

Identities are read from the directory you already have, even when there is more than one, and permissions follow the role. When someone leaves the company and you remove them from the directory, they also lose access to the new software.

Our access to your environments follows your rules too: how we get in, and where, is up to you.

The code is yours: it belongs to whoever paid for the work. The documentation and the environments stay yours along with it, and one day you can hand it to another supplier too.

Access to the repository while we write it is agreed in the contract, depending on the work to be done. If you want to read the code as it grows, that is a line to write in before signing.

The software runs on your servers or in the cloud, as you decide, and getting it into the chosen environment is part of the work. The code is under version control from day one.

At dotenv there are 11 of us, across management and team. With a supplier of this size, the right question is what happens if someone is missing halfway through a project.

Every project has a dedicated team, always of at least two people, and what they do is written down: if someone is away, the work carries on.

dotenv’s CTO is Christian Ascone. Roles change from project to project: interface design, project management, backend and frontend development.

After the release, fine-tuning in production falls within the deadlines in the contract, and we fix defects in the software we deliver at our own expense, under the statutory warranty. Ongoing maintenance and enhancements are a separate agreement, and they are paid for. If you need guaranteed response times we write them into that agreement, with the hours, and they are paid for even while the software is under warranty.

The people at dotenv →

We use AI on every project, to support the team’s work. The decisions are made by people, and dotenv answers for what we release. Data from your systems goes only through private AI services of our own, never through external services.

Code written with the help of a model goes through the same checks as everything else, tests included.

The people at Neurally also bring their expertise on AI: Neurally is the company we founded, and today it has two products, Neurally Platform and AREA.

A project in a large company has several people who decide: those who look at how the work changes, and those who look at what goes into the systems.

On your side we need a person who can make decisions. At short intervals we sit down with them for an hour in front of what is running, look at what has changed and decide what comes first.

We work in phases, and the next phase is decided on your results and on checking that we built what was needed: how it works is set out in our method.

Our method →

Before the code there is a prototype: clickable screens, with your cases in them, tried out by the people who will use the software.

Those people may work at another site, far from the meeting where the supplier is chosen. With the prototype they come into the project, and their corrections arrive while the software is still a drawing.

If after the prototype you decide not to go ahead, the screens and the design work stay yours.

How we design →

It starts with a call, free of charge. Then a visit to your site, to see how you work today.

For the call we need whoever has the problem and whoever manages the systems. During the visit we look at the process and the systems the software will have to talk to, and both are needed there. It helps to have ready:

• The process to change, and who is responsible for it in the company.
• The systems involved, such as ERP, MES, directory and databases, and who manages them.
• Your constraints: where the software has to run, how people get in, which security rules apply.
• Who decides on your side, and who will use the software every day.
• Whatever you have already written, if anything.

How we also work: For startups · For SMEs · For the public sector