7 Must Ask Questions About Every Interface Idea

1. What benefit do you hope to achieve by building this interface?

Since the client has an idea for an interface, they most likely know what benefits they hope to achieve.

It is important that those benefits are understood by everybody and are used throughout the design process to ensure that as the interface design evolves, it is still realizing those benefits.

A follow up question that should be asked is, “Is an interface the best way to achieve that benefit?” Sometimes, the desired benefit can be achieved without the cost and effort of building an interface.

Some common examples of interface benefits include:

• Save time by eliminating the double entry of transactions
• Make data available in multiple systems
• Speed transaction processing times
• Reduce manual entry

2. Which system is the data producer and which is the data consumer?

It is important to establish the direction the data is flowing. For a data producer, the data is flowing outbound, they are the “from” system. For a data consumer, the data is flowing inbound, they are the “to” system.

If the answer is both systems are data producers and data consumers, you are probably describing more than one interface. Break them down further if possible. If a data object is truly flowing both directions then treat each direction as a separate interface.

For example, System A creates invoices that are sent to System B. System B updates the invoices and sends the updates back to System A. These are two interfaces:

• System A is the data producer and System B is the data consumer in the first interface (invoices being created)
• System B is the data producer and System A is the data consumer in the second interface (invoices being updated)

3. What are the triggering events?

A triggering event is what flags a record as needing to be interfaced. This is usually something that happens in the data producer, but can also be triggered by the data consumer as well.

Knowing the triggering events in the ideation phase helps to flesh out the magnitude of the interface. There is a big difference between having one triggering event to initially send a transaction and having two (or more) triggering events, one to send over a transaction the first time and one to send updates to the transaction. The latter will require much more effort in the design, build, and testing phases of the interface creation process.

Some examples of triggering events include:

• A customer record is created
• An invoice is signed by the customer
• A payment is received
• A customer contact is updated

4. What type of data is being interfaced?

I am treading into the hotly debated topic of classifying data. However, I feel it is important to understand a few basic things about the type of data in your interface during the ideation phase. Admittedly, it’s an oversimplification but I am going describe two types of data typical in OLTP business systems, master data and transactional data.

Transactional data typically has shorter lifecycles and relates to specific business transactions.

Examples of transactional data include:

• Customer Invoices
• Purchase Orders
• Sales Orders
• Inventory Receipts

Master data is data with longer lifecycles that is used by other transactions.

Examples of master data include:

• Customers
• Suppliers
• Inventory Item Master

5. Is there any dependent data between the two systems?

This question is the one most likely to kill your interface idea, not because it is a bad idea, but because there are other dependencies that need to be worked out before it is feasible to build your interface. Usually, this results in additional interface needs being identified as prerequisites or a mapping needing to be created to translate the data between systems.

Some example of dependent data:

• A customer invoice interface requires a customer. The data producing and data consuming systems must share the same customer master or a mapping must be created to translate the data.
• A purchase order requires inventory items. The data producing and data consuming systems must share the same item master or a mapping must be created to translate the data.
• A vendor invoice interface requires payment terms… you get the picture.

7. How often does the interface run?

What you are trying to identify with this question is the maximum tolerable time between the triggering event and the data appearing in the data consuming system.

The knee-jerk answer to this question is usually “we need the data interfaced real-time.”

There is not that big of a difference between a requirement of 1 hour and 2 hours. However, there is a huge difference between a requirement of 5 seconds and 1 hour. The architecture and design patterns used for a real-time (or near real-time) interface are very different than those used in a batch interface.

Negotiating and rationalizing this answer in the ideation phase sets the requirement for the design phase. Occasionally, during the design phase it is discovered that either the data producer or data consumer does not support a real-time interface.

Conclusion

Answering these questions will not ensure that the interface idea is a success, but it will give you a solid basis to move on in the interface design process or save everyone the pain of proceeding with an idea that cannot be successful.