Interface Analysis
Interface analysis (BABOK 10.24) catalogues the points where a solution exchanges information with what surrounds it, and sets the terms of each exchange. BABOK gives the word interface a wide reach: a screen used by an employee, an authority receiving a mandatory return, a business process handing over to another, a data flow between two systems, an API and a device are all interfaces in the sense of the technique. Its product is a boundary contract: what crosses, in which direction, in what format, at what frequency, in what volume, on what trigger, under which validation rules, with what behaviour on failure and under whose responsibility on each side. An interface nobody identified is a feature nobody built, and it surfaces at integration, at the moment it costs the most.
Purpose
The technique serves three decisions, and they arrive in that order. It first secures functional coverage: BABOK makes this its first strength, an interface analysis run early raises requirements coverage, because every forgotten exchange is a feature missing from the scope and from the estimate. It then enables allocation: once the boundary is specified, you know which side carries which rule. Validating an AVS number is somebody's work, and the specification is where that somebody is named. It finally directs elicitation: the list of interfaces names the counterparties, therefore the stakeholders, therefore the people to bring together for the rest of the requirements work. It is on that count that the technique belongs to elicitation as much as to requirements analysis.
The deliverable is twofold. The interface catalogue is the inventory: one line per interface, with its counterparty, its direction, its type, its format, its frequency, its volume and its owner. The interface specification is the contract: for each interface that deserves one, the field-by-field definition of the message, the validation rules, the transformation, the triggers including the failure triggers, the error behaviour, the service level, security and the version in force. Systems engineering calls this second document an Interface Control Document, and NASA's systems engineering handbook fixes its family (interface requirements document, interface control document, interface description document). ISO/IEC/IEEE 29148:2018 carries external interface requirements inside the system requirements specification. On a project run under HERMES, the Swiss Confederation's project management method, that inventory is prescribed: the integration objects and interfaces form one of the nine rubrics of the integration concept, alongside the system overview, the integration environments and steps, the risks and quality assurance.
Usage
When to use it
- Solution boundary freshly drawn: every crossing of the scope line is an interface to specify and to cost.
- Package or SaaS under selection: the interfaces to the existing application landscape carry most of the integration cost.
- Legacy system replacement: its interfaces are the inventory of what the successor must still satisfy.
- Exchange imposed by a standard: ELM, ISO 20022, eCH, the contract comes from outside and the work is to read it.
- Costing an integration: volume and frequency per interface turn a list into an amount.
- Planning the elicitation: the list of interfaces names the counterparties to bring into the room.
- Handover between two units or two companies: this is where responsibility gets lost.
- Business case to evidence: the real usage and the incidents of current interfaces are quantified proof.
When not to use it
- Internal behaviour of a component: BABOK's own limitation, reach for business rules analysis or a data model.
- Scope still open: specifying the crossings of an unagreed line produces a disposable catalogue, frame first with scope modelling (BABOK 10.41).
- Message ordering in question: the sequence diagram (BABOK 10.42) says in which order, which the specification ignores.
The six interface types
BABOK lists six types, and this list is the point practitioners miss most often, because they hear interface and think API. User interfaces are the screens through which people in the organisation interact directly with the solution. People external to the solution are the stakeholders, the regulators and the authorities that receive or supply information: in Switzerland, an AVS compensation fund, a cantonal tax administration and a statistical office collecting a mandatory return are interfaces in full, with a format, a deadline and a failure mode. Business processes form an interface when one process hands information to another, including inside the same company. Data interfaces between systems are the classic exchanges, nightly batch, replication, message queue. Application programming interfaces, APIs, are the published interface of a callable component. Devices are the hardware interfaces, badge reader, payment terminal, shop-floor sensor.
That reach anchors the technique in business analysis, and BABOK draws a strength from it: its broad application spares it the over-analysis of fine detail. The two types nobody catalogues are the public authority and the handover between processes. The integration architect will not find them, because they appear in no technical configuration.
HERMES deals with the interfaces between a temporary project organisation and the core organisation that hosts it (Stammorganisation): the method guarantees the compatibility of these standardised interfaces, reporting for instance. It names the three roles indispensable to their functioning: the project sponsor, the project manager and the user representative. What crosses that boundary is named: project status report, phase report, release report. This handover falls under the business process type and is catalogued like the others, with its sender, its recipient, its frequency, its content and its deadline.
The material interface
A device exchanges matter and energy as much as messages, and its specification carries rubrics no file exchange knows. Form comes first: the geometry, the footprint, the connector, the fixing, the orientation, everything that decides whether the two parts go together. Service tolerance is the non-functional requirement of the physical world: the temperature range, the mechanical resistance to shock and vibration, the chemical resistance to cleaning agents, the sealing against dust and water. The medium qualifies what physically crosses the boundary: a gas, a liquid, a part, at what pressure and what flow rate. Energy is an input in its own right: the voltage, the current, the power, the earthing and the question of which of the two sides feeds the other.
Communication then unfolds into three storeys that are routinely conflated. The physical link and the encoding: the twisted pair, the 4-20 mA current loop, the fieldbus and the way the bits are carried on the signal, an NRZ coding, a Manchester coding. The protocol: the frame, the addressing, the error checking, the pacing of the exchanges, Modbus RTU, CAN, OPC UA. The semantics: what the value means. A temperature sensor in a pasteurisation vat returns the integer 3820 in a Modbus register, the protocol is honoured and nothing is specified yet, because 3820 is 38.2 °C under a scale factor of 0.01 and a reading in degrees Celsius, but something else entirely under another convention. A conforming protocol and an assumed semantics produce a correct value that is read wrong. The specification is where the unit, the scale factor, the valid range and the agreed value for a faulty sensor get written down.
Identifying the interfaces
Preparation consists in gathering what already exists. BABOK names document analysis, observation, interviews, scope modelling and above all the context diagram, which reveals the high-level interfaces between human actors, organisational units, business processes and solution components. On an existing application landscape, the most reliable material sits in the running system: the integration code, the batch schedules, the message bus topics, the firewall rules and the file drop directories are the interfaces the documentation forgot. BABOK notes a second benefit of this work, often overlooked: it surfaces the real usage frequency of existing interfaces and their defects, material that strengthens the business case.
Identification proper walks through every stakeholder and every system that interacts with the solution, and lists the interfaces required for the future state. The relationship between a stakeholder and their interfaces can be many-to-many and in some cases one-to-one. BABOK insists on the non-obvious interfaces, the ones serving a regulatory function, an audit or staff training. For each one, four questions: describe its function, assess its usage frequency, determine the appropriate interface type and elicit the first details.
Six questions structure the whole, and BABOK poses them as such: who will use the interface, what crosses and in what volume, when and at what frequency, where the exchange takes place, why the interface exists, how it is or should be realised. The product of this step is an interface map, the solution at the centre, its counterparties around it, one labelled arrow per interface.
Specifying an interface
BABOK gives five definition items: the interface's name, its scope, the exchange method between the two entities, the message format and the exchange frequency. To these it adds the inputs and outputs, the validation rules governing them and the triggering events, specifying that these events cover the nominal flow, the alternative flows and the failures. That last mention is the one that gets forgotten. It is the hinge between a list and a contract.
The template is filled rubric by rubric, and each rubric answers a question that, left empty, will become an incident.
| Rubric | The question it settles |
|---|---|
| Any interface | |
| Parties and direction | Who sends, who receives and is the exchange one-way, request-response or bidirectional? |
| Trigger | What sets the exchange off: a clock, a business event, a demand? The alternative flows and the failures have one too. |
| Data exchanged | Which fields, of which type, mandatory or optional, with which code lists? This is the point where the specification hands over to the data dictionary (BABOK 10.12): the interface names the message, the dictionary defines each of its fields. |
| Method and format | Through which channel and in which shape: XML over a web service, JSON over REST, signed file dropped on SFTP, ISO 20022 pain.001 message, barcode printed on paper. |
| Frequency and volume | How many messages, at the peak? Volumetry is what turns an interface into a cost and into a non-functional requirement. |
| Validation rules | What does the receiver reject and on what criterion? In Switzerland it is often an imposed format whose check digit is verifiable without calling anyone, such as the thirteen-digit AVS number, 756.XXXX.XXXX.XX. |
| Transformation | Which side maps the two representations onto each other, and what becomes of a value the target's code list cannot express: rejection, default value or silent loss? The third case is the most frequent and the only one that raises no error. |
| Error behaviour | Malformed message, unavailable receiver, half-processed batch: is there a negative acknowledgement, is a resend idempotent, who is alerted and within what delay? Over HTTP, RFC 9457 gives the canonical format. |
| Ownership | Who, by name and on each side, can commit to a change? |
| Service level | What availability, what latency, what throughput, what retention and past what delay does a late file become a compliance problem? |
| Security and data protection | What crosses? AVS numbers and salaries are personal data within the meaning of the revFADP, a property of the interface. |
| Version | Which version of the contract governs, through which channel is a change announced and how long does the old version stay accepted in parallel? |
| In addition, for a human interface | |
| Roles and privileges | Who sees which data, who can change it, who may only consult it and by which mechanism is that right granted and then withdrawn? |
| User workflow between systems | What does the person who leaves one system in the middle of a task to finish it in another carry by hand? That manual leg is the part of the interface nobody specifies. |
| Management objectives | Which measure will say the interface works: a processing delay, a data-entry error rate, a support load? |
| Usability and accessibility | Which of the organisation's guidelines bind the design, as inputs? |
| In addition, for a material interface | |
| Form and mounting | Which geometry, which footprint, which connector, which fixing, in which orientation? |
| Service tolerance | Which temperature range, which mechanical and chemical resistance, which sealing? |
| Medium and energy | Which gas, which liquid, at what pressure and what flow rate? What voltage, what current and which side feeds the other? |
| Physical link, encoding and protocol | Which physical link, which signal coding (NRZ, Manchester), which frame and which protocol (Modbus RTU, CAN, OPC UA)? |
| Semantics of the signal | What does the value mean: which unit, which scale factor, which valid range and which agreed value for a faulty sensor? |
BABOK is explicit about the timing of human interfaces: they require detailed analysis conducted upfront, because that is where the major design defects are decided and where they then become expensive to unwind. A catalogue whose template can only fill the common rubrics types its screens as user interfaces, then leaves them empty.
The last step is to validate the catalogue with the owners at each end. An interface specification signed on one side only remains a wish.
The boundary with neighbouring techniques
The data flow diagram (BABOK 10.13) shows the data moving through processes: where it comes from, what transforms it, where it rests, where it ends up. Interface analysis specifies the contract at a boundary between two systems or two organisations. The context diagram enumerates the crossings, interface analysis specifies each of them, and the handover is explicit in BABOK, which places the context diagram among the inputs to preparation. Two asymmetries finish separating the two techniques: interface analysis also covers user interfaces, authorities and devices, which a data flow diagram treats as plain external entities; and a data flow diagram says nothing of frequency, volume, error behaviour, ownership or service level, which are the whole substance of an interface specification.
Scope modelling (BABOK 10.41) draws the line and places elements inside or outside. Interface analysis specifies each crossing once the line is drawn. The dependency runs one way, and launching the analysis before the scope is agreed produces a catalogue that will be thrown away.
The sequence diagram (BABOK 10.42) models the logic of a usage scenario by showing the information exchanged between objects, with lifelines and ordered messages. The difference is temporal: the sequence diagram shows the order of messages within a scenario, the interface specification shows the permanent terms of an interface, independently of any scenario. The two compose: once the interface is specified as request-response with a negative acknowledgement, the sequence diagram is the support for showing the choreography of a failed call and its recovery.
The interface as a source of data
IIBA's Guide to Business Data Analytics (§3.13) turns the technique around: an interface produces usable data of its own. Alongside what the user enters, the system records what the user does, and that transactional data answers questions the entered data does not cover. Which features are actually used. Why a request is left unfinished. How long an operation takes end to end. Where login failures or loading times concentrate.
The guide draws a second consequence for the specification: every interface element corresponds to a database attribute, and writing that correspondence down exposes the implicit retention rules. Does a profile update overwrite the record or create a new one that the most recent identifier designates? The two look alike on screen and behave differently in a report. The documented correspondence is what the extract and load routines then pick up.
The pitfalls
The interface nobody owns
Each side assumes the other validates, retries or monitors. The defect only shows in production and its correction is organisational. The catalogue column that avoids it is a named owner on each side: a person's name and their role. When the counterparty is a supplier with no designated contact, the exit is contractual escalation.
The undocumented field that carries meaning
A free-text reference zone in which somebody, years ago, started writing a code that a downstream process depends on today. It appears in no schema and in no dictionary, and it breaks the day the field is cleaned up. Interfaces accumulate these stowaways. That is the reason to specify field by field.
The batch that silently loses records
The receiver loads the file record by record and discards the ones it cannot read. On a batch of 4'812 records, 4'796 are loaded and 16 are discarded, no error reaches the sender, nobody counts. The specification's answer is a reconciliation contract: the sender announces the number sent, the receiver acknowledges the number loaded, a discrepancy is an incident. An interface with no acknowledgement leaves its error behaviour to hope.
The other side's assumed error behaviour
With the reconciliation contract in place, the receiver now reports its 16 rejections, and the defect moves one notch. The sender's recovery was built assuming that the receiver rejects the whole file as soon as one record is malformed: it therefore resends the whole file after correction and duplicates the 4'796 records already loaded. The receiver accepts record by record, the sender assumed the opposite and neither behaviour was ever written down. Whole-file rejection or partial acceptance is a decision, and the effect of a resend, replacement or duplicate, is another: both belong to the specification.
Volumetry left empty
The interface is identified, named, typed, and nobody asked how many. Sizing, the service level and the estimate then rest on an intuition.
Contract drift
The other side changes the contract and you find out at a rejection. The Swiss example is dated and public: the QR-bill implementation guidelines moved to version 2.3 on 21 November 2025, which requires structured addresses in the Swiss QR Code and no longer admits the combined form, with version 2.4 taking effect on 14 November 2026. Any billing system that treated the address as free text had an externally imposed interface change, on a known date, to absorb. A specification with no version and no announcement channel is a snapshot.
The format specified, the meaning assumed
Two systems agree that a field is a thirteen-digit string and diverge on what it identifies. Agreement on the format leaves the semantic agreement to be made, and that one lives in the code lists, in the transformation's mapping table and in the data dictionary's definitions.
The catalogue reduced to technical interfaces
BABOK's six types include user interfaces, people external to the solution including public authorities and business processes. The regulatory return and the handover between two departments have a format, a deadline and a failure mode, exactly like a web service.
AI considerations
The best use is the derivation of a candidate catalogue from what actually runs. Point a model at OpenAPI, WSDL or XSD schemas, at the integration code, at the ETL job definitions, at the message bus configuration and at the firewall rules, then have it extract a first pass into the columns already set. On a legacy landscape nobody has documented for ten years, this replaces the blank page with a draft to refute, and the refutation is run against the running system.
Two other uses are solid. Schema diffing and impact analysis: two versions of an XSD or of an OpenAPI document and the question of which of the fields actually used have changed. The task is mechanical, exhaustive and exactly the kind of vigilance human review loses at the four-hundredth element; it turns a supplier release note into a work list. The generation of sample payloads and negative test cases from a schema: malformed message, boundary value, missing mandatory field, code outside the list. Failure paths are the least tested and the most specified part of an interface, and generating them from the contract costs little. The error behaviour matrix is pre-drafted the same way from the status codes and the error model an API declares.
Three limits rest on judgement and on the law. Volumetry, frequency, ownership and service level appear in no schema: they are properties of the organisation, so a model asked for them will produce a plausible number. A fabricated volume is worse than an empty cell, because you will size on it. The semantics of a code list come from the two owners: a model will say a field enumerates eleven values, only the business will say which ones are still in use, which one is systematically misused and what each translates into in the target's list. Data protection, finally: an ELM message carries AVS numbers, salaries and the employer's UID number, therefore personal data within the meaning of the revFADP. The work is done on the schema and on synthetic payloads. A production extract pasted into a general-purpose model is ruled out.
Examples
The landscape chosen is the payroll interfaces of a Swiss SME of 120 employees, around the payroll system. Of those 120 employees, 34 are taxed at source (B permit holders and cross-border commuters), and accounting splits the wage bill across four cost centres: those two numbers, together with the headcount, are the only inputs on which every volume in the catalogue depends. The landscape carries eight interfaces, five of BABOK's six types, five formats and four rhythms (event-driven, monthly, annual, every two years), and it brings the public authority and the handover between processes into view as ordinary counterparties.
The map carries each flow's contract in three signs: the direction, the format, the rhythm. The catalogue unfolds the same eight interfaces into columns and adds what the map cannot carry, the volume and the owner at each end.
| Id | Interface | Direction | Counterparty | Type (BABOK) | Method and format | Trigger and frequency | Volume (peak) | Owners (sender / receiver) |
|---|---|---|---|---|---|---|---|---|
| IF-01 | ELM salary declaration | outbound | AVS compensation fund | Person external (authority) | XML Lohnstandard-CH, web service (PIV procedure) | Annual payroll close, 1 submission a year | 120 records, one per employee | Payroll manager / the fund's technical contact |
| IF-02 | Tax-at-source return | outbound | Cantonal tax administration | Person external (authority) | XML Lohnstandard-CH | Monthly statement approval, 12 submissions a year | 34 records, the 34 employees taxed at source out of 120 | Payroll manager / cantonal tax-at-source office |
| IF-03 | LAA wage-bill declaration | outbound | Accident insurer | Person external (insurer) | XML Lohnstandard-CH | Annual close, 1 submission a year | 120 records | Payroll manager / policy administrator |
| IF-04 | Swiss earnings structure survey (ESS) | outbound | Federal Statistical Office | Person external (authority) | XML Lohnstandard-CH | Federal survey, 1 submission every two years | 120 records | Payroll manager / the survey office |
| IF-05 | Salary payment order | outbound | Bank | Data between systems | ISO 20022 pain.001, e-banking upload | Payroll approval, 13 runs a year: the 13th month salary goes out as a separate run in December | 120 transactions per run; peak of 240 transactions in December, which carries two runs | Payroll manager / the bank's e-banking support |
| IF-06 | Personnel data | inbound | HR system | API | JSON over REST, synchronous call | Event-driven (hire, change, departure), about 8 a month | 1 record per event | HR manager / payroll manager |
| IF-07 | Salary certificate | outbound | Employee | User interface | PDF, employee portal | After annual close, 1 per employee | 120 documents | Payroll manager / employee |
| IF-08 | Payroll accounting entry | outbound | Accounting (the accounting process) | Business process | CSV file of summary entries, dropped on a shared directory | Payroll approval, 12 submissions a year: the 13th month salary is booked in the December period | 4 summary entries per submission, one per cost centre | Payroll manager / accountant |
The catalogue stops where the contract begins. The specification unfolds a single line, IF-01, and the rubrics that set it apart from the catalogue are the most painful to fill: the error behaviour, the owner who can commit their side, the service level and the version.
| Rubric | IF-01, ELM salary declaration |
|---|---|
| Scope | Annual wage bill of all employees subject to AVS, for one financial year. |
| Parties and direction | Payroll software (sender) to the AVS compensation fund (receiver). Outbound, with a response: acknowledgement and processing report. |
| Exchange method | Web service, PIV procedure of the Swissdec standard. Fallback provided: EIV procedure (export a file, upload it manually to the recipient's portal) if the web service is unavailable at the deadline. |
| Message format | XML conforming to the Lohnstandard-CH declaration. The software is Swissdec-certified for the version of the standard in force at the time of submission. |
| Pivot fields | The employee's AVS number, 13 digits, 756.XXXX.XXXX.XX. The employer's UID number, CHE-NNN.NNN.NNN. Accounting period, amounts subject to contribution by category. |
| Validation rules | Check digit of the AVS number and of the UID number verified before submission. The AVS number is not generated: it is assigned by the Central Compensation Office, and an employee without a number blocks the line. |
| Transformation and mapping | The software's wage types are mapped to the standard's rubrics, on the sender's side, before submission. Decided by the project: an internal wage type with no counterpart in the standard blocks the submission and escalates to the payroll manager. |
| Trigger | Annual payroll close. Secondary trigger: resubmission of a corrected record after a rejection. |
| Frequency and volume | 1 submission a year, 120 records, one per employee. No peak. |
| Error behaviour | Imposed by the standard and to be read in the Swissdec documentation: the granularity of a rejection, the content of the processing report returned by the fund and the effect of a resubmission after correction (replacement of the record or duplicate). The specification copies them out. Decided by the project: the reconciliation contract, the sender matches the number of records sent against the number acknowledged and treats any discrepancy as an incident; and the escalation, a rejection unhandled after 5 working days goes up to the payroll manager. |
| Owners | Sender: the payroll manager, by name. Receiver: the technical contact designated in the affiliation contract with the fund. Each can commit to a change on their side. |
| Service level | Imposed by law: the declaration is due on a fixed date, and overrunning it is a compliance problem with regulatory consequences. Decided by the project: the submission is prepared and checked at the latest five working days before the deadline. |
| Security and data protection | The message carries AVS numbers and salaries, therefore personal data within the meaning of the revFADP. Encrypted transport, access restricted to the two named roles, no production extract outside the perimeter. |
| Version and change | The version of the standard the software is certified for. Announcement channel: Swissdec's publications. To be established at each version step: how long the old version stays accepted in parallel. |
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | Gathering the existing material (context diagram, integration inventory, evidence drawn from the running system) is bounded. Finding, on the other side, a person who can commit their part is what costs time. |
| Execution | Medium | Identification is quick and fits in a workshop when a context diagram exists. Characterising each interface (volume, transformation, error behaviour, service level, owner) depends on the counterparty, and the technique's duration follows their availability. |
| Documentation | High | The specification is the contract: it is versioned and kept current at every change on either side. This item decides whether the technique survives over time. It is also the first one abandoned. A specification that has drifted from the real interface is harmful, because people trust it. |
Tools
The spreadsheet or the wiki table is the catalogue's honest home when the landscape is small, where most real catalogues live. Requirements management tools (Jama, Polarion, DOORS) take over when the specification carries contractual weight and the interfaces have to be traced through to requirements and tests.
The contract formats are the specification in machine-readable form, and adopting them is the only known way to stop the specification drifting from the build: OpenAPI for REST APIs over HTTP, AsyncAPI for event and message exchanges, WSDL and XSD for SOAP (which Swissdec's PIV procedure uses) and JSON Schema for payload validation. Contract tests (Pact) and API clients (Postman, SoapUI) make the specification executable: the integration pipeline then catches drift before release. API gateways and developer portals are where the catalogue and the contract are published on the consumer side.
For the map, a modelling tool is enough: an ArchiMate application cooperation view or a C4 container diagram sit at the altitude of the interface map. That leaves the standards' own documentation, which for a Swiss interface is often the specification you are not allowed to write: Swissdec for ELM, SIX for the Swiss Payment Standards, the IBAN and the QR-bill, eCH for e-government exchanges, the Forum Datenaustausch for invoicing between healthcare providers and insurers. Reading the imposed contract is the work.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.24 Interface Analysis: the definition, the six interface types, the technique's three elements, its strengths and its limitation.
- ISO/IEC/IEEE 29148:2018, Systems and software engineering, Life cycle processes, Requirements engineering: the standard that carries external interface requirements inside the system requirements specification.
- NASA Systems Engineering Handbook, §6.3 Interface Management: the family of interface documents (IRD, ICD, IDD).
- OpenAPI Specification, OpenAPI Initiative: the HTTP interface contract in machine-readable form.
- AsyncAPI Specification, AsyncAPI Initiative: the same contract for event and message exchanges.
- RFC 9457, Problem Details for HTTP APIs, IETF: a canonical convention for error behaviour at an HTTP interface.
- Swissdec, Lohnstandard-CH (ELM): the Swiss salary declaration standard, the distinction between declaration and procedure, the PIV and EIV procedures, the certification of software.
- ISO 20022: the financial messaging standard behind the Swiss Payment Standards and the
pain.001message. - SIX, QR-bill and Swiss Payment Standards: the implementation guidelines and their versioning, including the move to structured addresses.
- SIX, IBAN: the Swiss IBAN standard and the IID bank identifier, held by SIX.
- Federal Statistical Office, Enterprise identification number (UID): the
CHE-NNN.NNN.NNNformat and its check digit. - Federal Statistical Office, Swiss earnings structure survey (ESS): the federal survey conducted every two years, which the ELM statistics domain feeds.
- OFAS, Les éléments qui composent le numéro d'assuré AVS: the
756.XXXX.XXXX.XXformat, its 13 digits and its check digit. - Federal Act on Data Protection (revised FADP), SR 235.1: the regime applying to the personal data a payroll interface carries, in force since 1 September 2023.
- eCH: the e-government exchange standards of Switzerland.
- Forum Datenaustausch, XML standards: the exchange standards for invoicing between healthcare providers and insurers.
- IIBA, Guide to Business Data Analytics, §3.13 Interface Analysis: the interface as a producer of transactional data and the correspondence between interface elements and database attributes.
- Swiss Confederation, Federal Chancellery, HERMES 2022, Project Management Reference Manual, outcome 4.4.1.18 Integration concept: the integration objects and interfaces as a required rubric of the document that describes the integration of the system into its environment.
- HERMES 2022, Project Management Reference Manual, Swiss Confederation, Federal Chancellery, §A.5 The interfaces of HERMES project management: the interface in the organisational sense, the guaranteed compatibility between the project organisation and the core organisation (Stammorganisation), reporting as the example and the three roles indispensable to the functioning of the interfaces.