The pain of application integration: The age of cloud can not relieve pain

Application integration has become a pain point for corporate software since the middle of the 1980, and it was the first time I started it reporting. The same old problem allows different software to coexist, mostly because the owners ' equity is higher than the open standard. In addition, application integration is always the idea that buyers are attracted by the latest applications, and the integrated pain points are often forgotten.

These two factors have not changed in the cloud computing era, so I suspect that new cloud-based Integration Services will do the same. I am also hopeful that some of the cloud services in the enterprise software practice are the primary integration strategy and radical change.

As early as the 1980, internal departmental applications were often incompatible with each other. Integration of customers and partner software? Forget it. In this babel scenario, most businesses build a hybrid application in different operating systems, databases, and development languages.

What happens next? Ideally, software and hardware manufacturers collaborate on standards, interfaces, and other foundations that allow all things to work together better. The problems of interoperability and integration fade away, creating the creative and innovative money-making patterns that arise. Instead proprietary packaged software creates short-term things for those buyers who buy everything from a manufacturer.

The "Dense moon phase" will combine prices to increase and lead to a glut of kits. The emergence of open source operating systems (especially Linux) and the application lock-in caused by vendors are especially daunting, as innovators create better points of product than some software application components. Some enterprises want full open source or mixed open source and proprietary software, but all face the problem of integration.

They did it. In TechTarget's recent survey, application integration is the primary cloud issue for Software architects, engineering, and C-level executives. In the latest 2013 TechTarget Cloud Pulse Survey, many respondents said they ignored customization and integration issues until problems arose. Another 64% of respondents said that connecting data, applications and processes between the cloud and the local system was an immediate or imminent problem.

Similarly, the TechTarget applications Survey 2012 of respondents ranked integration and customization as the primary issue for Software as a service (SaaS) application (14%). In the Cloud Pulse survey, SaaS applications were the integration challenge for 34% of respondents, and their projects could not interact with other cloud or internal projects. Once again, customization is tightly linked to integration: Instant customization, 34%cloud Pulse respondents still say SaaS applications do not apply to their client business requirements.

According to Cloud Pulse survey respondents, Ovum senior analyst Saurabh Sharma and Cimi cloud consultant Tom Nolle, added cloud applications to the enterprise application portfolio, addressing the thorny issues. They once again told me that strange applications are mixed together, legacy systems, moves, clouds, and so on, but in this case they are in a dynamic resource allocation environment, each of which complicates integration more difficult. Things move to the cloud, and the integration of applications and data is more difficult to implement, Nolle said.

Proprietary protectionism, the integration barrier I mentioned above, is supported by most SaaS vendors, and Sharma says it is not possible for the industry to transform every architecture for the cloud computing table and make things easier. In addition, the Web Service Application Interface (API) does not commit silver bullets to a clear integration between SaaS and local applications. That's because local applications are developed under different standards and typically require more customization of code development to interact with the SaaS environment.

Even though human greed locks the standard, there is hope for integration between cloud and local applications. Platform as a service (PaaS) helps developers build applications that are compatible with the cloud. Cloud Pulse respondents were asked what factors led them to choose their PAAs provider:

49% indicates that the provider is part of the planned cloud ecosystem;

36% indicates that the provider supports the application development language;

35% point out the integration of the provider and the existing architecture;

31% indicates that the provider has better performance or functionality than other providers;

25% reporting developers already have experience with this PAAs platform.

The PAAs platform is primarily used to develop and deploy cloud applications, 63% of respondents said. PAAs also extends the role of SaaS products in applications such as SAP (43%), developing and deploying mobile applications (40%) and providing an application test environment (36%).

Service-Oriented Architecture (SOA) provides a strong integration base in many ways, including reducing integration costs by exposing services that are dependent on open source standards. Built on the Web services paradigm, SOA applications can easily migrate to the cloud and integrate with other web-based services projects, and they are well able to bite the cloud's relational model of application to resources.

Moving to the DevOps team requires developers to consider deploying strategies and it to provide interoperability and to consolidate context for developers.

New cloud-based tools and services provide some comfort, including current application integration tools and services such as Dell Boomi, Informatica, Cloudswitch Integration Services, IBM Cast Iron, Mulesoft, and more. New tools and services are also evolving. For example, Tasktop's introduction to the Software Lifecycle Integration service, which promises to fix the integration strategy in the business plan of the Enterprise, is a prior, not an afterthought.

More integration expectations

I recently saw a job advertisement for an integrated architect position. If this is to be transferred to an in-house integration specialist, I fully agree. Integration is not "hindsight," especially if this is the core focus of DevOps team members.

Open standards will be the Holy grail of application integration and interoperability. Until vendors find a profit-making model of open standards, however, it is easier to put some new integration tools, services, and in-house experts to work.

Translator: Zhang Peiying

(Responsible editor: admin)