Push or Pull Me Hearties: The Maritime Digital Data Dilemma
As maritime informatics continues to shape trade, the next challenge is to make sure everyone can and will play nicely together. Shipping people and digital transformers can be the best of friends, but the terms of engagement need to be set. So in a world where data can be pushed or pulled, it is time to pin down who does what and why…in which direction.
INTEGRATION FOR THE MARITIME NATION
The boom in maritime informatics and the enthusiasm in the shipping industry for ever more data means that we have so much more information to access and manage. This means that all providers need to better understand the needs, wants, hopes and dreams of clients.
We are at a wonderful age, where clients and tech are coming of age together. However, all the advantages can be eroded if the terms of the data exchange are not fully understood or managed. Once there is understanding, then the means of doing “business” can be shaped and this means turning to an API.
It is impossible to read about maritime data or listen to tech gurus, without at some point the term “API” being used, which means “Application Programming Interface”. Which put simply, is a set of programming code that enables data transmission between one software product and another. It also contains the terms of this data exchange. It is a software intermediary that allows two applications to talk to each other.
The API is the messenger that delivers your request to the provider you want information from and then delivers the response back to you. A runner if you like, between you and what you would like to know, or to share. It is vital in setting out how data will be exchanged, that the API is shaped to reflect what a client wants, and how they need it.
DEVELOPING SOLUTIONS
An API is the building block that allows all parties to get what they want in the way they want it. It spans between one system and another, allowing functionality and flexibility when it comes to how services are offered.
It serves as the interface that delivers data from the application and facilitates the interaction between the application and the system being interrogated. The ability of API-led connectivity to allow systems to change as easily as plugging in is key to the modern vision of enterprise IT.
The API makes things work for all the parties involved and shape the experience of a user. Get the API right and it is a solution, get it wrong and it can become a problem — but one that you may not even know is damaging you, until it is too late.
Whether cargo data, navigation, stability, engine performance, whatever the user is interested in, the APIs do the same for all interactions between applications, data, and devices.
LET US KNOW THE FLOW
Even ashore it can be tough untangling some of the misunderstandings around APIs and web services. When you throw ships into the mix, it gets more challenging again. At the core of the debate is which way data initially flows, and there is much debate in the IT industry about the issue of “push versus pull” — a Google search brings up 20k results of just that very discussion alone. There is rather less discussion when it comes to the same API issues and shipping.
Regardless of where, when it comes to how systems are integrated, and how they are interrogated, without getting too “Carry on Computing”, it is always a case of knowing who’s pushing and who’s pulling. Vendors, clients, charterers, offices ashore, all are vying for the right set-up for them. So, it matters to get it right. Indeed, it matters more than you might think. The implications for the right choices are clear.
Done properly and everything about digitalisation can drop into place. The data and information flow, and the systems deliver for the client wanting the right insight and intelligence when and where they need it.
Conversely, if the API doesn’t deliver, there can be frustrations and all parts of the data exchange are frustrated. There are also significant cost implications. Pull calls all data whether it has changed or not, while push only sends what is needed. Those debates aside, though, we need to be aware that digitalisation fails if we don’t get the flow right. So, let’s ponder the power of push versus pull some more.
PUSH V PULL
In a “push” architecture, a client requests work from a server — the work is “pushed” to the server, which has no choice in the matter. So, the client either gets what they want or can flag issues if they don’t. “Pull” architecture is different. This is when a server requests work, which it then holds in a queue until it is ready to complete the task.
The “push” approach tends to be almost a default for request-response operations and works because it usually involves a persistent connection over which both the request and the response travel. Matching the response to the request is as simple as seeing what response comes back over the same connection.
Pushing isn’t perfect, but ultimately it gives a greater insight into potential problems. Whereas pull can feel less certain. as the request/response communication pattern makes it easy to see requests go out, but the response is less certain.
It can also be a problem as the pull approach in essence forces the client to apply business rules to the pull frequency. This is not the best answer in a maritime informatics setting. The client can end up with complicated rules, and sometimes their own developers may not fully understand the challenges of the shipboard setting and needs. Inefficient pull frequencies can end up impacting the bottom line too, which is no good for anyone.
GETTING IT RIGHT
These are really important distinctions when it comes to data too. Get the push/pull dynamic wrong, and we have a potential recipe for disaster. So, the emphasis is on getting it right. Which in turn means understanding the terms, the implications and what it means for you, your company and of how to make the right choices to get the results needed.
The ways in which data and information flow from sensors are pivotal, and in a world where data can be sucked or blown, it is time to pin down what clients want from the data chase. In a situation where sensors can push or pull, you risk problems where you simply pull data blindly.
All too often there are problems from the very start, as people misunderstand the integration issues and challenges. They use push or pull, pull or push, interchangeably. Not realising the real-world problems that can be created.
So, starting the metaphorical voyage of integration in the right direction is imperative. It is the foundation of all that comes. So, getting the basics in place gives the foundation for success. With APIs moving data from one system to another in any integration, pushing information results in a very different scope of work for a developer when compared to pulling information.
It is vital to make it simple to both understand, but even more importantly, simple to apply. To ensure we all play the same way, which makes us all the more efficient. The message is that if companies aren’t optimising for the trade they are developing for, then there is a potential cost in time, money, bandwidth, processing power, speed and timeliness.
If you really want to get the developers attention, don’t even talk push and pull…use suck and blow instead!
