tibbr 3.5 turns the world into interactive post-its

Tibbr released version 3.5 to the public today in Palo Alto California, 9 AM Pacific time. I got a solo preview yesterday and I was impressed by it - as usual I'd say.
"In twelve months since launch, tibbr has been deployed to hundreds of thousands of employees across global enterprises, who can now use tibbr to unify people, data and businesses processes to get work done"

A clear message: ...to get work done. In my opinion, tibbr dramatically reduces unnecessary human intervention in the workplace, thereby making work less unpleasant while freeing up resources for the really interesting work.
Not the greatest nor shortest sales pitch - but then I'm not selling anything here

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.

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

Perfect Integration 4 - Common language: direct translation

Update March 22 19:07 CET: extended this paragraph along the lines sketched in my comment below. Thanks Stuart

This post in the series is about my favourite subject: translation. Long, long, long ago I aspired to become an interpreter - but changed my mind. Still, I consider myself a linguist and a good one at that, speaking 6 languages of which 3 fluent. The existence of extreme diversity in languages of the world, and the same existence in diversity in an average enterprise IT landscape have always hooked my attention

Just like people speak different dialects and languages, so do applications: not one of them can perfectly understand the other without changing a thing. Even when interfacing between SAP systems, there will be differences on the technical level that have to be resolved.
So, how do you solve these misunderstandings at the technical level? How do you "translate" between the different languages and dialects spoken? One of the sides has to adapt, or maybe both? When, and how?
To answer that, let's look at the everyday world of natural languages. A completely different world, with an identical problem - and a working solution

Learning a language can be very hard and time-consuming, and very few will ever master a non-native language perfectly. Most of us know someone within the same country that has an accent and just can’t seem to get rid of it; those that have connections across the border might have heard other people speak their language and have difficulties understanding them. Or one has heard a colleague or neighbour speak a foreign language and, while not being able to speak that language fluently themselves, has good reason to suspect that there will be people on the other side having difficulties understanding that “version of the language”

Perfect Integration 3 - Common language: semantics first

This post will elaborate on messaging and transformation (part I), and explain how information exchange works in the daily world, considering simple or complex information exchanges. That will then be related to IT, and the basic ways of “writing down” information in IT will be explained.

If you want to have a chat with someone else, what do you do?
First, a common theme to discuss has to be found - usually not that hard. The favourite ones in e.g. IT usually are new technologies, cars, and the occasional sports.
The topics then have to be found, which is a bit harder. Do we discuss hardware technologies, or software technologies, or is it architecture or open source we want to discuss?
If the topics have been identified, last but not least the definitions have to be checked: are we talking about the same subjects?

The Greek philosopher Socrates filled entire conversations, and books, with merely trying to establish that he and his counterpart were talking about the same thing. There are numerous occasions on which he talked half a dozen times or more to someone, only to mutually agree on the fact that they didn’t mean the same thing while using the same word, and then end the discussion.

Perfect Integration 2 - Common subset and transformation

Number two in the series, this post deals with the common subset found on all levels in the previous post:

• what is the shared interest (Business)
• which information do you want to share (Information)
• which definitions are mutually exchangeable (Information Systems)
• how do you want to exchange ideas (Infrastructure)

Information exchange form: messaging
After having agreed on mutual business and information to be exchanged, transferring information in a certain message layout from and to systems is the logical next step.

Perfect Integration 1 - Architectural Approach

First post in a series of 5-10, I will release all my views and opinions on the Art of Integration. I challenge you to disagree, and bash me with arguments and reasoning. Feel free to shoot from the hip and aim at the heart, anything goes really. I am absolutely convinced that I am right and spot-on on every single statement, sentence, and word

Itching already? Great. Let the games begin...

Social Business Revolution

Social Business (R)evolution

by Martijn Linssen

(sample)

The current world is abuzz about Social. Social networks, social media, Social Business: all things social. People, Twitterati and even a small number of companies embrace the diverse ideas and notions of Social, trying to sell and implement them

That movement is a natural counter reaction to the events that have occurred over the last centuries: industrialisation and automation has allowed industries, companies and societies to grow beyond belief

Tibbr - the revolution starts right here

Today I attended the launch of Tibco's tibbr in London. A perfectly short and great event of a few hours with excellent food, drinks, very interesting speakers and some great panel remarks - not in that order

Ram Menon, Executive Vice President of Worldwide Marketing presented a very clear overview emphasizing the punch-line: when information is available, it comes to you

There were several speakers, among which Sriram Chakravarthy, Head of Cloud Services and Strategy (Tibco) and Jon Scarpelli, VP of Technology for CIBER. The panel existed of Dennis Howlett, Enterprise Buyer Advocate, Jem Eskenazi, Chief Information Officer of Groupama Insurances, and Ray Wang, Industry Analyst, and was moderated by Euan Semple, Consultant and Writer on The Social Web for Business

Those are the facts. Here are my findings:

My January experiment: one post a day - results

This post concludes my January experiment of one post a day. It took considerably more effort than I was used to as my average for 2010 was 100, and this just about tripled that. Anyway, I had fun doing it

Of course there was some quality and quantity involved in this month's experiment. Overall, however, I think I maxed out on both. I did product two flowcharts that didn't make it past my 500 word marker, but those were work too, and actually the (Re)Tweet flowchart was quite a bit of that. What was extremely hard work was the 5-series on Google, Microsoft, Apple, IT-vendors and system integrators: I went through 82 financial reports and an estimated 15,000 pages just to come up with 5 blog posts

It's a mobile revolution - not a social media one

Following the dialogue between Malcolm Gladwell and Clay Shirky concerning the events in Tunesia and Egypt, among others, I noticed that both missed a valid point.
The picture above shows"The Art of War" by Sun Tzu in the form of a bamboo book - and I'd like to apply the term "war" to what is happening now

Waging war has always been a classical hierarchically organised business: headquarters making up the strategy, delegating that via generals, who delegate the orders to captains, who delegate it to lieutenants, who delegate it to sergeants, who order the soldiers to move left or right or any other direction

It is technology that changed all this