Speeding up hyperlinks: topics

In a conversation with Jon Husband earlier today, we discussed hyperlinks - and how they've changed this world. In my view, hyperlinks form zero-threshold access to any and all information just a single click away. Whenever I scavenge the Web for info, I open up links in new tabs until there are 20 or so of them, and then scan the results, greatly helped by search, maybe jumping back and forth or drilling down deeper and deeper.
Compare that with the old fashioned way I had to gather information, which at best resulted in a day or so in one or more libraries where some or most books would be out on loan and I'd only have the full result set after a week or two, sometimes more - leaving me with a metre of paper books I had to plow through

Scanning them was simple yet elaborate: read the index, pick the most appetising chapters, and from each of those carefully read the first and last paragraph. Mark in mind or on paper if worthwhile, and continue search - I used to write 10-page papers in a single night doing so

Now, we have hyperlinks - and I still miss something. I call it topics, and here is how I envision them to work

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

Avoid dashes and fancy quotes in blog titles

John Reed pointed me to a post by Jeremiah Owyang, which I failed to retrieve on my phone:

Coping With Twitter’s Unfollow Bug bit.ly/H6rUUz - by @jowyang (via @jonerp) #ensw
— Jon Reed (@jonerpnewsfeed) maart 31, 2012

Ironic as it may seem, this is due to another bug which doesn't have clear ownership: let's call it the character translation bug (sorry non-IT folks)

SAP, Integration and Star Trek: the future is now

I commented ranted on an SDN post yesterday. Submitting it failed, and I lost the +/- 500 words. A bit more miffed after that, I wrote the comment anew in Notepad, and copy/pasted that - it worked.
I got a few reactions, some of which inviting me to post on the topic on SDN via a blog post in stead of just a (lengthy) comment. While I appreciate the invite, I'll just do it here for now

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

Big Data needs Big Collection and Big Execution

[Image by John M. Kennedy T]


Big Data is the new buzz it seems, and I must say I have been sceptic of it since I first saw the very word - or phrase, what is it?
As an IT architect, I've always equaled data to databases, and information to applications - and knowledge to the people on top of these

For one, I think you can very easily handle the perceived issue when dropping the data, and acting on the information instead. Since when did databases contain useful information?

Vijay Vijayasankar wrote a good post on it, and I'd like to add to that from another point of view

Asphalt that controls traffic type and flow?

This weekend I attended the SAP Inside track NL event, held at Ciber HQ in Eindhoven. The event was great, and I really enjoyed it but would have loved to stay longer and gotten more involved.
What has followed are great conversations and discussions, new people to follow on Twitter and elsewhere, and lots of topics to talk about

One of the inputs for that is the presentation I gave at #sitNL

Social silos adding to enterprise silos? Not with proper Integration

Laurie Buzcek called out for Integration as a solution for the failure of Enterprise 2.0 and Social Business - which she equates to each other - and I couldn't help but think of Tibbr when reading her post
Dion Hinchcliffe responded with a post in which he also stresses the integration of social media with enterprise tools, albeit he's careful to stress that pure technology can't be the answer - apparently we're really beyond E2.0 now

Dion claims OpenSocial 2.0 is the answer but I fail to see how that will help us further: although an impressive amount of work, it is purely technical and relying on the fact that

Developers can create applications, using standard JavaScript and HTML, that run on social websites that have implemented the OpenSocial APIs

and I don't see that happen any time soon - the only successful 2.0 Social Tools are those that are 1.0 in nature: confined

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

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”