The face of the moon was in shadow
Systems integration is one of those terms that appears in every supplier's description of itself and means something different in each. It is worth defining precisely, because the difference between an integrator and a reseller is the difference between buying a system and buying a pile of equipment that ought to work together.
The definition, without the jargon
Integration is making separate technologies operate as one system, designed around an operational objective rather than around a product catalogue.
The word doing the work is 'designed'. Anyone can supply a camera, a radio and an access control reader. Integration is establishing what has to happen when the reader is forced at two in the morning (which camera records, who is told, over what channel, and what the record looks like afterwards), and then building the thing that does it.
What it looks like when it is absent
You can recognise an unintegrated installation without opening a cabinet.
- Systems that were bought together but do not talk to each other
- Three separate interfaces an operator has to watch simultaneously, so in practice they watch one
- An incident that is visible on one system and invisible on the others
- No single record of what happened, only fragments in three places with unsynchronised clocks
- Each vendor confident the fault is somebody else's
That last point is the practical reason organizations pay for integration. Not elegance, accountability.
When you genuinely need an integrator
- When more than one technology has to work together to achieve the objective
- When the operational requirement is specific enough that off-the-shelf configuration will not meet it
- When you are extending or connecting systems you already own, which is harder than building new
- When the consequence of the system failing is operational rather than merely inconvenient
- When you do not have the in-house capacity to own the design yourself
When you do not
Plenty of requirements are procurement, not integration, and treating them as integration wastes money.
If you need twenty radios on an existing system, that is supply. If you need cameras added to a working platform with capacity, that is installation. A supplier who turns either of those into an integration project is inflating the work, and you are entitled to say so.
Integrating what you already own
Most integration work in practice is not building from nothing. It is connecting systems bought at different times, from different suppliers, by different people, none of whom expected them to be joined.
That is harder than new-build and it is where experience shows. The constraints are real: equipment that has reached end of support, proprietary interfaces that were never meant to be opened, cabling installed for a different purpose, and documentation that does not match what is actually there.
The honest sequence is to survey what exists before designing anything, and to expect the survey to contradict the drawings. Any proposal to integrate existing systems that was written without someone looking at them is a guess with a price attached.
What an integration project actually looks like
For anyone who has not run one, the shape is worth knowing, because it tells you where to apply attention.
- Requirements and survey, where the operational objective is established and the site is examined
- Design, where the technologies and the interfaces between them are specified, and which is signed off
- Procurement, where lead times and licensing usually determine the programme rather than price
- Installation and configuration, which is the visible part and rarely the risky one
- Integration and testing, where the joins are proved and where problems surface
- Training and handover, including documentation, credentials and the maintenance arrangement
The two stages that decide whether a project succeeds are the first and the fifth. The middle is logistics. If a supplier's programme compresses survey and testing to make a date, that is where the failure will come from.
How to tell an integrator from a reseller
Four questions, and the answers are revealing.
| Ask this | An integrator will… |
|---|---|
| What do you recommend, and why not the alternative? | Name the alternative and explain the trade-off |
| Will you survey before quoting? | Insist on it, because the design depends on it |
| What happens when this fails at 2am? | Describe a process, not a phone number |
| Who owns the design? | Say you do, and hand over documentation to prove it |
A reseller answers the first question with a product, avoids the second, treats the third as a warranty question and does not understand the fourth.
The documentation test
The most reliable indicator is what you receive at handover. An integrated system comes with as-built drawings, configuration records, an equipment schedule, credentials handed over properly and a maintenance schedule. A pile of equipment comes with manuals.
The reason this matters is not tidiness. It is that the next engineer to touch the system (who may not be from the same company) can only work on what is documented. Undocumented systems become unmaintainable at exactly the moment the person who built them moves on.
The honest version of the single-supplier argument
Integrators argue that one accountable supplier is better than several. That is true, and it is worth being clear about why, because the reason usually given is not the real one.
The real benefit is not convenience. It is that when several suppliers each own a part, the gaps between the parts are owned by nobody, and the gaps are where systems fail. A single accountable design means somebody is responsible for the joins.
The corresponding risk is concentration: one supplier failing you across everything. Mitigate it by owning your documentation and insisting on standards-based equipment rather than proprietary lock-in. A good integrator will agree with that, because it is a description of good practice rather than a threat.
PLACEHOLDER 
AGPO Certified 
