Brief introduction to the pain of application integration

Application integration in the middle of the 1980 has become the enterprise software pain Point, the same old problems so that different software coexistence, the main reason is that the owner's equity is higher than the open standard. In addition, application integration is always the idea that buyers are attracted by the latest applications, so the integrated pain points are often forgotten.

Neither of these factors has changed in the cloud computing era, as is the case with new cloud-based Integration Services. I have at least a bit of hope for this because some of the cloud services in enterprise software practices are primarily integrated and radically changed.

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 things that allow everything to work better together. 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 recent surveys, application integration is the first 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, respondents included integration and customization as the first issue of Software as a service (SaaS) application (each 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.