5+ garages to service your car? Sure

[Image by Expressive]

After a very lively conversation with Holger Müller I decided on "posting it up" - Twitter is fine for conversations but sometimes the 140-char limit just doesn't cut it.
We discussed Integration, within enterprises. Along the analogy of a garage, we found out that every enterprise has more than a few garages "to serve their car" - meaning integrating their applications

Yes that can be true, but it doesn't need to be - some of the work I do involves "Integration rationalisation", meaning bringing back the number of Integration solutions to -preferably- one

Holger told me what is happening, and has been happening, in his world - and I don't disagree with his facts. I just think that there are far, far better ways of using your time and money. "Free Integration Tools" you get with purchasing an application or ERP module don't always usually mean that they are

Resource identification is not a REST invention

An article on programmable web - pointed out to me by Fred Verheul (thanks Fred!) - gave me an adrenaline rush.
It was so full of bollox that I almost started to hyperventilate - which is a pun on the abundant use of the word hypermedia in that same post

Let me just quote one part of the post:

This subtle shift in the source of application control information makes it possible for the same client code to recognize and execute new features as they appear over time without the need for patches or downloads

The post contains more nonsense like this. Let me quote yet another brilliant piece, and be done with quoting:

TIBCO Transform - it says it all

I attended TIBCO's Transform event in London.
Located at the Westminster Bridge Park Plaza hotel, around 600 people were there. Kicked off by Raj Verma, Senior VP of worldwide Marketing, a 2 hour session started that never bored for a minute. Very smoothly Raj led us through a full history of TIBCO, showing impressive figures like a 21% CAGR over the last 15 years, reaching almost a billion dollars in revenue with currently 3,000 employees

Having spent $130 million in R&D last year, the total R&D sum over the years accounted to $1 billion - a huge amount that proves how serious TIBCO is about innovation and fulfilling their goal of "making this world a better place"

SAP Integration? Not what I had in mind

I couldn't attend nor even follow the stream at Sapphirenow, but I picked up a few tweets on Integration. Well actually, Seb pointed one out to me.
As much as I detest it, I'll have to base this post on the limited info I retrieved - although I did browse the usual placeholders for SAP news of course.
If you read my latest post on SAP and Integration, you might presume I was a little overexcited about what was going to be announced

Well, the excitement wore off. Really off

Airline ticket pricing: ticket prices compared

After yesterday's post, some wanted to know "the best" flights / airline, regardless of surcharge(s). Fair enough, that probably means the cheapest ones, so I dove in again and came up with the following data (I calculated my own surcharge based on the experience I now have, so prices will differ from what you can find yourself)

(Like yesterday, I took a round-trip from New York to Amsterdam and back, leaving 21st of March and returning 4th of April. I compared both Economy as Business)

Airline ticket pricing: surcharges compared

Lots of regulations and restrictions have been enforced in Europe, and some other parts of the world, to "keep airplane tickets transparent".
You must know from your own situation or someone else's how that too-good-to-be-true 200 dollar one-week trip to the sun turned out to be 550 after all extra charges (that applied to your particular situation of course!) got slapped on, only to find out that airport bagage rules and local customs had to get their share of the pie too. Oh well, so it cost 700 dollars in stead, but it sure was fun, wasn't it?

Damn right it was - for them

Did Apple finally get hitched?

[Image by Roberta F.]

Thanks to Peter Hicks for inspiring me for this title

Lately I've noticed quite a few complaints regarding the upgrade to Apple's iOS5. A few examples of that: the upgrade itself failing to complete, having to restore factory settings and lose all apps and files, battery draining like mad, Twitter failing until after complete deinstall and reinstall of Twitter, all iTunes lost, all images lost, being unable to SMS, and many, many more complaints when you search for "ios5 fail" on Twitter

Coincidentally, this the first time I've heard fanbois complain about their Precious. And no, relating that to the passing of Steve jobs wouldn't be funny

How to queue - that is the question

The other day my attention got drawn by a very large national company that claimed to have a performance problem: sometimes it would take ages for messages to reach their destination, and entire applications would come to a screeching halt.
After a few questions and answers, it was clear that they didn't have a performance problem: they had an architectural problem or, in a nutshell, a very unfortunate design

Queueing has become a much-appreciated message-transport system in the last decades.

What am I going to condone it for?

Yesterday evening, the BBC announced an interview with Darcus Howe,

to discuss if comparisons between these inner city riots and events that took place in the 1980s are useful or misleading

This morning, that interview took place - and bit the BBC in the ass (pardon my French)

Tibbr, the new OS. Integrating is the new Operating

I just watched the live feed of Tibbr's 3.0 launch. It was impressive and even more so than the 1.0 launch I attended live in February - although that was a revelation, and revolution too

Back a dozen years or so, Larry Ellison dreamed about the network PC as replacing Microsoft's Operating System (OS) - and woke up in a nightmare.
Since, Apple has come back with their OS and stole some marketshare.
Linux was born and stole great marketshare, most of that server side in companies - not in the consumer market

Still, it was oldfashioned OS as we know it - Jim

Perfect Integration - the eBook

Perfect Integration

by Martijn Linssen

What started with Perfect Integration 1 - Architectural Approach and ended with Perfect Integration 13 - the do's has become a lot of words, more than 10,000 actually

Perfect Integration 13 - the do's

Final post in the series, this is the summary and conclusion, to be used as some sort of checklist if you like

When conducting enterprise business application integration, within the enterprise IT landscape among applications and systems, or from there to others at another company or even directed towards the customer, here are the pragmatic rules:

Start at the business level, and write down which process it concerns. What is the business event, which its trigger, how often does it occur, how sensitive is the data? Why should this be automated, in other words, what is the manual alternative and the benefits and concerns of both?
Write out the functionality it concerns. List the entities, their cardinalities, and all attributes concerned, and describe them as complete as possible. Here's an example

Perfect Integration 12 - the dont's

I changed my mind and decided to end this series with positive do's, so this is the dont's one. Then again reserving no. 13 for the dont's was a superstitious move anyway, and as I'm neither religious nor superstitious (they usually travel in pairs), it's better this way

This post is about debunking TLA's and FLA's. XML, SOAP and REST primarily, but Webservices and other concepts whose added value is flimsy or even absent, will get proper attention

Perfect Integration 11 - Orchestration

I've compared the diversity of an IT application landscape and managing its information exchange in a uniform way to translation, with the European Parliament as a perfect example of translating dozens of languages via three intermediate languages. In IT, we only need one, as languages (syntaxes) there are far less complex than in the linguistic world

I've used a similar metaphor to explain how different transport protocols can be handled, by referring to James Bond's opening scenes, where he takes all kinds of transportation in order to escape death. He simply manages by getting off one kind of transportation, and getting on another one. Clever hey?

Perfect Integration 10 - the missing link: envelope

With a common language, a common transport protocol, and the need to exercise the necessary translation and transformation on both levels in between, there is a growing need to be able to identify all "service requests" on a generic level too

Numerous and various requests will be made, in different formats, via different transport protocols. This certainly is not Utopia, but a pragmatic observation that is maintained in almost an evolutionary way: within successful companies IT systems, like people, are selected based on professional excellence (meaning specialist instead of generic properties).
Excelling in one area usually means being moderate in a few others, and being capable of good and generic integration is usually one of those. Intellectual supermodels, and good-looking scientists: they are either scarce or non-existent

When all those requests are being made in different ways too, it becomes nearly impossible, but at least very time-consuming and costly, to collect and streamline all the information. Whatever the flexibility on the messaging and transportation level may be, addressing all those variations must be made possible in a generic and structured way

Perfect Integration 9 - history with hindsight

In the previous post, the history of Integration passed: point-to-point, EAI and ESB. For those who read and grasped post 1 through 7, it'll be clear why I favour which one - but let me explain it in more detail

What are the differences between the different historical approaches?

The crucial difference is that EAI describes a hub and spoke architecture, where proprietary messages to and from applications are translated by a central integration broker. Yes, that is the European Parliament post, among others.

As described, applications can plug in and out of the landscape this way, and the necessary transformation of information is taken care of by the central hub

Perfect Integration 8 - history of the last decades

In the first seven posts, the approaches to Integration have been shown. The architectural top-down approach, the common subset theme, and the central integration methods: messaging, transformation and transportation.
Now the approach to successful integration has been set out, a brief story about integration in the real IT world, over the last decades, is in its place

Point to point interfacing
Point to point connections, is a term that describes how applications can be connected. Point to point interfacing was commonly used to link applications together "in the early days", and was a reasonable solution as long as the scale of integration stayed small

Perfect Integration 7 - information exchange: transportation

[Image courtesy of Ferdinand Reus]

After creating and or choosing a common or generic format to exchange the information, there is one other field to explore: the facilitation of various communication protocols through which this information can be transported

What applies to messages, also applies to transport: a common language is to be advised as "main artery" for all the traffic. Besides that, each application must speak its own language here as well, and use its own infrastructure as much as possible. Adjusting applications for transport protocols can be even harder than doing so for messages: transport protocols are very, very static and rely on worldwide standards. Making your own version of it is highly unappreciated

Perfect Integration 6 - Common language: syntaxes

In the previous posts I explained semantics, syntax, and the fastest, cheapest and easiest way to get from diverse IT applications to one uniform business language. This post will take a deep dive into message formats such as Flat file, EDIFACT, XML and JSON

Ever wondered about the pros and cons of XML? JSON? What it is really? What other possible message syntaxes are?
When semantics and a logical structure has been defined, and functional groups and fields have been identified, just about any message format can be chosen.
Choosing message formats (or rather, predefining them) is a rather pragmatic measure that narrows down the margin for discussion when it comes to choosing a form for your common language

Perfect Integration 5 - Common language: indirect translation

Number 5 in the series, this post is about indirect translation, in contrast with the direct translation shown in the previous post, which came with costly, exponential dependencies

When looking towards large-scale use of translators, e.g. the European Committee in Brussels, it is easily observed how these dependencies can be greatly reduced: all languages are first translated into English, French or German, after which either one of those is translated into the final destination language