Summary
- Software Design srl is the Neapolitan company identified by Italian VAT number 05695790633, and not a synonym for SITA's global communications and passenger processing business. Its current legal footer designates SITA BV in Rotterdam as the company exercising direction and coordination, while company and vendor records confirm continuity since the 100% acquisition by SITA in 2019.
- AOSnice is presented as an integration environment built around an airport operational database, core services, a shared event bus and distribution channels. Its modules span schedules and collaborative flight management through stands, gates, staff, passenger information, security, retail data, CRM connections, airport billing and analytics.
- The commercial appeal lies in a common operational dashboard across systems and organisations. The corresponding risk is that data models, business rules, interfaces, historical records and operator habits accumulate around the coordination layer, making replacement far more difficult than changing a screen or renewing a software licence.
- Palermo's public procurement records independently show an annual contract for the AOSnice platform, perpetual licences for FIND displays, baggage system integration and minor commercial service modifications. They confirm a hybrid model of platform continuity, modules, connectors and projects, but do not reveal full pricing, service levels or Software Design's margins.
- SITA ownership may bring scale, capital and adjacent aviation products, but it also changes incentives: a locally embedded integrator is now controlled by a global provider with overlapping airport management offers. Buyers need explicit commitments on product roadmap, resilience, security, data portability and exit, rather than assuming integration automatically means interoperability.
The flight that changes every other answer
Imagine an arriving aircraft whose estimated time advances by twelve minutes. Nothing dramatic has happened: no runway has been closed, no terminal has lost power, and the flight still appears on the board. Yet the revised time may render the planned stand unavailable, conflict with another movement, alter the sequence of a baggage belt, change when a ground team and bus are needed, move a gate announcement, affect a passenger assistance task and modify the chargeable services the airport ultimately records. If the aircraft continues to another sector, a local delay can also change a wider network plan.
The hard part is not displaying "12 minutes late". It is deciding which observation is authoritative, when it became so, which parties can modify it, which downstream systems must receive it, and what to do when two sources disagree. An airport is full of specialised systems each knowing part of the truth: airline departure control systems, air traffic control messages, stand planners, baggage systems, staff schedules, security tools, point-of-sale systems and financial applications. The operational layer that connects them must transform many partial statements into a single usable account of what is happening now.
Software Design's own description ofAirport Traffic Managermakes this coordination role unusually explicit. The module stores and exchanges real-time flight data, accepts automated and authorised manual updates, associates resources and loads with movements, and records history for operational analysis and service accounting. ItsAOSnice frameworkgoes further: the company describes the airport operational database, or AODB, not as a mere database but as a coordinator and information broker, linked to core modules and a shared service bus.
This is the central economic fact about Software Design srl. The company is not best understood as a collection of airport applications, let alone as a small local version of its parent. Its value proposition is the custody of the seams. When the seams work, an airport can add a system, change a plan, or recover from a disruption without every application maintaining a bespoke connection to every other. When the seams fail — or when the airport wants to replace the part that holds them — the same central position can amplify the operational consequence.
The article therefore tests a narrower question than the usefulness of airport digitisation. It asks what an airport buys when it lets a single vendor mediate schedules, resources, messages, passengers and money, and what evidence is needed before that convenience becomes a dependency.
The Neapolitan company behind the brand
The designated entity has a reasonably clear public boundary. Thecurrent footer of Software Design's websiteidentifiesSoftware Design srlas a single-member company at Capodichino Airport, Viale Fulco Ruffo di Calabria, 80144 Naples. It gives the tax and VAT number 05695790633, the REA 455315 reference from the Naples Chamber of Commerce, and a fully paid-up share capital of €581,062.50. The same footer states that SITA BV, Rotterdam, exercises direction and coordination under Article 2497‑bis of the Italian Civil Code. Acustomer privacy notice dated 28 June 2022repeats the Naples headquarters and VAT number and names Software Design srl itself as data controller for the customer contact processing described therein.
These are company disclosures rather than a recent Italian registry extract, so they do not answer every corporate question. They are nonetheless specific enough to avoid a common misidentification. The subject is the Italian limited company located at Naples airport. It is neither SITA's cooperative structure, nor SITA's global network, nor its passenger service system, nor any other SITA affiliate simply because the parent brand appears in the footer.
This distinction also governs evidence. Theglobal SITA websitecurrently claims more than 2,500 customers and presence in over 1,000 airports, but that scale cannot be attributed to Software Design. Likewise, a SITA product announcement does not establish that the Neapolitan subsidiary developed, hosts or contracts that product. Parent company documents are relevant only when they shed light on ownership, distribution, adjacent offers or strategic direction. Product claims attributed to Software Design come from the subsidiary's own catalogue or from customer and procurement evidence that names exactly the VAT-numbered company.
The boundary also works the other way. SITA's control does not make Software Design a defunct brand. The active legal footer, the support desk link, the Naples contact details, the extensive AOSnice catalogue and the 2023 trade association entry all continue to identify the Italian company. The defensible picture is that of an operating subsidiary with a distinct legal identity and a parent-directed strategy — neither an independent supplier nor merely a web page for SITA.
This matters in contracting. A buyer must know which entity licences the software, employs the support team, holds customer data, assumes professional liability, owns or can sub-license the relevant code, and provides any parental guarantee. "Part of SITA" is only commercially reassuring to the extent that the contract turns group resources into enforceable obligations.
Three eras of ownership, one operating address
Software Design states it was founded in 1988 to bring information technology to transport companies and airport operators. Itscompany historymarks a shift towards the end of 2010, when F2i–Sistema Aeroportuale Campano became the principal shareholder, and a second change at the end of 2019, when SITA acquired 100%.
The vendor dossier provides useful detail. A6 November 2019 acquisition press release hosted by F2istates that SITA bought Software Design from its incumbent shareholders and 2i Aeroporti, the F2i–Ardian airport joint venture. It calls the company the main IT services provider at Naples airport, says the transaction brought a team of 70 people into SITA, and notes that the team would continue to operate from Naples airport. The stated aim was to strengthen SITA's ability to integrate technology across many systems and vendors in Italy and Europe, with SITA leading the modernisation of Naples airport's IT and digital infrastructure.
Italy's independent technology publication CorCom described the same deal on7 November 2019, identifying systems integration as the deal's core mission and Software Design as Naples airport's main IT provider. CorCom largely reported the deal announcement rather than conducting a financial investigation, but it corroborates the identity, date and strategic rationale.
Post-sale continuity is visible in two later disclosures. The2023 Air Tech Italy membership cataloguedescribes Software Design as 100% owned by SITA and retains the Capodichino address. The current statement of direction and coordination by SITA BV in the footer is even stronger because it is a living statutory declaration. Together they confirm ongoing control; they do not reveal the full chain between SITA BV and any ultimate association or holding company, nor do they publish subsidiary accounts.
The ownership change altered incentives even as the address and team persisted. Under airport investors, Software Design's integration knowledge and capability sat close to a network that included Naples and other Italian airports. Under SITA, the same capability sits inside a vendor whose commercial interest is to sell a broader portfolio of aviation technology. This may remove coordination friction and fund product development. It may also make neutral integration with competing products less straightforward. The acquisition history is thus not just corporate context: it is part of the architectural and customer-concentration analysis.
AOSnice is a coordination system, not a single application
Software Design divides AOSnice into three broad clusters: airport operations, non-aeronautical activities, and administration and finance. This grouping is useful because it prevents conflating several different systems into a single vague "airport platform".
At the centre is the AOSnice core. Theframework pagedescribes an AODB and core modules for resource configuration, user access, diagnostics, airport offices, device management, flight scheduling, allocation logic and a gateway to airline departure control systems. The AODB holds shared operational entities such as flights, aircraft, carriers, check-in desks, gates, stands, baggage belts, devices, applications, users and alarms. It is both a data store and the context in which resources are configured and linked.
Around this centre is an airport service bus. Software Design describes a publish-subscribe hub-and-spoke mechanism by which internal and third-party systems can send and receive events without every subsystem building point-to-point exchanges with every other. This is a sensible integration pattern: reducing the number of bespoke interfaces can lower the cost of change, isolate applications and give the airport a controlled path for new systems.
It does not abolish coupling. It moves coupling into event definitions, identifiers, timing rules, transformation logic, access policies and the operator's understanding of which system is authoritative. A gate allocation application may be technologically decoupled from a display system while remaining operationally dependent on the same flight identifier, status vocabulary and update sequence. If those shared semantics are proprietary, poorly documented or heavily customised, the bus can become the strongest tether.
The third architectural component is distribution. AOSnice describes services for screens, web channels, email, SMS, voice and wireless devices, allowing an operational fact to be presented to staff and passengers in different forms. Some published channel references — fax, teletext and palmtop devices among them — reflect the long life of the product catalogue. Their presence does not prove that those technologies remain in a current deployment. It nevertheless raises a lifecycle question: buyers need a version-specific architecture and supported channel matrix, not an assumption that every public page describes the latest release.
The core modules extend the model into seasonal schedules and contracts. Flight Programming manages schedules and slot clearance messages; Service Contract Manager links operational services to aircraft, routes, destinations and contractual conditions. This connection explains how a flight update can travel beyond a stand planner into subsequent billing. It is also why a migration cannot be limited to a simple database copy. The airport must replicate behaviour across a repository, integration contracts, configuration, workflow and presentation.
The schedule becomes live operations
An airport starts planning well before the day of operations. Seasonal schedules, slot clearances, carrier plans and service contracts define an expected workload. Software Design's Flight Programming material describes the automatic processing of slot clearance requests and the creation of the schedule from authoritative information. Airport Traffic Manager then takes planned flights into daily operations and keeps them current.
TheAirport Traffic Manager descriptionnames several input classes: airline departure control systems, standard IATA telex messages and tower control systems, connected via an AirportGate module. It states that movement and load messages can update records automatically while authorised operators can enter or correct information via a web interface. The system also highlights inconsistencies when parallel sources do not align.
This last function is more important than automatic ingestion. In airport operations, data availability without quality can be worse than an obvious outage. A stale landing estimate that appears current can send people and equipment to the wrong place. A duplicate message can trigger an action twice. Two flights with an inconsistent shared designator can make passenger information diverge from the ground plan. A useful operational layer needs provenance, sequencing, freshness, validation and a responsible human resolution path — not just connectivity.
Collaborative decision-making adds organisational complexity. Software Design'sCollaborative Flight Management pagepresents its orchestration tools as an extension of AOSnice intended to coordinate human operators and systems across airport stakeholders. The external standard is clearer on the aim. EUROCONTROL'sA-CDM descriptionstates that airports, airlines, ground handlers, air traffic control and the network manager improve efficiency and predictability by exchanging accurate and timely information, especially around turnaround and pre-departure. EUROCONTROL lists Naples among 34 European airports with full A-CDM implementation.
This directory verifies A-CDM at Naples; it does not say which Software Design modules enabled it nor attribute the implementation to that company. The distinction is essential. Software Design can claim an A-CDM-compatible portfolio, and Naples can be independently recognised as an A-CDM airport, without the public record proving that every required milestone, network message or safety assurance is delivered by AOSnice.
For a buyer, the practical test is the full timeline of a flight. What source creates it? How are schedule changes versioned? Who can set the target off-block time? What happens when airline and tower data differ? Which event changes the stand, resource plan, public display and invoice? Can an operator undo an incorrect update without removing the audit trail? These questions reveal whether "collaboration" is implemented as a controlled shared truth or simply more flows into the same screen.
Stands and people turn data into movement
Flight data has little operational value until it changes the use of scarce resources. Software Design separates fixed infrastructure from people and mobile equipment, which is the right boundary for understanding its scheduling modules.
ResourceBrain Fixed Resourcesplans check-in desks, gates, baggage belts, passenger boarding bridges and stands recorded in the AODB. The company describes strategic, tactical and online planning, with airport-specific constraints configurable by business users after initial setup. This is not just a timetable. A stand may be limited by aircraft type, proximity, towing plan, border status, turnaround time or temporary closure. A gate change becomes feasible only if all relevant constraints and dependent information move with it.
ResourceBrain Human and Mobile Resourcesstarts from flight services, converts them into workload by time period, uses that demand to size staff, generate shifts and rosters, allocate people and equipment, and oversee the day of operations. The public description covers handling staff, security agents, coaches, steps and fuel trucks. It also states that automated outputs can be manually modified during unpredictable events and that staff can receive tasks and report progress via mobile or wireless devices.
This combination illustrates both the value and the governance burden of automation. The software can make thousands of constraints visible and produce a plan faster than a spreadsheet. But an optimisation result is not an operational instruction until the buyer knows what objective was optimised, which safety and labour constraints were treated as absolute, how stale availability is handled and who can override the output. A plan that minimises idle time may be fragile under disruption; a plan with deliberate slack may cost more and recover better.
The operational record also becomes commercially significant. The ResourceBrain material refers to cost per flight and per airline. If task completion times and allocated equipment feed into customer billing or contractual performance, then the same dataset supports allocation, payroll analysis, service-level disputes and revenue. This multiplies the cost of incorrect timestamps and makes curation, correction and audit rules part of the product rather than a back-office detail.
Passenger, retail and finance systems are separate
The breadth of Software Design's catalogue can create the impression of a single seamless super-application. In practice, the modules address different purposes, users, data and failure consequences. They must be evaluated separately even if they share the AOSnice infrastructure.
FIND is the passenger information layer. Itsproduct pagestates that flight facts can come from manual operators, Airport Traffic Manager, airline departure control systems and resource allocation algorithms, then be distributed to display units and other channels. A correct record in the AODB is therefore necessary but not sufficient: display configuration, device status, local caching, message priority and operator overrides determine what the passenger actually sees. Palermo's subsequent purchase of FIND NewGen licences suggests that the display product has continued beyond some older channels described on the site, but the public catalogue does not provide a version history.
AirportFlow deals with terminal queues rather than flight truth. Software Design states thatAirportFlowcan combine specialised acquisition devices and available airport data, store observations centrally, forecast passenger flows and support both live queue management and longer-term resource planning. These are company claims. The described architecture could range from door counters to Wi‑Fi tracking, so procurement must identify the actual sensors, accuracy, legal basis, retention and device identifier handling for each installation.
ShopView moves into retail analytics. Itsretail management pagedescribes ingesting transactions from tills or retailer systems and associating purchases with boarding card attributes such as destination and airline. It supports real-time sales monitoring and analysis of commercial layouts and route economics. A local tablet can retain records during a local network outage and transmit them when connectivity returns. This is a useful continuity feature, but it also raises questions about deduplication, device security, retention and whether the airport, retailer or vendor is data controller or processor for each dataset.
The CRM layer is a connector rather than a claim that AOSnice replaces every customer platform. Software Design'sCRM pagestates that non-aeronautical purchase and loyalty information can be exported to external systems, while those systems can request voucher generation. It names SugarCRM and Salesforce as supported platforms and says other connectors can be developed. This is a clear example of integration work becoming a recurring dependency: every change in an external API, identity model, voucher rule or consent field may require coordinated testing.
Passenger Assistant and associated tools sit closer to the digital journey. ThePassenger Assistant descriptioncombines airport services information with flight information, e-commerce, parking, loyalty and customer support on mobile devices. It should not be confused with the operational database even if it consumes its data. The passenger app may fail while flight operations continue; the AODB may be wrong while the app remains perfectly available.
Security and safety modules carry a different burden of proof.DigiEyesis presented as a networked video surveillance framework with live viewing, remote camera control, motion detection, alarm generation, local recording and privacy filtering based on permissions. The page establishes claimed functions, not their current implementation, cybersecurity hardening or legal compliance at an airport. Video, operational and passenger data must not be bundled into a single undifferentiated assurance statement.
Finally, SOFA connects operations to money. Theairport finance pagedescribes multi-entity billing for airport fees, handling services and central infrastructure, including VAT registers, exports to external systems and revenue reporting to ENAC. ABI adds analytics: thebusiness intelligence moduleis presented as an extensible data model with dashboards, historical analysis and customer-specific reports. These are back-office systems, but they depend on operational facts. A corrected movement time or service record may need to propagate into an invoice and official report without erasing the earlier version.
The important separation is therefore functional, not cosmetic. AODB, scheduling, information, passenger flow, security, retail, CRM and financial modules may share identities and events, but they have different owners, recovery priorities, privacy roles and acceptance tests. "Integrated" should mean governed interfaces among them, not a single blanket approval.
Deployment evidence is strongest at Naples and Palermo
Software Design's public claims of scope are broader than the independently visible contract evidence. TheAir Tech Italy membership cataloguestates that the company has served more than 16 airports worldwide and lists Naples, Palermo, Milan Malpensa, Milan Linate, Pisa, Turin, Florence, Bologna, Bari and Alghero among principal airports served. Because the profile appears in a trade association membership brochure and reads like company-supplied text, these names are useful leads, not proof that every airport was a current customer in 2023 or used the full suite.
Naples has stronger support. The 2019 acquisition press release identifies Software Design as the airport's main IT services provider and includes a statement from the airport operator's CEO about using SITA's expertise post-sale. EUROCONTROL independently lists Naples as an A-CDM airport. These sources show an embedded operational role and a relevant collaborative environment, but they still do not disclose the installed module inventory, contract value, service levels or incident history.
Palermo provides the most concrete third-party evidence because its operator has published public procurement records. The2024 GES.A.P. contract registernames Software Design srl with the same VAT number and records an annual contract for the AOSnice airport platform, FIND NewGen display licences, AOSnice integration with a Siemens baggage system, and modifications related to fast-track sales. These are direct-award entries rather than a technical evaluation or performance report, but they verify that the exact company supplied multiple layers at a named airport.
The evidence supports a limited conclusion: Software Design has a long-standing operational footprint at Naples and an independently documented multi-module relationship at Palermo, while a wider Italian airport footprint is claimed via the trade catalogue. They do not support a current market share figure, audited customer count or the assumption that a reference airport proves another airport's configuration or outcomes.
The price is in continuity, licences and connectors
Software Design does not publish a standard price list for AOSnice. The Palermo register nevertheless reveals the shape of the business model. In 2024 it recorded €150,112 for an annual AOSnice platform contract. Separate entries recorded €28,000 for 70 perpetual FIND NewGen licences and €20,000 for another 50, €11,500 to integrate AOSnice with a Siemens baggage system, and €8,300 for a software adjustment on a cash register used for fast-track tickets. The register does not state whether the amounts include each tax, support component or option, so they should not be combined into a total cost estimate.
The model is more instructive than any number. It indicates at least four paid units: platform availability or ongoing support; licences for a defined fleet of display terminals; connector and implementation work; and commercial workflow modifications. This is a hybrid enterprise software model, not a single subscription or a single perpetual purchase.
The economics follow the operational architecture. A larger airport may have more movements, users, screens, gates, interfaces and support demands. A heavily customised airport may require more mapping and testing even if its passenger volume is lower. A customer may buy a module but still need the AODB or service bus on which it depends. Legacy integration, local labour rules, airport-specific billing and 24/7 support may affect cost more than the nominal licence count.
Perpetual licences do not eliminate dependency. They may preserve a right to run a particular version, but the procurement entry does not establish rights to source code, security patches, new operating environments, third-party components or post-termination support. Conversely, an annual platform contract is not automatically cloud software. The public documents do not provide a current, installation-specific split between customer-hosted, vendor-hosted and public-cloud deployments.
SITA's currentAirside Optimizer offeradvertises cloud-native modules, per-solution pricing and cloud or on-premise options. This shows the parent company's current commercial direction, but it is not proof that AOSnice uses the same terms. A Software Design buyer should demand a price list that names the exact module, deployment, environment, interface, service window, upgrade right and exit service rather than assuming from SITA's broader catalogue.
Implementation is part of the product
The company itself describes its role as more than software provision. Itsabout pagelists hardware and software integration, outsourcing, consultancy, training, assistance, technical support and business continuity. The homepage claims a help desk for airport operators available 24/7. These are first-party service claims; no response-time history, restoration time or service credit accompanies them.
The architecture explains why services matter. Before an AODB can coordinate anything, people must agree on flight identifiers, timestamps, status codes, ownership and correction rights. Resource planners need local constraints, staff qualifications, labour rules and exception priorities. Passenger displays need layouts and device mappings. Retail connectors need product, store and transaction models. SOFA needs contracts, billing rules and accounting interfaces. Each is a configuration and governance project as much as a deployment.
Software Design's pages repeatedly expose this local work. ResourceBrain allows business users to configure airport rules after initial setup. ABI reports can be agreed and customised. CRM connections beyond the named platforms can be developed. Airport Traffic Manager accepts extensions for additional data sources. Product flexibility is precisely valuable because airports differ; that same flexibility means a buyer can accumulate a large volume of local logic that no replacement product understands on day one.
Implementation quality must therefore be judged through artefacts and rehearsals. The airport needs an interface register, data dictionary, responsibility matrix, configuration history, test cases, operating procedures, training records, a fallback plan and a known manual mode. It must be able to distinguish standard vendor code from airport-specific extensions and third-party components. If only the incumbent's engineers can explain why a movement update produces a particular allocation or invoice, the airport has bought operationally critical but institutionally fragile expertise.
Support also has a locality dimension. A Naples-based team with long experience of Italian airport operations may resolve an ENAC reporting issue or local airport process faster than a remote generalist. SITA ownership could add global escalation and adjacent specialists. Procurement should make both advantages concrete: named support tiers, language and time-zone coverage, on-site access, succession for critical skills, parent escalation and tested restoration obligations.
SITA control changes the integration bargain
SITA's stated acquisition rationale was compelling: airports struggled to integrate many systems and vendors, while Software Design had local airport expertise and a deep role at Naples. Integrating the integrator into a global aviation technology provider could combine product breadth with implementation knowledge and give the Neapolitan team access to new markets and investment.
The parent's current portfolio shows why the fit remains strategically important.SITA Operations at Airportsgroups airport management, passenger information and airside optimisation around shared real-time data and collaborative decisions. SITA states the offer has more than 150 deployments across airports, airlines, handlers and multi-airport environments. These are parent company claims, not Software Design deployments, but the functional overlap with AOSnice is clear: flight operations, fixed and mobile resources, collaborative decision-making and passenger information.
Ownership can improve the customer bargain in three ways. First, SITA can fund product renewal and security work that a smaller vendor would struggle to sustain. Second, a single group can accept responsibility across connectivity, airport operations, passenger processing and baggage interfaces rather than pointing to another vendor at each boundary. Third, SITA's distribution and support network can export expertise developed at Naples to airports beyond Italy.
The same structure creates three procurement risks. One is roadmap ambiguity. Public documents do not explain whether AOSnice is a continuing product family, an Italian delivery layer for SITA Airport Management, a source of components for new SITA products, or a legacy estate to be migrated over time. The live AOSnice catalogue and Palermo contracts show continuity, but not the long-term destination.
A second risk is reduced integrator neutrality. Software Design advertises connections to third-party and legacy systems, and the Siemens baggage integration at Palermo proves at least one such project. Yet a company controlled by SITA also has an incentive to favour group products where they compete with external alternatives. This is not proof of exclusionary behaviour; it is a predictable incentive that must be managed through interface commitments and objective support terms.
The third risk is group concentration. Buying multiple components from the same parent may simplify accountability, but a single commercial dispute, security event, strategic reprioritisation or support failure can then touch more of the airport. The right measure is not just the number of vendors. It is whether responsibilities are clear, failure domains remain separable, data is portable and the airport can replace one module without being forced to replace every dependent layer.
Failure travels along the same paths as data
The coordination layer can fail while every server stays powered. Useful resilience analysis starts with failure modes, not a generic uptime percentage.
Upstream data failure occurs when an airline, tower or network feed is late, duplicated, malformed or unavailable. Airport Traffic Manager may continue to serve the last known value. Key controls are freshness indicators, source priority, inconsistency alerts, manual correction and a clear distinction between "unchanged" and "not received".
Repository failure affects the AODB itself: loss of availability, corruption, slow queries or incomplete recovery. Because flights, resources, devices and users share the repository, the blast radius can span modules. High availability is useful, but recovery proof also requires a known recovery point, known recovery time, integrity checks and reconciliation of transactions accepted during degradation.
Event bus failure can be more silent. Messages may queue, arrive out of order, repeat or reach some subscribers but not others. The flight record may be correct while a display, staff device or billing process is stale. Monitoring must therefore cover end-to-end business events, not just bus process health. A synthetic test must be able to follow a controlled flight update through every subscribed system and confirm acknowledgement, latency and idempotent processing.
Configuration failure can be fully replicated and highly available. A wrong stand constraint, incorrect contract rule, excessive user permission or erroneous display mapping will produce reliably wrong output. Change approval, versioned configuration, peer review, simulation and fast rollback are resilience controls. So is preserving the rationale for a manual override rather than silently replacing the generated plan.
Dependency failure may start outside AOSnice. The Siemens baggage connection at Palermo is a concrete example: a change in either party's interface can break the workflow even if both products work independently. The same applies to departure control systems, CRM platforms, sensors, identity providers, network links and endpoints. Every interface needs an owner, supported versions, a test environment and behaviour under failure.
Field device or connectivity failure creates local divergence. ShopView states its tablet can retain transactions during a local network outage and transmit later. This design may preserve service, but delayed synchronisation must prevent duplicates and expose device status. Staff task devices, displays and cameras need equally explicit offline behaviour. "The central system is operational" does not help an operator whose only usable endpoint is not.
Human and organisational failure can be just as material. An operator may trust an optimisation result that violates a local rule, enter a correction under the wrong flight, or lose the trained employee who understands a custom connector. Training, role design, two-person approval for consequential changes and accessible procedures are part of system reliability.
Finally, recovery can create a second incident. Restoring a database without properly replaying queued events, reconnecting endpoints before identity services, or applying a delay when the operational situation has moved on can distribute stale instructions. The airport needs recovery sequences, data reconciliation and criteria for discarding or manually reviewing aged events. A platform that coordinates many domains must be tested as a dependency graph, not assigned a single undifferentiated availability number.
Security assurance is thinner than the operational claim
Software Design's public catalogue touches several sensitive surfaces: user access and operational data in the AODB; staff identities and schedules; camera feeds; passenger flow observations; boarding-card-linked retail transactions; CRM exports; billing and VAT records. The security question is therefore not whether the company mentions security, but whether assurance matches every installed module, data flow and responsibility.
The company'sIntegrated Management System pagestates that its risk-based approach is aligned with ISO 9001:2015, ISO 14001:2015 and ISO 27001:2022 and describes information security training and supplier expectations. This is positive policy evidence. The page examined does not itself provide certificate numbers, issuing bodies, validity periods, covered sites, statement of applicability or product scope. It should not be converted into an unconditional certification claim. A buyer must inspect current certificates and audit scope, then determine whether the development, hosting, support and relevant airport environment are included.
European rules place responsibility on the airport even when work is outsourced.Commission Regulation (EU) No 139/2014requires aerodrome operators to maintain management and safety systems, document key processes, control aeronautical data quality and integrity, and ensure that contracted services, equipment and systems comply with applicable requirements. A contracted organisation may work under the operator's approval and oversight. The vendor may provide controls and records; it does not absorb the airport operator's liability.
Cybersecurity obligations sharpen the vendor test. TheNIS2 Directiveexpressly includes airport managing bodies, airports and entities operating ancillary installations at airports. Its risk measures cover incident handling, business continuity and disaster recovery, supply chain security, secure acquisition and maintenance, access control, cryptography and multi-factor authentication. Its significant incident process includes an early warning within 24 hours and an incident notification within 72 hours. National scope and implementation determine the precise legal obligation, and Software Design is not automatically the regulated airport operator. Nevertheless, an airport cannot fulfil its own obligations if a central vendor withholds logs, dependency information or rapid incident facts.
The threat is not theoretical at the sector level.ENISA's Transport Threat Landscape, published in 2023, analysed attacks against aviation, maritime, rail and road organisations from January 2021 to October 2022. It supports treating transport vendors and connected operations as a real attack surface; it does not show that Software Design has been attacked.
No credible public document reviewed for this article established a specific outage, breach or cyber incident at the exact Neapolitan company. That is an evidence limitation, not proof of a clean incident history. The public pages also did not provide an availability register, public status history, vulnerability disclosure process, penetration test summary, software component inventory or recovery test result. Parent company incidents should not be silently attributed to the subsidiary, just as parent company scale should not be borrowed for it.
Procurement must close the gap with evidence: module-specific threat models, secure development and patch processes, component and subcontractor inventories, administrative access controls, logging and retention, independent testing, backup and restoration results, incident notification timelines, forensic cooperation, data deletion proof and exercises that include the airport's manual mode of operation.
Interoperability starts with meaning
Software Design states its service bus is multi-standard, can connect third-party systems and prevents each subsystem from maintaining many dedicated interfaces. These are useful design goals. The public product pages do not publish the event catalogue, API specifications, canonical data model, versioning policy or the customer's rights over connector code.
The sector context shows why these details matter.ACI World's Airport Data Dictionaryaims to create consistent airport terminology, complementing broader models such as AIDM and AIRM and reducing ambiguity across systems and organisations. TheEUROCONTROL A-CDM frameworkdepends on precise and timely exchange between parties, not merely an available network path.
Two systems may both support a standard message and still disagree on business meaning. They may use different flight segment identifiers, time zones, cancellation states, gate-change semantics or rules for codeshare flights. A connector may translate syntax while hiding loss of provenance or accuracy. Version changes can also create asymmetric behaviour: one subscriber understands a new event value while another silently maps it to "unknown".
A serious test of interoperability therefore uses real scenarios. The airport must trace a schedule creation, aircraft swap, delay, gate change, diversion, cancellation and recovery through the AODB and every relevant consumer. It must verify timestamps, source attribution, acknowledgements, duplicate handling, corrections and the audit trail. The same exercise must be repeated with a system unavailable and after an interface version upgrade.
Commercial interoperability matters as much as technical interoperability. The customer needs usable specifications, test environments, export rights and reasonable assistance for a third-party replacement. A proprietary bus may integrate competitors well during the contract yet still make exit expensive if only the incumbent can build or certify connectors. Acquisition by a vendor with its own adjacent products makes these rights more important, not less.
Alternatives split breadth and optimisation
Software Design competes with several purchasing strategies rather than a single identical rival. An airport can buy a broad operational suite, assemble best-of-breed modules around an independent integration layer, use a parent vendor stack or keep more integration capability in-house.
Amadeus offers the clearest broad-suite comparison. Itsairport operations portfoliolists an AODB, fixed-resource management, digital displays, airport billing, operational analytics, a virtual operations centre and connections. Amadeus presents the suite as cloud-based and integrated. These are first-party claims, but the functional overlap is direct: schedule planning, resource allocation, flight updates, contracts, billing and a shared operational view.
INFORM's GroundStar illustrates a more specialised alternative. Itsaviation ground operations documentationfocuses on fixed airport resources, ground staff and equipment, and aircraft turnaround. Theresource management pageemphasises constraint-based allocation of gates and stands, while itsturnaround producthomes in on bottlenecks, target off-block time and disruption decisions. A specialised optimiser may be stronger in a narrow scheduling problem but still requires an AODB, integration and passenger information layers from elsewhere.
SITA is both owner and adjacent alternative. Its current airport portfolio can potentially bundle operations, passenger information, airside optimisation, baggage, processing and communications under a single commercial group. This can be an advantage where the buyer values a single escalation path. It also makes it important to know which product is contracted from Software Design, which from another SITA entity, and how liability runs across the boundary.
The remaining substitute is architectural: keep an airport-owned data model and integration layer, then acquire modular applications. This can improve negotiating power and portability, but it shifts integration, security and 24/7 operational responsibility to the airport or another integrator. Open interfaces do not make this work free.
The decision should not be reduced to feature counts. Buyers must compare the quality of the common data model, recovery evidence, local airport expertise, configuration ownership, support depth, roadmap credibility and the cost of removing one module. Software Design's strongest argument is the combination of Italian operational knowledge and broad integration responsibility. Its weakest public proof is the absence of a current technical roadmap and a transparent assurance set commensurate with that responsibility.
Exit is a live operating programme
An airport cannot stop movements for a weekend to change the coordination layer. The exit problem is therefore a live transition across domains, not a final.
The first asset to recover is data: current and historical flights, schedules, resources, contracts, services, users, device mappings, passenger information configurations, planning scenarios, work records, billing entries, reports and audit logs. The customer needs schemas, identifiers, timestamps, provenance and correction history, not just flat tables. It must know which records are authoritative and which were derived.
The second asset is behaviour. Allocation constraints, staff qualifications, shift rules, service definitions, message transformations, conflict resolution, display layouts, billing formulas, access roles and alarm thresholds may embody years of operational decisions. If these rules are stored in proprietary configuration, the airport needs a readable export and documentation. If they are embedded in custom code, it needs licence and transition rights or sufficient time to rebuild them.
The third asset is the interface estate. Every airline feed, tower connection, baggage system, CRM, sensor, identity service, screen, mobile endpoint and financial application must be inventoried with owner, version, data contract, certificates, network route and test case. A replacement AODB that holds the correct flights but cannot drive the installed displays or reconcile baggage events is not ready.
Migration must proceed in controlled slices. A new platform may first ingest a copy of live feeds, then reproduce views without issuing instructions, then run calculations in parallel, and finally become authoritative for one domain at a time. Results must be reconciled with the incumbent, with tolerances and responsible decisions for differences. A rollback must be possible before each authority transfer. Manual operations must be rehearsed for the period when neither system has full control.
The contract must make this practical before termination becomes contentious. It must specify export formats and frequency, ownership of configuration and custom code, API and connector documentation rights, perpetual licence use during transition, ongoing security support, assistance rates, key personnel access, deletion schedule, audit retention and the right to periodically test an exit. Source code escrow may be appropriate for irreplaceable custom components, but escrow without build instructions, dependencies and qualified personnel can be false comfort.
SITA control adds a specific question: can an airport replace a Software Design module with a third-party product while retaining other SITA services on equal terms? The answer must lie in interface and support commitments. Otherwise, AOSnice's theoretical modularity may not translate into commercial modularity.
The switching cost is not inherently abusive. Long-lived airport systems must preserve history, encode local rules and train users; those investments create value. The procurement aim is to distinguish value-creating embedded knowledge from avoidable captivity. A buyer must be able to leave at known cost and risk even if it reasonably chooses not to.
Twelve acceptance tests for the coordination layer
A credible procurement can turn the gaps in public evidence into measurable conditions.
Fix the contractual boundary.Name Software Design srl by VAT and registry details, identify every SITA or third-party entity performing development, hosting, support or data processing, and specify which obligations carry a parental guarantee. Confirm rights to licence all standard and custom components for contract duration and transition.
Map products to supported versions.Require a list of installed modules covering AOSnice core, AODB, service bus, flight management, resources, displays, passenger, retail, security, BI and financial components as applicable. For each, record the version, deployment model, dependencies, end-of-support date, patch cadence and successor. Reconcile this with SITA's roadmap and prohibit forced migration during the agreed support period.
Establish data authority.Create a field-level matrix for schedules, movement times, stands, gates, loads, staff, tasks, passenger messages, transactions and invoices. State the authoritative source, accepted fallbacks, freshness threshold, correction right and audit requirement. Test conflicting and late sources rather than only the happy path.
Prove interface behaviour.Inventory every feed and consumer, including airline systems, tower data, baggage, CRM, sensors, identity, finance, displays and mobile endpoints. Provide schemas, version rules and test environments. Demonstrate handling of duplicate, out-of-order, malformed and missing messages, and end-to-end monitoring from source to final screen or transaction.
Calibrate the day of operations.Test seasonal load, peak movements, mass gate changes and disrupted flights using the airport's own traffic shape. Measure data age, event latency, planning time, display propagation and operator response time, not just server throughput. Define degradation thresholds and show how non-critical analytics or channels can be isolated to protect core operations.
Exercise resilience and manual control.Fail a feed, a service bus node, a database component, a network link, an identity service and a representative field device. Restore from backup and reconcile queued events. Demonstrate manual flight updates, resource allocation and passenger messaging with clear authority, then return to automation without duplicate actions or lost history. Contract for recovery point and recovery time objectives per service domain.
Validate security and change governance.Trace consequential configuration changes from request through simulation, approval, release and rollback. Confirm that safety and labour constraints cannot be carelessly overridden, that exception overrides are attributed and reviewed, and that contracted activities produce the records the aerodrome operator needs for regulatory oversight.
Inspect security evidence.Obtain current certification documents and scope, independent test results, secure development controls, component inventories, vulnerability and patch schedules, privileged access design, multi-factor coverage, logging, key management, backup separation and vendor dependencies. Conduct a joint incident exercise that can meet the airport's 24-hour and 72-hour reporting decision facts.
Separate privacy roles by module.For staff scheduling, cameras, passenger flow, boarding-card-linked retail, loyalty, CRM and billing, document the purpose, controller and processor roles, legal basis, fields, retention, location, sub-processors, access and deletion. Test offline devices and delayed synchronisation. Avoid a broad "airport data" clause covering materially different uses.
Price the complete operational unit.Separate platform, module, endpoint, environment, interface, implementation, customisation, training, 24/7 support, upgrade, third-party licence and exit fees. Model volume and airport changes rather than rely on an introductory licence price. Define which interfaces and updates are included and how migration to parent products would be priced.
Test support as a system.Use incidents that cross vendor boundaries and observe triage, ownership, escalation and communication. Record response, diagnosis, workaround and restoration separately. Identify key personnel concentration, on-site access, Italian language coverage and the Naples team's path into SITA's wider organisation.
Rehearse partial and full exit.Export data and configuration during the contract, rebuild a representative connector from supplied documentation, and run a mirror consumer against equivalent live events. Confirm that one module can be replaced without degrading retained services. Price and time a full dual-run, including ongoing licences, security patches, staff assistance and verified deletion after cut-over.
These tests do not presume Software Design will fail. They recognise that the company asks to occupy a position where an unsubstantiated claim or ambiguous responsibility can matter across an entire airport. The more processes the integration layer coordinates, the more precise acceptance must become.
The missing evidence is itself a roadmap
Several important facts remain publicly unresolved. Software Design does not publish independently audited revenue, profitability, customer concentration or research and development spending. The current site establishes direction and coordination by SITA BV, but not the full ownership chain nor the financial support available to the subsidiary. Air Tech Italy provides a broad airport list, but the actual contract scope and outcomes are only independently visible in fragments.
Technical gaps are equally material. The public pages do not identify AOSnice's current version, programming stack, database technology, hosting architecture, supported operating systems, standard API catalogue, release cadence or end-of-life policy. Some channel and device language appears dated while Palermo was buying NewGen display licences in 2024. This could reflect a durable platform with updated components, a stale public copy, or both. Only a version-specific bill of materials and roadmap can decide.
Security disclosure stops at policy statements. No public document examined here provided certificate and scope details, vulnerability disclosures, independent assessment results, availability history, recovery outcomes or an incident timeline for Software Design. Commercial disclosure does not reveal standard service levels, credits, data exit terms, subprocessors or termination assistance. The absence of these documents online does not prove they are unavailable to customers; it means procurement must not assume their content.
The most consequential strategic gap is the relationship between AOSnice and current SITA Airport Management and Airside Optimizer products. Palermo's renewals and the live Software Design catalogue show that AOSnice has not simply disappeared. SITA's newer, cloud-native, modular positioning shows a parallel direction. Buyers must monitor product name changes, shared release notes, migrations, bundle contracts, personnel moves and any change in the legal entity delivering support.
Other monitoring points are observable. Future Italian airport contract registers may show whether annual platform awards continue, expand or move to another SITA product. Updated certificate pages could clarify assurance scope. A public supported-version matrix would resolve lifecycle concerns. New independent customer awards, losses, outages or post-incident reports would improve the sparse performance record. A documented data model and interface programme would make the claimed openness more testable.
The conclusion is not that integration must be avoided. Airports need a shared operational dashboard, and Software Design's long presence at Naples, documented work at Palermo and unusually broad module set give it a credible claim to understand the work between systems. The conclusion is that the shared version of now must remain governable.
SITA's acquisition did not erase the Neapolitan company; current disclosures show the subsidiary and its product legacy continuing under parent direction. It changed who benefits from architectural consolidation and who controls the roadmap. An airport should welcome the ability to put more responsibility in one place only when it can also locate the evidence, accountability and an exit path there.
The best measure of Software Design srl is therefore not the number of modules in AOSnice. It is whether an airport can trust a changed flight to reach every appropriate person and system, understand why each downstream decision followed, recover when the chain breaks and replace part of that chain without losing control of the operation. That is the difference between an integration platform and an indispensable but ungoverned intermediary.