You said you just wanted it built. You had a great app idea and wanted to get from zero to online as fast as possible. And to achieve that goal, maybe you cut a few corners, intentionally or not. It’s understandable.
After all, didn’t the all-conquering Facebook get built on the philosophy of ‘move fast and break things’?
While that motto is widely known and even still admired in some circles, what’s less widely known is that Facebook ditched ‘move fast and break things’ way back in 2014. Their new motto? ‘Move fast with stable infra[structure].’
Why the change? Facebook’s original motto acknowledged that even if it has certain benefits, speed can also be messy. Perhaps that’s what you’re finding out right now.
One such issue that can result from (dare we say too) hasty development is the discovery of interoperability problems with your new code.
How could this have happened?
Perhaps you didn’t realise you needed your software to connect easily with another digital product. Maybe you did but forgot to mention it in your PRD (product requirements document).
Regardless, now you have a headache and you’d trade way more to go back and change what you asked your devs for than your comfortable admitting.
Don’t worry - we get it. Here’s a handy article for you to understand interoperability and how you can get your project back on track.
The definition of interoperability is the ability of one product or system to work with other products and systems.
The concept of interoperability is used in a range of fields. It’s a popular concept in healthcare, for example, where multiple care providers may interact with the same patient.
If you’ve ever gone through a health problem requiring a range of specialists at a range of clinics and felt less like a well-cared for patient and more like an overworked messenger trying to help each part of the health system communicate with the rest, you understand some of the downsides of a lack of interoperability.
“Why can’t all these different parts talk to each other so I can have a single, seamless experience?” you may have wondered.
If so, I’m happy to tell you that your past frustrations haven’t been entirely fruitless; you now have a headstart in understanding the concept of interoperability in all areas of industry! I hope this is a comfort to you.
With that, let’s turn to the question of why interoperability is important in tech generally and software development more specifically.
How many apps do you have on your phone? I want you to take a moment to actually open your device and check.
How many did you have? Research has shown that the average phone has over 80 applications installed. Were you surprised by the number of apps you have? If so, that’s possibly for two main reasons:
In that two item list, it’s point number two that reveals the magic gold dust of interoperability for users in our app-filled world.
Notice that I said filled rather than saturated. That’s because saturation implies that there’s no room for more. And that’s not true. Whether we’re talking about traditional software, apps, or websites, the only thing a new digital product needs is market fit.
And we’re still seeing new products being developed and released every day. The global business software and services market size is projected to grow from USD 389.86 billion in 2020 by a compound annual growth rate (CAGR) of 11.3% through 2028.
A chunk of that market is made up of digital product agencies such as ourselves, Develocraft, specializing in developing apps and other digital products for other businesses and individual entrepreneurs.
But with so many apps (valuable though they may be) hitting the market, the user experience could be damaged with insufficient interoperability.
How?
Because switching between dozens of different apps each day isn’t ideal from the user’s perspective. You may have noticed this during the Covid era with several different streaming services on hand, each with a different library of content.
You may have sat down with your partner one evening and tried to decide what to watch. In doing so, you probably found yourself switching between some or all of the following:
I’ve personally found myself frustrated by being unable to simply see all the content available to me in a single location.
I swear to you, this isn’t sponsored content, but that’s exactly the kind of issue that some services like Movies Anywhere are now aiming to solve for their users. Their service allows users to access their digital movie collection from a single location.
And how does it do that? By connecting with other digital products and services through interoperability. We’ll leave the technical specifics of that to a later section. Feel free to skip ahead if that’s what you’re looking for.
Now imagine that for each of your streaming services you also needed an individual user name, contact email, and password. You’d have to create a new password each time you signed up for a new service.
That takes time.
You’d also need to somehow securely record each username / email and password combination along with the service it belonged to and be able to retrieve it when needed. In such a reality, you’d probably find yourself using the same password for everything, potentially putting your data, privacy, security, and financial information at risk.
Fortunately, thanks to the magic of interoperability, nobody does that anymore. Right? Well, maybe only 50% of people.
Password insecurity: is this actually fine? No.
How has interoperability solved this problem (at least for some of us)?
Consider firstly the ‘sign-in with’ options you get when accessing a digital product (such as a website or app) for the first time. Because the service is able to connect with Google, Facebook, Apple, or another preferred provider, you don’t need to go through the potentially security-threatening hassle of going through a unique sign-up process.
You can thank interoperability for that.
The second way interoperability has solved this problem for security-minded users (who, really, we all should be) is through connecting password management services to internet browsers.
These services allow users to securely store their login credentials where no hacker can get to them. Many also let users automatically generate secure, unguessable passwords - usually a cryptographically intimidating string of special characters you’d struggle to find on any standard keyboard interspersed with numbers and letters from alphabets you’ve likely never heard of.
But mostly Latin.
All good password managers also connect with your browser through a plugin allowing them to instantly enter your credentials for you and log you in immediately through an autofill feature. Personally, I wish I’d been doing this years ago.
Again, this is not sponsored content. I’m just grateful for all the time I’ve saved. That’s the value of excellent user experience.
Examples of password managers ferociously smashing the demons of poor security and tedious logins to pieces include (but are very much not limited to):
Sidenote: if you don’t have a password manager, pick one and use it. You’ll be making your life easier (and safer).
Internet security is a big issue. A recent report found that in 2019 7,098 reported breaches exposed 15.1 billion records. That was the worst year on record.
Some password managers including Dashlane also allow you to securely store payment information in their system, allowing you to make online payments more securely.
At a time when organizations are losing an average of $4.5 million per year due to online fraudulent transactions, that seems quite useful.
Through supporting online security measures, apps and services that make use of interoperability are protecting millions of people around the world from major threats.
Does interoperability matter? You bet it does. Make sure your code can connect with other software. It can be very useful down the line in ways that can be hard to anticipate.
Different digital products might want to connect with each other interoperably for a variety of reasons, so let’s start by breaking down the different ways components (a component is just a part of a piece of code or software with a particular function) might try to communicate:
When we say systems of code like pieces of software are interoperable (meaning that they have the characteristic of interoperability) it generally means they can connect to each other through one the following types of interoperability:
Let’s take a quick look at each of these types of interoperability and what they mean for software development.
Fancy word, syntactic. Combine it with ‘interoperability’ and you have a phrase that can make you sound like a Harvard data scientist.
But what does syntactic interoperability mean?
Syntactic just means ‘having to do with syntax.’ What’s syntax? I’ll save you the trouble of Googling it. Syntax is the name linguists gave to the rules in language about structure, like word order. Why is this right but wrong is this? Syntax. Sorry, Yoda.
Oops. Bad syntax. 🤷
In English (or any other human language) if you structure your sentences correctly you have ‘correct syntax.’ Another way of putting that is that you’ve formatted them right. Order a coffee from your barista and receive the right beverage? Syntactic interoperability helped get you your favorite beverage because you said, “I’d like a caramel oat milk latte” rather than “Latte like milk latte a caramel oat I’d.”
You and your barista are syntactically interoperable.
Congratulations.
Of course, we’re more interested in how this affects programming languages, of which, just as with the regular human variety, there are many.
Two such languages are XML and SQL. Remember what we were saying about formatting what we say in our coffee example? Well it’s just the same here. The fact that these languages are formalized - meaning they have officially fixed rules for how to format information - is what makes them relevant to interoperability.
XML-based code is formatted one way. SQL has its own rules. Separate bits of code, if properly programmed, should be able to work with each other because of their shared format (or syntax - the syntactic in syntactic interoperability).
If you want your software to connect with outside digital information, one reason it may be able to do so is because both parties - your app and theirs - are literally speaking the same language. That’s syntactic interoperability in a nutshell.
Don’t like the name? Some call it structural interoperability. We’re not taking an official position on this, but we think that’s more boring and less descriptive.
‘Let’s not get hung up on semantics!’ If English is your first language, you’ve probably heard that phrase a lot. Usually in an argument. Other languages have their own versions that refer to the same idea.
What idea?
That the symbols (or labels, such as letters and words) we use to talk about a subject aren’t as important as the meaning they’re trying to convey - and we should focus on those instead.
Not here, though. Here, we’re all about both the meaning and the semantics or ‘signs’, if you like.
Why?
Because for one digital system (like a piece of software or multiple connected digital products) to understand another, they need a shared understanding of both. Or, you know, as close as software can get to ‘understanding’ anything. But this isn’t a philosophy class.
That’s semantic interoperability. If you have uniform code across the different bits of software you want to connect, you’ve got semantic interoperability.
So far, we’ve looked at the more technical aspects of interoperability in software. But there’s more to interoperability than code. That’s where this last of the three categories comes in; it focuses on the wider context of code rather than the code itself.
Think of standardization of practices and processes. If your organization has a particular way of performing a given task that’s unique, that isn’t necessarily a problem. However, if you need to interact with another organization to perform the same task, that might then become an issue.
As such, cross-domain or cross-organizational interoperability refers to the practices and processes we find at different organizations (or sub-groups within individual organizations).
For example, it’s not unusual for early stage startups to have (coughs) unique(?) approaches to project management that could generously be referred to as informal versions of Agile.
At first, this can be tolerable or even completely appropriate. An overly formal project management structure might not be appropriate when so much of getting a very early stage startup moving is the passion and enthusiasm of a small number of individuals (perhaps even just one or two) working around the clock.
But imagine the startup grows. Eventually the core group of initial founders no longer have the time to do all the coding themselves. So they bring in help, perhaps an outside digital product development agency like Develocraft, to outsource some of the workload.
Developers from both inside the startup and the agency could be working alongside each other, sharing planning meetings and trying to contribute to the same goals collaboratively.
At this point cross-domain (or cross-organization) interoperability comes into play. We can imagine two idealized scenarios - of which only one is ideal:
It’s probable that most actual instances of inter-organizational collaboration fall somewhere in between these two hypothetical ideals. But there’s no doubt that of the two, you’d rather be part of scenario two.
This is just one example of how interoperability in software development applies not just to code, but to systems of people working together. You can now understand and appreciate the value of cross-domain (or cross-organization interoperability).
One easy way to remember it? Cross-organization interoperability helps prevent other organizations from becoming cross with you!
We’ve already seen in general terms how interoperability enhances not only software development, but the role of software in everyday life through features such as login credential autofills and the ability to sign-up for new services with existing accounts.
Still, if we’re going to truly understand interoperability it’s best to offer a broader list of examples that can reveal how intrinsic this concept is, not only to software developers, but to the modern economy as a whole:
Facebook has been making a lot of noise lately about how, contrary to what you might expect, they back updating internet regulations (at least in the United States) for the first time since 1996 - the last time there was major legislation passed on this issue.
One of the key changes Facebook advocates is, “Enabling safe and easy data portability between platforms.”
Why? According to Facebook, “If you share data with one service, you should be able to move it to another. This gives people choice and enables developers to innovate.” That’s interoperability in the news, people.
If you read part one, congratulations. That was more reading than most adults do in a week! Do we have any evidence to support that? Cards on the table, no. But it feels true.
Anyway, I hope it wet your appetite for more info on interoperability. Because it’s here, ready for your perusal. What’s part two about? How you can identify and fix interoperability problems in your own digital product.
The more your code represents a Frankenstein’s monster of different elements pulled together from different sources, the more likely it is that one of those parts will introduce interoperability problems.
First, identify any specific digital products you want yours to be able to work with. This will help you prioritize your work when it’s time to start making fixes.
Second, audit your code. Find out which bits are necessary and which add extra complexity for little return. Try to identify the components that may be causing compatibility issues.
If a component needs to be there for your code to function, leave it in. However, if there’s an alternative that would offer greater interoperability while delivering the same - or better - functionality for your users, consider making the switch.
The aim should be to do as much with as few moving parts from various sources (code from different libraries in different styles, etc.) as possible.
Third, look back at your list of top priority software/apps etc. you’d like your code to be interoperable with. What changes can you make that you found in step two that could help?
Add these into your task management system (like Jira or ClickUp), ordered from most important to least.
Fourth, bring those tasks and your devs together to create magic.
Does the sector, industry, or market have any standard practices relating to data / digital formatting? By consistently following these standards, you’re much more likely to achieve compatibility across distinct software / platforms.
For example, in the United States the healthcare industry operates specific standards concerning EHRs (electronic health records). With so many healthcare providers around, it’s necessary for EHRs to be easily transferred between different practitioners.
One patient might be referred by a primary care provider (or general practitioner) to a cardiologist. If the patient’s health records cannot be interpreted by the software used by the cardiologist, that could have serious implications for treatment.
Having set standards for the formatting of EHRs also means that legacy records remain usable without having to go to the extra effort (and cost) of reformatting them. Since a patient’s records can accumulate over the course of decades - some people live for more than a century - it’s likely that this could prevent a lot of problems in the near future.
It’s likely that even if your market isn’t affected by formal requirements, there are still common practices relating to interoperability that you should follow. Find out what these are and implement them. By doing so, you’re likely to find your software is compatible with other digital products in your area by default.
Depending on your market area, you may find there are digital services available intended to help you achieve interoperability. Returning to our healthcare example, the CMS (Center for Medicare and Medicaid Services) provides templates for EHR data collection.
Keeping your software current is crucial.
For example, if you’re using outside code that’s no longer being supported or maintained, there’s a real chance that you’ll be out of step with any external software that your product needs to communicate with in the near future.
If your platform is built with any external components, make sure you keep them updated. If not, you can expect to face interoperability issues that will escalate over time.
Do you have concerns about your software? If so, we can help. Reach out to us here. We can help you find out what’s going on with your digital product and even establish a plan to get you back on track.
