The minimum and extended ESB capabilities enable the making of an informed decision for adding an additional Enterprise Service Bus to an existing ESB infrastructure, and the technology to use. However, the decision criteria for this technology should not be restricted to these minimum and extended capabilities. In many situations there will be a list of “softer” attributes that will shape the decision, and these are shown in Table 4-2.
Table 4-2 Softer attributes for an additional ESB
The following section describes in more detail the additional softer attributes introduced in Table 4-2 that must be considered for adding an additional ESB to an existing infrastructure.
Attribute Description
Existing ESB technology What ESB technology is deployed today? Maturity of existing ESB
implementation
How long has the existing ESB been deployed? How much investment has been made in its overall
capability?
How well is the ESB delivering its non-functional attributes, for example:
– Performance – Reliability – Serviceability
ESB strategy What is the strategy for the following ESB attributes: Single administration
Single namespace / naming Single security
Governance
Capabilities of existing ESB
How well does the existing ESB implement the minimum (and extended) ESB capabilities?
ESB technology allegiance
Are there any historical or commercial allegiances to a specific ESB technology?
Enterprise integration strategy
What is the overall integration strategy within the enterprise? Single / dual vendor
Analyst ratings
Programming model What strategic programming models and tools are used in the enterprise?
Hardware and operating system
What is the current ESB deployed on?
What is the enterprise strategy for the hardware and operating system?
Existing ESB technology
It is important to understand which products and version numbers are used to implement the existing ESB infrastructure. This is not an actual attribute that will affect the decision for the additional ESB technology. However, no decision can be made without this fundamental piece of information as it may be required in further commercial discussions with its vendor and for understanding its minimum and extended capabilities. This is very important and should not be overlooked because “version n+1” of the existing ESB may have additional capabilities when compared with “version n”.
Maturity of existing ESB implementation
The enterprise may have implemented the latest and greatest version of an ESB but how long has it been in production and how is it performing in terms of functional and non-functional requirements? Understanding this may have a bearing on whether an additional ESB is implemented or whether the existing infrastructure is extended or replaced.
Established ESB example
Many enterprises will have already deployed an environment that displays all of the minimum requirements for an existing ESB (for example, using WebSphere Business Integration Message Broker).
The existing environment might have been deployed for a number of years and had a considerable investment in its overall capability within the enterprise. If we assume that it is delivering satisfactory service then it is reasonable to conclude that this ESB will be retained and the additional ESB will have to integrate with it.
Non-functioning ESB example
We can take an alternative view where the existing ESB displays the following characteristics;
Has only been deployed for a relatively short period of time Has a small number of providers and consumers
Is delivering a marginal level of service
This example may guide us down a number of different paths:
Making additional investment in the existing ESB to bring its level of service and capability up to the required level. And then:
– Extending it to include the requirement for the additional ESB. Therefore, no new, additional ESB is required at all.
– Adding the additional ESB to it for reasons of governance or any other capability reason as discussed in 4.1, “ESB capabilities and decision attributes” on page 58.
Replacing the existing ESB with the new ESB technology so that it consumes the capabilities of the existing ESB. The existing ESB is removed from the enterprise infrastructure.
Capabilities of existing ESB
How well does the existing ESB implement the minimum and extended ESB capabilities?
If the existing ESB implements the minimum capabilities for an ESB and potentially some of the extended capabilities then it is likely that this ESB will be retained and the new ESB added alongside.
However, if the existing ESB does not provide capabilities beyond the minimum ESB capabilities it may be reasonable to choose a new, additional ESB that has strong ESB capabilities and to integrate the two ESBs together using one of the patterns described in this book. This is a realistic situation as many enterprises may have implemented ESB-style capabilities using older technologies that have little investment, and which therefore are unable to grow to meet the requirements of a fully-fledged ESB.
ESB technology allegiance
Many enterprises have an allegiance to a particular vendor or technology. Irrespective of the merits of a particular technology solution for the additional ESB, the historical or commercial allegiance to the existing ESB vendor may be so strong that the decision might have little regard for the strength of other technologies.
Enterprise integration strategy
The enterprise integration strategy for the organization could have a considerable bearing on the selection of the additional ESB technology. For example:
Some enterprises are moving to policies where they are reducing the number of core IT vendors.
Others are continuing on a best-of-breed IT selection policy.
Finally, some enterprises have a policy for building middleware solutions versus buying Commercial Off The Shelf (COTS) software, commonly known as “build versus buy.”
Therefore, the enterprise integration strategy could dictate what type of additional ESB technology is chosen and implemented, irrespective of the capabilities and wider decision criteria.
Programming model
The programming model and development tools used by an enterprise could also have a strong bearing on the implementation choice made for an additional ESB within the enterprise.
For example, a J2EE-centric organization might lean more toward making a WebSphere Application Server service integration bus decision because of the similarities of the programming model for application and mediation
development. Whereas organizations using a longer-established programming model, for example using COBOL as the programming model and its associated programming model, might decide that WebSphere Business Integration
Message Broker has a tighter fit to their programming practices.
Additionally, an organization geared toward Web services might choose to implement their additional ESB using WebSphere Application Server because of the associated tooling capabilities of Rational Application Developer. In particular they may use the Rational Application Developer wizards to build Web services components from existing J2EE components and vice-versa.
Hardware and operating system
We must not forget that the underlying hardware and operating system
infrastructure could have a bearing on the additional ESB decision. For example, the enterprise may have a strategy for deploying new infrastructure deployments on Linux®, or more specifically on particular versions of Linux. These
prerequisite statements might preclude specific additional ESB technologies.