Imagine you could wave a magic wand and suddenly have your applications, data and business workflows integrated without any of the investment or time usually involved.

You'd surely jump at the chance.

After all, when your apps talk seamlessly, your productivity goes up and your operational costs go down.

But since magic wands don't exist, we're giving you the next best thing: 4 pro strategies you can start using today to reduce your integration costs in terms of money and time.

Cost Reduction Strategy #1: Widen Your View

At Launchpad, we see it all the time. A company just wants to integrate app X and app Y around a very specific process or data flow.

That might look like this...

...or this...

...or maybe this...

That narrow view is understandable since the company's immediate need is to solve a very specific pain point today.

But if you take a moment to step back and widen your view, you'll see that app X and app Y aren't the only ones your organization is using.

Those 2 apps probably aren't even the only ones involved in the business workflow in question.

When you widen your view, you suddenly see that the mix of apps that could be integrated might look like this...

...or this...

...or maybe this...

And that's just the wider view of what your company has in place TODAY.

When you also anticipate the apps and more complex workflows that are expected to be part of your company IN THE FUTURE, that's all the more reason to widen your view beyond the here and now so you create an integration that can easily scale up later.

Widening your view is all about gaining a clear understanding of your overall system first, and then working down from there to build a robust and efficient integration.

The alternative is the trap of assuming you can work up to the same robust and efficient integration by tackling one lower-budget, isolated connection at a time. It doesn’t work that way.

Widening your view before starting your integration efforts is all about efficiency.

Think of it this way.

Say you had a construction crew build you one stand-alone room that fulfilled one single purpose for your organization. Then later you repeated that process. And so on, until you had dozens or even hundreds of separate rooms, all constructed with only their singular function in mind.

How likely is it that, after the fact, those rooms would fit together to provide an efficient office complex?

And how likely is it that you would have spent the least amount of money and time to get to that point?

In contrast, say you widened your view first and developed a blueprint that considered all the rooms and functions your company needed to operate smoothly, both now and in the future. And with that map in hand first, you then started construction...even if you didn't build everything all at once.

In that wide-view approach, the rooms would fit together efficiently by design. They'd also accommodate scaling up with new rooms later.

And you would have taken the most cost-effective route in terms of money and time.

Bottom Line: Widening your view before starting your integration efforts is all about efficiency. It gives you the overview you need of the territory to avoid costly redundancy, detours and haphazard systems.

COST REDUCTION STRATEGY #2: Look for Reusability of Your Data

This strategy is related to Strategy #1 about widening your view.

In this specific case, a narrow view will increase the cost of your integrations over time because you'll end up creating more connectors than you need to.

For example, imagine that TODAY you need a piece of data from your accounting platform (e.g., Sage, FinancialForce, etc.) to flow into your Enterprise Resource Planning (ERP) platform (e.g., NetSuite, SAP, etc.). If you have a narrow view, you'll only see the need for an integration between those 2 nodes. So you pay to have that connector created. Problem solved.

But then LATER, you realize you need that same piece of data to also flow into your HR software. So you pay to have that additional connector created. Problem solved...or so it seems.

The reality is you might not have needed a new connector at all.

By using the strategy of looking for reusability of your data, you can build ONE connector that you simply reuse with any and all apps that data is compatible with, both today and tomorrow.

If the nature of the data in question is compatible with both your ERP platform and your accounting software (and any others), then extra architecture didn't need to be built...IF your original configuration was created to handle multiple data flows.

In other words, by using the strategy of looking for reusability of your data, you can build ONE connector that you simply reuse with any and all apps that data is compatible with, both today and tomorrow.

When you reuse data and connections this way, you can drastically reduce your integration and data connectivity costs.

Why?

Because you build once, then use those connectors multiple times. That reusability gives you increased efficiency and maintainability with lower costs of scalability.

The graph below illustrates the actual math behind the cost savings:

Companies that don't leverage reusability of data end up following the trajectory of the yellow line in the chart above. They create more and more connections, each with a single, narrow function.

That approach might seem easier and less costly at first. After all, as the chart shows, if you only have 4 nodes at first, you only need 6 connectors to get them integrated.

But that yellow line is exponential, not linear. So even the small step up to 5 nodes means a big jump up to 10 connections.

And 10 nodes means 45 connections, 20 nodes means 190 connections, 50 nodes means 1225 connections, and so on, until your whole system quickly becomes overly complicated and expensive in terms of building and maintaining.

That's exactly the nightmare one of our Fortune 500 clients – CRM giant Salesforce – was facing.

They had 54 nodes and were headed down the road toward building an unwieldy 1400 connections.

The illustration above shows what's known as a Point-to-Point (P2P) network.

In a P2P network, all your process flows between 2 systems are direct. There's no logic layer between the nodes. There's no intermediate transformation of data. It's inefficient and certainly not cost-effective.

So, what's the alternative?

A modern Enterprise Service Bus (ESB) architecture.

With an ESB model, you gain the advantage of having connectivity from any and all your apps through the central intermediate ESB layer.

And that's exactly how we helped that same Fortune 500 client.

With an ESB model, when any app needs access to a piece of data, there's no need for you to create (or recreate) another data connection. Instead, everything gets routed through your ESB layer.

Bottom Line: By looking for reusability of your data and using an Enterprise Service Bus (ESB) architecture, you increase your integration's reusability and scalability, which gives you the most cost-effective approach for both development and maintenance.

How To Gain Scalability Without Overpaying

Imagine your organization is a little larger. You're running a grand total of 20 critical apps and peripherals all together.

You find an integration product in the marketplace. The Tier 1 package handles from 2 to 19 systems. The Tier 2 package handles 20 to 100 systems.

Which do you choose?

Tier 1 means you can't scale up. Tier 2 means you're overpaying for big scalability you're not using yet.

So how do you gain true scalability without overpaying?

An ESB (Enterprise Service Bus) architecture gives you true scalability without paying for a big system price tag.

Once your ESB platform is in place between your people and your apps, it can scale up as and when needed to as many additional data flows as you'll ever need while reusing smart many-to-many connectors that save you money.

COST REDUCTION STRATEGY #3: Avoid the Mistake of Thinking "Out-of-the-Box" is Less Expensive

Preconfigured connections are often marketed as being affordable "out-of-the-box" data integration solutions.

The idea is that you're able to save money by purchasing a generic connection that requires little to no modification.

It sounds nice, but that approach only works with VERY simple systems.

Even small to mid-sized organizations typically have enough complexity in their data systems and application workflows to find that out-of-the-box connectors aren't a valid integration solution.

But if you do decide to purchase an out-of-the-box connector, and you manage to nail down exactly what it supports and how it can be configured before you buy it (to make sure it will fit with your unique system and mix of apps), there's still another factor: the amount of time needed for post-purchase customizations is commonly underestimated.

That means you could end up spending 3 to 4x the cost of the connector itself just to get it working in your organization.

That's not to say generic out-of-the-box connectors are never an option. If you have a very simple organization with only a few nodes and just a handful of connections needed, they could work.

But if your company or organization has any amount of customization of data stores and flows, then generic connectors might not be able to handle your complexity.

Your organization's process is probably unique enough to have outgrown generic out-of-the-box connectors.

In contrast, custom developed integration solutions are specifically designed to work seamless with your system, no matter how complex it is. And while custom solutions represent a larger initial investment, they actually reduce your costs over the long term by lowering your maintenance needs while being designed to support future scaling.

Bottom Line: Your organization's process is probably unique enough to have outgrown generic out-of-the-box connectors, especially when you employ Strategy #1 (Widen Your View) and Strategy #2 (Look for Reusability of Your Data).

COST REDUCTION STRATEGY #4: Factor in the Cost of Maintenance & Support Early

It would be nice if you could get your applications and data integration configured once and then simply let it run without any further attention being required.

But that's not the case. After all, your apps, systems, security protocols and more will need upgrades and monitoring to confirm they're working properly, and that your data is safe.

That's why you need to factor in the operational expenditure of maintenance and support. And the earlier the better.

Why?

Because your mission-critical data and processes can't be trusted to just anybody.

If you're going to rely on internal team members for maintenance and support, you need to be sure:

• Their other duties won't prevent them from having the time available to run and monitor your system.

• They'll always be up to date on the latest system requirements and updates.

• They have the expertise and tools to detect if and when any data issues crop up (e.g., data corruption or inconsistencies across nodes).

If you're not sure your internal team members will pass the test of those considerations, then you should consider turning to external resources.

If you're going to rely on external specialists for maintenance and support, then on top of the considerations listed above, you also need to be sure:

• They have a growing team that can handle taking on new clients.

• They are easy to reach.

• They are easy to work with.

• They are affordable.

Without those considerations in place, your data and integration's support and maintenance will be inconsistent at best, and vulnerable at worst...both of which will result in more work and operational costs for you.

With reliable, professional support and maintenance being so vital to any organization's data integration, you would think that companies providing custom integration services would always include managed services as part of their development packages. But they don’t.

At Launchpad, we're different.

All our packages include:

• Ongoing server maintenance (OS & security upgrades)

• Sandbox and production instances

• Monitoring software/services and monthly statistic reports

• Daily review of message routes and logs

• Support hours per month (per package) of bug fixes/inquiries

• Reduced rate for additional fixes/changes/inquiries

• Core hours of real-time support

• 24x7 online ticketing system
  
  

Built-in support and maintenance from dedicated experts are especially important when you consider the large number of languages and platforms that companies commonly leverage today. Fortunately for our clients, we speak them all.

Bottom Line: No matter how simple or complex your integration is, you'll need ongoing support and maintenance. You'll keep your costs down by making sure you have a professional integration management team in your corner right from the start.

SUMMARY & NEXT STEPS

So, those are the 4 pro strategies you can start using today to reduce your integration costs in terms of money and time:

1. Widen Your View

2. Look for Reusability of Your Data

3. Avoid the Mistake of Thinking "Out-of-the-Box" is Less Expensive

4. Factor in the Cost of Maintenance & Support Early

If you're relying on your in-house team to map, create and support your integration, it will likely be your central IT group or a business tech group that owns and drives that process. Use the information in this article to make sure they're up to the task.

If you're looking for a dedicated team of specialists to handle everything for you, then you can count on our integration experts at Launchpad. That's how we help our clients every day.