8 Factors that Adversely Impact Cloud Application Integration

As we actively engage in the rapidly evolving and rich spectrum of technologies and methods for application integration, we often overlook some of the intangible factors that can significantly influence the decisions, approaches, and ultimately, the outcome of projects involving such integrations. This is particularly important when such projects involve integrating applications hosted outside an organization’s firewall, typically by a third party (cloud app vendor), with those hosted internally. Such integrations have fewer stakeholders than touch points within the organization. Here, technology offers far less challenges as compared to the organizational hurdles that I will briefly discuss here.

The hurdles mostly refer to the lack of preparedness, lack of skills, and often siloed culture of various IT groups within an organization, as they pertain to the implementation of integration needs of their business users. Ignoring these hurdles invariable results in unpleasant surprises when teams embark on their process improvement tasks that require various facets of integrations.

For a decade, we at zAgile have been involved in developing and deploying solutions for integrating applications and processes for organizations, spanning a range of technologies and domains. The issues I discuss here are those that we encountered frequently, irrespective of the size of the organization, the industry, or the applications involved in the integration. Based on our experiences, we strongly feel that all likely participants in integration-related projects, i.e. app vendor, systems integrator, IT engineer and the business user — have a responsibility to recognize and adjust to these hurdles to ensure overall success.

Here, I identify several factors that have, at times, played a significantly negative role in the outcome of integration projects. I divide these into two separate discussions — first, the silos that often exist within an organization that can impact external integration projects, and second, the problems amplified by these silos or directly caused by them.

1. Siloed cloud user community

As cloud applications typically exist outside the IT’s domain (and outside the firewall), they also contribute to the isolation of the business user community from internal IT operations. It is difficult to track all the different cloud applications that business users sign up for to support various aspects of their processes. These applications are typically ‘invisible’ to internal IT teams, who are seldom needed to deploy or support them but may be called upon for tactical engagements, such as those involving integrations.

2. Siloed IT teams

Further to this, we also see internal boundaries, defined by areas of responsibilities, such as the IT groups that manage applications and those responsible for internal infrastructure (network, firewall, security, etc.). Depending on the size of the company, internal IT may have additional separations along the lines drawn by specific applications (one group supports a Wiki and another supports product development tools, and yet another the CRM application, and so on).

3. Siloed data owners

As each application manages its own data, the principal users of that application (and there isn’t always a clearly defined line here) claim ownership of the data. When it comes to integrations, their reluctance to share this data or insistence on imposing additional access restrictions often blindsides business users who desire to be a consumer of this data via the integrations, to incorporate it into their own process flows. This leads to unplanned, protracted internal negotiations and project delays (or outright cancellations). This is also complicated by the fact that the chosen integration technologies may not support the data separation and access restrictions imposed by different teams.

4. Siloed business processes

For all the justifiable reasons, teams develop and evolve their internal processes that fit their needs. This creates process silos across teams. Application integrations typically cross process boundaries, intending to bridge these silos and implement some limited unification.

5. Siloed objectives

The larger the project, the more stakeholders it may serve. This also leads to further divisions with regards to the overall objectives to be achieved and the specific use cases to be implemented. A generic integration solution tends to satisfy no one in particular and leaves individual teams to finish the last mile to achieve their own objectives. On the other hand, integration solutions directed at specific teams and processes demand collaboration from others who are often reluctant to participate.

Depending on the size of these silos within an organization, their impact on cross-functional projects can vary, application integration being a key example. However, it is almost always burdensome and with negative consequences.

Here are some of the specific ways in which the silos above impact an organization’s ability to effectively achieve success with application integration projects.

6. Familiarity with cloud apps

Mostly as a result of the above, internal IT is unaware and unfamiliar with the cloud applications in use by their business users. As a result, they are unprepared, unskilled, and often unwilling to effectively meet the needs that are imposed by their business users. The more the applications, the more overwhelmed they are in being able to address the tactical requirements for integrations. The preparedness includes everything from internal policies and procedures, as they related to infrastructure, security, data integrity, etc. to governance. Occasionally, it includes the need to support the integration components that reside within the firewall. It also manifests itself via limitations in the design of network and system architectures towards providing support for external integrations.

7. Shared vision

Integration project seldom start with a single unified vision across its constituents. It’s not unreasonable for each team to focus on its own processes to achieve some degree of optimization, efficiency and productivity. However, this also creates a conflict of interest when implementing a single solution to address one or many objectives not shared across teams. Often there is only one team with a vision and requirements for the integration – and that vision isn’t shared or well understood by others who are also equally involved in the implementation cycle.

8. Multiple integration touch points

Integrations, especially those involving cloud applications, will have a number of touch points with an organization — network security, user directory, application itself, the data owned by the application, and the users of the application. These touch points cross multiple silos. The more the touch points, the more difficult it becomes to manage through the simplest of integration projects. Furthermore, it is not just the implementation of the integration components, but also ongoing supports for which the cross-functional teams need to be prepared. These touch points, therefore, add to the vulnerability of the implementation on an ongoing basis.

While departmental specialization and silos are the result of natural evolution in an organization’s lifecycle, it is clear that they can often hinder cross-functional efforts, such as those involving application and system integrations. We continue to see this in our engagements with customers. When such hindrances are observed, it is almost always because of some of the reasons I cite above.

Based on our experience, I strongly feel that enterprises must take proactive measures towards anticipating and planning for application integration, especially with the rapid adoption of cloud applications. The anticipation implies that organizational structure and systems architectures are in place to accommodate and address these needs as they arise. Subsequently, the prep work for such projects must always be to first integrate the teams involved in the initiative to achieve a shared vision for the project. This can make it easier for the teams to follow up with appropriate preparedness, skills, understanding of the key objectives/stakeholders and finally, the success criteria.

Original article published in Infoworld, October 4, 2016