The CUSS Handbook / Who does what in a common-use deployment
Who does what in a common-use deployment
Role allocation in a common-use network is not the same as in a conventional single-airline self-service network, and getting it wrong is the most reliable way to produce a deployment that nobody can operate. The standard names four roles.
The four roles
Platform supplier
Software and hardware development companies. The platform supplier implements the platform software, integrates that software with hardware, and takes the platform through certification. It is the party that has to make an abstract specification work on real printers.
Platform provider
Typically the airport. The platform provider purchases and installs the platform, integrates applications onto it, and operates and maintains it in service. This is the role that owns the passenger-facing estate day to day, and it carries the obligations that go with running public equipment — including, in most jurisdictions, accessibility.
Application provider
Typically the airline. The application provider supplies the service applications and operates them. Note the distinction from the next role: providing an application means being answerable for the service it delivers to passengers, whoever wrote the code.
Application supplier
Software development companies. The application supplier implements the service applications. Frequently this is a third party working for the airline rather than the airline's own development team, which is why the standard separates it from the provider role at all.
Why the split matters
In a dedicated deployment, one airline owns the machine, the software and the passenger relationship, so responsibility is unambiguous. In a common-use deployment those three things sit with different organisations, and every operational failure lands in the gap between them.
A worked example: a passenger cannot print a boarding pass. Is the printer faulty (platform provider, via the platform supplier's design)? Is the application mishandling a printer state it should have handled (application supplier)? Is the airline's host refusing the check-in for a reason the application is reporting badly (application provider)? Is the passenger ineligible for self-service at all? Without an agreed model of who owns which layer, that question takes a week and three conference calls. With one, it takes a diagnostic view in system management.
This is the substantive argument for taking system management seriously at procurement time: it is the instrument that makes the role split enforceable rather than theoretical.
The service level agreement
The standard is explicit that a service level agreement between the platform provider and the application provider is part of the arrangement, not an optional commercial extra. It defines:
- the relationship between the platform or service provider and the application provider;
- system operation and maintenance;
- customer support;
- integration of the platform and the applications;
- billing of used services.
Those five headings are worth treating as a minimum contents list rather than as a summary. In practice a workable agreement will also need to say something about availability targets and how availability is measured, incident severity definitions and response times, the change and release process for both platform and applications, who may take a unit out of service and on what authority, data protection responsibilities where passenger data crosses the boundary, and the test environment — because an application provider with no way to test against the real platform before release will eventually ship something that only fails in production.
Where accessibility responsibility lands
This is the point at which the role model meets the law, and the answer is less tidy than the role model suggests. In the United States, the Department of Transportation's rule places obligations on carriers for automated kiosks they own, lease or control — and for shared-use kiosks it makes carriers jointly and severally liable with airport operators and other participating carriers for compliance.
In other words, an airline cannot discharge its accessibility duty by pointing at the airport that bought the machine, and an airport cannot assume the carriers have it covered. Both are on the hook, which means the allocation has to be handled explicitly in the agreement between them. The detail is on the kiosk accessibility page.
Two roles that are not in the standard
Real deployments usually contain two more parties the specification does not name.
The ground handler operates check-in on behalf of carriers that have no local staff, and may be the practical application provider for several airlines at once. Whether it appears in the agreements as a provider or as an agent of one is a question worth settling early.
The independent service provider runs common-use infrastructure at an airport under contract, in place of the airport's own IT function. Where one exists it typically absorbs the platform provider role. Note that the US regulatory definition of a shared-use kiosk explicitly contemplates this arrangement, describing a machine jointly owned, controlled or leased by an airport operator and carriers and/or an independent service provider.
For how these roles behave during a procurement rather than in service, see evaluating a common-use deployment.