Ramblings of an integration guy

Are you getting the message? IBM MQ - it's a beast but it's also the beast that's best at what it does - getting messages from A to B and not losing them. If you don't believe me then speak to the world's banks and see what they use. But, nothing is perfect and IBM MQ is old. It shows its age in some obvious ways - the security model is treacherous. I would also say that having, how many is it now...? 5 different ways to achieve HA (https://developer.ibm.com/articles/mq-ha-dr-options/), shows just how complex a beast it can be. Never mind the number of switches and options you have when setting up the queues and clients.  But... I still love it. It's what I specialise in and I still think it's a product that does what it says on the can - not lose your messages. However, wait for it.... it's biggest problem is.... I never know where my messages are at any give point in time. Trapping messages in MQ is hard so trusting that your message has been and gone ...

Which partners are using my Sterling B2Bi? One of the problems we have in integration is knowing just which partners are using my services. Silly as this sounds it's a real problem. Over time customers come and go, services get replaced, customers  migrate to different services. Service Management API-Management knew this was a problem from the beginning - they have the in-built concept of managing who's using the APIs and you can, reasonably easily, deprecate APIs and track who is using them. However, the likes of IBM Sterling B2Bi do not have that concept. To find out whether a customer is currently  using a sterling hosted service requires some clever database searches which are deep in the bowels of the product. It's not alone in having this problem - many integration products have little partner usage visibility. They all take great care in onboarding customers but lose track of who's still using the services over time. Opsis usage tracking Opsis, Coliance's bu...

Helping your business department untangle the IT spaghetti This is a blog I wrote for the monitoring tool that I am writing for Coliance - called "Opsis". Your Purchasing system may run using security gateways, messaging systems, an Enterprise Service Bus (ESB), an API Manager etc. Overlaying each individual piece of software is a layer of configuration that makes up the runtime for each specific business solution. i.e., security gateway policies, messaging systems queues, Enterprise Service Bus Flows, etc. When viewed like this, we can see that business solutions take ‘paths’ through ‘systems’. These paths are complex and vary depending on the business problem being solved. Sometimes, however, this is unattainable with your IT team kept busy monitoring whether machines are running, or if the software is generally operational. They spend much of their time examining individual artifacts on these systems such as queues and flows. Chances a...

In the May 2019 release of Mule they have included a new function called flow designer templates. These caught my eye as they are very similar to IBM’s APP Connect Designer flows and show how integration is becoming more accessible to the Line-of-Business.

One of IBM's best-known secrets is that they have two solutions that can act as API Management microgateways. This is a short post to highlight the various ways that you can expose APIs using IBM products and, in particular, the App Connect Enterprise (formerly IIB) Microgateway functionality.

Having worked in the MQ labs at IBM Hursley for many years I was always struck by how complex MQ appeared. As time has gone by little has changed my mind on this. Recently I was asked to create a solution for the customer that required repetitive creation of an MQ environment. We chose to create a tool using JSON as a configuration language. I'll describe the tool here and welcome feedback on it.

A lot of my customers are currently deciding which API Manager to use in their estate. With so many of them to choose from and a confusion of terminology this is not an easy task. I see RFP with long lists of criteria but I often think that the choice should be based on some other, softer, questions. I'll outline here some of how I help my customers choose which API Manager is right for them.

API Management promises a nirvana of exposing data using well-known and simple techniques. Vendors focus on how easy it is to create the APIs and nearly always mention security as part of the API Lifecycle. Yet, we've all seen the headlines screaming the latest security breach so, what does Security really mean when it comes to API Management? In this post I try to differentiate the basic policies that all vendors discuss from the many other attack vectors that we need to be aware of.

Kubernetes - a skills issue Although the offerings I'm about to discuss are different, they're interesting enough to explore more closely. Both IBM and MuleSoft are claiming that the reason for implementing their solutions is because they perceive a lack of skills in containers and Kubernetes.

When I first joined Lightwell I was struck by how everyone discusses "on-boarding". What was this magical and mystical thing? Why was it discussed in such reverential tones? Having analysed this further I'm still a little mystified as to why the hush tones but I'll put a few words down here about what I consider on-boarding to consist of and why it's as much a human process as a technical challenge.

Last year I discussed how I saw the evolution of APIs and EDI evolving.  I'm going to grow that argument here to say that agile methodologies have more to do with API management's current proliferation than the usurping of EDI.

"App Connect" ring any bells at all? In case it doesn’t, App Connect is an  IBM integration  product suite released a couple of years ago. Now, IBM has announced that IBM Integration Bus (IIB) V11.0 is  now IBM App Connect Enterprise    There's more to this than just a renaming of IIB—IBM has added in some IBM WebSphere Cast Iron capabilities and they've created a new  IIB  GUI as well. In this blog entry I’ll go through these changes and look at what it means in the long-term.

Every time I see a "Blockchain 101" inevitably, it mentions Bitcoin. Personally, I think that's like telling you what a spoke on a wheel is rather than telling you how to ride the bike. I figured I'd write the "How to ride a bike" version of "Blockchain 101". BTW: I'm going to try to not mention the *B* word again here, so, let's go...

In this post Connor Smith and I will give a brief overview of Poison Messages, and how the various IBM MQ clients handle them and what you need to do as an application writer.

APIs are something I've discussed a lot recently and this blog continues the theme. In this entry I discuss how API management relates to Service Orientated Architecture (SOA). I discuss how SOA is not going away but it is going to be greatly simplified by the introduction of API management and its concepts. I also discuss how IBM's API Connect product works in both a "traditional" SOA world as well as the more rapid and potentially more agile world, that APIs have grown from.

It’s hard not to notice the up-swell of API Management in the press in recent times. If you come from an EDI background you may dismiss API Management as not being relevant. I also often hear the contrary view - that EDI is old-school and that APIs are taking over.  I don’t believe either to be true.  There are plenty of Qualities of Service that EDI gives in spades that API management simply doesn’t touch and vice-versa. In this blog I’ll review those differences and show how API and EDI are complimentary technologies not competitive. I'll also suggest where the future lies for these two differing technologies and that, actually, the comparison isn't EDI Vs API but should be API Vs Web Services.

Back in the day Web Services were the de facto standard for accessing "systems of record". Out of this grew the secured ESB architecture that is synonymous with enterprise architecture. More and more, projects are utilising API Management in those architectures now and pushing on Web Services' door. In this blog I'll explain why social factors as much as technical ones are enabling API Management to make inroads into 'traditional' SOA architectures. I'll also show that API Management is much more than the " API Economy ".

I’ve previously blogged about what most people would think of when they consider  hybrid integration scenarios . In this blog I’m going to show that some recent additions to the IBM portfolio are adding to those core scenarios. These additions are not major product announcements but just a few little extra additions to current products that will probably have slipped under most people’s radar. Whereas I previously discussed how hybrid integration usually consists of whole sets of servers being moved into the cloud; IBM is now enabling much smaller units of work to be placed there. By doing this they are changing the granularity of hybrid integration.

Ask three different people what hybrid cloud means to them and you'll probably get three different answers. In this entry I'll outline the eight major hybrid cloud concepts as most people would know them. Hopefully, this entry provides a solid introduction to hybrid cloud scenarios discussing not only the use-cases but also what I term their granularity . In my next entry I will discuss how these scenarios are being augmented by recent announcements in IBM's integration portfolio and show that the granularity of  hybrid cloud has just changed.

Over the past few months I've been focussed on the "API -Economy". It's become clear to me that API's have several business drivers - and they're not all just about directly making money. Regulators are now playing an increasing part in the spread of APIs. In this blog I'll try to capture the three main influencers in the API economy and how you may see their affects . I'll focus in on the regulators role as it's not often discussed.