Most of the organizations in today's world have some legacy software or systems. With pressures coming from outsourcing and cost-cutting, new applications are constantly being added to existing IT frameworks. In most cases, it is risky to completely replace the existing systems. As a result, most places have complex applications and systems frameworks. In order to achieve a successful coexistence of several applications on different platforms and technology architecture, teams are faced with some major questions, such as "Should we 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