Interoperate or Integrate

In this paper, I consolidate and support some of the points one weighs while deciding to interoperate or to go with integration between the systems or applications that should coexist for successful operations of any organization.

What Is Interoperability?
According to whatis.com, interoperability is defined as "the ability of a system or a product to work with other systems or products without special effort on the part of the customer." Interoperability has become an increasingly important feature for products.

In other words, systems or applications should coexist and work with each other without having to implement major design/code changes at the core or interface level. These systems just "talk" to each other and function in their respective domains without causing much interference within the technology infrastructure.

They may also be referred to as the plug-and-play software components, although a comparison to a plug-and-play device may be an oversimplification.

What Is Integration?
Integration, as normally defined in the software community, is changes (design/code or configuration) made in order to make several software components work together as a system. Integration can be used between new software components or between new components and legacy systems, though the latter is more common.

The changes are made so that several applications may coexist and meet business requirements. This normally needs a lot of analysis and a certain amount of design changes, code changes, and testing?not to mention ongoing maintenance costs.

Which Way Should I Go?
So how does the organization decide how a new product should be implemented? The answer depends on many factors, including: 

• The framework of the legacy system
• Systems built in house vs. third-party applications
• Organizational willingness and ability to invest in development, testing, and maintenance
• Nature of the core business

The Framework of the Legacy System
Depending on the age of the organization, the number of legacy systems supporting the business will vary. For example, if an organization has been around for thirty years, it may still have mainframe systems and probably some software code written in COBOL. On the other hand, if the organization is fairly new-let's say about two to five years old-there may be no legacy system issue. If the organization has a massive number of legacy systems, achieving interoperability with new applications may not be possible or, at the very least, not easy to achieve. This is because most legacy systems were not built with interoperability in mind. In order to make legacy systems work with one another and with new applications, code and design changes are almost always needed and inevitable.

Integration is necessary, to a certain degree. If the organization is fairly young, it is most likely that the existing systems have the ability to interoperate and require very little code and interface changes to implement a new application. One example of interoperability is data transfer using XML. If an application can output data in XML format that is suited to another application, we can achieve the communication channel between the two without having to deal with design and code changes.

If the organization has a lot of legacy systems, then it will be more difficult to choose interoperability over integration.

Systems Built In House vs. Third-Party Applications
If the organization has existed for a considerable period of time and has had a full application development team for a while, it may be more inclined to integrate the applications than try to make them interoperable. Since the knowledge resides within the organization, which includes the subject matter experts (SMEs), more often smaller, internal projects are planned without giving much thought to future technology. If these projects include integration between several applications, this becomes the necessary evil going forward. Changing to interoperability in such cases takes a lot of effort in terms of both cost and time. In such cases, integration becomes the norm.

This may not be the case if the organization has a strong technology strategy and its main objective is to keep integration at a minimum.

Organizational Willingness and Ability to Invest in Development, Testing, and Maintenance
Resorting to integration instead of interoperability substantially increases the overhead of development, testing, and maintenance. Design/code changes require a lot of testing. When a number of applications are integrated, a complete cycle of testing is required to ensure nothing is broken and everything works, so business can continue as usual.

Higher degrees of integration will mean higher maintenance costs for the organization. If an organization is looking at cost saving, it should go toward interoperability rather than integration. If it chooses to outsource or buy from a third-party vendor, interoperability becomes an important quality to consider during the selection of the potential candidate.

On the other hand, if it is the policy of the organization to have its own development center due to security or privacy reasons and the existing applications don't cater to interoperability, integration might be a better option.

Nature of the Core Business
Organizations with a core business that provides services to the general community, like banks, financial institutions, and other retailers, are more likely to have legacy systems. For these organizations, it is harder to get the application to interoperate, and normally some amount of integration is involved when a new application is implemented.

If the organization is a supplier of applications or application suites that are purchased and implemented either as standalone or integrated solutions by other organizations, the approach to interoperability can be radically different. The organization can actually build interoperability into its products. This does not mean that these applications cannot be integrated if need be. Rather, these organizations have an edge in selling something that can be used virtually "out of the box" if the customers desire to do that.

Conclusion
So what is the best implementation for an organization? There is no one, best way. An organization can choose either to interoperate or integrate, or even partially both. It depends on the nature of the business, the technology strategy, and the long- and short-term goals of the organization. It definitely is not a decision that should be made in a split second, but something that should be carefully determined by the stakeholders.