Syncing and Linking Trade-offs – How Kovair Manages Both

According to the International Data Corporation – IDC report, there will be around $270 billion spending on ICT products and services in 2015. Much of this spending is directed towards the maintenance of software. According to the Lehman’s Law on Software Quality Evolution, quality of a system declines unless it is rigorously maintained.

In order to develop and maintain software efficiently, it is important that each phase like Requirements gathering, Coding, Testing and Defect tracking are carried out in perfect synchronization between tools. Ensuring synchronization necessitates that all stakeholders and toolsets involved in various phases of the development are brought together or ‘Integrated’.

One of the many ways to achieve this is data synchronization or data ‘Syncing’ which means replication of data from source tool to target tool. The other means of bridging information gaps between stakeholders is ‘Linking’. Unlike ‘Syncing’ there is no data replication involved. In ‘Linking’, the concepts of data federation and data virtualization are employed in order to achieve inter-tool data visibility. Here the data from other tools are made visible to users by means of virtual links. Stakeholders can follow the links to view or modify data in any other tool from their own tool environment.

Fig: Bi-directional Data Syncing between a Pair of Tools

Syncing – How it helps

Synchronization of data between tools helps geographically distributed teams to have a real-time status and information of what other team members are doing. It reduces communication time that is otherwise spent on series of email chains and long calls. This results in improved team productivity and product quality.

An accuracy in auditing increases when data between tools are integrated and visible through a single interface. The managers do not need to hop around tools and resources to know the predictability of a release, thus making the process more accurate and trustworthy.

As goes the saying “Change is the only constant factor in life”, change requests have also become an integral part of the software development process today. This makes the decision for implementation tougher in the absence of proper impact analysis. For a proper impact analysis, the stakeholders of different stages of development need to be abreast of the changes in real time which can be facilitated by ‘Syncing’.

The presence of multiple tools for multiple purposes often becomes a major hindrance in implementing an efficient workflow. Let us take an example here. Every time a code is checked in to SVN – a source code repository tool, a build needs to be triggered in Hudson. In absence of ‘Syncing’ between tools and the facility to design workflow across tools, this process has to happen manually which is a very counter-productive activity.

Fig: Data 1 in Tool A Linked to Tool B

Challenges of syncing – An introduction to linking

Further to the discussions above, it seems ‘Syncing’ is the ultimate solution to achieve an integrated tool set. However, some of its constraints cannot be ignored as well.

Some of the tools especially the IDE’s like Eclipse, Visual Studio do not have their own storage. Replicating data or Syncing of Data doesn’t quite work in such cases.

It is often required that the data from multiple tools be visible from inside the tools without having to store the hundreds or thousands of data in the respective tools. Such a feat can only be accomplished with Linking.

Getting real-time updates on data syncing status is also a critical challenge. For any of the data getting changed in one tool, the bulk data replicated across multiple tool instances needs to be updated concurrently. Though handled efficiently by the synchronization capability of Kovair Omnibus, propagating such updates to the ‘n’ number of tools in real time can become a bit time consuming at times.

The solution to these problems lies in ‘Linking’ of data. It involves creating virtual links between data of two tools. This enables stakeholders in one tool to have real-time visibility into the data of another tool by using virtual or federated links of data. With ‘Linking’, data residing in a particular tool can be viewed or modified by a user from another tool environment. This approach has its own advantages over syncing.

Advantages of Linking

No storage is required in any of the tools other than the tool where the data is originating from. It also has its disadvantages if you want some reporting and analytics, it is not possible!

Virtual links give visibility into the data as they are residing in the other tools, from one tool. This proves to be a beneficial solution for the IDE’s which do not have their storage. A developer working in such an IDE is thus spared from having to move in between the different tools to get the glimpse of data residing in the other tools.

The ‘Data Federation Linking’ mechanism is particularly helpful in SCM tool integration. These links enable users to access code file contents directly from a tool without having to connect to the SCM tool server or to maintain a local copy of the source file.

Fig: Data 2 in Tool B Linked to Tool A

What Linking fails to achieve

Replicating data in multiple tools as well as to a central repository tool empowers users to generate cross-tool data based consolidated reports, metrics, and KPIs. It also enables traceability between data residing in different tools. Implementation of some effective policies and workflows becomes a possibility when data between multiple tools are synchronized. All these things cannot be achieved with the help of ‘Linking’.

Sometimes, tools where data resides may face a substantial downtime. In the worst case, there might be a partial or complete loss of data due to a number of unavoidable circumstances. Under such conditions the data may be unavailable to connected tools using virtual links.

Conclusion

Having talked about the mechanics of Syncing and Linking, and their advantages and disadvantages, it would be worth mentioning that both are practical options in integrating toolsets and keeping the stakeholders ‘Integrated’. It is actually the business case that dictates the approach to be used.

The Kovair Omnibus Integration Platform is one of the leading tools in the market which supports integration by both Syncing and Linking. It employs an ESB (Enterprise Service Bus) framework based on the SOA (Service Oriented Architecture) technology in order to achieve integrations among different tools.

Kovair Omnibus Integration Platform achieves seamless data movement with effective SOA technology. With multiple powerful synchronization monitoring tools on the Omnibus Platform, the user gets to see the status of data syncing as and when they are happening. Kovair application also comes with some effective reporting mechanism which allow the user to derive reports from the data coming in from different integrated toolsets. With the data coming in from different tools Kovair facilitates the creation of automated processes and polices which allows various actions to be performed in the different tools remotely.

Besides moving the data across multiple tools, Kovair empowers to monitor the data movements across the tools with multiple interactive data sync monitoring tools. The monitoring tools give data in textual as well as graphical formats catering to the micro to macro level information needs about the syncing as and when they are occurring.

‘OSLC Linking’ and ‘Federation Linking to SCM Repositories’ are also some of the features that can be achieved with ‘Linking’ using the Omnibus Integration Platform. Kovair offers some powerful plugin capabilities for IDE’s like Eclipse and Visual Studio that allow the developers to view artifacts in different tools without physically signing into those tools.

Data visibility into other tools from non-repository tools like the Eclipse or Visual Studio is further facilitated with the help of Kovair Omnibus Plugin for IDE’s. With the aid of Plugins the developer is spared the task of running into multiple cross functional teams for information about the Requirements or QA. Instead all the information remain visible to the developers with the provision of modifying the same if required, all with the help of Kovair Omnibus Plugins.

Arunava Bhattacharya is a Software Engineer at Kovair Software, specializing in corporate solutions and services. Designing configurations to satisfy customers' ALM use cases is his core competency. He also takes keen interest in technical writing and photography.