Making the Cloud, Microservices, and Enterprise IT work!

Reader Francesco Annunziata asked the following excellent question... ERP Vendors are embracing the field of BPM e and SOA. Sooner or later their solutions will catch up with those of current leaders. On the one hand, if they can’t show much deeper integration with their ERP suite than any other BPMS vendor can offer, they will be just another behind-the-curve BPMS struggling for market share (a quote from the Column 2 blog ). On the other hand, If they can take advantage of their ERP by showing a superior capability of integrating their applications I think the BPM deals will by default go to them. Those considerations boil down to my question: Is SOA, among other things, leveling the vendors' playing field in terms of integration and composite applications? In other words, will a potential Client be able to choose a BPM system (and other applications) only considering its capability to meet the company needs, "taking for granted" that the well implemented Service Orient

Bridging tools allow a communications protocol or methodology change. Generally bridging tools are unique one-off solutions and need to be avoided in a SOA integration environment. There will be some instances where only a bridging tool will do, those are when basically the only way to connect or bridge is via that tool. The general rule is reduce bridging tools to the minimum set needed, and use the more generic SOA bus tools to replace them with a single tool or a suite. Why? Bridging tools usually require their own environment (their own server or region) and have specialized configuration parameters and settings. Supporting them is supporting another complete application and technology. But because they are narrow use, the knowledge to support them is usually concentrated within a small group (often just 1 or 2 people). Often a variety of bridging tools are being used in an enterprise as they were brought in over time to make connections that only they could make...at that time

The ESB (Enterprise Service Bus), instant awesome integration power in a single tool. Magic SOA at the press of a single button. (Ok, maybe not but that's what the vendors say.) An Enterprise Service Bus is an advanced middleware tool that serves multiple purposes to enable a managed SOA integration environment. If you're doing SOA, plan on getting one. And if you're doing SOA and you don't have one, you're not doing SOA - you're just using SOAP and XML for quick and easy point to point integrations. So what does an ESB do for you? • Communications and Protocol Transformation – The tool connects to systems providing a service or function one way, and allows systems requesting a service or function to communication another way. For example, the providing system may expose the function by MQ (IBM’s messaging protocol), while the requesting system may request via a SOAP (TCP/IP & HTTP). The ESB acts as the intermediary. • Data Format Transformation – The p

For some years I've been dealing with IBM SOA oriented products. About 3 years ago I had a chance to be in an IBM center and discuss their EBS product strategy with some top IBM SOA experts. As IBM had (and now has even more) products in the space, I was trying to make sense of where to position which product that was being pitched to our large enterprise IT. At the end of the conversation I was not successful. Recently I was speaking to a top MDM expert about Oracle's product strategy in the MDM space. I was commenting on Oracle's "product", for which I had recently received a vendor pitch. He responded that Oracle has 5 products competing in the MDM space (and primary MDM tools). Today I'm trying to produce an architecture model for a medium sized IT shop that purchased IBM DataPower to include within their existing SOA model (and fit with existing tools). In my search I came across this slide from IBM... I see... one product provides fast connectivity