info@hathority.com       
September 17, 2020 admin

Five Challenges Building Integrations With Legacy Middleware

If you’re an integration developer in today’s economy, you’re probably being asked to do more with less.

Perhaps your company has discovered it needs to radically change its product strategy or revamp its supply chains, and you’re writing the code that makes those changes possible. Or perhaps your company is hunkering down, asking you and your colleagues to make incremental improvements to existing applications and integrations for the sake of efficiency and cost savings.

In either case, if you’re working with legacy middleware, your work is probably getting harder, not easier. I know this, because at Boomi we talk regularly with customers who are trying to do their jobs while working with slow, complex legacy middleware. These customers have described firsthand the strain they’re experiencing using old tools and techniques in an economy that is – to put it mildly – applying lots of torque to aging enterprise architectures.

From our conversations with developers, we’ve come to recognize five major challenges that customers are experiencing with legacy middleware. Read our list below, and see how many of these apply to you.

Want to learn how Boomi can help your organization modernize? Sign up for the Out of This World digital episode series, launching Sept. 29.

Challenge #1: Too Many Interfaces and Too Many Tools

This challenge is largely the result of decades-old software vendors taking a hodge-podge approach to product development.

Say you’re working with a middleware platform that had its start in the glory days of service-oriented architecture (SOA). The first five or ten years of feature updates for that platform probably seemed cutting edge. Then paradigms changed, companies found SOA overly complex, loosely coupled representational state transfer (REST) interfaces became the new standard, and suddenly everyone was talking about a new generation of applications that ran in the cloud. Platform as a service, software as a service, and integration platform as a service (PaaSSaaS, and iPaaS) took off. At first, these platforms seemed powerful but risky. Within a few years, they were powerful but trusted. They became the new standard.

And that legacy middleware platform from the SOA era? It still ran on-premises, still required lots of hand coding, and was still complex. To compete against cloud software, the middleware platform’s vendor may have made a few acquisitions, adding cloud startups to its product portfolio. It might have changed a few logos and introduced a few brand names in effort to tie everything together – at least in brochures – as a bold, new middleware suite.

But today, the cracks in the suite are showing. Product incompatibilities can’t be patched over with marketing copy. The duplication of tools is unmistakable to anyone writing code. And the complexity of this tangle of tools makes training, developing, and troubleshooting take longer than ever.

The vendor’s website might talk about exciting new cloud solutions, but the vendor’s expertise and technology is stuck in the data centers of yesteryear. It turns out that extension cords to the future stretch only so far.

Your life would probably be easier with a unified platform with one set of interfaces, so that whether you’re connecting business applications, publishing APIs, extending your EDI partner network, or building automated workflows, you’re working with one platform, not seven and a half. The world has moved on. Your middleware needs to move on, too.

Challenge #2: Upgrades That Disrupt Development Work

Another pattern we see is that those legacy middleware platforms require a major upgrade every year or two; sometimes vendors even require upgrades twice a year. Depending on your support contract, these upgrades might be mandatory. They’re certainly disruptive.

Servers need to be sidelined for the upgrade. The vendor’s software is loaded and tested. Inevitably some of your code breaks or needs to be rewritten to work with new features and interfaces. Instead of building new products and automating internal processes, you find yourself running fast just to stay in place, writing and building code just to ensure that what was working a month ago still works next week.

After a month or two, the disruption is over, and you can finally resume development without distractions. Meanwhile, the development teams at your competitors have been working steadily, taking advantage of cloud platforms that update themselves.

It’s hard enough to develop code without these kinds of interruptions. Compared to the nonstop development taking place at newer companies, this pull-the-brake-cord approach to middleware might strike you as archaic — and it is. It comes from the era of waterfall development, when development cycles were longer, and product introductions and updates occurred every couple of years, not once or twice a month as a result of the latest sprint.

Everything moves faster now: the economy, your competitors, and the requests you keep getting from sales and marketing. When you’re trying to run a marathon, do you really need to stick with a shoe that needs re-soling every eight miles?

Challenge #3: EDI Technology That Isn’t Integrated With Your Middleware Platform

If your company has multiple supply chains or an extensive partner network, chances are your enterprise architecture includes an EDI platform for onboarding partners and managing trading-network transactions. And chances are that technology is completely separate from the middleware platform or platforms you’re using to connect applications for finance, logistics, and HR. Which means you’ve got one more set of tools and interfaces to learn, and you’re continually having to coordinate and integrate data from all these different systems.

There’s a better way: adopt a middleware platform that supports EDI and B2B networks out of the box. After all, EDI transactions are probably going to affect other business applications. When a partner places an order, your finance and ERP systems will probably need to take notice. Inevitably, business transactions cross departments and teams. Why not adopt an integration platform that reaches everywhere your transaction goes?

If your legacy middleware can’t connect to EDI, find a middleware platform that can.

Learn more about the pitfalls of legacy middleware in our ebook: “7 Warning Signs It’s Time to Modernize Your Legacy Middleware.”

Challenge #4: Time-consuming Development Practices and a Lack of Choice in Tools

Let’s be honest: there are some engineering projects that are going to require your utmost creativity, and there are others that are well understood and can be performed in a standardized way – and that’s fine. Connecting Sales to a finance application, for example, should be a straightforward endeavor. Given the availability of published APIs and ready-to-use connectors, it shouldn’t necessarily require any hand coding at all.

Other projects might require some customization, but even that customization might be able to be delivered through configurations and scripts, rather than, say, days of Java programming.

And then there are projects truly original and possibly proprietary: a company’s algorithm for identifying utility grid usage patterns, for example, or for relating biometric data to IoT devices and visualization systems for caregivers. That advanced work — which is probably related to your company’s core strengths — probably genuinely requires custom programming.

Legacy middleware often gives you one development approach for all these types of work: hand-coding. Whether what you’re building is conventional or cutting-edge, you’re going to end up writing a lot of code. Which takes time. And requires a lot of testing. And means that you can’t develop other things, such as new features or algorithms that might be unique to your company.

In contrast, a modern middleware platform gives you choices. It allows you to hand code whatever you want to hand code. But it also allows you to take advantage of ready-to-use connectors and AI-powered suggestions to help you quickly build high-quality integrations and transformations using low-code techniques. That low-code development takes far less time and requires far less testing. Which means you’ll have more time and money to apply to that really special coding project that distinguishes your team or your company from the rest of the pack.

Challenge #5: Time-consuming Audits and Budget-consuming Software Licenses

In discussing challenge #2, I mentioned those annual or biannual upgrades from legacy middleware vendors. Those upgrades typically involve audits tied to licensing. When the audit is over, the bill comes, and it usually goes up.

Legacy middleware is expensive. You’ve got the software licenses – as high as $400K for a single, 4-core server from some vendors – and audits and upgrades following the audits and the slow development cycles resulting from a mix of old and new tools, as well a requirement for hand-coding most integrations and lots of testing for that hand-coding and interruptions from all of the above.

Integration is essential to anything new you want to build. Sticking with legacy middleware platforms means that integration is going to be slow and costly.

I began by saying that most development teams are being asked to do more with less. Relying on expensive legacy middleware for integration means that while you’re asked to do more, there isn’t much more you can do.

A development team at a competitor might be able to work five times faster than you, simply because they’re not encumbered by that old, slow, and expensive middleware. That competitors’ dev team is doing more with less. Can you do the same?

There’s a better way forward, and it is easily done and affordable. Complement your legacy middleware with a modern, cloud-native integration platform that reduces your overhead, gives you fast, efficient tools, and gives you choices about how to build your code.

The Boomi Advantage for Developers

Let’s talk about what Boomi offers for developers like you.

The unified Boomi Platform is a cloud-native platform designed to make integration fast, reliable, and efficient. Our platform features:

  • A low-code development environment with a drag-and-drop design interface that typically accelerates integration development anywhere from 2X to 5X
  • Support for custom coding and scripting
  • A collection of ready-to-use connectors for common technologies and popular business applications
  • AI-powered guidance for building integrations and data transformations, drawing on the expertise inherent in over 30 TB of anonymized data from over 11,000 customers
  • API Managementdata governanceEDI/B2B managementdata cataloging and preparation, and workflow automation — all in a single, unified platform with consistent interfaces
  • A flexible, scalable architecture that allows you to deploy runtime processes wherever they’re needed: in the cloud, on-premises, both in the cloud and on-premises for a hybrid architecture, or across clouds to support multi-cloud architectures
  • A modern cloud platform that automatically updates itself 11 times a year with minimal disruption to development and operations

As I covered in my post about making legacy modernization fast, affordable, and predictable, Boomi delivers more power and efficiency at a lower cost than legacy middleware platforms. (Want case studies? We have them.)

Try the Boomi Platform for your next integration project. And in a time when developers are being asked to do more with less, Boomi gives you more for less cost.

https://resources.boomi.com/resources/blog-posts/five-challenges-building-integrations-with-legacy-middleware



Contact Hathority!

We’ve got a solution when you need it. Our advanced service and support tools provide step-by-step instructions without being put on hold or waiting in line.