[eksemplar]

I think we should go even further and think systemic. I work in the public sector, where we have more than 500 different IT systems (in this context, mostly programs).

It’d be a clear advantage if they were all build to be systems, but it would be even better if they were build to be systems that coexist with each other.

I wish suppliers would ask us what hardware we operate, what services and API we’d want them to interact with, and, made plans for what we have to do when their system eventually dies. Because right now, everything is build for specific purposes, and it’s impossible to make most things work together.

So you’ll have one program that handles finances for sick people. Another that handles networking to companies and businesses that help get sick people back on track. Another program which keeps track on the wellbeing on families with sick members. A while range of medical programs. And none of them work together, run on the same hardware or has any form of uniform support solution, so we have to waste thousands of nan hours simply making sure every program has the data it needs.

It’s silly, but every developmenthouse seem to suck equally at making non silo sollutuons.

[magicalhippo]

Specialized applications aren't too bad if they're made with integration in mind. That allows them to tie together different datasets to do a limited set of things really well.

The problem is if it's difficult to get data into or out of them.

At work we make a fairly specialized application, but we're very flexible in how we can receive data and send data back out. From manually copying and pasting Excel sheets, parsing emails and PDFs, plain XML over SFTP or web services/REST APIs, we got solutions depending on where the core data comes from and where results needs to go (status back to WMS/TMS, financial details to invoicing system etc).

If needed we have customer-specific "integration shims" to easily adjust/correct/ignore data as it comes or goes.

This allows us to focus on making our application really good at a few things, and let other programs handle the tasks our customer also needs to get the job done (warehouse management, transport management, invoicing etc).

I agree though that support can be a bit of an issue when you have many systems working together and something is wrong. The place where the user discovers the error is often not the place where the error occurred. Monitoring is important, allowing support to be proactive ("hey, the server where you're hosting the DB to our program has less than 1GB diskspace left again").