webMethods Integration Server and API Gateway as the enterprise integration layer, with API design standards and integration governance around it.

Choosing an integration platform is unlike choosing most infrastructure, because the incumbent is never neutral. A broker already in production has an application group around it with a release process and a support queue, and its manufacturer has more to lose from the comparison than the challenger has to gain — so a vendor defending an installed base can discount faster than a migration can be justified. A comparison reduced to the next three years of licensing is not won by the platform that is architecturally right.

The useful evaluation is therefore a proof of value against the interfaces the organization actually has, with written use cases in advance and references checked independently rather than arranged. Integration platforms demonstrate well and implement badly.

And the decision, in a public body, is usually settled by what is already licensed and what the contract vehicle permits rather than by the architecture — which is an argument for reading procurement rulings, and for attaching the platform to a capital project where it is paid for as part of delivering something and proves itself against live subsystems at the same time.

The Medical Examiner’s Office architecture is the fullest expression: webMethods across three sites with a standby pair at an out-of-region disaster recovery site in Atlanta, federating nine subsystems through one bus. An integration layer that everything depends on and that exists once is not an architecture, it is a hostage.