What are the challenges with interface projects?

When we think of the IT landscape in a large company, with different systems, you know it: Each system has its authorization and its own special options, and yet the systems require subsets of each other's data. Examples: You have a career area on your website where data from your HR database should be dynamically integrated. You have an online catalog that consumes product data from your PIM (Product Information Management) and your MAM (Media Asset Management) — i.e. systems that work together. And in general, anyone who wants to digitize their marketing processes using powerful individual systems (keyword “best of breed”) cannot avoid interface projects. But these projects aren't always easy.

What you should pay attention to when it comes to interface projects.

At first glance, interface projects seem simple: Two systems exchange data. From a technological point of view, this is rarely a problem when project management clears things up and the developers have the necessary skills. It's all no problem. But even if this is the case, the preparatory work is particularly important. Otherwise, the project may fall by the wayside somewhere. An example: Data and formats have been well documented and also understood. The output is clear so far, and you read the data once and looked at it — it actually looked good. The go-live is already in sight. The closer it gets, the sooner you commit to the deadline — and suddenly something doesn't fit. You can tell that the import strategy has not been fully thought out, that the system may not be able to handle delta updates, or that the export times do not suit data maintenance. It is therefore clear that the critical aspects were not clear at the beginning.

How do I plan an interface project?

There are deadlines in every project, and of course you would also like to know the costs involved. When planning, it is particularly important to focus on the critical path. Even if you work in an agile way, you run the risk of getting lost in such projects if the direction is not clear from the start. Therefore: Give yourself enough time at the beginning to design. That's the first thing. Second, people from different organizations often work together. These often have additional tasks and other priorities, which means that small things often take longer — not necessarily in effort, but in time. And as far as the effort is concerned: This is higher than in other projects, especially for coordination, communication and testing. So plan enough voting dates, tests and reviews so that you don't run out of time. It often takes longer and is more complex than expected — that's the rule of thumb. But when it works, it was worth it.

Why it's worth looking at the big picture when it comes to interface projects!

At the start of an interface project or sub-project, you often already have a good idea of what the interface should do and how everything should work. Nevertheless, it is worthwhile to look at the whole picture again in peace and quiet — according to the principle: “To make rapid progress, take your time. ”

• Which systems actually need to communicate with each other, and in which order?
• If the interface is interactive, i.e. sends information back and forth, it must be clarified: What information must flow exactly when?
• What are the potential errors and how are they handled? Is an error critical or acceptable?
• Can a product go online without an image, or what does it look like?
• What are the restrictions?

First of all, these are the questions that deal with the “big picture.” So the three most important tips: Identify critical aspects early on, ensure good communication between the parties involved and get someone on board who already has experience with such a project.

Why you should know your content

After all, the content is the real reason for the project. You do not want or cannot maintain the content in several systems, or it makes sense that the data is created in one place and is visible elsewhere. The better you know the content and the systems involved, the fewer problems you'll have. examples:

• What is the trigger for data delivery?
• Is this done daily or on an event-based basis?
• And what counts as a “change”?
• Is this the same in both systems?
• Do we know the amount of data?
• Is there any experience with the transfer rate?
• What other types of data do the respective systems have that could be interesting in the future? You just want to keep your doors open...
• When data needs to be transformed or changed, who does it?
• And what is the level of security of the data? What can happen in the worst case scenario?

As you can see: Lots and lots of questions. But every minute that you talk about it longer in advance pays off.

The five standard topics for interface projects.

Almost no matter what type of project or data transfer you have, there are five standard topics in interface projects that arise again and again: The content we've already talked about. The format — ideally the native format of the delivering or receiving system. The delivery interval — do I need the data in real time, hourly, daily? Is a delta export enough, or is a full export necessary? The transmission path — how is the data transmitted, how is the transmission secured, how is it monitored whether something has gone wrong? And finally, the processing rules: Data between two systems is frequently transformed. Who does this and how is the data visualized later? These are the five topics.

What's next for testing?

Perhaps everything went well in your project up to implementation and testing. The interface is implemented, the data is understood, and the first test looks good. But if you have repeatedly loaded your test system with data, it now makes sense to take a clear approach: Stop development, stop making changes to relevant parameters, reset the test system, transfer and test data. If the data is then available in the correct format and has been transferred, the same checklist as above applies: Has the content been transferred as expected? Is the transmission path stable? Have you thought of a penetration test, i.e. a security check? The same topics: content, format, transfer, processing.

No stable development without documentation!

Anyone who is familiar with the agile manifesto knows the sentence: “Working code is more important than comprehensive documentation.” That is also true. But you don't have to choose between working code and full documentation. As soon as it works and there are no more changes to be made, document it so that someone else can understand it. Especially in interface projects, this is the basis for stable development. It also means freeing yourself from the “head monopoly.” You remain able to act, even if the person who implemented it isn't there for once. Good, isn't it? There are many companies that do this in an exemplary way: API documentation via Swagger, business logic documentation via a project space, etc. This makes documentation fun. Don't document obvious things, and the documentation doesn't have to be a journal. If it is as central as possible and not distributed — i.e. not in code, in the Word document and in the chat program — it makes work easier for everyone. So document centrally.

What does your target data model look like?

In interface projects, especially large ones, there is one topic of particular importance right at the start: What does the target data model look like? It is not about how the data comes, but what it must become. If you understand this early on, you can develop accordingly and implement the interface at the same time. In the end, a corresponding data transformation ensures that the delivered data is also accepted. An example: We automate a catalog based on data that we receive via an interface. Instead of waiting for the interface project and transferring every delay to the catalog project, the right way would be: Define the data model, check the content based on the layout, program accordingly, complete the interface project and finally compare and connect the delivered data with the required data via transformation.

Why interface projects are easily underestimated.

Once again, in a nutshell: What distinguishes interface projects from other projects, and how do you implement them successfully? Interface projects are different because there are more participants and more unknowns. That is the first point. They are easily underestimated and are the drivers of effort and costs in many projects. At the beginning, take enough time to understand the landscape, the data flows, and the data itself. It's worth it, I promise. Ask the right questions right from the start and get someone on board who is particularly familiar with the data and interface projects. Assume that coordination and testing are more complex than in other projects and that there will be delays between work packages. Do not document too extensively, but do so sufficiently. And define the target data model as early as possible to reduce dependencies.