Calling all integration experts!

Remember the old Universal Translator as modeled here by the late Mr. Spock? One of the first (or perhaps future?) examples of integration solutions, and certainly one of the most fondly remembere! But at its heart, it is also an almost perfect representation of the integration challenges today. Many years ago, there was EAI (Enterprise Application Integration) which was all about integrating homegrown applications with purchased package applications and/or alien applications brought in from Mergers and Acquisitions activity. The challenge was to find a way to make these applications from different planets communicate with one another to increase return on assets and provide a complete view of enterprise activity. EAI tools appeared from vendors such as TIBCO, SeeBeyond, IBM, Vitria, Progress Software, Software AG and webMethods to mention just a few.

Then there came the SOA initiative. By building computer systems with applications in the form of reusable chunks of business functionality (called services) the integration challenge could be met by enabling different applications to share common services.

Now the eternal wheel is turning once again, with the integration challenge clothed in yet another disguise. This time it is all about integrating systems with completely different usage a resource characteristics such as mobile devices, IoT components and traditional servers, but also applications of completely new types such as mobile apps and cloud-based SaaS solutions. In an echo of the past, lines of business are increasingly going out and buying cloud-based services to solve their immediate business needs, or paying a third-party developer to create the App they want, only to then turn to IT to get them to integrate the new solutions with the corporate systems of record.

Once again the vendors will respond to these user needs, probably extending and redeveloping their existing integration solutions or maybe adding new pieces where required. But as you look for potential partners to help you with this next wave of integration challenges, it is worth keeping in mind possibly the most important fact of all; a fact that has been evident throughout the decades of integration challenges to date. Every single time the integration challenge has surged to the top of the priority list, the key differentiator contributing to eventual success is not the smarts built into the tools and software / appliances on offer. Rather it is all about the advice and guidance you can get from people with extensive experience in integration challenges. Whether from vendors or service providers, these skills are absolutely essential. When it comes down to it, the technical challenges of integration are just the tip of the iceberg; all the real challenges are how you plan what you are going to do and how you work across disciplines and departments to ensure the solution is right for your company. You don’t have the time to learn this – find a partner who has spent years steeped in integration and listen to what they have to say!

Why did IBM produce the MQ Appliance?


So IBM has delivered an MQ Appliance (the IBM MQ Appliance M2000 to give it its handy IBM name). For the uninitiated, this is MQ in a box (literally!). But why? Obviously, appliances often appeal from a security point of view, since they are often tamper-evident and anyway pretty hard to hack if they are physically locked up. But MQ is all about delivering messages; OK, the messages in the queues might have value, but they are probably encrypted anyway if they are sensitive. Now a security gateway, well sure an appliance makes sense. Stop all those undesirables coming into your enterprise with a secure box. But MQ?

Turns out there are some pretty damn convincing reasons why numerous companies are going to be very interested in the MQ Appliance. Think about MQ and where/how it is used. MQ usage is pretty much pervasive in most large companies, often providing the enterprise backbone for all application to application communications. It offers assured once-only delivery and is particularly good at dealing with hostile networks where connectivity is sporadic. Messages are simply queued and then delivered when the connection is available. As a result, it is often the most attractive way to communicate between applications all the way out to the fringes of the enterprise. When dealing with countries that have limited communications infrastructure the asynchronous nature of MQ makes it an ideal communications mechanism. However there is a drawback; often these sorts of locations are also the ones with the fewest available IT skills locally. Setting up MQ queue managers and queues is not a trivial operation.

But it is now! Instead of having a software stack that needs to be installed, companies can simply deliver the MQ Appliance to all their key locations. The recipients plug it in, turn it on and then specialists can configure it remotely. It is now ready to run; no wait, no messing, no opportunity for accidents, no need for expensive maintenance and support resources, just start messaging straight away. Maintenance is quick and easy and can be handled by a single team; each box is consistent and maintenance is applied as a single firmware upgrade to all devices. In terms of capacity, the MQ Appliance has a pretty vast RAID array for holding the messages in queues until they have been delivered, and if availability is critical then by simply having two MQ Appliances and three cables between them you instantly have duplex queues ensuring that any hardware failure does not cause an outage.

Having a uniform appliance for all the major MQ nodes also ensures that there is consistency in terms of configuration and operations. This makes results predictable and speeds up problem determination if there are any application or usage issues. Seems to me that just about any enterprise that has adopted MQ as its messaging backbone will be interested in the MQ Appliance.

And the best bit? It has to be that cool ‘MQ Appliance’ label just under the display!

Why enterprise mobile computing needs an mBroker – part 1

mobilephonesMobile computing is all the rage, with employees, consumers and customers all wanting to use their mobile devices to transact business. But how should an enterprise approach mobile computing without getting into a world of trouble? How can the enterprise future-proof itself so that as mobile enterprise access explodes the risks are mitigated?

mBrokers are emerging as the preferred method of building a sustainable, governable and effective enterprise mobile computing architecture. The mBroker brings together ESB, integration broker, service gateway, API management and mobile access technology to provide the glue necessary to bring the mobile and corporate worlds together effectively and efficiently; for a summary of mBroker functionality see this free Lustratus report. In this first post in a series looking at mBrokers, we will look at the fundamental drivers for the basic broking functionality offered by mBrokers.

Integration brokers have been around for many years now. The principle is that when trying to integrate different applications or computing environments, some form of ‘universal translator’ is needed. One application may expect data in one format while another expects a different format for example. A trivial example might be an intenrational application where some components expect mm/dd/yy while others want dd/mm/yy. The broker handles these transformation needs. But it plays another very important role apart from translating between different applications; it provides a logical separation between application components, so that requestors can request services and suppliers can supply services without either knowing anything about each other’s location/environment/technology. In order to achieve this, it provides other functionality such as intelligent routing to find the right service and execution location, once again without the service requestor having to know anything about it.

Enterprise mobile applications face a lot of the same challenges. When crossing from the mobile device end to the corporate business services end, the same problems must be addressed. For example, mobile applications often rely on JSON for format notation and use RESTful invocation mechanisms to drive services. But many corporate networks employ an SOA model based around XML data and SOAP-based invocations of services.  In addition, the same sort of abstraction layer offered by integration brokers is beneficial to avoid the mobile device needing to know about locations of back end applications. It is therefore not surprising to find that integration broker technology is one source for mBroker technology.


IBM reinforces its Appliance strategy with acquisition of Netezza

When IBM  acquired DataPower’s range of appliances in 2005, it caused some raised eyebrows; was IBM really serious about getting into the appliances game?. Subsequently the silence from IBM was deafening, and  people were starting to wonder whether IBM’s foray into the appliances market had fizzled out. However 2010 has been the year when IBM has made its strategic intent around appliances abundantly clear.

First it acquired Cast Iron, the leading provider of appliances for use in Cloud Computing, and now it is buying Netezza, one of the top suppliers of data warehouse appliances. Netezza has built up an impressive market presence in a very short time, dramatically accelerating time to value for data analytics and business intelligence applications. In addition, it has continued to extend its DataPower range, with the addition of a caching appliance and the particularly interesting ‘ESB-in-a-box’ integration appliance in a blade form factor. For any doubters, IBM has clearly stated its intentions of making appliances a key element of its strategic business plans.

This just leaves the question of why. Of course the cynical answer is because IBM must see itself making a lot of money from appliances, but behind this is the fact that this must indicate that appliances are doing something really useful for users. The interesting thing is that the key benefits are not necessarily the ones you might expect. In the early days of appliances such as firewalls and internet gateways, one key benefit was the security of a hardened device, particularly outside the firewall.  The other was commonly performance, with the ability in an appliance to customize hardware and software to deliver a single piece of functionality, for example in low-latency messaging appliances. But the most common driver for appliances today is much broader – appliances reduce complexity. An appliance typically comes preloaded, and can replace numer0us different instances of code running in several machines. You bring in an appliance, cable it up and turn it on. It offers a level of uniformity. In short, it makes operations simpler and therefore cheaper to manage and less susceptible to human error.

Perhaps it is this simplicity argument and its harmonization with current user needs that is the REAL driving force behind IBM’s strategic interest in Appliances.

Ultramatics works with IBM to defuse SOA security threat

Ultramatics has just announced SOA SafeGuard product, which is designed to shut one of the major SOA security holes – the opportunity to inject virus and other malware threats through XML file sharing.

This is good news for SOA implementers, but also introduces an interesting new stress point for IBM. Back in 2007 I was on a podcast where I identified the five SOA security traps, one of which was the XML problem. To summarize, most virus and other threat detection solutions look at the datastreams coming into the system and identify threat signatures that indicate the presence of some noxious code, but unfortunately they cannot see inside the XML wrapper, so to all intents and purposes the contents of any attached XML file are invisible. This offers the opportunity for malicious agencies to pop in some nasty code into the XML content and smuggle it through the security gates to the enterprise. Of course, it is not immediately obvious how this would help, in that getting this code executed might not be so easy, but hackers are smart….therefore it is best to close this exposure.

One way to close the window is simply to forbid any XML file sharing, but since industries such as healthcare now more or less rely on this to conform to industry standards and regulations, this is not really practical. The new Ultramatics product claims to be able to protect from these types of intruders. It runs on the IBM DataPower XI50 Integration Appliance, providing a hardware-based shield that can see into the XML files and weed out anything unpleasant. This solution will be very valuable to many SOA companies worried about security.

But there is something else interesting in the product details. The datasheet for the product says it can be used (in conjunction with IBM’s MQSeries) to:

Create a SOA ESB that can perform routing, transformation and protocol mediation functions

This is intriguing. Of course, the idea of an ESB appliance is not new, but the interesting point is that IBM is supplying this capability through the Ultramatics product…..I wonder if the other IBM ESBs, WebSphere ESB and WebSphere Message Broker, see this is encroachment?