Tag: Integration

After several technical previews over the last few months, Red Hat Fuse is officially available. This is a significant release, both for Fuse itself and for integration platforms, because it represents a shift from more traditional, on-premise, centralized integration architecture to distributed, hybrid environment integration architecture.

Integration itself has historically been a bottleneck for infrastructure design and changes. The integration points were largely centralized and controlled by a central team in an attempt to manage dependencies and standardize data management between applications. However, that centralization also made change difficult, and it was governed more by procedure and bureaucracy than business innovation. As with traditional infrastructure architecture more generally, integration has not historically been an agile or adaptive architecture.

Red Hat Fuse (and related community projects) is the beginning of a departure from traditional, rigid integration platforms to more agile, distributed integration design. Fuse introduces three major features in the latest release:

Fuse Online, fully hosted Fuse applications and integrations. Fuse Online provides immediate access to the functionality of Fuse, without having to install and configure it on-premise. Developers can begin testing and customizing integrations immediately. Connectors can be uploaded to the online development area to allow even more integrations.

Fuse container images for Red Hat OpenShift. Fuse runs natively on OpenShift, allowing local, containerized integration points to be created in development teams and to be designed, tested, and updated within DevOps workflows as part of the overall application development cycle.

A drag-and-drop UI for integration pattern design. While integration development is typically done within IT teams, integration design relies on business knowledge. Business managers and analysts need to be able to collaborate effectively with their development teams. The new Fuse Ignite UI (based on the Syndesis.io project) is a lowcode way to develop integration — business users can use design elements to create integration architectures and to work with their development teams, within the same tool set.

These three features allow more agile integration development. Fuse installations can span online, on-premise, or container based environments without reducing functionality. This allows an integration platform that crosses environments, and be as lightweight and decentralized as an individual development team or an enterprise-wide platform. The lowcode UI allows business users to be brought directly into the application development cycle, enabling business logic to be incorporated into the integration application design from the beginning.

Additionally, Fuse 7 contains these new features:

Support for Spring Boot deployment for Fuse applications

50 new application connectors (with a total of over 200 included connectors)

At its core, IoT is all about data: data from devices, commands to devices, integrating IoT data with other data to gain insights. The data sources include devices, enterprise applications, vendor/partner systems, service providers and customers. The point-to-point integration between these various systems is not feasible; hence, APIs become the primary means of communication between these disparate systems. A clean architectural approach is the one suggested by the agile integration concept. APIs are central to this concept, which allow data to be shared securely between internal and external systems. The opening of APIs enables a company to provide uniform data and transaction interfaces to internal and external developers, partners, and customers, for improved data access and control of remote resources. By providing well-defined APIs, developers can use data in a programmatic manner; e.g., app developers can get access to IoT devices data without worrying about the underlying hardware interfaces. Considering the importance of APIs for IoT, it’s imperative for an organization to manage these APIs effectively. In fact, APIs have been called a fundamental enabler of IoT however, without an effective API Management solution, API sprawl can easily lead to catastrophe.

In the mid 90s, Bill Gates famously said that “banking is necessary, banks are not.” There is certainly a lot of truth in this statement. We all need banking services in some shape or form. But who delivers these services to us is secondary. In fact, Accenture concluded in a study conducted in 2016 asking over 30,000 people in 18 countries that if the tech titans like Google, Amazon, or Facebook would offer such services, 31% of the respondents would switch to them. This clearly imposes a significant threat on traditional banking institutions.

Another challenge that banks are facing worldwide are the increasing demands for regulatory compliance with respect to openness. Such regulations include, for instance, Payment Services Directive 2 (PSD2) in Europe, the Amendment Bill to Japanese Banking Law in Japan, the National Payments Corporation of India (NPCI) with the Unified Payment Interface, UK’s Open Banking standard by the Competition and Markets Authority (CMA), or the Open Banking Regime by Australia’s Federal Government. Banks approach these regulatory challenges in many different ways. Some see it as a serious business threat and only do the bare minimum for compliance; others see it as an opportunity and with smart investment start building banking platforms for the future.

Our suggestion for building the banking platform of the future resides on the principles of agile integration, which is an architectural approach centered around application programming interfaces (APIs) and API management. At its core, agile integration resides on the three pillars: distributed integration for greater flexibility, containers for the ability to scale better, and managed APIs for re-usability and hence speed. We described the details in an earlier post.

Earlier this months at the Gartner ITxpo event, Massimo Pezzini presented the challenges that must be addressed by a pervasive enterprise integration strategy. In summary there are four types of hybrid challenges (see Massimo’s diagram below).

Continue reading “How to Address the Challenges of a Pervasive Integration Strategy”

If you Google the term “agile integration,” you’ll come up with about 30 million results, but they focus heavily on one area: continuous integration within agile development. That definition of agile integration is based on the build environment.

However, it is possible to have another definition for “agile integration,” one that looks at the platform architecture.

Traditional vs. agile as an architectural approach

There are functional similarities between traditional integration and agile integration – like routing, connectivity, and orchestration capabilities. The difference between traditional enterprise application integration and agile integration is not in the tasks performed, but in the strategic perspective of those tasks. Put simply, integration can be viewed as a necessary but often limited part of the infrastructure (traditional) or it could be viewed as the core framework of the application architecture (agile).

We are pleased to announce that Red Hat Fuse has recently completed the SAP certification process for BOR API Certification and Red Hat Fuse is now a SAP certified solution.

Red Hat Fuse is an open source, lightweight enterprise service bus (ESB). It delivers a robust, cost-effective, and modular integration platform that lets enterprises easily connect their disparate applications, services, or devices in real time. An integrated enterprise is able to provide better products and innovative services to its customers. A flexible architecture coupled with popular and proven integration tools enables Red Hat Fuse to integrate everything, everywhere.

Red Hat Fuse provides a certified enterprise integration solution with SAP, enabling Camel routes running in Red Hat Fuse to retrieve all business objects from the SAP business object repository (BOR), the metadata and documentation of their business application programming interfaces (BAPIs), and to invoke all the methods of a BAPI. In addition it provides a certified solution for invoking non-BAPI remote function modules (RFMs). The performance of Red Hat Fuse is certified to maintain multiple connections to SAP, handle the transfer of large amounts of data and to handle multiple concurrent calls to BAPI methods. In addition, Red Hat Fuse is certified to properly process any Unicode characters passed in remote function calls.

There have been a couple of events lately that, at least tangentially, made me think about information and what we do with it. There have been a series of DDOS attacks on popular sites, at least one of which was driven by a blind army of smart devices. The other is the volatile and ultimately inaccurate polling leading into the US Presidential election. Both of these hint at the Wild West nature of technology — its flexibility and newness offers a lot of promise and a lot of unknown risks. So the theme for this week is — what is the quality of data and analytics and how do we do it “right.”

Integration is one of those concepts that is easy to “know,” but becomes less obvious that more you try to define it. A basic, casual definition is making different things work together. The complexity, though, comes from the fact that every single part of that has to be broken down: what are the “things,” what are they doing that makes them “work together,” how are they working, and what is the goal or purpose of them working together. All of those elements can be answered differently for different organizations, or even within the same organization at different times.

An understanding of integration comes from looking at the different potential patterns that you can integrate and then defining the logic behind the integration so you can select the right patterns for your environment.

Integration Patterns

Integration itself is an architectural structure within your infrastructure, rather than an action or specific process. While getting various systems to work together has long been an IT (and organizational) responsibility, integration as a practice became more of a focus in the early 2000s. With emerging large-scale enterprise applications, there became a growing need to get those applications working together without having to redesign or redeploy the applications themselves. That push became integration.

Integration is subdefined by what is being integrated; these are the integration patterns.

There are different types of patterns, depending on perspective. There are patterns based on what is being integrated and then there are patterns based on the topology or design of the integration. Basically, it’s the what and the how.

Data is increasingly moving from being an asset within an organization to one of the key business drivers and products, regardless of industry. The ability to integrate data from disparate sources is a crucial part of business digital strategy. Many organizations have been locked into proprietary and closed software solutions like TIBCO, but as the IT environments transform again into microservices, agile, and cloud-based infrastructures, those proprietary systems may not be able to keep up – or it may be too cost-prohibitive to try. Open source offers standards-based approaches for application interoperability with potentially lower costs and faster development times. This webinar looks at three key aspects of effectively moving from proprietary to open source solutions:

Recommendations for migrating from TIBCO to open source applications

Performing data integrations

Defining automated business processes and logic

Registration is open. The webinar is August 9 at 11:00am Eastern Time (US).

Fun Follow Up: Webinar Q&A

I will collect any questions asked during the webinar, and I’ll do a follow-up post on Friday, August 12, to try to capture the most interesting questions that arise.