Complex integration projects demand best practices

Complex integration projects demand best practices

on Jul 1, 14 • by Chris Bubinas • with No Comments

Industry expert Aaron Mulder recently offered a number of key best practices for complex software integration projects...

Home » Code Review » Complex integration projects demand best practices

Integration is a major focus in the world of software development today. The struggle, and later success, of the HealthCare.gov website is undoubtedly the most widely known example, as this project effectively unified a wide range of disparate insurance portals into a single entity. While not as large-scale, many businesses face similar projects as they consolidate, combine and connect various systems.

Writing for the SD Times, industry expert Aaron Mulder recently offered a number of key best practices for complex software integration projects.

1. Build in monitoring
As Mulder explained, it is inevitable that any integration project will encounter problems. No matter how skilled and experienced the teams involved are, systems will crash and delays will emerge. By deploying advanced monitoring solutions from the very beginning of the project, these problems can be minimized and overcome with as little hand-wringing and panic as possible.

"[S]imply monitoring for failures in any of the integration points can mean the difference between proactive fixes and customers complaining that their requests were never completed," wrote Mulder.

To truly be effective, though, Mulder emphasized the need to go beyond solely building in monitoring support – software developers and team leaders must make a concerted effort to actually utilize these resources early and often. For example, he recommended developing automated tests that capture messages and responses. This allows developers to allow the monitoring system to discover issues, rather than manually testing consistently.

"It may seem like more work upfront, but having all the plumbing in place sure beats 'monitoring support' that's never been tried in practice," the writer explained.

2. Separate integration from application logic
Another critical best practice, according to Mulder, is separating integration logic from application logic. These are two distinct areas with distinct functions, and equating the two will lead to unnecessary complications and problems. A user-facing application, for example, should not be used for converting synchronous and asynchronous requests or translating data formats. These and other integration-specific issues demand integration-specific processes and policies.

The overriding concept, according to Mulder, is that developers must build "a service that can easily adapt to changing integration partners, formats or endpoints, [while] leaving the application side of the interface fairly clean."

3. Use the right tools
One final, essential best practice is using the right tools. Without the correct solutions and resources, software developers will struggle to achieve their integration goals.

According to Mulder, it is imperative that the tools chosen are all capable of improving and simplifying the integration process. They should be easy to use, test, configure, debug and deploy. He emphasized the need for solutions that support numerous options for developers building integration logic.

Considering the collaborative and comprehensive nature of many integration projects, it will usually prove particularly essential for organizations to select and deploy tools that can enable multiple developers to work on a particular piece of code simultaneously. Static code analysis tools that operate on the entire code base and work across the entire team allow this degree of cooperation, and can play a powerful role in integration, as well as many other software development projects.

As Mulder noted, though, it is oftentimes difficult for decision-makers to distinguish between the various options at their disposal when it comes to software tools. From a spec sheet, they appear essentially the same. He therefore argued that the only course of action is to gain hands-on experiences with the various options, discovering which ones are truly the right fit for a given organization or a particular project.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top