Integration Architecture Explained
What is Integration Architecture?
In a well-designed building, the electrics and plumbing usually keep working no matter how many appliances are switched on. Such a building is also capable of extension without having to tear up the blueprints and start again. Why? Because it has good architectural design.
The same applies to software systems. Software architecture is the backbone of any complex computer system. The architecture encompasses all of the software elements, the relationships between the elements and the user interfaces to those elements. The performance and reliability of a software system are highly dependent upon the software architecture.
Well-designed software architecture can be extended with relative ease to accommodate new applications without requiring extensive infrastructure development.
This article describes the most common "Integration" software architectures.
POINT-TO-POINT INTEGRATION ARCHITECTURE
The original architecture used to support systems integration was called Point-to-Point. It derives its name from the direct, tightly bound connections that are made between applications and is the simplest of the integration architectures.
What are advantages of Point-to-Point architecture?
Point-to-Point solutions are often fast and efficient. The efficiency that derives from applications being tightly bound is one reason why at least a few Point-to-Point solutions will continue to be utilized for the foreseeable future.
What are the disadvantages of Point-to-Point architecture?
The down side of Point-to-Point is that, while each individual connection might be relatively straightforward, as the number of applications increases so too does the overall complexity of the environment. This can result in high maintenance costs and a lack of flexibility when it becomes necessary to make changes.
Any discussion with an integration vendor will often start with a presentation showing the mesh of Point-To-Point connections shown here. While Point-to-Point connections are not generally recommended, good software architecture will continue to support occasional Point-to-Point connections because they are often quick to implement and may fit perfectly with a particular requirement.
The drawbacks don't stop there, though. All other aspects of your integrated platform will be adversely affected by an overuse of the Point-to-Point option. Business Activity Monitoring (BAM), for example, is particularly difficult to develop where Point-to-Point connections are in use.
HUB AND SPOKE INTEGRATION ARCHITECTURE
The earliest formal integration technologies worked on the principle that all information coming from the applications had to be processed within a single machine or server called a "hub". Acting as a central point of control, the hub dealt with all message processing including routing, splitting and combining of messages, mapping, and so on.
Hub and Spoke implementations decouple the sending and receiving applications. Unlike Point-to-Point, the applications on either side of the hub can be modified independently of each other. Since applications no longer need to perform data mapping, centralized definition and control of business processes could be easily achieved for the first time.
Hub and Spoke Architecture
What are the advantages of Hub and Spoke architecture?
With Hub and Spoke, the integration environment becomes less complex. Whereas Point-to-Point becomes impossibly complicated as the number of connections increase, Hub and Spoke remains, in principle, simple since all the connections are to and from the hub. Hub and Spoke is the preferred architecture for achieving an easily controlled and managed environment in a medium sized integration project.
What are the disadvantages of Hub and Spoke architecture?
With Hub and Spoke, the initial setup of two-way communications can be challenging. The hub has to coordinate messages flowing between applications, and at the same time applications on both sides of the hub need to work well in a decoupled fashion. Both the source and target applications need some knowledge of each other in order to process messages. This sometimes makes it difficult to add or remove senders and receivers.
Since the hub must control all of the integrated processes, it is a viable option only when both sender and receiver agree on which hub to use. This will not be a problem for companies that are integrating internally, but may become a serious issue for Business to Business (B2B) and even cross-departmental integration projects.
Unfortunately, with so much processing taking place in the central hub, Hub and Spoke exacts high overheads. Processes within the hub often require significant processing power and lots of disk space. As the number and complexity of processes increase, performance can suffer and hubs often become difficult to manage, maintain, and extend.
Pure Hub and Spoke implementations do not scale well. One solution is to create a Federated architecture, which is an extension of Hub and Spoke that allows for multiple hubs to provide load sharing and back-up in case of failure.
DISTRIBUTED INTEGRATION ARCHITECTURE
One solution to the Hub and Spoke scalability issue is to perform message translation, routing, splitting, and combining closer to the source and target systems by using smaller computers known as "agents." Agent computers are connected to just one system and reduce the processing load on that system. Agents take information from the application they are connected to, process it, and send it to any target application(s) interested in receiving that information. The end result is Distributed Architecture. It is also known as Peer to Peer architecture.
Distributed Integration Architecture
What are the advantages of Distributed architecture?
Distributed architecture is governed by centralized rules and the requirements of the business flow. Most of the processing is performed in agent processors located near the source and target applications. Besides gains in processing efficiency by distributing the workload among dedicated processors, a Distributed Architecture is able to grow relatively easily. This ability to scale is a clear improvement on Point-to-Point and Hub and Spoke solutions.
Early attempts at Distributed Architecture would only work where the internal and external facilities operated under the same distributed technology. The choices available were:
- CORBA (Common Object Request Broker Architecture) This was the Object Management Group's (OMG) open, vendor-independent architecture and infrastructure that computer applications employed to work together over networks.
- Microsoft's COM (Common Object Model) This was later to become Distributed COM (DCOM) and a transactional version called COM+ was created later still. All of these have subsequently been combined with Microsoft's .NET initiative.
- Java RMI (Remote Method Invocation) Java RMI enabled the creation of distributed Java-based to Java-based applications. It is now available in several software packages from Sun Systems.
What are the disadvantages of Distributed Architecture?
Many organizations have a mix of platforms and operating systems on which their business applications run, a situation that is often the result of mergers and acquisitions. When it becomes necessary to change or expand the system architecture, it is unfortunately not simply a matter of choosing one of the distributed technologies and implementing it. Opting for one technology may only provide a distributed solution for half of your organization due to the mix of systems that are being used.
Beyond these internal problems, there is also the issue of engaging in Business to Business (B2B) exchanges with other companies. This is another case where an eclectic mix of systems and technologies between businesses can impede the use of Distributed Architecture.
Vendors attempted to create various "bridges" between CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Common Object Module) in an attempt to overcome these problems. However, these solutions never really gained acceptance in the marketplace. While the concept of a distributed environment showed promise for a long time, the business community never adopted it in great numbers.
SERVICE ORIENTED ARCHITECTURE (SOA)
Service Oriented Architecture (SOA) is the latest architectural approach, although it's not really very new. Service Oriented Architecture is essentially an enhanced version of Distributed Architecture that uses loosely coupled software services to support the requirements of business processes and software users. It goes a step further than the previous architectures by providing an integrated environment which spreads out the workload, breaking down the different "silos" of business functionality and opening their processes to other applications.
One way to think of SOA is like a Lego set. A Lego set is more than just the individual blocks; specialized bigger pieces for complex creations are also available. Similarly, with SOA, an application can customize and/or change the individual pieces or "services" that it uses. Using these concepts, vast and complex component based applications can be developed.
Service Oriented Architecture (SOA)
What new developments support Service Oriented Architecture?
The breakthrough for SOA came with the acceptance of Web Services. Although CORBA, DCOM, and the like have been available for constructing SOAs for a number of years, the advent of Web Services was the first time that Microsoft and IBM could finally agree on a communication standard. They both wholeheartedly embrace Web Services.
After Web Services came Enterprise Service Bus (ESB) technology. Based on Web Services, and exhibiting all of the characteristics of the Messaging and BPM solutions previously supplied by the integration vendors, ESB has become the accepted standard for the creation of an organization's Service Oriented Architecture.
Without exception all of the integration vendors now provide an SOA architecture built on the concept of an Enterprise Service Bus (ESB).
Thanks to Web Services there's now a thriving integration industry that is creating more and improved services that can be used to construct bigger and better business solutions. There were initial concerns about reliability and security but these have now been dealt with. There seems to be no stopping the universal acceptance of the Enterprise Service Bus and Service Oriented Architecture.
- Systems Integration Made Friendly (Digital Book)
For IT Managers and Developers who would like an overview of Systems Integration but don't need (or want) to get into specifics. Covers: Web Services, Enterprise Service Bus (ESB), Enterprise Portal, SOA, B2B, ERP & Integration Blueprinting.
- Systems Integration Resource Centre
References to integration-related publications.
Specialist provider of Integration Blueprinting services.
- Integration Competency Center (ICC)
Shared service function within an organization for performing methodical Data Integration , System Integration or Enterprise Application Integration.
- Integration Technology Providers
Links to over 20 key players in the Integration market.
- Systems Integration Explained
Covering: Process Automation, Data to Data Integration, Enterprise Portal and Business Activity Monitoring
More by this Author
When did payments via the Internet first begin? The Internet has been used as a vehicle for the payment of goods and services online since the mid 1980s, but only really took off in the 1990s when more online...
An explanation of Systems Integration for IT managers and software developers who would like to have a simple overview of Systems Integration and not get lost in technical jargon.
It’s important to understand the relationship between returns and chargebacks. Both are ways for customers to get their money back, but the processes involved are very different. What Exactly are Returns and...