Vendors are necessary. They bring tools, expertise and pace. But their incentives are not the same as the client operating model. The vendor wants a successful sale, implementation or renewal. The organisation needs a capability it can live with after the project team has gone.
The hard questions often appear later: who owns the configuration, who understands the failure modes, who can explain the dependencies, who knows whether the product remains the right answer, and who has authority to change it when the evidence changes?
Good advice makes use of vendor knowledge without allowing the vendor roadmap to dictate the architecture. Product guidance is useful input, but it still has to fit the client's environment.
That is not an argument against vendors. It is simply recognition that an excellent product can be wrong for a particular organisation's constraints, people, budget or risk.
Engineering lessons
- Vendor input is evidence, not architecture.
- Ownership must outlive the project.
- The environment decides what is appropriate.
Read the engineering principles behind this work →
Confidentiality: Engineering Notes are based on real engagements. Client identities, timelines and identifying details may be changed to protect confidentiality. The engineering decisions and lessons remain representative of the work undertaken.