How middleware eases enterprise software upgrades

Published on the 08/05/2018 | Written by Donovan Jackson

Flow Software middleware
icon_feature

FURTHER READING

Christchurch council_IoT sensors

Can sensor tech turn Christchurch into the smart city of the future?

December 13, 2018 | Jonathan Cotton
The $4b rebuild sees Christchurch emerge as New Zealand's busiest testbed for sensor tech...
Digital transformation hype_Flow Software

Digital transformation – peel away the hype

October 24, 2017 | Maria Koppens
Focus instead on creating business value…
Oil worker

Field service at the sharp end of digital transformation

March 3, 2017 | Donovan Jackson
Doing the same thing again and expecting a different result is, apparently, at least one definition of insanity...
Quest for Digital transformation

Transformation: Put documents and processes in the crosshairs

August 22, 2016 | Newsdesk
Take a closer look at information management in the quest for digital transformation…
Air NZ

Air New Zealand: The tech company with planes

August 13, 2015 | Donovan Jackson
Think Air New Zealand is an airline? Well, yes it is, but according to CIO Julia Raue, it needs to be an experience-led digital social company to get the competitive edge…
Flow Software makes for smooth warehouse management system migration…

When it comes to upgrading enterprise software systems, it can be as difficult as implementing them in the first place, particularly when those systems are integrated into an extended supply chain. However, with appropriate middleware in place, the virtual isolation of one system from multiple other internal and customer systems can greatly ease the process.

That’s according to David Masters, CEO of integration software vendor Flow Software. “When you have middleware in place, it eases migration and provides the capability and flexibility to upgrade or change software systems, facilitating adoption of best of breed technology to maintain competitive advantage.”

This is an important benefit, Masters points out, because the pace of technology advancement is rarely even. “If one of your systems becomes obsolete, or something new emerges which delivers a potential advantage, you want the ability to pull the old component and plug in that new one,” he explains.

With a ‘hub and spoke’ model, Masters says middleware facilitates systems or application migration with reduced difficulty. “Integration software serves as the ‘hub’, with data feeds to or from applications, trading partners, or service providers as the ‘spokes’.”

Masters explains that transaction data messages – orders, invoices and so on – from multiple trading partners are reduced to a standard set of messages into and out of the main business system, be it ERP, or CRM. Messages that need to be shared or synchronised with other business applications (such as warehouse management systems) or service providers (e.g. third-party logistics) also go via a standardised set of spokes.

When a new application is introduced, including those which are being introduced to replace existing applications, it is connected to the hub with a new set of spokes. “The testing of various interfaces to or from the new application can potentially be confined to confirming that the application and the hub can successfully exchange data via the new spokes. In many cases, the parties or entities connected through the other spokes do not need to be involved in the migration project,” Masters adds.

Simply put, this means when a new application is introduced (or swapped out), the rest of the technology environment is untouched.

Upgrading a WMS
Colin Burrow, CIO at logistics company Fliway, confirms the value proposition laid out by Masters. He says the company sought an upgrade to its warehouse management solution (WMS) owing to the passage of time and the inevitable arrival of obsolescence for this component of its application set. “While it was fit for purpose for a good period, the Exceed WMS had reached the end of its life. Complexity had evolved, so the old system wasn’t meeting our business requirements and was lacking in key functionality.”

Like many enterprise applications, the ageing Exceed WMS was comprised of multiple layers: the application, the operating system and database.

All these elements, Burrow notes, were at end-of-life, so the transition would require a complete replacement of the entire stack. “It might sound straightforward, but this was the better part of a two-year project; we were staying with the same application vendor, but upgrading to the latest generation of the WMS which offered all the functionality and performance required by the business.”

Burrow confirms, however, that any change is difficult, even when sticking with the same vendor. “There were some other complications. We were also moving from Unix to Windows for the operating system, and from Oracle to SQL Server for the database. These factors all influence the work involved in upgrading a system which is pretty fundamental to the successful operation of our company.”

Middleware ‘ace’
The ace that Fliway had up its sleeve is that the WMS was integrated into the company’s other systems (and the systems of its key customers) with Flow Software. “What this meant in practice was that the WMS was effectively isolated from the other applications. With all the integration in one place – the Flow middleware layer – it meant we could replace the old WMS and minimise the customer impact because we only needed to change the Fliway side of the transaction.”

This, he explains, is a far less disruptive situation than may have arisen had there been bespoke integrations between each application and the WMS. “It makes integration a whole lot easier when it is all in one place. In practice, it meant we could just replicate the messaging and there was very little change required from the perspective of our customers, unless we collectively agreed to take opportunities to deliver new functionality. We knew what to expect in terms of scope and detail of the messaging exchange, so our upgrade for them was really low touch.”

A similar ace was apparent when construction company Stevenson upgraded its ERP from a legacy JD Edwards system to Microsoft Dynamics NAV (NAV). Again, an existing hub and spoke integration model made for a smooth switchover from the old to the new.

Anthony Bitossi, Chief Information Officer says the architecture of the original integration was a major advantage for the upgrade project. “When we were putting in a new CRM system and new software for our weighbridge, we recognised that putting middleware in would allow us to smoothly implement a new ERP in due course,” he explains.

“These systems were then integrated into our outgoing JD Edwards system on a ‘hub and spoke’ architecture. As a result, when we implemented the new NAV system, it wasn’t a matter of redoing all the integrations, but rather a matter of connecting the new system to the hub.”

And, at European Motor Distributors, the use of middleware has enabled it to upgrade its Incadea ERP systems without losing focus on the business itself. Matt Tohill, EMD’s General Manager IT & Digital, says the distributor integrates with multiple dealer management systems (DMS), and so an upgrade potentially impacts on companies the length and breadth of New Zealand. Not so with middleware: “With Flow, we pump data out from a single source, Flow manipulates it into the format required by each of the different DMSs. That’s relevant, because at the time of the ERP upgrade, it again meant that we only had to deal with one solution – our Incadea which we were upgrading – rather than having to interfere with the integrations across our supply chain.”

Essential integration
A solid middleware infrastructure doesn’t just take care of immediate needs, it also provides for the inevitability of change. That’s confirmed by Bitossi, who says that if any other applications need to be swapped out in future, much of the integration is already done. “We don’t have to touch [our middleware] as it connects to NAV; it means we only have to deal with the side that connects to whatever other applications we might introduce. For example, when we upgrade Command, we can do that and run User Acceptance Testing, without needing to reengineer the connection to NAV.”

Bitossi says choosing an integration platform has proven ‘a good decision to make’. “It is hard to compare what we have done with any alternative and certainly the transitions from one ERP solution to another hasn’t been without its hiccups. But I’ve worked with a lot of different IT vendors and Flow has to be right up there if not tops in terms of service delivery.”

For EMD’s Tohill, he says at the time of the ERP upgrade, middleware enabled his team to focus efforts where the results can be found. “Not having to deal with multiple integrations across teams not directly under our management has meant a substantially easier project. Flow’s people worked with us on a case to case basis with an integration map and user acceptance testing to make sure that all the points that we touch worked suitably well. That made life a lot easier, rather than having to go to a bunch of organisations, vendors and partners; working with one piece of middleware meant that at our end, we migrated to the new ERP effectively.”

And asked how important integration is to a project like his, Burrow is unequivocal. “It’s a big part of it. We use Flow for all the integrations between our business and our customers and the successful operation of the WMS isn’t possible without it. And being a Kiwi company not only means direct access to the people, it also means a shared ethos of getting things done.”

Post a comment or question...

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.


Follow iStart to keep up to date with the latest news and views...