Embracing API connectivity: The first steps to future-proofing your back office

Share on facebook
Share on google
Share on twitter
Share on linkedin

Embracing API connectivity:
The first steps to future-proofing your back office


By Lee Humeniuk

Consider this: It’s 2019, and your organization has been around for ten years. You thrived over the first few years with cutting-edge technology that put you ahead of your competitors. Suddenly, the internet changed, and the technology your customers relied on wasn’t so cutting-edge anymore. Everything lifted into the cloud while your systems were left on the ground, not yet irrelevant, but certainly aged in an instant.

If the above scenario describes the position you’re in, or one you want to avoid desperately, here are some of the first steps you can take to embrace API connectivity and future-proof your back office.

API Management

Taking an API-led approach can lift your versioning, authentication, authorization management, and service level agreements (SLAs) into their own layer. This approach makes it easy to configure an API as public or private control who can access which endpoints with a given request and monitor real usage patterns. With all of these concerns separated from the actual implementation, we free up a lot of dependencies and potential risk when changes are made to the code.

Legacy Systems Modernization

If decommissioning legacy systems is not an option, a good strategy is to expose key functionality in a layer of system APIs. The core concept is to expose the necessary functionality of legacy systems into a standardized internet-friendly way. You may want to consider standardizing connectivity protocols (HTTP vs. HTTPS), authentication protocols (Basic vs. Digest), and providing a canonical error handling library.

ESB (Enterprise Service Bus)

ESB can mean a lot of things, so in this context, we will define it as making sure we use a common runtime for all of our APIs. If we are developing using a framework like Express.js, then we would want to say that our common runtime will be Node (Node.js runtime) and all APIs in the scope of our organization should run on the Node runtime. Another example would be if we develop APIs using MuleSoft, we would want the entirety of our APIs to be built using MuleSoft so that our APIs are compatible with the MuleSoft runtime. Two key indicators here are resourcing and the CI/CD process, both of which should be simplified by this approach.

We’ve addressed some of the more common long-term bottlenecks companies face when trying to modernize and with these suggestions, we find ourselves in a position to maintain overall flexibility and promote scalability in the cloud. Welcome to the future of API connectivity!

If you’re not sure where to begin with your integration, or API development project, feel free to reach out to BIG. We can help lift your new project, provide expert consulting on an existing project, or help you scale rapidly.

About the author

Raised in Beaumont, Alberta, Lee grew up playing hockey and struggling with math. Often sarcastic and always a dreamer, you’ll find Lee at the local pub enjoying a Guinness whilst laughing at his own jokes and pitching the next big software project. Read more of Lee’s blogs here.

About us

Bits In Glass is an award-winning software consulting firm. We combine our deep industry expertise and experience with the best names in technology to provide innovative solutions to your unique business challenges. Our expert consultants excel at solving complex technical problems across industries and verticals, specializing in healthcare, financial services, insurance, and the public sector. Let us help you improve operations, drive better customer experiences, and return more to your bottom line.

Subscribe to Bits In Glass

Get the latest news and updates directly in your inbox.

Check out our video library!

Learn how Appian helped top brands gain success.