Success in the age of connectivity
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 MuleSoft’s 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, click here.
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 behaviour 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.
5. Future integrations
Thinking about future integrations that your organization may want to implement has a direct impact on solution architecture. It’s not often that you can scale a solution by packing all of your business requirements into one or two apps. We suggest splitting your solution into smaller pieces. Create a network of APIs over time that will help you maintain flexibility as time goes on, and that fits perfectly into your development lifecycle.
6. Subject Matter Experts (SMEs)
Anticipate your customer business questions. Having go-to people who are highly knowledgeable and accessible and who can answer any business-related question is a necessity for a successful project. All too often we see that an “integration expert” may have integration experience, but rarely do they also have industry expertise, i.e they can create a banking API, but shouldn’t give banking advice. Make sure your front-facing SME’s also have the breadth of knowledge your customer is likely to call upon, or that there is someone internally they can call upon for specialized industry knowledge.
7. The stack
Of course, reliable middleware is key – it’s the glue between all of the pieces. Accessible API design tools, reduced implementation time with Anypoint Studio, and API management and monitoring with Anypoint Platform. However, we often need to consider the end systems we interact with. Are we accessing a database? If not, do we need to store state for any reason? Should we implement a caching solution with a 3rd party i.e Redis? Do we need to stand up our own OAuth provider for authentication? The system stack lays the foundation for what is possible with your next integration project.