7 Key Considerations for Unlocking Your Back Office: Part One
By Lee Humeniuk, Bits In Glass
Every business has a problem to solve. Whether it’s increasing engagement with existing customers, coming up with more efficient internal workflows, or trying to break into a new market, businesses are constantly trying to fit hundreds of puzzle pieces together in order to meet their goals.
The simplest demonstration of an integration is having data flow from Point A to Point B; numbers in a database to the smartphone screen of your most loyal customer. The question is: what will it take to get it there?
For those businesses feeling like they are missing out on the age of connectivity, I’ve put together 7 key elements that should be on your radar:
1. What Is An API?
The focus here is web APIs. A common use case for your department may be to create a bundle of lightweight microservices to automate the retrieval of files from a server and import them to SalesForce. At a larger scale, your organization as a whole may benefit from a complex application network that facilitates exposing your aggregate historical data to hundreds of 3rd party apps as a source of revenue. Before we can do any of this, it is important to define what an API is to your organization. A good place to start is deciding what the data should look like and how it is accessed – what is your input and what is your desired output. Check out https://www.mulesoft.com/platform/anypoint-design-center for more information on how the Anypoint Platform facilitates the design and implementation of APIs.
Don’t take any chances with your data, it’s often the heartbeat of your business. Design your integrations with authentication management and data encryption first, and build from there. Nobody has ever thought it would be fun to implement security on production-ready APIs after months of development. For an example of how MuleSoft does it, visit https://www.mulesoft.com/platform/soa/mule-enterprise-security.
3. Development Lifecycle
Software doesn’t go stale unless it’s abandoned. Your goal should be to develop software that isn’t abandoned a year or two down the road, so it’s important to make sure that you have proper mechanisms in place that support an evolving codebase. Tools that track development progress and issues, version control, and automated building and testing are essential for developing software that is going to remain vibrant and relevant.
4. Legacy Systems
Legacy system documentation is often out of date (or completely lacking), and behavior can be unpredictable, so POC (Proof of Concept) everything you do. Creating a POC for each piece of functionality required of a legacy system may seem tedious, unnecessary, or a waste of time, but this approach can alleviate pain and suffering when things become really complex – and they frequently do! You’ll thank me when the six-month project is almost ready to launch and a requirement was left unidentified – because that’s when the legacy system unknowns will hurt the most.
Part one has been all about the current state of affairs and what you need to reflect on before planning your next project. Keep an eye out for part two, where we outline considerations to bring up during planning that will help future-proof your next project.
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.
About Bits In Glass