Understanding integration concepts

Have you ever sat in a meeting where the topic of software integration has come up? If you’re not from a technical background, chances are you mentally checked out as soon as the tech terms and acronyms began flying about. You probably also thought to yourself, “I really should find out what all this integration stuff is about.”

To help, in this article I cover the basics of integration so the next time you’re asked to join an integration meeting, you’ll be able to understand and join the conversation confidently. Let’s start by understanding what exactly integration means and why you might need it.

What are software integrations?

One of the ways local governments and asset-intensive organisations can improve their levels of service and create time efficiencies is through back-end integrations.

Integrations are how we connect one software application to another so they can talk to each other and work together. By linking up processes and sharing data rather than information staying in siloes, everyone can do their jobs more effectively – saving time and money, reducing the risk of error or duplication, and improving customer service. 

For example, as an asset manager you might want to make better decisions around the repair and replacement of buildings that range in age, condition and complexity. For greater insights to support decision-making, you might want to connect your asset maintenance data with your capital planning software or with Power BI. Or you might want to improve the efficiency of day-to-day repairs by connecting your maintenance planning with GIS, scheduling and other productivity tools. 

Whichever way you approach it, asset management conversations turn to integrations sooner or later, which can get quite technical and fast.

Integration terms

There are a few key integration terms that are worth becoming familiar with before your next meeting.

API: The first tech term that’s usually mentioned is API, which stands for Application Programming Interface. APIs are a programmatic interface to the software application. They’re like a touchscreen that allows you to access or exchange data between software applications and perform actions. 

For your IT people, APIs provide a set of definitions and protocols that allow them to easily access the functionality of different software programs and integrate them so they can communicate. 

For users, APIs simplify access to the system. Essentially, you can achieve the same via an API as if going directly through the software – allowing for various actions such as initiating tasks, creating or updating records and retrieving data.

One advantage of using APIs is that they can automate specific tasks. Most people don’t like to do things more than once – APIs allow you to make a process repeatable, such as around updating data.

A key point to remember is that the API interface remains constant. The application may undergo upgrades and new releases, but the structure of the API will remain constant across these different versions. 

REST API: Another thing technical people often talk about is REST API, which stands for Representational State Transfer. It’s just one of the ways an API is set up by creating a set of simple functions – like GET, POST, PUT or DELETE – to exchange data via HTTP protocol. 

REST is a really simple way of accessing data between programs because it handles all data types – from an Apple or Android device, Windows, or any browser or scripting language. For this reason, REST APIs are one of the most popular and flexible type of API. 

REST APIs have a defined set of fields or properties that don't change, meaning your interface will stay the same even if there are software updates. So, if you’re in a meeting and people start talking about REST APIs, they’re basically saying, “We’ve got these standard ways for you to communicate with our application to get a consistent outcome.”

SOAP API: Another API that was popular in the past is SOAP API, which stands for Simple Object Access Protocol. Being a protocol means it has standards that APIs have to follow, making them less flexible around how they’re implemented compared to REST APIs. 

IT programmers will encounter both REST and SOAP APIs – sometimes vendors might even use a combination. With SOAP, a message is passed between applications as an XML document, which is similar to HTML, in that you have a tag that defines the property and its value. While SOAP APIs tend to be an older framework, they still work fine.

From a user perspective, it doesn’t matter whether an API is set up as a REST or a SOAP; they both do the same thing.

WSDL: Something else you might hear is, “I’ll send the WSDL file after the meeting.” This simply means that they’ll send a definition of what the API does. WSDL stands for Web Service Description Language and describes the functionality of a SOAP web service.

Or, they may say, “We’ve got REST APIs, so I’ll send you the link to the Swagger doc.” Again, it just means documentation. Like with WSDL, Swagger is simply a way developers describe and document how the REST API works.   Swagger is now also known as OpenAPI Specification

OData: Developed by Microsoft in 2007, Open Data Protocol (OData) is a query protocol that, like SOAP, has a structure around it, meaning it has to be implemented in a particular way. 

It’s actually a form of REST API that uses simple HTTP messages to allow users to publish and edit data. It provides a uniform way to describe both the data and the data model. In short, it’s a standard, best-practice way to build and use REST APIs.

GraphQL: GraphQL is an API query language that was created by Facebook in 2012. This is a more flexible or dynamic way of specifying what data you want to get compared to REST API. For example, it might use the relationship between assets and work orders to allow for a more targeted data request.

GraphQL offers great flexibility in that you only receive the specific data you request.  The downside is it may become problematic for the service to process if a poorly formed query is requested.

Using APIs to integrate

So, if you have an API, does that mean you’ve got an integration? The answer is no – all you’ve got is an interface. You’ll need an integration platform – either on-premise or in the cloud – to talk to the API, and there are plenty to choose from. 

These days, organisations are beginning to move all of their applications into the cloud, making integration much easier to implement. There are plenty of cloud-based integration platforms, such as Microsoft Azure Logic and Power Automate, Mulesoft, Boomi, Amazon Web Services (AWS) and others which allow you to connect to APIs. Sometimes the integration is hosted within an application, with the software provider offering their own framework for providing the integration. 

Types of integrations

There are several different ways to perform an integration, with some of the more popular ways being:

Point-to-point: This directly integrates two systems, taking data out of one app and putting it into another. Point-to-point integrations are really easy to implement because you know exactly what you’re dealing with. 

Hub and spoke (horizontal): This is when you have a central point for all your integrations, such as an ERP system that acts like a hub through which all your data flows. This hub provides a framework to allow you to readily integrate. However, the drawback is that if that central point fails, everything else fails.

Star: This is a collection of point-to-point integrations. With this type of integration, everything talks to everything else. Each integration is done independently, which offers high functionality, but can become more complex to manage as the number of connected apps increases. 

Enterprise Service Bus (ESB): This is the most sophisticated integration and usually involves an enterprise-level integration strategy. It’s where you have one central system that links to all other applications, but they are not linked to each other. Imagine there’s a change to your data that needs to be communicated to different apps. Inside your system, there’s a little bus driving around containing a message that says to the apps, “Hey, I’ve got this message. Does anyone need it?” Then, the apps that need it take that message and apply it. The nice thing about EBS is that you can easily add or remove applications from the bus route as you need to.

There’s no real right or wrong way to set up your integration ecosystem. It’s more about where your organisation is at in its maturity and what your budget is like. 

Pushing and pulling

Lastly, it’s possible you’ll hear the words pushing and pulling in an integration meeting. So, what do they mean?

Pulling: Pulling is where you’re proactively calling the API looking for new or changed records.  Also known as polling as you are asking the application for information.  Typically, the integration would make an API request on a defined frequency (e.g. daily, hourly) looking for changes.

Pushing: With pushing, the application to which you are integrating sends a notification on creation or update of records. Examples include Publisher/Subscriber where the application publishes a message that subscribed clients receive.  Another example are webhooks where the application stores the recipient client details and pushes the message to the client. With pushing the client is made aware of the change without needing to poll for changes.

Now you’re more familiar with some of the tech terms around integration, I hope you walk into your next meeting feeling more confident. If you’re wondering what type of integration best suits your organisation, please reach out to your Brightly account representative or contact us and we’ll connect you with one of our integration experts.