In a past life, or some time ago at least… I ran a fairly successful and fast growing IT support company here in the UK. From a standing start we trampled over the local competition, doubled in size every year while doing good work for our customers.
One of the reasons we managed to do this was successfully joining the dots between different systems in use in our IT company.
We had to pay a developer to do the magic for us, but it worked well and allowed us to scale with very little falling between the cracks.
GFI MAX RemoteManagement sent alerts to our helpdesk system. Our helpdesk system was joined to our billing system. Our billing system was joined to our accounting system. Our sales quoting system was joined to our billing system, etc, etc.
In any event, by building these all together we were able to scale quickly while retaining profitability and delivering what our customers wanted.
These days it’s much easier. Most pieces of software that you can buy or rent to run these businesses are very capable of being tightly integrated via API (application programming interface).
Consequently, it’s possible to build a coherent uber-system by building your systems together using APIs and perhaps a tiny bit of coding.
To my mind, as long as integration is tight and relatively simple – it’s probably best to use the best tools for the job rather than looking for one ‘monolithic’ system which claims to do them all (but probably doesn’t), is likely to cost a fortune and will probably have you using just 10% of it anyway.
I guess it’s much like the 7 layer model, allowing you to swap in pieces of technology to run particular layers of your operation ever more efficiently.
And I’m thinking, there’d have been no interweb without the 7 layer model.