The flexibility that cloud promises can have a high cost. Integration, both within the cloud and across the cloud boundary, with applications that are moved into the cloud is complicated. Cloud architects can deal with this complication through automation. Cloud architects should think of integration in workflow terms, align the scope of tools and practices with their application goals, focus extra care on the special transition points and look ahead to how business changes could dictate integration changes.
The purpose of cloud application integration is to connect workflows through components. This connection process should be viewed in a technology-neutral way if possible because most businesses will use the elasticity of the cloud, moving things in and out on demand. Thus, cloud architects want cloud-compatible tools for workflow integration and not cloud-specific tools.
Most cloud integration tools will support a design, deploy and manage progression that relates to the "development and operations" (DevOps) progression familiar to cloud architects. The design phase is aimed at mapping workflows to components, the deployment phase at deploying the components and connecting them to the workflow, and the management phase at supporting lifecycle management and problem management while the application is in service. A cloud integration strategy has to accommodate all of these phases. Manual integration will be necessary at some point if a given tool doesn't do that.
While all integration tasks include those three points of progression, what is supported in each phase will vary depending on the type of cloud application being targeted by the tool provider. For example, if the goal of cloud application integration is to move pieces of current applications to the cloud, then the "design" process is really a matter of mapping components, connecting workflows and managing policies to handle any necessary dynamic positioning of components. If the goal of the integration is to create new cloud-friendly applications that will mean a restructuring of business processes and even new development, then the design process will have to be very sophisticated.
A good example of this issue is projects that address mobile-worker productivity enhancement through more event-driven business processes. This involves the creation of new workflows and new applications, though most of the components may already be available. Simple mapping tools aren't likely to be helpful here, because workflow design is most often a software architect task. It is possible to address this extra complexity through software development tools or to extend the design features of integration tools. Deployment, similarly, may be handled through repurposing DevOps tools like IBM's Service Virtualization or by selecting an integration tool designed to support all three phases, such as Jitterbit.
The three evolutionary phases of cloud integration create two transition points that require special attention. The design-to-deploy transition is similar to the transition intrinsic to DevOps tools -- the goal is to faithfully create what the design phase mandates. However, it's easy for the design-to-deploy transition to become brittle, meaning that practices and tools may be dependent on the specific needs of one or more early target projects.
One possible way to avoid brittle transitions between integration phases is to try to plan considering as wide a range of applications as possible. Many users find this leads to projects without boundaries and vast overruns on requirements and costs. A better approach is to try to generalize the goals of these transitions based on the early projects. Think of the design-to-deploy transition in terms of applying data mappings and business policies from the design phase, with the deployment phase focusing on specific issues of platforms and scaling or failover.
The transition from deployment to management can be complex because it often necessitates looking back to the design phase. The management phase is a combination of application service-level agreement support and application lifecycle management (ALM). The former requires that deployment policies reflect user quality of experience, which means that real-time event-driven interaction is necessary. The ways that this interaction is then fed back to deployment create an interdependency, a two-directional flow. On the ALM side, the workflow models and policies are used to establish goals that ALM processes enforce and validate when changes are made. This means that design-phase activity jumps over deployment to organize management processes, making the true model more complicated than the general linear progression that applies in most cases.
ALM is a good introduction to the final point, which is future-proofing the integration process. Architects point out that cloud integration may be the topic that leads most often to over-specialization when selecting tools and solutions. In particular, there's a tendency to see the deployment phase as the main issue and fail to consider workflow design on the front end or ALM at the back. There is a value to adopting a complete cloud deployment and integration suite, obviously, because these are most likely to track application evolution in the broadest sense.
The problem users report is that the cloud suites tend to be focused on the vendor's own development and middleware tools. IBM, Microsoft and Oracle often share accounts, so it may be difficult to achieve harmony through a suite unless you go to an independent vendor. There is also the option of supporting the three phases of design, deployment and management with phase-specific tools.
It comes back to those transition points. Weaknesses in cloud integration tools and practices will show up at the phase boundaries, so no matter what approach cloud architects take, it's smart to first look closely these points and resolve issues before they grow.
Get the definition for cloud-oritented architecture
All of the essentials on cloud application integration