Infinity POS is bridging the technology gap between retailers and the US Department of Agriculture’s Women, Infant and Children (WIC) program to help stores serve customers faster and more accurately.
New video series discusses technical aspects of APIs
Mike Baxter, head of Infinity product, shares his thoughts on using APIs for retail so you can get new products and services to market faster and improve customer experience. In this first video, Mike discusses the advantages of microservices for APIs and why this design pattern isn’t the only one to consider when you want to innovate quickly.
Five things to look for in a retail technology partner
If the beginning of the year means it’s time to re-evaluate your retail systems, start here.
No matter the scale of what you want to accomplish – boosting POS functionality, getting a single view of inventory, or starting your unified commerce journey to connect POS, inventory, fulfilment, order and customer data – you need a partner with the right people, processes and technology. A partner who understands retail’s demands and can give you the system that will improve customer happiness, staff satisfaction and your bottom line.
Here are important indicators of a good technology partner plus questions to ask
1
Maturity and market responsiveness
Look for a partner who’s been around retail for a while, with a sound platform, business model and proposition. They’ll need to understand your fast-paced, data-intensive environment where any significant level of downtime is unacceptable.
Their people will have the capability to help you plan and implement your projects so they suit you right now and into the future. When you choose a partner with a mature platform, they can focus on delivering innovation because the core functionality you need already exists.
2
Customer experience
Make sure your partner has a recent and proven success record for planning, implementing and managing complex, large-scale deployments across multiple stores, multiple formats and multiple geographies.
Do they have stable and well-tested strategies and technology or are they just adapting existing supply chain and fulfilment models? Ask if they’ve worked with related technology, systems and service providers. And how their capability integrates with eCommerce, payments, supply chain and finance software.
Request case studies or references and ask about the consultancy, customisation, deployment, training and support services they provide.
3
An agile and innovative mindset
You want a partner who’s got the people and processes to move fast, while cultivating an environment where innovation flourishes. They should use agile methodologies and have experience working with agile retailers.
Get evidence of their history of responsiveness and their ability to assess and quickly correct any unforeseen issues. Ask how they’ve managed things for a client when faced with unexpected changes, a competitor’s action or customer demands.
4
Broad product capability
Choose a partner that can give you a broad and holistic portfolio, perspective and experience. One that gives you all your core requirements out-of-the-box plus the ability to customise and easily add new functionality.
For the best customer experience, you need to intrinsically link inventory, fulfilment, orders, supply chain and planning. You don’t want to be tied to a point player that can only provide portions.
Your partner should let third parties connect to their technology via APIs and cultivate a community with those parties so you can give customers more shopping, payment and fulfilment options.
You also need to know that your partner has a strategic roadmap and investment committed for new capabilities.
5
Best of local, best of global
Look for a partner that’s an Australasian business, focused on our region’s potential to succeed. A local partner means you can have more influence on the product roadmap and enjoy direct engagement with people on the ground who are committed to your success (and not distracted by offshore business activity). And a mid-size partner is more likely to view you as an important customer of influence. It’s far better to be a big fish in a small pond (and not have to fight for attention as a small fish in a big pond would).
If you’d like a benchmark to rate your current or potential technology partner against, contact us. For more than 23 years, Infinity has been dedicated to the development, implementation and support of retail systems. We’re renowned for being both pioneering and reliable. You can count on us for consulting, platform implementation, integration, training and support that helps you get great results.
How to build the right mindset for retail success
Accreditation first for Fiji’s new VAT Monitoring System
Announcing The Salient Idea Conference 2017
Is your omnichannel software flexible enough for tomorrow's customer?
Consumers are changing the way they shop and engage with brands, providing a healthy challenge for retailers as they plan to meet their increasing demands. Meanwhile, the competitive environment continues to heat up. With Amazon appearing on Australia’s virtual and physical horizon, the local landscape is going to feel the impact – and it’s going to hit hard.
How savvy is your cyber security?
The Cloud: Pack your parachute for a smooth landing
API Days: opening the door to new strategies
Attending the API Days NZ Conference recently gave me the opportunity to learn the API journey of several successful companies, and how they came to be where they are today.
Ian Randall, a software engineer at Pushpay, presented ‘APIs at Pushpay – A Continuous Delivery Story.
Ian described the PushPay API store from the beginning to its current position. Starting from one API, they eventually split into two: public and mobile. The mobile API is for internal company use only, with the amount of data used always kept at a minimal level – the only data transferred is what a client needs.
Ian also spoke about Pushpay’s delivery approach. Changes are pushed to production at least six times per day. The development team and the test team are fully integrated, allowing for the efficient resolution of any issues raised during testing.
Barak Chamo, a London-based developer, introduced us to GraphOL, a new technology which is leading to a new language.
Originally developed by Facebook for its mobile applications, GraphOL became open source in 2015. It brought a paradigm shift in the way we approach data transfer, from the front to back-end of applications.
Instead of using predefined data and response structures, a developer can declare a graph form of a data model, and request data in its object form in a JSON-like syntax. GraphOL also makes things easier, without the need to maintain v1, v3, and v100 or APIs to ensure legacy versions are supported. GraphOL queries always return predictable results. Send a GraphOL query to your API and you get exactly what you need – nothing more and nothing less. If more than one object is required, GraphOL queries follow the references between the resources, retrieving multiple objects in a single request. This means applications which are GraphOL-based are fast, even on slow mobile network connections.
The only disadvantage is GraphOL is a brand new language API developers need to learn – or is that actually another advantage?
Abhishek Tiwari is a lead software engineer at Isentia, and spoke about legacy code API transformation journey.
Due to one-time, one-place processing and isolation of business rules, stored procedure has been used as a de facto standard for application to access and manipulate data. But if you have a legacy code with most of the business logic imbedded into it, you can still develop API against the stored procedures considering them as a variation of Functions as a service (FaaS).
A function in FaaS is a self-contained piece of reusable functionality, which makes them similar to stored procedures. This means stored procedures can be converted one by one into FaaS functions to be executed via API endpoints.
API days presented a wide and informative range of new technologies, together with approaches to using these new technologies. We were able to see ways to enhance the API build process and get new features into production quickly and safely. There were ideas on how businesses use APIs by mixing new and old technology to enable them expand the capabilities of legacy systems through APIs, without the need to reengineer or rearchitect much of what is already in place.
While API itself is not new, it has recently turned into a key tool. It could be compared with a door. For a developer, it is a door into the software program, allowing interactions without need to share the code. For a business, it is a door to the leading products market, which turns competitors into partners.
