Most workshops don't set out to build custom software. They set out to solve one specific problem — connect the warehouse system to the accounting export, or bridge the ERP to a customs portal — and a small script grows into something nobody dares touch two years later. Everyone is afraid to change it, the person who wrote it has moved on, and every "quick fix" takes days instead of hours. That's not bad luck. It's a predictable category of software, and business informatics has a name for exactly why it happens.
Two axes, four kinds of software
Any piece of software can be placed on two axes: how much it is tied to a specific business use case, and how deeply it is coupled to the underlying technical layer — hardware, network protocols, file formats, low-level infrastructure. That gives four categories.
- Neutral (0) — low on both axes, such as an operating system, which doesn't care what business runs on it.
- Anwendungssoftware (A) — high on the business axis but low on the technical one: pure application logic, like a price calculation rule.
- Technik-software (T) — high on the technical axis but low on the business one: a device driver, a network layer.
- AT-software — high on both axes at once: it encodes business logic and is deeply wired into the technical plumbing at the same time.
Why AT-software is the one nobody wants to touch
AT-software is explicitly the hardest category to maintain, and the reason is structural, not a matter of bad coding:
- A change on the business side — a new pricing rule, a new customs field — carries a real risk of breaking the technical coupling underneath it.
- A change on the technical side — a new file format from a partner system, a protocol update — can just as easily break the business logic sitting on top.
To maintain it safely you need people who understand both domains simultaneously — not a business analyst and a systems engineer working in sequence, but someone (or a tightly coordinated pair) who holds both pictures in their head at once. That's a rare and expensive combination, which is exactly why these systems tend to rot: the one person who understood both sides left, and nobody dares touch it after that.
Individual software is (almost always) AT-software
Individualsoftware — custom software built for one or a very few specific use cases — is typically AT-software by construction. It is written for your exact business process and wired directly into your exact technical environment, with no abstraction layer protecting one side from changes in the other. Standardsoftware, by contrast, is built to be usable across many different companies without substantial change, and that changes its economics:
- Development cost is shared across many customers.
- Deployment is faster.
- Baseline quality tends to be higher, because more people have exercised the same code paths.
- Best practices get built into the product itself.
- You need less specialized staff to run it.
- Vendors offer additional services around it.
- It integrates more easily with other standard products.
Standard software has real downsides too:
- You carry hardware and resource overhead for generality you don't use.
- You risk vendor lock-in that can run 10 years or more.
- Adapting it to your process can eat up to roughly 40% of the implementation cost.
- Interfaces to your other systems can still cause real integration problems.
- Using the same system as your competitors can be a genuine competitive disadvantage.
- Staff often resist a one-size-fits-all tool that doesn't match how they actually work.
The practical implication for a workshop is this: the connectors and adapters you build between your ERP and everything around it — warehouse, sales, customs, a partner's file export — are, by this definition, AT-software almost every time. They deserve deliberate architecture, documentation, and a named owner who understands both the business rule and the technical wiring, not a script one person wrote under deadline pressure that everyone is now afraid to open.
Nguyễn Hải Minh
I build custom software and data solutions for manufacturing ERP systems, including INFOR, for clients in Germany. As a Staatlich geprüfter IT-Techniker (Fachrichtung Informatik) and Informationselektroniker, I combine deep technical skill with business-systems thinking to help manufacturers automate operations and optimize cross-border import and export.
More about the author →