Interoperability and challenges in R&D (2/4)
May 8, 2012 1 Comment
The cultural component
Besides technical aspects, the cultural component is often a point you shouldn’t forget if you want your project requiring interoperability between different technologies to be successful.
Technical interoperability is like using a common language. It doesn’t rub the cultural differences.
With our clients, we have observed a lot of different contexts in the field, each bringing new difficulties to make completely different computing cultures to cooperate.
For example, some real life cases we worked on:
- Huge mainframe system back-end integration with a Windows web server in the front,
- SharePoint-based application using SAP processes,
- Rich .NET client used to manipulate decisional data of a SAS repository on Unix,
- iOS application using a full .NET back office and exposed through JSON/REST services.
Coming from different backgrounds, with different cultures and working styles, co-workers often feel hard to communicate, even just to implement the test process to validate the systems that need to interoperate.
In practice, it often takes a person to bridge the gap, someone who has already worked on both universe, or curious enough to get interested on a new set of technology and then acquiring skills to understand the big picture.
Global Benefits
There are plenty of benefits for software’s publishers in interoperability:
Benefit 1: Integrate into customer’s legacy
The first benefit of being interoperable for a software publisher is to allow integration into customer’s legacy environment.
In the IT, the inertia is really high and therefore the obsolescence curve is way longer than the forecast.
The existence of operational and validated systems, the importance of real production data and the habits acquired by users make any movement risky, and inevitably, economically costly in the short term.
So, one of the most important solution choice criteria is to ensure minimal disruption to systems that work.
Therefore, every solution which can integrate with the legacy, evolving step by step, has a major asset to be considered as compared to those who can’t.
Benefit 2: Enlarge your targeted market
The second benefit of interoperability, platform-wide, is to enlarge your targeted market by supporting a maximum of the platforms available as:
- Databases,
- Middlewares,
- Operating systems,
- Web browsers,
- Mobile platforms,
- Cloud platforms.
With a lot of investment, a software publisher can enlarge its target by diversifying platforms where its solutions works on, because many customers impose or favor one technical environment or the other.
Benefit 3: Optimize the value/cost ratio and invest in differentiation
The third interest in interoperating with other software suites is to focus your effort on the differentiation. Levering other software pieces that are doing great with some transversal or mature functions, we can invest our energy, time and money developing more accurate functionalities which will make our offering unique.
Depending on the sector and the application type, this kind of approach can be optimal in terms of generated value for a given cost.
It’s the principle of “best of breed” and effort concentration on the best element for a given sector.
Benefit 4: Comply with any regulatory requirements
Finally, you’ll have to remember that interoperability is often a regulatory requirement.
In a lot of businesses there is regulation to protect customer from being captive of a publisher who’s using too much proprietary formats.
Depending on the market situation, some legal work made sometime necessary to maintain the competition. Depending on the region, there are various laws to protect interoperability, from format regulations, to decompilation authorization, not to mention the very visible anti-trust actions that sometimes target the giant companies.
The lawmakers try to preserve a balance between intellectual property protection and the assurance of a competitive environment serving customers interest.
Interoperability can be defined for pipes (aka shallow interoperability), or contents (aka deep interoperability). Perhaps it’s time to deal with the latter.