Business or Pleasure? - why not both

Enterprise Integration interview by Richard Seroter

2012-05-31T20:03:00.002+02:00

I got the chance to participate in Richard's Interview Series - I was number 40 and you might know what that number means to me
Richard is a principal architect and Microsoft MVP, and well-versed in integration on a whole, especially Microsoft / BizTalk. He's been blogging since 2007, authored / contributed to three books and written an extensive series on BizTalk

You can read the interview on Richard's site, or right here:

Q: You've been writing a series of provocative articles that take a bit of a contrarian view of REST as a viable enterprise (integration) mechanism. You seem pretty sceptical that REST/JSON is a practical service strategy for most enterprises. Given that an earlier post of yours also expresses doubt that XML/SOAP/WSDL is the answer, What types of services SHOULD enterprises be embracing and investing in so that they have a maintainable and usable ecosystem?

A: Tools and techniques aren't the answer to the Integration issue, and certainly not one single tool and technique. But first you'd have to know what the Integration issue actually is, before trying to formulate an answer to it

The Integration issue is that in IT there's an evolutionary, ever-changing diversity in platforms, operating systems, programming languages, applications - and now also devices and locations. Will there ever be a one-size-fits-all for even any of those? No.
I compare this diversity to human languages: they are extremely diverse, and then you have dialects and accents, and those also evolve, and the persons that speak them also get better or sometimes even worse at speaking them

So, we have to tackle that diversity - we can do that in two ways

1) We can make everyone speak the same language, e.g. English.
What's the ROI of that? It takes years, and the majority of people will never get fluent at any language. A huge investment in time and money, and what is the result?
Take American English, English English, Dutch English, but especially German English, French English and (my favourite) Indian English: very hard to understand.
What's the spin-off of that, the result? Well nothing really, given the bare fact that people speak the same language: you need to understand each other. Does you and your partner speaking the same language prevent arguments, misunderstandings? No.

You first need to find a common ground in the actual topics you want to discuss. You ask me a question, I give you an answer, and / or vice versa: we hold entire conversations by firing off requests and responses. I myself usually switch languages when I speak to e.g. Germans; when it gets hard, I switch back from German to English which is neither my native tongue but still a lot more often used than German.
Does that change the conversation? No - it just serves me better. For me there's no difference between speaking English or Dutch, but for a lot of people it would be a whole lot easier to speak just their native tongue

Take this back to Enterprise IT: you bought, built or made all those applications exactly because they play their role so very well. Each of them are Olympic athletes, perfectly apt to do what you want them to do, specialised in one thing only, well maybe 1.5. Now spend the time and money to teach them a different language - ouch! that will cost you dearly, and probably give you Frenglish or Indienglish at best.
[On a side-note, I am not making any statement about nationality or race here, I am just taking an example everyone can relate to. To me, all people are equal regardless of their physical attributes]
Now, let's see how this can be handled in a professional, business-efficient way: the European Parliament. With currently 23 languages in the EP, there are 506 (23 x 22) possible combinations of spoken languages. 750 members serve for 5 years, which means that on average 12.5 people per month get replaced

How much time and money would it cost to teach each of those e.g. English? Could that even be worthwhile? Of course not, and it would seriously hamper the content of messages sent and received across. So, they don't make all these people speak one and the same language, because the diversity and dynamics are so great, that it is simply not an option.
Remember that these 12.5 people per month getting replaced represents 1.5% of total: could you handle 1.5% of your IT landscape being replaced every month?

2) We can hire interpreters. People specialised in translating languages on the fly in mid-air, face-to-face, real-time. That exactly is what happens at the European Parliament.
Now, we run into another problem: you'd need at least 506 interpreters to handle all the diversity (= variations in language combinations). This is commonly known as the N2 (N to the power of 2) problem where (back to IT!) N2 possible combinations arise for N applications / languages.
The solution to that? Still using one common language, but this time it's used by the translators / interpreters to translate any language into, and from. The result? One fluid, fluent common language hanging in mid-air above all the awesome diversity of all languages spoken. The effort for the participants? Null, zilch. Nada. Niente. Niks. Nichts. Rien
[On a side note, the EP uses three middle languages: English, French and German. That's linguistically but also politically determined]

So, I believe in one common language so that the business is not bothered with the evolutionary IT diversity - after all, that diversity is not a goal, nor even a means; it's an unwanted side-effect that will never go away and has to be dealt with.
Do I think the business should be burdened with that diversity? Absolutely not.
Do I think the participants in the Enterprise conversations should be burdened with it? Most certainly not either

Back to your question, the answer to which will now be easy to understand. Did SOAP solve the Integration issue? No. XML? No. WSDL? No. Will REST? No. Will JSON? No. All those imposed, and all these will impose, the Integration issue onto the participants in the conversation, and the Business.
But let's turn that around: where do I see good application for either? In some places, mainly B2C. Not in A2A, and certainly not in B2B. If your customers or service consumers demand any of the above, or if you can profitably maintain or extend market share by translating from your common business language into those, and back again, please be my guest - you'd be a fool if you wouldn't.
But hold a knife to everyone's throat and force them to change their existing SOAP/XML/WSDL to REST/JSON? Good luck with that

Why do you think Google, Twitter and Facebook never used SOAP? It's too undefined a standard, even after more than a decade - and no one asks for it. I've witnessed its use and implementation in Enterprises, and it only resulted in long, heated debates about whose perception of it was right, ending up in yet another bilateral agreement that didn't result in any interoperability whatsoever.
Why do you think they booted or even refrained from using XML? It's too bloated of a syntax, doesn't add anything but overhead. I've witnessed the use and implementation of it in Enterprises, and it only resulted in long, heated debates about whose perception of it was right, ending up in yet another bilateral agreement that didn't result in any interoperability whatsoever. (sic)
Why do Twitter and Facebook now support JSON? Easy, it dramatically decreases overhead compared to XML. You'll notice that the implementation of JavaScript Object Notation has come to be extremely loosely coupled from Javascript (pun intended) and that it is only used as a flat-file syntax for exchanging information regardless of platform, operating system, etc etc etc. To no surprise, as it's ye good old fashioned CSV with a twist

So, what type of services should Enterprises embrace? Simply extending their existing back-office functionality outside the Enterprise is all.
In what form? Whichever form is best suited. Speak Chinese in China, Greek in Greece, and certainly not vice versa.
The location (= bandwidth) impacts the form because the services need to be exposed and thus transported from the back-end to somewhere else on this earth, and vice versa: the further away from the office and civilised world you get, the smaller the bandwidth.
Fit impacts the form, because most programming languages and platforms have a predefined taste, and even ready-built building blocks or components. The older the platforms and programming languages, the more old-fashioned that taste is and the higher the chance that building blocks are present, and fixed. The older the platforms and programming languages, the smaller the variety as well as the chance that building blocks are present: old will tell you: "Listen we only support format XYZ" whereas new will ask you "Well what do you have to choose from and we'll just pick one" - this is presuming that old is on the supply side, and new on the demand side

It all is a question of supply and demand. If you have ample of supply but little demand, you'll be inclined to adopt your consumers' format and transport protocols. If vice versa, you'll wave your existing format(s) across the consumers' faces and say "my way or the highway". It is as simple as that

Q: What are some the positive trends you see in enterprise integration? What are integrators doing now that they weren't doing 5 or 10 years ago?

A: Well, if my answer to the previous question was long, this one might be even longer - but it ain't. To be concise: we have to travel back to the previous century to answer this.
Back in the 80's Integration was confined to database point-to-point connections. All was batch, mostly focused at database replication when there weren't any tools for that, and the database market was still very diverse and far from mature / settled.
A decade later (I'm being very rough with regards to timelines here), Enterprise Integration moved up the stack and targeted applications itself, directly addressing the business logic layer. It was at that point that the canonical model was invented because diversity dramatically increased

In fact, the invention of the canonical model was the solution to the Integration issue

Yes it added overhead because messages had to be translated more than once, but with the batch schedule and low-frequency near-time Integration back then it was heaven on earth. It also enabled BIM and BAM although those two acronyms never made it out into the world because of the fact that the Integration filed got extremely disrupted by Web.
Then, 10 years plus a few years ago, B2C entered the arena, along with Web. Client-server happened along, and along with all that was the cheapification (some poetic freedom here) of servers and clients. Microsoft invaded the Enterprise and pushed aside the costly main- and midframes. Along with that, VB and Javascript put themselves on the stage

The result? Anyone who was handy could sit next to the business and script them through their solution - it was the point where we as an IT industry went from the old ways to the new ways. The old ways? 80% of code was meant to prevent the system from doing what it was not supposed to do. The new ways? 80% of code was directed at having the system do what it was supposed to do.
Anyone with even a faint memory can tell you that this resulted in unintelligible error messages and program dumps - yet that was beyond the scope of the initial key user.
The effects for Enterprise Integration? It put the profession back for a decade and more, reintroducing siloed point-to-point integrations

And here we are now. Over the last decade, we've tried ESB and SOA, focusing on XML and WSDL to make those happen, forcing all consumers to speak that one single language. And it failed, as I have been saying since last century that it would. W3C has become an authority, Oasis has, and countless others try to become yet another purely technical institution that is sponsored by vendors. It resulted in "standards" that are compromised to death: the standards support what their constituents support.
Will REST make up for that? Absolutely not, it is as undefined a "standard" as SOAP was, and will be. 5 Years from now a new tech discovery (no, not invention) will see the light or some old paradigm will get hijacked the way REST currently is, and the world will try to force it onto Enterprise Integration in exactly the same way. Will I stand at the front lines then? Yes, just like now

So, what are the positive trends I see? Well, not much really. I really like how XSLT enables vendor-independent XML-based mappings, yet every vendor has their own implementation of it, so there goes that win. The vendors have to uphold their lock-in and they do it very well, alas.
Yet I see some positive spin-off from SOAP with companies thinking about an envelope to accompany their messages - they're getting closer to the proven concept of old-fashioned snail mail for routing information exchange.
Gateways are still there, functioning as good old post offices, whether they are VANs or not. It depends on industry really, the financial world has remained almost untouched by the craze of the last decade (they can't afford experimenting) as have most if not all logistic and retail platforms. It is governments and semi-governments (e.g. insurance companies) that still hold the deep pockets of Mickey Mouse money with which they can finance early adoption of a tech solution to a business issue (with the likely outcome) - although that will be changed in the future too, given the current crisis

What are integrators doing now that they weren't doing 5 or 10 years ago? They just try to offer New Blacks as much as they can, regardless of their business value. Integration has become a predominantly tech-ruled field, and I despise that.
System integrators are still partnering with vendors and get a cut of the pie for every vendor product they sell to the customer. On the other hand, there are new kids on the block like tibbr, who handle Integration from a customer-friendly and even neutral perspective.
Apart from that, there are Social Integration tools flooding the world, all of them lightweight and inside-out focused, providing their customers with a few basic Integrations. All these will have to learn the hard way that there is no Integration but any-to-any, and who ever learns that quickest and best will lead that pack. But it will be 2-5 years.
A positive side-effect is that Integration has been put onto the agenda of the Social world - I can't complain about that nor would I want to

Q: What, if any, new challenges arise from integrating off-premises/SaaS applications with on-premises systems? Have you seen what decisions makes these scenarios successful, and unsuccessful?

A: Ah. Now that deserves a really long answer (just kidding). Off-premise poses exciting problems to real-time Integration - bandwidth is the new bottle-neck. Regarding successful or not scenarios, there is no choice really. Salesforce.com does a very nice job integrating real-time and batch, limiting each of those with regards to message size depending on what you pay for. So pay-per-Integration is the new mind boggling topic for Enterprises, and speaking of which, yes JSON in stead of XML will absolutely make a difference there - I bet some sweet money on compressing data before it gets interchanged, and back again, at least for the batch variant

The big question of on-premise versus off-premise is out of the question for Integration there, as a fun side-effect: whether you Cloud your Integration solution or keep it on-premise has become irrelevant from a single CIO decision-point, as performance latency is a given now. Having your own Integration solution and hauling in off-premise data or information versus hosting it in the Cloud (right next to your SaaS) is becoming a very interesting decision matrix, highly dependent on what you SaaS where.
The speed of light doesn't help much either, although any request-response still remains sub-second in theory. A round-trip request-reply over 20,000 km will take at least 0.3 seconds, and I predict that Cloud will follow the same pattern that physical distribution of logistics warehouses whave: some centralised, some decentralised.
I expect SSD to be a best solution for making up the increased latency as Integration is all about I/O, as it always has been. Of course it won't overcome the physical barriers of speed, and if it does, let's excavate Einstein please - he wouldn't want to miss that.

The real issue, however, will be that SaaS will just tell you "hey, here's my integration syntax and transport protocol, happy now?" and eliminate the option of customising-to-death, and lest not forget, the practice of pure ESB: forcing all applications to speak the language of the Bus, reducing the Bus to an architect's wet dream that doesn't add any value whatsoever to the Business.
Of course you will be offered a choice between one or two, maybe even three, but that's it. Cloud will greatly drive standardisation, it's even one of my blog post titles I believe

New challenges in a nut shell then, wrapping this one up? Changing the supply-demand paradigm for most Enterprises into demand-supply. I really would like to see how e.g. SAP handles that, but I'm not putting any money on it any time soon. Off-premise SaaS (that's a pleonasm but hey) will confront all Integration participants with the simple fact I described above: the Integration issue is that there's an evolutionary, ever-changing diversity in the IT components that make up or affect your landscape, and the only solution to that is adapt, not adopt

Q: [stupid question]: I don't think I use more than 20% of the features of any single software product. Microsoft Office? Maybe 15%. Sparx Enterprise Architect? 10%, at best. Microsoft Visual Studio? Probably 2%. What software do you use every day, but rarely stray beyond a core set of capabilities? What software do you think you take the MOST advantage of?

A: Not a stupid question really, it's the package paradigm: you pay for 100% and never use more than 10-20%. Then you have to put up with 100% of upgrades and pay even more for functionality you don't use in terms of time and effort.
I use Notepad for the full 100%, primarily to cut and paste between applications, even if those are Microsoft Word and Microsoft Word. I use that, and PowerPoint for fancy forms / images - my world is limited to content and fancy images really.
I use plenty of programming languages to do whatever I need to do, if that gets complicated I prefer using Ultra Edit over Visual Studio. Why? Because I don't like being confronted with change. I prefer growth over change

Thank you Richard for this interview, and keep it up!

REST definition and its place within Enterprise Integration

2012-05-28T15:20:00.000+02:00

In a previous post I explained why REST is useless when it comes to Enterprise Integration. Even though at the very beginning I explicitly stated that

Roy Fielding wrote his dissertation entirely in the context of Web

and that

REST has absolutely no business benefits whatsoever with regards to Enterprise Integration

I got surprised to say the least by comments in various channels, most from professionals, even vendor representatives. Tech people, but nonetheless

The most commonly heared argument was that I misrepresented REST or even clearly showed my lack of understanding of REST, upon which my simple response was: can you please point me to a few articles or posts that respresent your understanding? but surprise you or not, the responses to that were either absent, or absurdly far from being to the point (e.g. "your post doesn't even make me want to help you")

So, I show you what REST is, according to Roy's dissertation, and Wikipedia, and then will disect that with regards to Enterprise Integration, and see where the twain meet. Does that seem fair? I most certainly think it does. If it doesn't, point me to definitions that better suit your understanding of either, please. This is not meant as a debate, but a dialogue (as usual). If you don't want to participate in the dialogue, fine - don't even bother to react or comment

The definition of REST is kind of hard to come by. Yet, according to the magnificent Wikipedia, here are the constraints of REST (shortened yet literally quoted by me for brevity):

Client–server: A uniform interface separates clients from servers
Stateless: The client–server communication is further constrained by no client context being stored on the server between requests
Cacheable: (...) Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests
Layered system: Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. They may also enforce security policies
Code on demand (optional): Servers are able temporarily to extend or customize the functionality of a client by the transfer of executable code. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript
Uniform interface The uniform interface between clients and servers, discussed below, simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are detailed below

Here's that "below"

Identification of resources: (...) For example, the server does not send its database, but rather, perhaps, some HTML, XML or JSON that represents some database records expressed, for instance, in Finnish and encoded in UTF-8
Manipulation of resources through these representations: When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so
Self-descriptive messages: Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cacheability
Hypermedia as the engine of application state: Clients make state transitions only through actions that are dynamically identified within hypermedia by the server (e.g. by hyperlinks within hypertext). Except for simple fixed entry points to the application, a client does not assume that any particular actions will be available for any particular resources beyond those described in representations previously received from the server.

You find very little of all of that when you search the Web. What you do find, is an insistency on CRUD to use with HTTP. Which is odd, because CRUD isn't even part of REST. It's unclear where it got added, how and by whom, but here's what the common misunderstanding is:

REST identifies four verbs or HTTP methods: POST, GET, PUT and DELETE - identical to C(reate), R(ead), U(pdate) and D(elete), the basic functions of a database

Roy explicitly disagrees with that in his March 2009 post:

Some people think that REST suggests not to use POST for updates. Search my dissertation and you won’t find any mention of CRUD or POST

So, CRUD's out the door, leaving the 6 constraints and the 4 guiding principles

Let me comment on REST's constraints first, from an Enterprise Integration point of view

Client–server: A uniform interface separates clients from servers. No, what Roy said was "By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components". And that makes perfect sense in EI. But uniform interface? That is a lock-in no one can afford - functionally uniform, yes I agree. But technically?
Stateless: The client–server communication is further constrained by no client context being stored on the server between requests. I certainly hope so. Cache prevents any means of scale
Cacheable: (...) Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. I never got around this one. You can't be stateless and allow for cache at the same time, client-side nor server-side. This is a void in Roy's plan
Layered system: Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. They may also enforce security policies. A clear deeply infrastructural technical addition, again focussing on speeding up the Web. Enforcing security policies? Only when those have been agreed upon beforehand, I hope - it would be devastating if your request bounces somewhere off intermediary server 5 or 6. Shared caches? Again, this defies the notion of statelessness
Code on demand (optional): Servers are able temporarily to extend or customize the functionality of a client by the transfer of executable code. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript. In a Web context, this may make sense. In an EI context, it won't: you offer back-end services, and that's it. Can't temporarily offer more to some clients, and then take away those privileges again
Uniform interface: The uniform interface between clients and servers, discussed below, simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are detailed below

So, out of 6 (or is it 5) constraints, only one might work for Enterprise Integration. The constraints are mostly focused on caching, but that doesn't come as a surprise:
Roy Fieldings's dissertation is 12 years old now. I read the dissertation, from beginning to end. It taught me among others that

REST enables the caching and reuse of interactions, dynamic substitutability of components, and processing of actions by intermediaries, thereby meeting the needs of an Internet-scale distributed hypermedia system. (...) REST elaborates only those portions of the architecture that are considered essential for Internet-scale distributed hypermedia interaction

Roy was mainly concerned about Web performance and thus wrote his dissertation. Did he mean it to be used as a great paradigm for Enterprise Integration? If any, he certainly didn't state so. I'll take my chances and state that he most certainly didn't, and still doesn't.
Anyway, there are 4 guiding principles left

Let me comment on REST's guiding principles, from an Enterprise Integration point of view

Identification of resources: (...) For example, the server does not send its database, but rather, perhaps, some HTML, XML or JSON that represents some database records expressed, for instance, in Finnish and encoded in UTF-8. Absolutely agreed. Decoupling between data in the database and the form it is requested in or even responded in, is without questioning
Manipulation of resources through these representations: When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so. Roy says "Information hiding is one of the key software engineering principles that motivates the uniform interface of REST. Because a client is restricted to the manipulation of representations rather than directly accessing the implementation of a resource, the implementation can be constructed in whatever form is desired by the naming authority without impacting the clients that may use its representations" which makes sense, and relates back to decoupling, and the use of an interface
Self-descriptive messages: Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cacheability. This is again strictly Web tech related, and touches on the fundamental differences between REST and Enterprise Integration: REST is written for the Web, where unknowns interact with unknowns. Enterprise Integration is all about predefined agreements between knowns
Hypermedia as the engine of application state: Clients make state transitions only through actions that are dynamically identified within hypermedia by the server (e.g. by hyperlinks within hypertext). Except for simple fixed entry points to the application, a client does not assume that any particular actions will be available for any particular resources beyond those described in representations previously received from the server. Again, strictly Web context. It is difficult to follow which parts of REST are about conversations, and which are about request-reply during those conversations

It's not my intention to invalidate REST. It is my intention to really get behind its definitions, and its benefits, and see where those can be useful for Enterprise Integration. Call me narrow-minded but that's all I'm interested in at the moment. The use of REST for the web? Not my area of expertise, but I believe REST is already widely implemented there.
I think I have done a fair amount of research in order to find out what REST really is about - I even found that one if its pillars, CRUD, isn't part of REST. It got added to it at some point, certainly not by Roy Fielding himself

Is REST useful for Enterprise Integration? Certainly not on the wide basis that Enterprise integration must operate on: multi-channel, multi-message, multi-device, multi-platform, multi-industry. In short: no, absolutely not.
REST focuses on caching, layering, dsitributed hypermedia interaction for an Internet-scale use. That dwarfs Enterprise Integration in size, of course.
But there is also a fundamental difference between the Web and Enterprise Integration. A2A, B2B, B2C: these all operate on predefined, fixed agreements. Can't just plug into the Matrix and try to figure out for yourself what the functionality is of the return of a function - that's the epitome of making assumptions

Where ever I look, REST is aimed to increase performance within an Internet-architecture by enabling caching, layering, intermediate services. Its second aim is to diminish or even avoid rework if parts change their definition or functional form, by using representations rather than the real deal.
The first goal is absolutely unrelated to any form of Business Integration. If there is any latency within Enterprise Integration, this is not the way to solve it - I'd first start to use a better tool.
The second goal is outright forbidden to use within Enterprise Integration. I explicitly want to subscribe to service A version 35 that provides me with information X.29a. I absolutely do not want that to change without my prior knowledge

The main difference between REST and Enterprise Integration is that the former runs on the Web, serving humans. The latter runs inside companies, serving machines. The first must be highly flexible to cope with the inherent dynamics, the second must be extremely rigid to enforce the agreed starics.
Their common ground? Basically, little to nothing

Simple Service Enterprise - part 6

2012-05-22T23:47:00.001+02:00

In my latest post, I recapped on the previous posts and started to take Integration from a business point of view. I'll continue to do that here, and try to mix in technical details without it getting too confusing. Wish me luck!

Here's the conversation again:

Hey Tom! What did the Red Sox do last night?
Dunno, didn't watch the game, haven't read the papers. Try Hank
Hey Hank! Did you watch the Red Sox game last night? What's the score?
Oh man it was quite a game. Lots of excitement, bases loaded with two down, but they scraped it at 15-13

This conversation could happen anywhere, and any time. You've probably created an image in your head that this is in an office or public place, and the person sits close to Tom and Hank.
That is one option - but there are many others:

The conversation is not real-time, but takes a few minutes, hours or even days
The people aren't located in the same room or place
The people don't speak to each other, but use different media: SMS, tweets, IM; even a quick call or email could be feasible here

Would any of that change anything to the content of this conversation? Well obviously the last one doesn't fit in one tweet, but it would in two - other than that, nothing should change, of course. Right? Right.
It would be odder than odd to change anything to the conversation here, just because you're using a different medium.
And it would be even more odd, to change it now, wait for a few years without the medium itself changing, and then having to change it again - wouldn't that be so? Yet that's what the REST fundamentalists advise - and in 5 years or so there will be another "invention", and other people, or the same-ish, who now praise the new new New Black.
REST assured that the majority of those people advocated SOAP a decade ago, for the same lack of (business) reasons

In my eyes, most if not all of these are amateurs who have little to none experience in the field of Integration, and probably all come from one environment: one ERP package, one programming language, one operating system - well maybe 1.5, or even 2 at best

What would make sense? It would make sense that the I's in the picture, the Enterprise Functions, remain unchanged -in essence- while being exposed to the "device layer".
It would mean that you can have the same conversation across any medium: real-life interaction, phone (landline or mobile), social media, text, fax, telex, whatever. Makes sense? Please shout out if you don't think so

Now, into the technical depths of one of these scenarios

Take the mobile device, for example: that would probably be a client-server scenario where the mobile requests an Enterprise Function. For old phones that would be GPRS (offered by GSM) and for modern, WCDMA and HSDPA are offered by UMTS. Those are the physical networks these devices live in, yet doesn't mean they can't use transport protocols like FTP, HTTP, and so on.
So, at least 4 protocols there you can or even should support if you want to "go mobile", i.e. gain market share by embracing the mobile model.
So how about the syntax of "mobile messages"?
Well, anything goes really, doesn't it? What is the syntax Angry Birds uses, or Wordfeud, or Draw Something? You don't know, do you? What if you would love to tap into those mega-favourites?
The message is easy there: the supply isn't in your hands, yet the demand is, so you have to suit up

Basically, this is the lesson to learn for this post: all you Enterprise people who read it, used to the world being mostly blue or green: heads up! The world isn't mostly blue or green, never has been, and really is very reluctant about being treated as such - regardless of so-called architectures devised over a decade ago

Dear ERP people: you can't cover the world in your blanket, because the world does change. The larger your blanket gets, the harder it becomes to change it along with it, and especially: the longer it takes. Your time has come, don't you hear the bells ringing? Your customers do...

SAP Integration? Not what I had in mind

2012-05-15T23:39:00.004+02:00

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

I would have expected for SAP to take Integration seriously. In the light of the new developments, i.e. them buying a few billion dollar of SaaS HR, the ambition to seriously go mobile and the current fuss about all their disparate Integration solutions, I would have liked them to come up with a single solution

In stead, they talk about Cloud Integration. I understand they want to build / compose their own Integration platform. SAP has been trying to do that for years, and it has brought them some kind of integration but certainly not the kind they need, let alone what they need for the future - that is, the future as I see it, so disagreement will abound there.
From the SAP event newsroom:

SAP recognizes that for many of its customers, heterogeneous IT landscapes and deployments across on demand and on premise will continue to be the norm and it is crucial to provide integration to make such a hybrid solution landscape work. To address this need, SAP intends to deliver a cloud-based integration technology, comprised of on-demand solutions for process integration and data services, with out-of-the-box content to connect the loosely coupled line-of-business on-demand solutions to other SAP solutions whether on premise or on demand. For integration to third-party solutions, SAP plans to offer its own cloud-based integration technology and also plans to enable its vast ecosystem of partners, including solutions from Dell Boomi, IBM Cast Iron and Mulesoft

I think the latter three are legacy (customer expectation) that came with Successfactors, or at least I hope they are. Boomi promises code-free integration with o.a. Atomsphere but is a very basic point-to-point integration solution that only works with known applications on either side - not surprisingly.
IBM Cast Iron? Again, the "Configuration, not coding" meme. By the looks of it, it connects to SAP business-in-one and ByD.
In Enterprise integration, about 99% of what you deal with is unexpected or exceptional - and you can't configure the unknown.
Even though handcoding has been admittedly absent from the Integration field for decades, when it comes to making a data mapping, apparently this is a differentiator for these two.
Cast Iron also seems to advocate the direct hard-coupled approach of linking two applications together. It's an approach that nobody will use at that level. For POS systems you might want to ram your connector in there and retrieve or even update some data yourself, but on an application level I'd strictly exchange service requests and replies.
On a whole, Cast Iron vaguely reminds me of Pervasive's Data Integration - yet on a much, much smaller scale.
Mule? That one has been around for a while, and slowly gaining enterprise track. Mule iON makes sense to me, and I wanted to have a peek at their System Integration Edition but that only led me to a form after which I got "Thank you, you'll be contacted"

Back to SAP's Integration roadmap - or is it merely a Cloud Integration platform as it states?
Yet another solution to the Integration challenge, or rather, as I said earlier, it seems yet another disparate workaround to an issue, rather than a solid solution to an Enterprise challenge.
Where SAP makes their entry usually based upon Buy Before Make, I don't understand why they choose to make their own Integration platform when there are so many proven technologies out there.
TIBCO, Axway and Pervasive are what come to mind - yet the real solution doesn't lie in offering a single vendor (although that is not within the mindset of most SAP people, I reckon).
Furthermore, the question remains: what will happen to all the different Integration opportunities already present within SAP? From what I understood from Vishal Sikka, these will remain, at least for now

What SAP could have done, is shed some light on what the future is for all their Integration solutions. If this is it, I might have misinterpreted the information and need lots, and lots more. Will this be their single integration platform regardless of vendor, location, and device? I didn't read that memo anywhere

If SAP were to go my way, they would have made their own stack Integrationable - instead of presenting a technology roadmap for their Integration platform. What do I mean? I'm talking about creating a humanly legible service repository across the board: what services does SAP offer where?
I am talking about business services of course, amply describing the business rules and exceptions for each - the very start for any Integration. If these are logically and functionally known, the syntactical variations in which these can be subscribed to can be disclosed. Add to that the necessary mechanisms of acknowledgement and error handling, slap on versioning, and it would all become a matter of Business decisions rather than Technological ones - and change the Integration approach from bottom-up to top-down

With such, and of course a price tag to each variant, SAP Integration would become a whole lot more insightful and intelligible. Integration vendor, tool or platform would be free of choice, and even mid- and long term ROI would be able to be calculated. The necessary tech dynamics would remain, but the current volatility in SAP Integration would disappear; a very important step if you ask me

Maybe that will come tomorrow, as we still have one day left of Sapphirenow. Mind you, I would have given a limb or two to attend but it simply wasn't doable. I may have misinterpreted some facts as a result, and am willing to stand corrected as usual

Simple Service Enterprise - part 5

2012-05-11T01:10:00.000+02:00

In my first post on SSE I explained why and how I want, and can achieve, and have achieved, an Enterprise Integration paradigm that will give you a device-agnostic, platform-agnostic, tool-agnostic architecture that will free you from being crushed by the two tectonic plates in IT at the moment: diversity in devices, platforms and tools on the inside, and diversity in devices, platforms and tools on the outside

In my second SSE post, I explained why the approaches of the last decade and more (XML, ESB, SOA and SOAP) have failed, and in my third post I dared to state that REST is never ever going to be a solution to solve the issues either.
The reactions I got to that mainly showed me that myopic perceptions persist across techniques - yet replacing SOAP by REST and XML by JSON without questioning the business value of any of those is now being undertaken by the most zealous, and I simply won't have it. Not on my watch

My business is about long term value and benefits for clients and their business partners and customers. I know that, in most of today's world, Integration is an afterthought at best, especially in ERP implementations. Quickly scribbling together an undocumented solution that works for now is what saves many projects.
Some people I know even claim that as a success - as if we don't live in a world dictated by evolution, change, growth. People like that merely give you workarounds to issues, without ever solving problems and handing you the definite solution

Let me tell you: Integration is not a Goal. It's a Means. And it's painless. And it's "proven technology" - with which I mean that successful Enterprise Integration has been in existence for centuries; regardless of technology

How can that be? you might think. It can't be that simple?! you might say. Why has no one told me?!?! you might exclaim. Read on

Enterprise Integration is as simple as day-to-day conversations, or information exchange. Here's an example:

Hey Tom! What did the Red Sox do last night?
Dunno, didn't watch the game, haven't read the papers. Try Hank
Hey Hank! Did you watch the Red Sox game last night? What's the score?
Oh man it was quite a game. Lots of excitement, bases loaded with two down, but they scraped it at 15-13

In (1 a Red Sox result service gets adressed. A request is sent, with the proper attributes. The semantics are commonly agreed upon, and the syntax happens to be English, colloquial

The reply to (1 is (2. The service apparently doesn't have access to the required information, and indirectly redirects to another service who might

The service request is repeated in (3 in a slightly different form, yet the response in (4 is satisfactory

That's how we live. That's how we communicate. We address someone, send a message across, and wait for the return

It is as simple as that. Write a recipient address on an envelope and yours on the back, put a letter inside, bring it to a courier, and wait for the courier to return with another envelope, open it, and read the letter.

What is not functioning in this scenario? Nothing. This is a perfect, simple, timeless model for information interchange. Regardless of technology, free from vendors, and independent of so-called independent organisations like W3C and OASIS

So, what's preventing us from using this model and apply it to our IT landscape?

Nothing.

Come again? Nothing. Nothing is preventing you, on a logical level, from (re-)using the same model of information interchange that has been proven extremely successful over centuries.

Technically, there might be some minor issues - but nothing worth the current excitement over SOAP and REST

I'll address the technicalities of this in the next post. In the meantime, ask your technical integration experts for their opinion. I'll go one level deeper in the next post

Simple Service Enterprise - part 4

2012-05-09T00:08:00.000+02:00

Today we'll take a REST from REST and I'll touch upon one of the issues I ran into today: the two types of data there are. REST assured however that at least a few of the next posts will be about yesterday's topic, as it has led to fierce debates here and there over the course of the day. Yes, pun intended

There are two types of main data: Master Data and Transactional Data. And both have very different CRUD models, requirements and needs

Master Data is what you could call slow-moving data. It does change, but over a very long period of time. Think of parts, people; building blocks to a larger product. It is depicted above as the thick, organic line slowly making its way from the data layer up
Transactional Data is fast-moving. It shouldn't even hit the ground, to help you visualise that. It is depicted as the the thin red line shooting up and out

The most apt example of Master Data is payroll data: employees, people, with their flat structures and simple relations, static and predictable to change at certain points in time: salary changes, promotions, organisational changes, save the odd marriage, divorce and moving hourse of course.
The best example of Transactional Data is supply chain data: orders and inventory statuses, with their multi-level and deeply nested complex structures, continuously changing until the very last cut-off moment

You could even divide the two in batch and event-driven / online. For payroll data there's a monthly cut-off time, for transactional it's daily or even a few times a day.
That also means that the level of automation required is much higher for transactional data, than it is for master data.
Next to that, payroll data must bring images of people-processes (being harassed by secretaries to fill in or fix your timesheets) to your mind as well, where transactional data don't

But in terms of read and write, or simply I/O, the difference is generally distinguished as follows: Master Data is written once, read many times, and rewritten and read many times after that. Transactional Data is written once, read once, and that's pretty much it

Master Data is the basis for a company, it forms the building blocks that allow you to do business, c.q. construct Transactional Data. It is the single largest cause for failure of B2B messages: orders that get sent out while containing items that haven't been "propagated" to the various suppliers.
Again it's the people-process there on top of the Item-Master interface that keeps it from being synchronised real-time - not the technology

These are the two main types of data. Of course there are shades of gray to both of them.
Employee data is thick, but organisational data is even thicker. Trying to automate that by building interfaces for it, is ridiculous. But believe me, I know customers that insisted on doing so - so much for business cases in companies where money means nothing.
Supply chain orders are thin, but auction or stock data is even thinner. Buy and sell and deliver sometimes occurs within less than a second.
Whereas automating CRUD for e.g. organisational changes is useless because the frequency is too low and the requirements never fixed, auction and stock markets have a frequency that is too high to even try CRUD

This world is a one of many shades of gray. It always has been, and it always will be. It lies within our nature to swing from one end of the scale to the other (outer) end, and like a dying metronome slowly swing back to a little bit before the other end, and so on, and so one, until ending in the middle: aurea mediocritas!

Remember though, that replacing a bad architecture or implementation (e.g. SOAP) by a slightly less bad or even better one (e.g. REST), doesn't mean that you are doing your best or even achieving your customer's best - nor does it honour the fact that you can't have a one-size-fits-all solution for a many-shades-of-gray challenge

Simple Service Enterprise - part 3

2012-05-07T23:04:00.001+02:00

My previous post showed the fundamentals of information interchange: exposing business functionality, currently encapsulated in the back-end, to the outside world via services. These services are a one-to-one translation to back-end functions, which are one-to-one translations to business process steps themselves: the smallest level of business transaction.
I also showed that the How of exposing these services, e.g. in which format, largely if not solely depends on a healthy amount of opportunism

This post will explain why REST is a bad idea, while taking the previous one a level deeper

I stripped all the technical details in the Adaptive Integrated Enterprise picture above. What remains, is the back-end, and people. The back-end contains functions that people want and need to use - and that is it

Roy Fielding wrote his dissertation entirely in the context of Web, but I see it increasingly being used as a replacement for SOAP and as such apply to the whole field of Integration. I couldn't care less how people will keep themselves busy trying to change the Web's way, but I will assure you that REST has absolutely no business benefits whatsoever with regards to Enterprise Integration. On the contrary, it has no place in it at all

REST advertises two main thoughts: resourcing and CRUD

"Resources are the key abstractions in REST. They are the remote accessible objects of the application. A resource is a unit of identification. Everything that might be accessed or be manipulated remotely could be a resource. Resources can be static, which means the state of the resource will not change over the time. On the other side other resources can have a high degree of variance in their state over time. Both types of resources are valid types"
REST identifies four verbs or HTTP methods: POST, GET, PUT and DELETE - identical to C(reate), R(ead), U(pdate) and D(elete), the basic functions of a database
I leave REST's constraints for what they are: part obvious (client-server and stateless), part irrelevant for Enterprise Integration (cacheable and layered system), part exclusively Web-oriented (code on demand and uniform interface)

I don't get what business benefit identification or use of resources should bring. You can't expose a resource. In Roy Fielding's own words, it was a problem that URI's changed - he wanted them to change as little as possible, even to remain static:

REST accomplishes this by defining a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created. It is then left to the author to ensure that the identifier chosen for a reference does indeed identify the intended semantics

I have reread that quite a few times, but I just don't get what that means. Functions change when their functionality changes, it can't be helped - and it mustn't be helped. Let me give you some clear examples of that

You're in a hamburger place, and want to order a hamburger. You say "One hamburger please" meaning you call the function / service or URI of hamburger provision with one parameter: a quantity of one.
Suppose that the hamburger place starts selling chicken wings or nuggets and fish filets as well: all of a sudden, their definition of hamburger provisioning has become invalid: in stead of a hamburger place, they're now a food place.
So, the one parameter isn't enough anymore: you also need to provide the type of food. Highly likely even, the function / service or URI of hamburger provisioning will become deprecated and a new one will arise: the function / service or URI of food provisioning, now taking two parameters in stead of one

Unlikely? No, not at all. It's happened to each and every hamburger restaurant.
Will you now call me manipulative because I changed the definition from hamburger place to food place? You can, but it wasn't me who did - it was the place itself that evolved and upgraded its service

But let me amuse you a bit more, and supposed the hamburger place sticks to hamburgers - but from a take-out place they become a bit more of a restaurant, or just decide to become just that little bit customer-oriented than the competition, meaning they'll give you the option: rare, medium or welldone?
Again, another parameter needed for the same function / service or URI

No business offers resources, they offer functions or services: no amount of redefining them as resources or Lawd knows what name is going to change that

So much for resources. They're just another example of a complicated solution to a simple problem - and I'm not even sure I understand the problem. What I do understand, is that this perceived problem doesn't exist in Enterprise Integration - there's a difference between a hamburger place, a restaurant, an a-la-carte and a 5-star dining place, and there's a linear line going through all four from simple service to complex

Verbs, or methods? The same applies, and let me give you another simple example. Can you delete a hamburger in a hamburger place? No, you can only order one, i.e. create. Can you modify it? No, you can only buy it once, or not at all. Can you give a hamburger to a hamburger place? That would be like carrying water to the sea, wouldn't it?
So, inventing all these methods doesn't change the fact that only functions / services are offered by the business

But let's suppose that there's something like a full CRUD URI. Let's take the booking of a hotel room. You create a booking, meaning you pick a room type and date, and pay for it, and the transaction is committed.
Can you delete the booking? Yes, and your money would get refunded. Normally, you pick up the phone and handle this exception on the people level. It would be a very hard case for me to make that this should be an automated service, given the fact that the limited use of this service will simply not ROI.
Not to mention the fact that I'd really like my employees to interact with my customers when the latter cancel a booking - don't want someone to book 50 rooms, pay for them and cancel them all just in time to get all money refunded...
So, modifying would get even harder. Not only is the customer entitled to a refund, but he also has to make a new booking - all in the same transaction, while there is no business relation between the two actions

So, I fail to see how this would be a handy addition to the Web, for even a simple service like booking a hotelroom - the level of trust needed for a fully automated CRUD model simply does not match up to the level of anonymity that exists out here

Is REST a good addition for the Enterprise? Most certainly not. The resource idea is too simple for the complexity involved, and simply irrelevant on a business level. And the CRUD model has of course been in existence for decades, and successfully handled in Integration for equally as long

Simple Service Enterprise - part 2

2012-04-28T15:23:00.000+02:00

Yesterday's post was about Simple Service Enterprise, and showed the basics: to keep up with the growing diversity inside and outside your enterprise for getting the same functionality on different devices and platforms, you need an Integration layer (the red in the middle). Can't argue with that, point-to-point integration is a neat quick and dirty solution for very small IT landscapes and doesn't scale cost effectively

SOA attempted to do so via ESB, but there a few reasons why that failed:

SOA was largely interpreted as having to do with webservices, i.e. XML wrapped in SOAP envelopes. Basically that meant, given the immaturity of both, that every one for himself defined and built his own XML and SOAP. Loads of restrictions, no benefits at all
ESB was largely interpreted as a dumb bus that got served by all applications, who needed to speak the new language. In stead of facilitating, it was limiting applications. Doing so, it gave the illusion of a uniform IT at a very, very high price. It also severely impeded phasing out applications and moving in new ones, as every new application had to go through the same painstakingly expensive effort of complying with the ESB's format
SOA for some strange reason enforced composite services: this meant offering functionality not in place, and conjuring that out of thin air. It highly complicated SOA, and commiting or rollbacking a composite service naturally posed a huge issue

What was good about SOA? The idea that you expose existing functionality in the back-end in a uniform way. Was that new or shocking? You know my answer to that question

Why do I call this Simple Service Enterprise? Because it is.

A business has processes.

These processes can be divided into process steps, the smallest transaction possible that can be committed and rolled back without biting your tongue.

These process steps can be translated into (and usually are) business functions in the IT back-end.

The business functions together form a module or program or whatever name you want to use, and those combined are called application - an application takes care of at least one process, usually more

So the smallest business transactions are process steps, and those are taken care of by IT business functions.

If you want to take those out of their comfort zone and expose them to other people and / or businesses, you can do that via services. You may call those services interfaces, integrations - whatever. They're just exteriorised back-end IT functions

Functionally, whatever you expose, you are not going to change anything between back-end and which ever frontend. Not a bit nor byte - nothing. If the business wants additional functionality, a business process or process step will get changed, deleted or created. That in turn will lead to a changhed, deleted or newly created function of module / program in your back-end, and it will be just another IT business function slapped onto the existing pile

Hence the three little arrows in between Information layer and Integration layer: those are just applications exposing their functions in a form that's most convenient and cost efficient to them. XML? Maybe, if that fits the definition. JSON? Same applies. EDIFACT? Silly example, yet same applies. iDoc? Same applies.

The Information layer only exposes full functionality to the Integration layer, so no one cares in what form that happens - as long as it's as fast, cost-efficient and (re-)usable as can be

Then, let's take a big step and meet our new friends right at the very top of the picture: people of all kinds in all possible locations and roles: employees, customers or consumers: paid people, paying people and all others.
Do those people care in which form those services get exposed? No. They'll be looking at them via screens, in which applications will run which will present them with fields, and the business functionality content will be in those fields.
Does it matter in which programming language those applications are built? Sure. Take the easiest ones, the best, the simplest, the most cost efficient, those that allow you for the smartest and sexiest representation, the best ease-of-use, in short: those that give you the biggest UX at the smallest price

Java, .Net, Ruby on Rails, PHP, script, HTML, XML, whatever? Exactly - whatever

So then, who does care about the format in which these services are exposed? Well, it seems nobody does. So what are the requirements and limitations here then?

Bandwidth, because the services need to be exposed and thus transported from the back-end to somewhere else on this earth, and vice versa: the further away from the office and civilised world you get, the smaller the bandwidth
Fit, because most programming languages and platforms have a predefined taste, and even ready-built building blocks or components. The older the platforms and programming languages, the more old-fashioned that taste is and the higher the chance that building blocks are present. The newer the platforms and programming languages, the smaller the variety as well as the chance that building blocks are present: old will ask you "Well what do you have to choose from and we'll just pick one", new will tell you: "Listen we only support format XYZ"
Location, because as with bandwidth, the further away from the office and civilised world you get, the smaller the choice of infrastructure

Bandwidth will influence size of message, fit will influence form of message, location will influence transport protocol.

Whatever these will be, the functionality will not change because you're still using the same services, nor will you have to change your architecture because the Integration layer will interchange information with the outside world

It is absolutely out of the question that a new device or programming language will affect your back-end in any way whatsoever. Next: why REST is a bad idea

Simple Service Enterprise - part 1

2012-04-28T01:42:00.000+02:00

I plead for a Simple Service Enterprise.
One that is ruled by Business, not IT.
One that is interoperable with any other business, customer or consumer, regardless of the platforms they operate on.
Regardless of the vendors that dominate those platforms.
Regardless of the programming languages used on those platforms.
Regardless of the devices used.
Regardless of the operating systems running on those devices.
Regardless of the programming languages used on those devices

I wanna have it all, for free - or almost free. I want a fuss-free, cost-efficient, business that scales horizontally, vertically, diagonally even if that's what I need; because either my customers demand it, or it allows me to gain market share - be it regaining lost share, cannibalising existing services that will be cannibalised by others if I don't do it myself, or simply gain market share in new markets

And I need IT to follow me where ever I go, sustain me all the way, not in the future, not in the near future, not when ever their partners decide to, I want it now. NOW!

I sympathise with you - and offer the solution right here

The picture above depicts our comfort zone: old fashioned data at the bottom, a few services on top providing the functionality and information that makes up our core business, a presentation layer, and our end user who is in our office. Welcome to the past, and the present of course. I'll be playing the role of Business for a short while

Fast reverse 10-20 years. There are our trading partners to the right, with whom we do business. Ten years ago, consumers decided they want to do business with us as well. All good. Both cost a bit of money, but it was all worth it:

Then, devices popped up all over the globe. Phones, tablets - and they all wanted to have what everyone else was getting. Worse, even our own employees demanded so. It started to become a whole lot messier:

Then, people who had told us that XML and SOAP were to lead us into the future, now claimed that JSON and REST would bring us into the next future. Of course we listened to them like we did before:

We have to admit that it cost tons of money, yet when we, business, asked they always screamed: we're just providing the same three services we've always provided, you should be grateful!
But we weren't grateful - we were confused. We just spent gazillions on XML, WSDL and SOAP, and lengthy (not to mention costly) projects, in order to build a SOA, because that's what should be done, IT said. And now, all of a sudden, the future had changed!

(...) Exit me, enter me.
Welcome to my world. I don't get it either. Well I do, but I don't get why businesses don't properly subject all this to sane ROI inquisition like they should (have ages ago)

Here's what I've advised, architectured, designed, built and implemented in the past 15 years. It's cost me many, if not all, customers, because none of them ever called me afterwards because they had a problem, or even an issue. I see some of them every now and then, and when I ask "And, well and, how is it doing?" I get the utterly disappointing answer "Fine, very fine. Thank you"

This is what I left behind:

Notice the differences? There are quite a few.
In the next posts, I'll drill down to their details

Oh Google, why did you stop being sexy?

2012-04-25T23:18:00.000+02:00

[Image by Exey Panteleev]

Born out of a tweet from Tom Raftery, who pointed me to Google's Terms of Services concerning their latest love child: Google Drive

I waved at Google Wave, Buzz didn't thrill me other than enabling the opt-out in Google Mail, and I jumped onto Google+ as soon as I could but the effort I put into it (and the goodies I got from it) went downhill fairly soon after.
I skipped Google Drive. I have a fully mirrored NAS meaning I don't care if a disk breaks, I can access it from anywhere in the world and the fast-moving docs I have on my laptop and phone as well, as I have to be able to work offline anywhere, for any duration

So, I didn't read their Terms of Service - but someone else did, and it looks awful

ToS's have always been fluffy and hardly legible and some do a worse job at it than others, yet that's not my point for this post.
The point is, that this pretty much kills or at least severely hampers the bandwagonness of Google Drive (making up words as we go here). And that's not this post's point either. The point of this point is:

Why does Google fail to attract? Since when?

I used Yahoo mail and MSN mail until Gmail came along - I loved it right from the start. Free from clutter, ads (yes, that was my experience!), lean and mean, quick, and so much storage that some people even thought it was ridiculous, or obscene.
I moved my MSN and Yahoo accounts to Gmail, started checking them on a monthly basis only and half a year later I slowly let them die - all decisions made within a week.
Then, Google Docs drew my attention, and it was excellent to share docs with colleagues all over the world across all "IT security" boundaries - even enabling us to work simultaneously on the same documents. W-O-W!

I've pretty much "grown up" doing hardcore Integration in the B2A area, straight from one backend into any other. My favourite industry? Logistics. Fast-moving goods, slow-moving ones, but especially raw materials, intermediate goods and finished products (the lifecycle of a product) and their various itineraries have always drawn my attention

Gmail launched as a finished product. It hasn't changed since, nor will it - nor does it need to.
Goodle Docs launched as a finished product. It has changed a wee bit since, but that hasn't altered the core benefits.
Both were simple, brilliant concepts: Gmail with its lean and mean design, fast performance and magnificent spam protection, and Google Docs with its ubiquitous access and superb simultaneous editing. Dazzling and sexy from the start

Google+ launched as a finished product - but it was a complex one. Introducing the great concept of Circles wasn't enough, it mixed tweets, updates, blogs, commenting, liking and / or hiding any of those, video conferencing for the masses, importing any contacts or friends from anywhere to populate G+ itself, and the list is endless really.
It's proven too much too handle for me. I spent so much time trying everything that I found it to be quite a lot of work, rather than a lot of quiet (business) benefit

I really would have liked G+ to start as a bit of raw material, with Circles as the Big Benefit. Then, slowly, witness it upgrade to include other functionality over time - weeks and months, like e.g. Yammer has done.
Build up the momentum, please the users with something new every so-and-so period, listen to their suggestions, mix those with your own, peel off a layer of clothing every now and then Google - learn to striptease

In stead, all of G+ was released to a selective audience, and when that audience started to show to lose interest a bit, the flood gates opened and no one really knew to whom they should hand out their invites. Yes, that's a form of peeling off layers of clothing, but it's pretty much like Leslie Nielsen undressing in the Naked Gun, taking off his entire suit with one finger within one second - hilarious, but certainly not sexy

Google Drive launched as a finished product. Of course it allows you to "Google Docs" your Drive content, and is available on PC as well as Mac. It offers full search, even OCR's your images into text while doing so (unsure of the "while" here, my own word), and there's an Android app of course - while working on an iOS one.
Showing some leg there, promising an Apple app, Google? Oh my. Fortunately, your "This is just the beginning for Google Drive; there’s a lot more to come" keeps me in exhilarating breathlessness though. Oh the promises, the vision, the road map, the joyful invitation to all people on this globe to share their ideas, please, hand me my inhaler!

Then, the ToS truck hits them. In all fairness, it's as garbled as the usual ones, but in all fairness (bis) it does a far worse job at making things clear. The end result? Reasonable doubt, or rather: the general public will find them guilty (yes I know that's supposed to work the other way, but it hardly ever does, now does it?).
Why? I mean please, hardly anyone reads them. I know I do, every single time I decide to sign up for a service - but then again I'm an exception to the rule there.
Why not just state, like Dropbox or SkyDrive, something along the lines of "You retain full ownership to your stuff. We don’t claim any ownership to any of it. These Terms do not grant us any rights to your stuff or intellectual property except for the limited rights that are needed to run the Services, as explained below"

That would greatly lubricate adoption, wouldn't it? Just stating that right at the spot where it matters? How much ink would that cost? Maybe that would make your ToS redundant up to that point, but it probably is at a few dozen others too. Why not tell the lawyers to rephrase their anal terms in a way that it doesn't cost you clientele nor revenue, not only not in the future, but especially not right now?
I mean if you're really evil, you can always change the ToS afterwards, even fewer people read it at that point (I'd consult with Twitpic first though)

Listen, Google: you got to change. Abandon the path of copying what the competition invented earlier, mixing that with all you have, and presenting that on a silver plate as a finished product that is frozen stiff.
Study the product-cycle, watch some striptease vids, learn how to lure and bait, skim the market layer by layer, piece by piece, and control yourself - don't give it all away mere seconds after you've made an entrance.
You're in the fast-fashion business whereas you should be in the slow-fashion one, dear Google. You have the money, the power and the glory to walk the catwalk - and keep or push every one else out. But when was the last time you did that?

If you're really sexy, Google, you just OWN the stage, even if it's not yours. Yet the last time I checked, you fell off a long time ago. Why don't you try the subtle approach: works for most

Why management rocks, and leadership sucks

2012-04-23T21:20:00.005+02:00

[Image by _MG_5503]

The past 24 hours I had a fierce conversation on leadership and management, and I love how just everyone joined in on Twitter; especially those that disagree with me because they teach me most in the shortest amount of time

I started it with

Every one wants to be a leader, but no one wants to be led #leadership
- Martijn Linssen (@MartijnLinssen) April 22, 2012

By the way, that picture of the Redskins cheerleaders is just there to spice up my blog and the post. Might lead your eyes astray for a moment, but no pun intended. I had a very hard time to select photographs that weren't shot at some battlefield or military institution, seems like the US army keeps their men happy that way. Now that is what I call management par example...

A few quotes:

and from there we went on to management, of course:

managing and leading are massively different, nearly disappointed you don't know the difference :-) #windup
Management is telling me I'm wrong, Leadership is convincing me I'm wrong.
don't need to be manager to be leader. See my Venn: #Leadership vs #management http://t.co/Zu8OQBmE

A lot more followed, and images quickly formed inside of my brain. Let me jot down a few thoughts from the conversations:

Managers and leaders are made from different stuff. They can be both, but that's an exception rather than rule
Many want to be led by leaders, but very few want to be managed by managers. Can you be led by managers, or managed by leaders?
There are many people who prefer to have others stand on the stage, or just take responsibility
Managers seem to take the more task / activity orientation towards them, leaders get involved in conceptual / strategic matters
In general, or let's say popular opinion, if you're bad "at it" you get to be called a manager, otherwise a leader - and vice versa

Martin English hits my nerve when he asks "maybe Management is about managing processes and people, Leadership is about changing processes and people ?"

I dig change versus growth very much, and I see my favourite topics coming together again:

Managers live by rules, are rigid, instruct you what to do, like to order the simple tasks around your working day so their predictions can easily be measured. Leaders go for the exceptions, are highly flexible, ask you what you want to do, start something complex and see where that will lead to
Managers approach you from the outside, leaders approach you from the inside
Managers stand at a distance from you, leaders are close - distance versus proximity
Speaking in Push versus Pull: managers Push, leaders Pull. Managers force you to adopt their methods, leaders gently tweak you into adapting to their new ways
Managers want to change you, leaders like to see you grow - anonymity versus intimacy

These are the black and white definitions, and let me throw a few associations into that same pool then while we're at it:

Managers are so 1.0 - leaders are 2.0, no, 3.0 even
Managers are suffocating Enterprises, leaders are found in abundance in Social Businesses
Managers keep you in your straightjacket: if they can't keep make you change into their mold, they'll at least stop you from self-development and growth. They will either grow you in their direction or not at all: managers treat you like a bonzai tree
Leaders challenge you every day, inspire you, make you question everything - they don't give you answers, they make you look for them yourself. Leaders stimulate you to reach the very best in your Real Self
Leaders live by Love and let Love, managers use Fear to scare you (back?) into the ranks

(I thought I'd take that all the way through)

This is a hot topic for me of course - it's all about Business or Pleasure, and if leaders achieve one thing it is letting you have Pleasure in doing Business, even if you're just a simple drone. I have depicted a few outer-scale characteristics and opinions on managers and leaders, and I think both have a goal and place

If you take my Social Business Magic Quadrant, elaborated in my Social Business eBook, you'll see that leaders pretty much follow people, and managers follow products - although that may be putting things in a wrong perspective. Leaders are needed most where people interaction is highest, beit among employees or in between customers and employees

But do we all want to be leaders? Even if so, we shouldn't. Can't have leaders in assembly lines, you need managers there. Can't have leaders awaken all the employees in a business unit - let sleeping dogs lie. Can't have leaders for your old employees who only have 5 year more to go until pension, already counting down since 10 years before that. Can't have leaders be nice and kind and inspiring when you need to lay off people, cut to the bone on the verge of survival. Your company (including all your customers) or your employees? Tough but simple choice...?

Other than that, leaders are high-care personnel. Leaders demand blank cheques, commitment from their managers and peers, a big bonus when they succeed where others have failed. Let's just say that leaders know how to positively wield their ego. But put three leaders in one room and I doubt they'll all make it out of there alive

I think we like leaders because to us they represent the good, the nice, and the lovely. I think we overdo all this leadership worshipping on our road to Social euphoria, and make asses of ourselves when we play the evangalyst role trying to assess their value for a company

I think we sometimes need to get back to the cold harsh reality and admit that you can have five leaders in one company at best, but can never have enough managers: dozens, hundreds, thousands even.

Can't have too many managers - that, history has shown

SAP gets the Future of Integration

2012-04-15T22:15:00.000+02:00

OK, I'll admit it: this title is heavily (heavenly?) influenced by the previous Easter weekend - yet has no relation to it whatsoever. Or has it?

Let's skip the usual introduction, here is the message from Vishal Sikka that absolutely thrilled me

@MartijnLinssen @steinermatt we do.The Gateway. It will simply be services in HANA.Also PI, NW rules engine, MDM, EP, all in or on HANA
— Vishal Sikka (@vsikka) april 12, 2012

I have never been a big fan of SAP. I presented my Enterprise Integration 101 at Sap Inside Tech NL last year, and the Borg picture of poor old Jean-Luc Picard is some representation of my feelings regarding any (ERP) monolith

Yet, after this tweet, I have been turned. Into a Borg? Maybe - I just couldn't care less at the moment

For your information, I visited Wikimedia for a nice picture. This is today's: A storm of rapid star births in Galaxy Centaurus A

Apt. Very apt. Vishal's words tell me a tale of what's to come for SAP, and I won't mention the word disruptive but if SAP follows up on this, well, I might need to modify some posts.
Let me walk you through the history of Enterprise Integration, where and how that went completely wrong, my vision on the ideal world, and how SAP will enable my vision. Say what? Yes

How the IT world came to its current form

In the beginning, there was a business application. It was whole, and it ran somewhere in the bellies of an enterprise, on mainframe. It would solely rely on data entry by living human beings, aka users, and check and verify, i.e validate, the data entered before swallowing it whole and storing it onto tape or disc, becoming the Single Source of Truth (needless to say, there wasn't an issue around sources yet, let alone truth, so that phrase didn't exist back then, but let's just use SSoT from now on).

Then, information interchange entered the scene: user-less data coming in sideways, from one machine to the other. That too had to be validated before being able to enter the SSoT, so another validation layer got introduced

Then, databases replaced file systems. And front ends were introduced. And B2B arose, and information interchange between enterprise applications grew out of hand. Point to point database connections ran into limitations of uptime, validation, and general control. B2C complicated matters even more, and Architecture saw the light, dividing everything neatly into tiers:

Presentation
Business logic
Data

Architecture still didn't solve the integration issue: data has no users, so a separate layer mimicking the business logic layer had to be introduced in order to make sure that no invalid data entered the database

B2C created new front ends facing new users, implementing an extra presentation layer. Still, like in the old, data validation was done in the presentation layer as well, leading to extra costs that theoretically could have been avoided - but certainly not in practice. ESB's were used to some extend, but mostly as dumb transportation systems for custom-made XML, wrapped or not in a bilaterally agreed-upon SOAP header

B2B avoided all of that, as its data came from backends. As such, it put business applications to the test and put the spotlight in some cases on IT fatigue: imperfect backend systems that were perfectly intelligible to its users but had outrun the initial data model, freely abusing unstructured text fields to provide information - useless to machines, of course

A2A, application to application information interchange, ran into issues of ownership: there was no clear audience or consumer, nor an identifiable owner. Most applications were shared in at least a few ways

Then, the concept of services was discovered in IT: business services. Hyped as Services Oriented Architecture having to rely on an Enterprise Service Bus, the combination of which being widely misunderstood as having to transmit data in the form of XML via SOAP, it cost many enterprises dearly. Yet, the idea itself was a sane one

What it should have come to

The main error committed during the ESB and SOA hype was the fact that Architects viewed the IT landscape from above, high-level, and judged: all this diversity ain't good. These applications need to comply with our standards.

Needless to say, these standards architects referred to, had been invented by themselves just a few minutes earlier - in the best-case scenario, that is...

That's like inventing Esperanto and demanding that everyone in your club or group masters it. Just checking: how is your Esperanto?

Right. The simplified version is that an ESB should facilitate, not dictate. An ESB (and the same goes for SOA, by the way) should add value to your company by doing something for your applications, and not the other way around. An Enterprise needs a professional interpreter who translates all the technical diversity back to the business uniformity, serving both business as well as applications. Applications exist in your landscape because they're the best of the best you could buy for money, solely, or at least mostly, because of their functionality.
Problems arising with regards to information interchange into, and out of those same applications? IT problems, to be solved by a central interpreter/translator: not by making every application speaking the same technical language, that's an enormous waste of money

The ideal world

In the ideal and perfect Enterprise Integration situation, and Lawd knows I have architected, designed, built, tested and seen countless of those, there is one backend (layer) and it contains the full business logic that the Enterprise needs.
It consists of best-of-breed applications of all sorts of platforms, vendors, programming languages and databases, and talks to anyone else through the ESB layer. It does so by complying with the functional needs for the specific service at hand (i.e. semantics defined by the business), in a technical syntax that suits each application best

The ESB takes this syntax and translates it into a simple, uniform syntax that can carry along the full business process definitions: old-fashioned flat-file or new-ish JSON would suit fine.
That's on the message level: on the transportation level the same happens. If you have an old mainframe, MQ series would be best to carry information to and fro, yet web users will (want to) use HTTP - no problem, similar translation there by the ESB, from one transportation protocol to the other

So, you have one backend, Lawd knows how many different frontends (Desktop, laptop, mobile, web user, B2B, etc), and one ESB that decouples it all, receiving, translating and sending service requests and replies

That's my vision on Enterprise Integration, and it always has been - and it will never change. It will give you access to this

and I call it Adaptive Integrated Enterprise. Look at the colours, and you'll see how each speaks its native tongue to the ESB hub, which takes care of all the nitty-gritty tech stuff, working hard as it should be.
It will e.g. link the following tech diversities:

This is a mere example. SMTP for email is missing, so is SMS, MMS, X400, X.25, JMS, industry messaging standards such as HL7, Swift, X12, and this picture is just a snapshot anyway - in 5 years it will be invalidated for at least 1/3rd.
But, I hope it shows my point: many points of entry, all totally different, yet if relatable to the business in a profitable way, drag them in there and prepare them a warm welcome

What the naysayers (would) say

Oh my, that's quite a bottleneck in there, isn't it? Not only will it take quite a performance drain, but imagine how long everything will take, making it from A to B and back, through all those layers of translation!
Probably. While the TIBCO's of this world are used to handle millions of messages per second on a single box, people who live in the Java world live by different standards: a 30-second timeout for one single request-reply is considered tight

Hence, within SAP, among others, continuous attempts to bypass any piece of middleware and fiddle a solution together yourself. Sometimes excuses are used that (draft) tech innovations aren't yet supported, most of the time performance and "ease-of-use" is used. "Much quicker to build!", "Great debug facilities!", and "All you need for REST is a webserver and a consumer that understands HTTP!" are some of the arguments made by coders

Integration middleware is a means to a goal: the goal is sustaining the business in a cost-efficient way.
You don't do that with dozens of disparate home-made geekified tech wonders: you do that with a centralised solution that stands in the middle between your world and everyone else's, giving you full control over incoming and outgoing data- and information flow, who used what when and most, and build a BPM layer on top of that, or BI, or Big Data, or whatever you want.
You need a uniform business information flow on top of your so very diverse IT landscape, regardless of its brand, make or colour, and for that you need an ESB that speaks all syntaxes, all protocols, and can support (or simulate) all new tech "innovations"

SAP to the rescue

And then HANA enters the scene, running middleware on top of it. This would solve any and all issues! You'd simply hurl out your native request to the HANA-ised Message Broker, which translates it to your client's uniform business language, looks up which application(s) will make up the answer, translate it to the language syntax those expect and send it off, await the response(s), again translate those to the uniform business language, and into the initial native language again

That does sound complicated and a lot of work, doesn't it? Yet, it's the smartest solution to the problem, and proven technology since decades. Performance has always been the biggest objection, and the irony of it all is that the introduction of XML as an integration syntax actually did cause an issue.
Yet, the P-word can't be used anymore, can it now? Not as far as I'm concerned, nor Vishal it seems. The new bottle-neck will be front-end and back-end performance, and everything in between will simply fly

This approach will turn all of SAP into simple back-end services.

Java or ABAP? Who cares - whatever makes you feel good, just point and shoot
Mobile? Build a front-end in HTML5, fire off mean and lean, slim services, and anyone can develop mobile SAP solutions
REST? Just take the unsupported HTTP extensions, their required parameters, transform them into the uniform business request actually meant, and on the way out simulate the REST service again - the bandwagoneers will love you for it

The HANA-ised Service Broker will simply wrap SAP functionality into any service you want, and with the word "performance" and "overhead" out of the way, the uniform business language (yes, the canonical) will make it back into play and enable cost-efficient BPM, EDA, CEP, BI - whatever you want

This will finally elevate Integration as a profession back to where it belongs: in the centre of the IT landscape. Application rationalisation? I've advised on Enterprise Integration before (where there are more than a few Integration products providing similar functionality) but this will take that a whole new step forward I suspect

SAP to point out as the ones who raised Integration from the deep sleep? Who would have thought...

How Dachis failed the Social Business test

2012-04-07T16:36:00.000+02:00

[Image by Pablo X]

My post the other day on Dachis deleting blog posts of employees who left has led to quite a bit of Twitter conversations - not all of them equally pleasant nor a true example of Social (Business). I feel that this extra post is needed to bring some closure, and achieve some lessons learned. I'll show how the story has unfolded, and also

I wrote Is Dachis rewriting its own history because at that point I had found that certain blog posts were no longer present, and Dachis (Dave Gray, informed by Peter Kim) ensured me that no blog posts had been removed.
In the light of those contradicting facts, writing the post was inevitable

My conclusion to the post was

The only conclusion I can reach, is that all of Armano's and Devon's posts have been removed from the Collaboratory. The only mitigation I can find for that, is that such a statement is not a strict matter of fact, because the website has been redesigned and "messaging has changed" as Dave Gray put it - meaning that Dachis must have forgotten to include David's and Jevon's posts while doing so

An omission? Your words, not mine...

Here's how the story unfolds:

I publish the post, and Dave Gray does it off as irrelevant: . @hjarche Oh please. Alert the media, a link is broken! @MartijnLinssen @dt @dachisgroup @armano @jevon #silly
Dave then comments on my blog, contesting my findings and referring to it all as "broken links" that to the best of his knowledge were unintentional
Then Peter Kim chimes in, telling how back in 2009 Dachis deleted all accounts of employees who left, as a consequence deleting all his posts. In addition, he assures me that "omission" is mine and my description only
Peter also entered a second comment to my post in which he explicitly states that he misinformed Dave Gray

So, Dachis did delete all blog posts - hence my conclusion was absolutely right

There, all done. I got misinformed because Peter misinformed Dave, hence I wrote the post and reached the conclusion that all posts in fact had been deleted, Peter Kim of Dachis comments to my post confirming the fact that these posts have been deleted, thus sharing my conclusion, and also informing me that he misinformed me via Dave Gray.
Case closed, right? Wrong

A rather ugly conversation unfolds on Twitter in the meantime. Several people joined, but I'll stick to those where Dachis was involved

Dave Gray's reaction to my reply to his comment?

@MartijnLinssen yes you have convinced me that you are either vindictive or misguided @hjarche @dt @dachisgroup @armano @jevon @techguerilla

I choose not to be offended by that, and reply:

@davegray I was rather expecting you to apologise for unintentionally misguiding me @hjarche @dt @dachisgroup @armano @jevon @techguerilla

Dave then says:

@MartijnLinssen I had some facts wrong. But my mistake was thinking you wanted truth @hjarche @dt @dachisgroup @armano @jevon @techguerilla

and even assures:

@MartijnLinssen no. Unintentional byproduct of deleting employee accounts. Blog posts were not intentionally deleted. @techguerilla @armano

Then (over a dozen tweets have been exchanged to this wide audience) Jevon MacDonald joins in with a fun tweet

@davegray @martijnlinssen @hjarche @dt @dachisgroup @armano This feels like a family fight at Christmas dinner. Pass the gravy!

and matters settle down. Still, Dave can't resist:

@armano and apparently I am the family member who feeds the trolls :/ #lessonlearnedihope @jevon @martijnlinssen @hjarche @dt @dachisgroup

It takes David Armano to end the conversation:

@davegray @jevon @martijnlinssen @hjarche @dt @dachisgroup Dave, when are you going to stop feeding the trolls and settle down! :-)

The conversation lays low for a few hours, picks up again when Ian Fenn joins, and ends with David Armano inviting us all for Thanksgiving, me saying that I'll then bring the knife to slice the turkey, and Dave ending with a positive note saying that that would be very interesting (referring to David's invite)

Quite a drama, but the curtain has fallen. Or has it? Believe it or not, Peter Kim decides to write a piece about trolls and turds on his blog and ends with the advice:

Next time you see a heated online exchange -- whether you're directly involved or not -- be curious, not furious. What you discover may surprise you

That post puzzled me beyond oblivion, and images of Dr Jekyll and Mr. Hyde very briefly crossed my mind

Last but not least, Peter Kim left a comment on Dennis Howlett's blog as well. It's in the same line of answering...
Alright. Apparently, this is how this story has ended, leaving us all with a few burning questions:

If blog post deletion was unintentional, why the angry reactions from Dachis? And why persevere in those?

An even more burning question is this:

If blog post deletion was unintentional, will they now be restored? I'm sure David and Jevon have copies of each of those, and it would only take a few hours to put them all back up again

Last but not least:

What will happen in the future when an employee leaves the Dachis company?

How this story should have unfolded

From my point of view, let me tell you how this story should have unfolded in a Social World:

I tweet about missing posts on the Dachis blog
Dachis confirms that no posts have been removed
I blog on the topic with the same post, as the contradicting facts only leave for two conclusions
People from Dachis read my tweet, and answer "That would be the day" or "We're certainly not rewriting (our own) history"
People from Dachis comment to my blog, somewhere along the lines of this:

Hi Martijn, nice title - fairly sure that will make for some good SEO ;-)

Thanks for pointing this out, we were absolutely not aware that blog posts were missing. Evidently, no one else was! In that light the statement from Dave (where he was merely relaying Peter Kim's information) is odd of course - let me explain. At the time they were having lunch and Dave asked Peter the question, who didn't do any online research but just answered from the top of his head - to the best of his (and all ours!) knowledge no post had been removed.

Well, it turns out we were wrong. We have done the research now, and we have found that deleting a blog account also removes all blog posts... Deleting blog accounts are just part of the process when an employee leaves the firm; all their accounts (Email, blog, Yammer, Basecamp, etc) get deleted.

Needless to say, that was not what we had in mind! We now have a few actions outstanding of course, most of which will probably get carried over this Easter period - bear with us please:
1. Do we, or don't we, restore all posts by David, Jevon and Oliver? Pro's and cons there, one of which being the exact date at which they got published - we'll probably run in to more after spending more time discussing this
2. If we don't, what do we do with the broken links?
3. What will we do in the future? Now we know that blog posts get removed when we delete an account, we might (and probably will) treat this differently.

Again, thanks for pointing this out, and our apologies for initially misinforming you about blog post deletion. Needless to say David and Jevon are well-respected ex-colleagues, and even if we wanted to rewrite our own history, in this online world that -as you just have pointed out- is just impossible

We'll keep you posted! Cheers, Dachis

A nice, balanced, mature and professional way of dealing with this, which would have me instantly satisfied and highly likely have me write another post about how fantastically Social Dachis' response was to this fairly nasty predicament - like I did once with Tamsen McMahon

United breaks guitars is on top of the list of social media failures involving traditional companies. Will this incident make it to a list of its own?

Is Dachis rewriting its own history?

2012-04-04T21:36:00.001+02:00

David Terrar and I were discussing his post on Social Business in which he takes a trip down memory lane back to even before the coming of E2.0 as we knew it, and I was pointing him to my Redefining the meaning and goal of Social .
I clicked the link to David Armano's post Tweeting at the speed of scale on Dachis' Collaboraty, to find out it was a dead link. Odd

I then went to his reblog of that on his own blog, in which he points to the same link - gone to (of course).
I made a remark about that:

@DT know what's funny? @dachisgroup removed @armano's post defining socbiz: people, process, technology (looks like all David's post r gone)
— Martijn Linssen (@MartijnLinssen) April 4, 2012

and a discussion followed between Dave, me, and Dave Gray who pitched in, telling that nothing had been removed, according to what Peter Kim had just told him (on a different channel, apparently)

@MartijnLinssen @dt pretty sure Dachis did not have a blog when @armino left. @dachisgroup redesigned website, changed messaging, that's all
— Dave Gray (@davegray) April 4, 2012

@DT that's what @peterkim just told me. No blog posts have been removed @martijnlinssen @armano @dachisgroup
— Dave Gray (@davegray) April 4, 2012

Odd. So I must have been wrong? Only my wife proves me wrong succesfully, yet nonetheless, I rechecked of course.
Just 4 days earlier, I wrote Business case for Social Business Design, in which I link to Jeff Dachis's Social Business Design. The Enterprise is Dead. Long Live the Enterprise.

Same place (the Dachis Collaboratory), same year (2009), same month (11, i.e. November). Yet there. I must be dreaming then? No.
In the same Redefining post as above, I link to an interview by Jevon of Andrew McAfee. Gone. Just like David's and Jeff's post, also located in the Collaboratory, 2009, November

So, I go to the Collaboratory directly, which turns out to have been relocated indeed: links don't start with e.g. http://www.dachisgroup.com/2009/11/ but now have the form of http://www.dachisgroup.com/blog/page/.
Ah, OK. Settled then - turns out I was wrong indeed, doesn't it?

Errr, hang on? Didn't Jeff's post on the old Collaboratory (http://www.dachisgroup.com/2009/11/social-business-design-the-enterprise-is-dead-long-live-the-enterprise/) just link fine? It did!
So, off I go to November 2009 on the now new Dachis blog: starting October 30st with a post by Bryan Menell at the bottom, and moving up to November 19 with a post by Daniel Siddle. Mmm, maybe later in that month then?
November 20 marks the end of that page, post by Kate Niederhoffer, and Robin Hamman tops it off on December 16th.

No posts by David Armano. Nor any by Jevon. Both have left Dachis - could there be a correlation?

The blog might have a new address, but the posts still point to the same old structure: http://www.dachisgroup.com/2009/11/...

The only conclusion I can reach, is that all of Armano's and Devon's posts have been removed from the Collaboratory. The only mitigation I can find for that, is that such a statement is not a strict matter of fact, because the website has been redesigned and "messaging has changed" as Dave Gray put it - meaning that Dachis must have forgotten to include David's and Jevon's posts while doing so

An omission? Your words, not mine...

2004-2011 financial analysis: Non-traditional SI (Indian players and IBM)

2012-04-02T00:05:00.002+02:00

Yesterday I published my financial analysis of 4 traditional system integrators: Accenture, Atos Origin, Capgemini and Logica.
In a conversation I got asked why IBM wasn't on the list, and my answer was somewhere along the line of "it's not a pure player". Also, I hadn't published my Indian friends yet, so here are another 3 "service providers" if you may: IBM, Tata and Wipro. Different worlds? Try universes

First, behold the Indian pure players up here (see top image): they make less than half the revenue of yesterday's traditional SI's ("the 4" from now on), yet more than double the profit. Of course that's hard to see like this, so here's the magic applied: revenue and profit divided by headcount: (by the way, click any picture to enlarge)

If you compare Tata and Wipro with the traditionals in my post, you'll find that they make 120% of the profit with 45% of the revenue - that's a huge difference and show that Tata and Wipro can run circles around Accenture, Atos, Logica and Capgemini. Can their markets and clients be compared? Probably not totally, but they are more than similar enough.
With 465k people working "for the West" and 320K "for the East", the former growing by 77K (17%) last year and the latter by 52K (16%), one thing is for sure: Asia Pacific is hugely profiting from this battle in terms of employment. Both parties took a beating from the crisis yet Tata and Wipro are still not back to normal, let alone growth - but neither are Logica nor Capgemini

Anyway... and now for something completely different. My stats-buddy and IBM-er Vijay Vijayasankar challenged me to calculate the figures for "IBM as an SI" (my words) and I took up the glove. I managed to trace back revenue and pre-tax income up to 2007, so that will be it, unfortunately. Before that, Global Services gave away gross profit and such, but no neater figures. Anyway, I think 5 years is good enough, managed to nail them before the crisis so I'm satisfied-ish

IBM has a Global Technology Services division and a Global Business Services one. The first roughly does twice what the second does. GBS primarily provides professional services and application management services (consulting and technology services as we know it), GTS provides IT infrastructure services and business process services and I'll label it outsourcing

An impressive new kid on the block with more revenue and profit than the 4 combined...

Worse, even, the profit is almost double. With an average of 0.719304 euro to a dollar for 2011, there's a combined total of 55.6 billion dollar revenue for the 4, and a profit of 5.0.
That means that, were IBM's figures to be taken as base, the profit of the 4 should be 8.5 billion - i.e. 2/3rds more (yes, 66%).
I hadn't expected an outcome like that - and this is not even the entire story.
My favourite calculation is impossible for IBM, as I haven't found any details on workforce per division - so I can't calculate per-employee revenue and profit. However, there's reason

Reason tells me that there are 433,362 employees within IBM. Let's be rough and claim that there's an equal division of people across the board, meaning that IBM's "SI division" would have 243,000 employees - almost half of what the 4 have!
Slightly more revenue, almost double the profit, with almost half the workforce? Hang on. I used the average per-employee 2011 IBM revenue, being $ 247k, for this calculation, and my sources whisper that the average IBM consultant revenues 115K. But were I to use that figure, then it would turn out that there over half a million people working for IBM SI - more than the entire workforce?

I'll turn it around, because it doesn't make sense at all. Let's just say there are 400,000 people working for IBM SI; that means they revenue 150k per person, and 23.25k operating profit. Yes that would mean that merely 33,362 work for Software and Systems divisions, doing around a million dollar revenue and 400k operating profit per person, but that wouldn't be so very odd, given what Google, Microsoft and Apple do...

Let's take our imaginary combined company of the 4; they'd have a workforce of 465K doing a total of $ 55.6 billion revenue and 5.0 profit, resulting in 119K per-employee revenue and 10.8k operating profit.
Let's take our imaginary combined Indian company; they'd have a workforce of 320K doing a total of $ 9.4 billion revenue and 2.2 profit, resulting in 49K per-employee revenue and 11.6k operating profit.
Let's take our imaginary IBM SI; they'd have a workforce of 400K doing a total of $ 60.2 billion revenue and 9.3 profit, resulting in 150K per-employee revenue and 23.3k operating profit

So, welcome to IBM, our new SI: they'll watch from the side while East (m)eats West, and have more than enough fat to battle the winner. Given these odds, they'll probably even win the war

Avoid dashes and fancy quotes in blog titles

2012-04-01T20:18:00.000+02:00

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)

The IT world is a messy place. IT started in the United States, so they developed a codepage to cope with their problems: ASCII, American Standard Code for Information Interchange. It contained 128 characters, enough for taking all the characters then known (I think they looked at a common US typewriter).
Then, the bloody Europeans joined the IT scene, with all their funny French c-cedilles, Scandinavian funny æ and other symbols, Germans with their ß and dozens of useless symbols Americans hadn't thought of (rant intended).
So, the second half of the total ASCII set quickly became populated with those, which came to be known as the Latin-1 extension or ISO 8859-1

Needless to say, that wasn't enough. Eventually Unicode saw the light, making the Asians happy, and offering plenty of space for tens of thousands of characters. Check out this list if you think you don't have much of a choice
But even that wasn't enough: the web kicked in, and HTML and URLs starting causing problems.
Why? Because the people who invented them, had a wide mind with regard to their invention, but not its application: yet another US invention, it was limited to only a few chars (Unicode was an invention by Apple's Joe Becker, so not all American inventions are evil if you might think that I think so)

HTML had special characters that needed to be escaped, and so did URLs - and they didn't use the same ones. What is escaping? Wrapping, translating, converting: different words for the same action.
For example, if you put a space in a URL, it needs to be translated to %20 or the URL doesn't resolve to anything useful. URL encoding is so much fun because it only has less than 70 non-reserved characters, and all the others have to be escaped. How? Haha...
You must escape a reserved character for use in a URL by taking its hexadecimal ASCII-value and preceding that by the percentage sign (%).
And therein lies somewhat of a problem, of course - see above. Characters you read (if you are a machine) have to be decoded, and characters you write have to be encoded. In between decoding and encoding, lots can go wrong.
For the real diehards among you, here is the IETF's latest RFC for generic URI syntax

HTML and XML have similar needs: check out this Wikipedia list that shows some escape examples, and then there's XHTML, and different versions for all, and so on and so on and so on

Is that all? No it ain't. Blog posts get spread across the world via Twitter, Stumbleupon, and many, many other sites that use URL shorteners: those take a URL and turn it into something smaller - of course once again escaping the reserved characters. On top of that, Microsoft Word is somewhat to blame as well, they of course have their own codepage and under da hood everything is XML since Office 2007.
Getting dizzy? Let's get practical

Let's take Jeremiah's post title, in URL presentation:
http://www.web-strategist.com/blog/2012/03/28/coping-with-twitter%E2%80%99s-unfollow-bug/
The sharp observer will see that the %E2%80%99 part is meant to simply represent a single quote:

Coping With Twitter’s Unfollow Bug

(I know the URL doesn't look anything like that, but just copy and paste it into a smart editor and you'll magically see the single quote change to the awkward %E2%80%99)
However, it's not a mere single quote: that would be a simple single %92. No, this is a fancy one and its proper name is Right Single Quotation Mark, and it is pure Unicode: hexadecimal 20 19.
(I could bore you with Big Endian and Little endian which tell which of the two bytes is leading, but let's just leave it at this shall we?).
Taking this Unicode value and translating it to UTF-8, you get E2 80 99. Simply prefix those with the percentage sign, and you get %E2%80%99

If you use longurl.org to check the URL shortened by Twitter, you'll get a 404. That's what I got, on my mobile using Hootsuite. If I use Hootsuite on laptop, I go straight to the page. What URL gets decoded on my Hootsuite mobile account?

http://www.web-strategist.com/blog/2012/03/28/coping-with-twitter%C3%A2%C2%80%C2%99s-unfollow-bug/

It seems that the decoder only took the E2 and completely lost it after that, and I suspect this is an Android issue rather than a Hootsuite mobile one. Nonetheless, the outcome is the same: invalid URL

Did you make it all the way down here? Wow, you must be really into bits and bytes and we should probably meet. Chances are, you do integration work or at least work cross-platform and cross-programming languages

I hope I've shown that there are a lot of dependencies involved and that the same URL might make it via shortener A but not B, or Twitter client A versus Twitter client B, or device A versus device B - and that all this might lead to a lot of confusion and misunderstanding

Want to stay on the safe side, and have your URL work for everyone? Avoid special characters in your post such as dashes, fancy quotes, and stick the dazzling stuff into the content itself

Traditional system integrators 2004-2011 financials

2012-03-31T22:12:00.002+02:00

Traditionally, 31st of March is the date that all my favourite system integrators (SI) have released their annual report for the previous year.
Oddly, however, I've seen some strange changes this year - for the first time. I could -and will- even say that traditions have been broken with

I had to look hard and deep to find Logica's annual report, which was hidden somewhere between the press releases, and on their site there still is the 2010 annual report prominently filling up the entire space - not the 2011 one. Secondly, it's in landscape, and looks like a Powerpoint presentation. Odd? Wait

Capgemini's annual report has the same layout. Don't click the 2011 Results link there, you'll download a 0 kb PDF. Sloppy? I couldn't possibly comment...Instead, go to Presentations and click the 2011 Full Year results link. As Capgemini doesn't show average headcount anymore, I guesstimated theirs by taking the BOY and EOY headcount and divide the difference by two

Logica's as well as Capgemini's report were extremely less informative than they used to be, and is Logica still spending money on R&D? I haven't found any evidence for that, but just left it at its old value - might update this post in the coming days.

Here's the interesting part: relative figures, where I take the headcount and divide revenue and profit (all operating profit, by the way, before interest, taxes and whatnot):

As you can see, it's all good in the SI industry, looking at headcount. However, this is deceiving: most of these new recruits are in Asia Pacific and attrition has been rough. Logica scored a mere 13%, but Capgemini managed e.g. 18%. Of the 32,000 new hires in Capgemini, half of them are offshore. I will write another blog post about what I call the long tail of SI: the Indian connection

Looking at relative performance however, only one stands out: Accenture. Where it took a serious in 2010 (finally, one would almost add), it is now slowly making more revenue and profit is better than in 2009. It still continues to make 120% more revenue and profit than the others combined on a like-for-like basis
Atos Origin has taken a nose-dive, with losing double-digit on revenue per employee. However, it magically has managed to cut cost at the same time, and 'only' lost 20% on profit. Twenty percent is a lot, of course, but if you lose 12,000 euro per employee in revenue and only 1,200 in profit, that's not too bad
Logica continues to bleed very, very hard, after the mysterious upsurge last year. I wouldn't be surprised if they file for bankrupcy sometime soon - an operating profit of 1,300 pounds (say 1,500 euro) per employee doesn't leave much room for pay raise, education, etc. One could argue that these have already been deducted but I know what happens in bad times: those get frozen stiff
Capgemini shows a magical turnaround. It consolidates last year's profit increase, while making even less revenue. Please note: this revenue lies almost 10 percent below Atos's and Logica's

The verdict? Atos and Capgemini will probably fight over buying Logica, and the French pride will cost he who wins dearly - that's my gut feeling based on absolutely no inside knowledge at all.

Other than that, if you look at 2007 (pre-crisis, shall we say?) then Logica is the odd one out, and Capgemini still recuperating

Will the system integrator survive? I don't see much of a business case for their business model in the remaining years of this decade. On the other hand, these four companies are still feeding half a million mouths, and probably well over a million if they have a partner and kids. They are cutting cost hard everywhere, and as usual the employee is at the end of that - while being squeezed by his government in his or her private life as well

All in all, 2012 will be a decisive year for one or two on this list, I think. let's meet again in exactly one year from now?

Why API's suck, and what they lack

2012-03-28T23:54:00.001+02:00

The Social Media Movement is slowly moving towards monetisation. Social Business, yes even Social Enterprise, is nigh.
Infographics bite the dust in an ever-increasing frenzy to prove that social is here to stay, to rule, to conquer the world!
And as yet another evidence of that, API's are brought forward - by the hundreds, no the thousands - to prove that the Brave New Open World has finally (yeah, really finally this time, right?) come

Well, I don't think so. API's suck - big time

First of all, API's aren't open. The fact that you can read about an API and use it, by making a request to it and getting data in return, is not a god-like miracle: it's so self-evident that it's boring. If you call an API open because it does allow you to do that, you might as well call a radio open, or a TV: change the channel, and - oh no!, it's a miracle - you get a different set of data on the spot.
API's are closed: the companies that offer them, decide what's in them, when it's in them, where it's in them, and how it's in them: and you just have to put up with that

Second of all, API's are for free, mostly, and no uptime is guaranteed. Whenever an API breaks down, it's tough luck. Does it stop supporting a method, or suddenly change the return value, its order, or dataype, without telling you? Normal behaviour.
API's are "a gift from God", if you like: they come and go without much, if any, notice. Builds a business around a free API? You better think twice before billing your customers - what if the API stops, changes, backfires, dies?
I'm a registered Twitter API developer, but I never get an email or something when it changes. That sucks

Third, API's are badly documented, if any. The Twitter API? I consider that wholly undocumented, sorry. Yes you get a small description per function, and if you drill deeper, also a description of some parameters to use when you call the function, but none of the return ones get described, let alone mentioned.
Their format? Unknown, have to find out for yourself.
Their occurrence? Lawd knows.
When can you count on a value to be there, i.e. when is it mandatory, and when is it conditional or just optional? You tell me - Twitter doesn't

Is this just an unfortunate example? No, Twitter is actually fairly well documented. Compared to Facebook and e.g. their open graph protocol, they're amateur-ish, but compared to all the others, they're swell.
I went to Programmable Web, a site that tracks down so-called Open API's, lists them on their website and does a short summary of them with links. Handy

I tried a few: most of these are just bait-sites, where you find a small promise and a big button for Pricing Details or Contact Our Sales. Some are in Russian, Chinese - how useful is that? Open? I just picked a few, please judge for yourself how very usefull, intuitive, clear, concise, helpful... - ah forget it:

5gig (unintelligible)
8coupons (bait link)
ACStechnologies (techfest gone wild)
ActiveCollab (confusingly content-free)
Adegga (fairly OK)
100 Faktovobome (or something)
Alert-grid (pretty good, with error codes even)
Aloga (not an API, but a Motorola dev platform?)
Amsterdam Museum (embarassingly embarassing)
Adobe Flash feeds (I always love a completely empty page)
Affinity Live (I'm fairly impressed. Yes, I am)

So, out of these randomly 10 API's, I count one fair, one good, and one impressed API, all judging by my own standards of course (wrote my first program 30 years ago, if that helps as a reference) - and 8 utterly useless ones.

Is that a result to be proud of, or happy with? No. Good grounds to cheer about social business now finally taking off because of the multitude of splendidly well-documented API's with 100% guaranteed up-time?

LOL - I'll admit that I'm slightly exaggerating here, but honestly, this is all crap. Sure, you can fool and fumble around a bit, and slap one service onto another after you've tried and tested a lot, but these are not API's - or maybe, these ARE API's: clumsly little slap-togethers that are highly undocumented and can only be accessed and asserted by techies

Social Business? Still remains a techfest for the full 100% it seems - if you rely on API

80-20: the deadly cause of IT project failure

2012-03-26T00:55:00.000+02:00

There seems to be a rush of IT failure topics these days, all trying to find the Holy Grail of project failure. While I hold that this is a world of AND and AND, not OR and OR, I do see a major cause for project failure for the last decade: shifting from serial processing (waterfall) to parallel (Agile, Scrum, and so on)

Apart from the fact that Agile is solely focused on delivering a project rather than a product, this is not an Agile-bashing post: it is intended to show a very weak spot of contemporary IT projects

In the 80's and 90's, IT projects would take a sequential approach: first administrative design, then functional design, after that technical design, then build, then test, then go-live, and then maintenance and governance (the latter two hadn't been invented back then as IT themes, but existed nonetheless as separate fields of attention)

Then, IT became somewhat of a big business (cough) and projects grew longer, and longer, sometimes taking up up to 3 years - not unusual these days for some really big enterprises that get a huge overhaul, but that's food for another post.
Around the year 2000, a major shift occurred in IT: the web became a primal focus point. Up to that point, the end-user was someone who got the main attention in the administrative design phase, and a good part in the functional design one as well - to be completely ignored when the techies made their entry in the relay race and picked up the baton from the functional folks

In a nutshell, the whole model collapsed: in the web era, the programmer was basically sitting next to the end-user, slapping one screen onto another and quickly modelling and pre-building the end product.
Largely following the Pareto principle of 80-20: "This is what we have in mind, more or less"

Suddenly, waterfall was out the door and predictions were made in the line of "9 months, 9 weeks, 9 days" - referring to the total time it would take to come from the initial end-user business requirements to the final product. Much to the delight of the entire IT industry, those 9 days were never achieved - yet those 9 weeks have come dangerously close.
Scrum, Agile and XP saw the light - all focused at shortening the project duration and reaching go-live far earlier than before.
The trade-off for all these was requiring highly skilled designers and / or developers, and spending considerably less time on documentation - there's always a trade-off of course

Yet, IT projects somewhat adopted to the changed ways: in stead of sticking to the strictly sequential ways of conducting a project, they went parallel: work streams were introduced where focal points were addressed by specialists. You'd have a work stream directed towards the business, one towards tech, maybe one or two directed towards business or tech specialties, one for test, and that's about it

These streams worked in parallel, where they used to work in series. Of course they didn't follow the adagium "9 women can deliver a baby in 1 month" but they did infringe on the old ways: they simultaneously relied on each other

Enter the Pareto principle, the 80-20 rule: naturally you can't expect either one of these streams to be fully perfect, they're all working towards the same project goal in the same time, each in their own fashion. So, the best you can expect is that they've got their stuff together for 80%, and will deal with the remaining 20% in due time.
Which they do. So, if you're the tech stream, you'll build upon the 80% finished product of the functional stream. Of course you also can only output a maximum of 80% yourself. When the test stream approaches you, you give them whatever you have, and expect them to do an 80-20 job as well - which they do.
Math, however, is a stubborn outsider. Math teaches us, that 80% (the tech stream best effort) of 80% (the functional stream best effort) is 64% at best. When the test stream comes to the tech stream for advice on what to test, 80% of that returns a result of 51% at best

So, on a running project, parallel execution of serial activities results in poor coverage - very poor. You relying on me and me relying on them: 50% outcome at best.
This gets worse when the streams are separated by location, time, language, culture or company; resulting in resistance rather than the will to achieve a joint solution.
Streaming activities into certain work streams might give you the feeling of control, but overall you'll lose out on quality. When the right hand relies on the left hand, it rightfully assumes it has 5 fingers - not just 4

You can't hide a project's complexity by turning serial phases into parallel ones: that's only paralising the entire project. If you do, then make sure you have a daily progress meeting across all streams (which would turn it into a proper project again)

Recognise your parents' dementia in an early stage

2012-03-20T23:12:00.002+01:00

No label for this post - wouldn't know how to.

As you may or may not know, my parents are over 80 and both in an advanced stage of dementia, or "suffering from memory-loss" if you like. Whether it's an official diagnosis or not, the results are that slowly, sometimes quickly, and then slowly again, life-as-we-know-it slips out of them

Through the various stages of anger, denial, acceptance, "ignorance" and all kinds of grayscale in between, me and my brother are now still watching from the side, trying to act when we have to, hands tied on our back - because there is nothing we can do

My dad is well advanced, so to say, from time to time not knowing where he is, where I am from, who he is or I am, and so on.
Ask my mother and they're still doing fine, it's not that bad alltogether, and you can hear the sorrow in her head and heart, yet, she still is in control of them both so they 'll just stay where they are: over an hour drive from me, slap on another half hour for my brother.
We visit them every weekend, call them every day, yet never know what to expect when we get there

If only they lived close-by

But they won't move until it's too late - had we only recognised the signs those 5-10 years ago, could we have moved them close to us, and visit them on a daily basis. And that's what this post is all about: tell you my story of the signs I missed or ignored, or both, so you don't, or won't - hopefully.
Hopefully, it will give you the chance to decrease the distance between you and your parents so that if, when, finally they need to be cared of on a weekly or even daily basis, you have the chance to do that yourself

It was 8-10 years ago, I think, when my dad started showing me where he put things: the key to the garage, hidden in one of the bushes. The key to the safe, hidden near the fuse box. Papers he kept, photos, bonds, all that.
He didn't do all that in one hour, weekend, or even month: I think it took half a year or even an entire one for him to show me "his most memorable spots". I didn't think much of it, in fact I didn't think anything of it - I thought he was being cautious and prudent, for anything might happen to them, of course: they traveled a lot, usually in Europe.
I only had the physical world in my mind - not the mental one

There were no reasons at all to worry about them: they were healthy, fit, active, as happy and cheerful as always - indeed, there was not a single reason to worry at all...

They made trips with the camper to Spain, enjoying the mild winters there, staying 3-4 months before coming back home again. In Spain, they would make trips with their bicycles, even send us an email every now and then - strong parents in their mid-70's

The emails slowed down, eventually stopped - I blamed it on the lack of use and practice. The calls remained: the second sign I missed. If you suffer from dementia, you first forget the last things (you learned).
Then, one year, we learned, after they had gotten back from Spain, that dad had taken a bad fall from the bicycle and stayed in a hospital for two weeks, while mom stayed at their residence in Spain, alone

We never got a call, and only learned it afterwards - they suckered us with "nah you would only have worried and there was nothing you could have done anyway - what would you have done, drop work, drive to Spain and hold my hand?".
The third sign, a vague one: you know that something is just very, very out of the ordinary. Yet, we tucked it away in being abroad, not speaking the language, etctera, etcetera, etcetera

The complaints about the camper increased: dad drove 90 kilometres an hour on the way to Spain (120 to 130 allowed), they took a few days or weeks to get there, never in a hurry - but the whining about trucks increased.
Stories about highway robberies increased. They stayed shorter, even skipped a year - and then decided to sell the camper.
That was the turning point: their world became radically smaller overnight

But, they still had the little cabin up north, close to the sea. They went there in the Summer, but complaints about that increased too: the local tax they had to pay, the maintenance it required (almost annual paint job required), etcetera, etcetera, etcetera.
Three years ago, they sold that too - and that pretty much ended it all, or should I say: started?

I started taking care of the finances pretty soon after that. Then, the notes started to pop up: first in the hall way, small notes of my address, telephone number, my brother's one.
Business cards of plumbers, carpenters, gardeners - sometimes identical ones at different places.
Then, I saw one with their telephone number - I thought it was for the household help (I hoped it was, I think I did know a lot better than that).
Notes showed up in the kitchen, to leave everything out and don't put it in the cabinets - we learned later that my dad just put stuff where he thought it was most apt to put...

My mom started to lock all doors at all times - burglars, she said. But we know better now. She gets in a panic when dad leaves the house, I just witnessed that last weekend: dad "escaped" before, 1-2 months before that. That's when the neigbour called me at home for the first time

We could and should have persuaded them to come live with or at least close to use at the first sign (telling me where he hid the keys, papers, all the important stuff). We should have done so, increasingly stronger, at every next sign. We should have raised hell at some point and threatened them with Lawd knows what if they hadn't moved close to us

We didn't. We can't anymore. Now we just wait for things to go bad, so we have legal grounds. Now, we lie to our parents again, just like when we were adolescents. This time, "it is for the better", we say - and I think it is. We listen to their stories, questions and answers repeat endlessly, and after a few hours of visiting them, we're exhausted. We try to go together, as it's harder to visit them all alone, not to mention how hard it is to leave them again

And yet, it's harder on my mom than it is on me and my brother - and it will get harder by the day. And we can only see them during the weekends, and we have no idea what we will see when we get there.
I wish, I wish, I wish; but I really don't, as I know it's too late. I visit them in the place that's their home, although my dad doesn't know that anymore, yet my mom still considers it to be like that.
We know that they're the last family that still lives there; all the others have moved or died, save one or two

The isolation they're in now, could have been much, much less had they had the chance to start anew at another place in time. Now, they're just that old couple living in that house. I even think that it would have "juvenated" them a bit, taking it longer for their minds to wither - I honestly don't know

My point? The goal is to have your parents close to you, or vice versa, when they "really grow old". One third will die of cancer, a quarter will die of dementia - at least here in NL, for those under the age of 90.
Both diseases will slowly progress, and keep you in insecurity for as long as they last.
Cancer is a dead give-away, but dementia can be ignored, denied, hushed, and so on, and so on, and so on

Dementia, in fact, can only be treated when it's diagnosed by the patient itself - that means recognising, in the very early stage, that it's time to move on to the next stage in life and prepare for old age, followed by death

Never an easy decision to make, but an extremely difficult and hard one to postpone, and leave up to your kids - who can't possibly make it unless they have no other choice left

Why SAP will be single-tenant at start

2012-03-13T23:50:00.000+01:00

There's an interesting discussion going on about multi-tenancy and SAP.
Let me be clear on one thing: SaaS can't be anything else but multi-tenant and opt-out, meaning that there is a single code base for all customers, with regular upgrades for everyone at the same time

But what is only natural for SaaS "pure players" will be impossible to realise for SAP - a small step for one can be a giant leap for others

From the SAP Management Report in the 2010 annual report:

our core business is selling licenses for software solutions and related services to deliver a broad range of choices fitting the varying functional needs of our customers

Well they say it like it is, isn't it? Can't call them shy for sure. Let's take 2010, and see what came from where:

Software revenue: 3.2 billion euro
Support revenue: 6.1 billion euro
Professional services revenue: 2.7 billion euro

That means that half of SAP's revenue comes from support fees. So take that core business mission statement with a grain of salt: not selling licenses, but cashing in on support fees is SAP's core business.
So, where do they get support fees from? Easy: customers pay 22% of their license fees for support. That used to be 17%, but in July 2008 SAP decided to increase that by 30%.
Why not? It wasn't like a crisis just hit us like a truck or anything, was it?

SAP currently is on-premise, and single-tenancy - of course. Customers need a lot of support, maintenance, and help with upgrades. Naturally, customers are forced to pay for support and maintenance, because if they wouldn't, no one would upgrade.
By making customers pay (dearly, I might add) for future upgrades, SAP makes fairly sure that the customers will in fact upgrade as well because they paid for it already.
Surely the actual upgrades themselves will cost even more money but that's just a speck on the map compared to the amounts already put down on the table - and so the lock-in continues, with the customer endebting himself to SAP for future upgrades.
Payback period for SAP products? Not in your wildest dreams! Hotel California man, hotel California...

Then, the future itself knocks on SAP's doors. "Hello, SaaS's here!"
"Damn", Waldorf must be thinking - "there goes the neighbourhood". The joke's on SAP now:

Customers will not be willing to pay 22% support fees for future upgrades. As everyone shares the same install base, they'll use the argument that they don't want to pay for their competitor's support fee
Customers will be very inclined to pay much less than 22% support fee, if any
However, with SaaS upgrades become stealth, and a thing of the past: everyone moves to the next new version at the same time, and doesn't need to do anything for it - ask salesforce.com

Consequently, SAP will move from a 22% annual support fee on-premise model to a 0% support fee off-premise one. That means slowly writing off 6.5 billion euro revenue per year until it reaches zero

That doesn't look much like a win-win situation, does it? And yet SAP has to go SaaS, because everyone else will, so on top of that they even have to invest in developing new existing offerings so they can be offered via the SaaS model, which means throwing even more money to it.
To make matters worse, customers will want their on-premise functionality in the Cloud as well, so SAP will have to offer their existing service offerings off-premise as well as on-premise - more money please!
Last but not least, of course this will cannibalise their current service offerings so that means less revenue - even more more money

So, would I like to be SAP? No, not really. It will be a slow process, of years, but if not killing it will at least inflict quite a few mortal wounds. One remedy (or rather, quick fix) for this? Single-tenancy SaaS

All that's needed is a proper excuse, well thought-out, but I'm sure SAP will manage. Single-tenancy SaaS will keep SAP very, very close to its core business, and not only uphold the support fee model, but even some of its level. I think SAP can get away with single-tenancy SaaS on 10-15% in support fees - it's a bargain compared to the current world!

Of course, that still is only 45-70% of the current fees, and there's still money needed to turn on-premise into off-premise, but if SAP can combine this with private Cloud, they can almost just take the current stack and move it to their own datacentre!
Yes, it will be an outrageous lie and the Clouderati will despise it, but the customers will save 15-35% a year in cost (I just sugguestimated the private Cloud cost to be 15% of support fee) and simply love it

There will be a very slow convergence from on-premise to off-premise, and this is one of its most likely scenarios to get that convergence started. Don't like it? Tough. Disagree? Please say so

Are you Living The Lie? Why?

2012-03-11T23:31:00.001+01:00

In the deeply religious village I live in, a Jehovah's witness folder dropped on my doormat the other day. I didn't recognise it as such, but it's close to Easter so time to convert a few souls. During Summer holidays, camps are established for a whole week to lure in the kids, and convert them or "harden" the current spell they're under. I wouldn't mind really if the message they bring is a happy one - but it isn't.
The Message from God these people bring, is an evil one. As a matter of fact, they are the Devil they warn us for - yes, religiots are Satan incarnate

I'll quote from the Jehovah's own flyer and tell you the story how it really is supposed to be told

Just as a formerly honest man makes himself a thief by stealing, one of the perfect spirit sons of God acted upon an improper desire and made himself Satan the Devil

That easy huh? Wow. One improper desire, and you can make it to the baddest of the Baddest? Kewl. There must be millions of Satans now, if not billions

The lie that the Devil (the snake in the tree of knowledge of good and evil which stood in the garden of eden) told Eve worked just as he had planned

Behold the version of the Christians, the Jehovahs, and others: God created a perfect man and woman, errr oh wait, that can't be any good: God took a part of the man and made that into a woman (much better now, isn't it? We'll just tell the latter version and skip the first, okay?) - and then the stupid woman ruined everything by eating the apple!
And now we have to repent, repent, and repent, and listen to the priests for they can offer salvation, and it's all women's fault. There. A 5 minute bed-time story

It's a lie. A bloody, filthy lie, told with only one purpose: to subdue you to the Church, and make you pay for your entire lifetime - of which the financial part is the least. The worst? Make you live in fear and guilt. You're put on the guilt-trip with the Lie, then have to Fear that you'll never make it into Heaven. Well, not to worry: if you believe all that crap, your life right here is Hell - it can't get any worse

Taken from Matthew, where the Devil is tempting Jesus in the desert:

Again, the devil took him up into an exceedingly high mountain, and showed him all the kingdoms of the world, and the glory of them;
And said unto him, All these things will I give you, if you will fall down and worship me

That is, what the Church has done, over the last 2,000 years: promised you Salvation, if only you do what they tell; if only you fall down on your knees and pray to their God; if only you worship Him and uphold their Institution - the Church is Satan incarnate

Thank God (pun intended) that this whole outrageous Lie is coming to an end. Thank God, that this edifice of secrecy, death, exclusion and expulsion, ruled by mumbling old males that have caused so much unbelievable death and destruction over centuries, by crucifying individuals, crusading entire countries, burning and drowning so-called witches, depriving poor people of medicine and anti-conception, and converting perfectly healthy and innocent people to their sick Lie of Guilt and Fear, is slowly cracking, crumbling and falling apart

In the (150K people) town where I grew up, there are only 6 catholic churches left - and 5 of them will close before 2013. Hurray

Jesus warned us for the Church - not the Jesus of the carefully censored Bible of course, but the Jesus it all began with - the Jesus of Thomas.
Logion 39:

Jesus said, "The pharisees and the scribes have taken the keys of knowledge and hidden them. They themselves have not entered, nor have they allowed to enter those who wish to. You, however, be as wise as serpents and as innocent as doves"

Logion 102:

Jesus said, "Woe to the pharisees, for they are like a dog sleeping in the manger of oxen, for neither does he eat nor does he let the oxen eat"

The pharisees haven't changed their ways since AD 0: they still try to hook you with their Lie, and make you dependent on their words and wizardry - yet they don't give any guarantees whatsoever. A False Lie is what they make you believe, accompanied by a False Promise - and you most willingly hand over your responsibility, kneel down, pay tribute, go to church once a week, etcetera: exactly like the Devil would have it

The Christian Lie is not the only one: Judaism and the Islam are pretty good at it too. In fact, any (almost exclusively) mono-theistic religion teaching you that you are imperfect and need to make up for that by doing what you're told, is just feeding on your basic and innate False Self-image: that something is wrong with you, and that you can only make that better by overcompensating for it

I have no idea where this image comes from, yet I've witnessed it in pretty much everyone around me, including myself. So-called self-helpers readily take advantage of it as well: they tell you different Lies, and different Promises, and of course offer you different treatment - but it is all the same.
Different Rules, same Game - where have I told that before?

Turn this Game onto the Liars: in stead of listening to the endless and vague answers, just ask This One Question:

What is wrong with ME?

You'll be surprised by the answers you get. With a lot of luck, you'll get a few, maybe even a dozen. Then, for each of those, ask "Says who?" eventually followed by "And why should I believe him / her?".
All that remains then, is to accept that you've been Living The Lie for Lawd knows how long, and then take on the future like there's no tomorrow. And you'll be in Heaven - right here, right now. That I can guarantee

The benefits and concerns of Social

2012-03-07T22:55:00.002+01:00

This post is the last in a series of six that deals with Social Business and Social Enterprise. The goal of the series: to explore the pros and cons of Social Business and Social Enterprise, given the current odds, and fast-forwarding to business opportunities now and in the near future

Well, this is it.

1. A small recap

What do we see there? We see individuals growing apart, due to distance, and we see the traders form larger groups in order to close the widening gap, and bring back trust to the level it was at

That pinpoints the best usage for Social at this very moment: in aftersales (customer service, providing that via communities and help forums) and presales (marketing and sales, providing that via communities and product reviews)

Social Enterprise will merely reproduce the current working mechanisms of the Enterprise: networks. It will take the old-boys networks, clone and copy them, and turn every apprentice into a master on the spot

Today, I'll (and I'd) put a fair amount of money on Social Business. It won't cure diseases, yet nor will it inflict mortal wounds. Focus on pre- and aftersales, train your people, monitor closely, evaluate frequently, adjust and adapt quickly - it's just another business opportunity

The clueless layer is there to absorb the bottom-up information flow, while freely letting the top-down flow through. It functions like a veil; the puppeteers (Board of Directors) can see through it, but no one on the outside can see what they're doing. Social will bring transparency to the Enterprise, all across the board. And like any old-boys network the average Enterprise is, they thrive on secrecy and anonymity

One quote from each post

2. My conclusion

My conclusion is that Social Business certainly offers a few nice business opportunities that offer relatively low-investment ways to improve your current offerings, and maybe generate some spin-off from that. It will work best where people-driven employees face consumers, and even customers (e.g. customer service), and will fail where product-driven and product-facing employees work (e.g. assembly lines) - and of course there are shades of gray in between...
My conclusion on Social Enterprise is that an Enterprise only works because it is a soul-less anonymous pit.
Social will break down the walls and bring transparency to the Secret Chambers of the Enterprise, and that will be the end of it - the employees will revolt, the apt and able will either demand and get huge promotions or jump ship, and the usual suckers and losers will stay behind; to continue their usual complaining but now out in the open

3. Practical view

Harsh? Indeed. But an Enterprise is harsh, and unlike a cosy 5-to-a-few-hundred people company, it works because it is so. How about an army where not following orders is okay? Or arguing with the sarge, the captain, or the general even?
Well yes but we have email, and a fair amount of openness in the Enterprise you say? You may, but does that mean good arguments always win? Certainly not - there is plenty of stakeholder issues hidden from everyone

To be honest, I've seen Social work in a few Enterprises - it's not that bad. The 90-9-1 rule is followed, the usual hard core that was there from the start dominates the conversation, there are a few useless megaphoners, some saboteurs, a few opportunists and one or two Crown Princes of Social Media that indulge in self-promotion.
And there are genuinely good questions, good answers, good pointers, and everyone gets to learn a lot if they try and can keep up with the unstructured mess that Social Enterprise is

Although: the structured vs unstructured information issue will safely be met by people taking the unstructured data and translating that into data fed into Information Systems - relying on "standards" there such as OpenSocial, as Dion Hinchcliffe does, is naive: standardisation never makes it past the hard, cold and deep infrastructural layer: networks, protocols, CPU's, disk I/O, etc.
Above that level, standards are taken and changed into bi-lateral or at best multi-lateral agreements: cf. message exchange patterns such as X12, EDIFACT, XML, JSON, etc

4. How does the Social Future look?

Right now we're in a greenfield situation with Social, with a few tweets, updates, yams or whatnots a day. Pretty soon we'll get the effect that we see with email: information overload and filter failure. While you are supposed to read (and answer also, mostly) every email addressed to you, you're not supposed to do so with social updates but pretty soon your Social Channel will be the main one and rely on fast and proper answers.

When you listen to the old people that refer to knowledge management when they talk about Social, they have a point, but they've missed one as well.
Knowledge management failed, because knowledge is dictated from above: knowledge isn't something you can "create" among yourselves - the teacher tells you what knowledge is, or rather, he doesn't: everything he shares with you is supposed to be knowledge

The same will happen with Social Enterprise: information at best will be shared, labeled, structured, classified and archived in the best case scenario, but not knowledge - that takes old-fashioned hierarchy, a desk clerk, a stamp, and a diploma: proper procedures the wild Social people detest so much for so many good reasons...

The verdict? Yes to Social Business where it can improve your current offerings, no to Social Enterprise - as the latter is an oxymoron. Using social media in an enterprise certainly does not make it one inch Social - although some would like you to believe differently

The concerns of Social Enterprise

2012-03-02T00:59:00.002+01:00

This post is the fifth in a series of six that deals with Social Business and Social Enterprise. The goal of the series: to explore the pros and cons of Social Business and Social Enterprise, given the current odds, and fast-forwarding to business opportunities now and in the near future

This post is about the concerns of Social Enterprise. While yesterday's was all about the concerns of Social Business, this one will take those concerns and apply them to Social Enterprise. An enterprise is a company with 10,000 employees or more, regardless of geographical dispersal (my definition)

So. Here we are. I gave my view on how we used to be naturally social and the current state of affairs: businesses trying to close the void of anonymity and re-establish trust. I then suggested how Social Business has tried to close that gap, and why that works.
One step further I dove into the Social Enterprise, first giving my view of the workings of the current Enterprise, then showing how it could greatly benefit from Social in order to solve its core problem: the survival of the fittest.
Then, I switched hats.
I put on my curmudgeon hat and had another look at Social. I voiced my concerns about Social Business, its challenges, its extremely high dependence on people for data quality and business information, as well its cannibalisation of your current business offerings.
Now, it's time to voice my concerns about Social Enterprise. And well about time, after this long introduction...

1. What is an Enterprise?

The Enterprise: a place where anonymity thrives. If you're lucky, you can get to meet 50% of your colleagues - the rest will have left before you can even get their names. All you know are your 50-100 direct colleagues, half of whom you've never met, nor will ever meet.
An enterprise is an organisation where your colleagues aren't intimate friends, but complete strangers

2. The social pleonasm

Have you ever heard of the Social Entrepreneur? Social SMB? The Social corner store? They are social by nature.
Annual pay rises, bonuses, rewards, compliments, gratitude: if you're one of the five employees in a corner store, you'll know exactly who gets what, when, why and how. You either witness it yourself, or your boss tells you (and / or all), or the grapevine whispers it into your ear.
When you are at such close proximity to all who make up the entire company, it's just hard, if not impossible, to miss the major individual events for all its employees

3. The anti-social Enterprise

An Enterprise is anti-social by nature.
An Enterprise functions, because anonymity thrives highly. I'm not a conspiracy theory kind of guy, as I don't like to live in the past - you can't change the past. So whether it's intended or accidental doesn't matter, but within an Enterprise all kinds of actions take place that keep you alienated from the company: take-overs, re-organisations, management changes, personnel manager replacements: 10, 5, 3 and 1 years for those respetively, on average.
Even when you make agreements with your direct manager, his boss, the HR department or whom- or whatever, an enterprise is known to unilaterally change the Rules to the Game - if you're lucky, with some notice

4. The Ultimate Enterprise: the Perfection of the Pillar to Post Play

Is it a goal? Is it a means? Regardless, it's a result, and the status quo. "Orders from headquarters" will be the final answer you get even when you try your very hardest to challenge a ~~proposition~~ decree nibbling off yet another limb of your own.
You check first with your direct colleagues - most of which appear to either not have taken notice, nor issues with it. Then you contact a few of your favourite colleagues, half of which appears to be subject to a different rule, and the other half (naturally) agrees with you - half of which have found some way to settle this but then they have different managers each.
Then, in the end, there you are: all alone. Fight or flight? Or bend and break?

5. The promise of Social Enterprise

Citing from two posts ago:

Social tools - unstructured information and knowledge can flow freely across all the political, regional and hierarchical boundaries of an Enterprise, cutting through all the meat and bones that usually form such a thick layer to penetrate

I can see where this would help realising a few extra business opportunities, but this kind of information sharing in general would connect the dots enterprise-wide as well. Yes goal, but yes also threat - as usual a strong(est) point is also a weak(est) point in some other context.
Sharing information across the entire enterprise? How about sharing all the information that the average corner store has access to? Performance, reward, potential, salary increase?
The concrete or swamp ceiling enterprises somehow magically have, where promotion simply drops dead after age 40 or 20 years of service, which ever comes first, might become apparent to all - turn into a glass ceiling and break, sharding everyone below.
That would seriously undermine the entire concept of how an Entrprise functions, if not utterly destroy it

6. Gamification of the Enterprise - reversed

While the above could and probably would be simply forbidden by some kind of "Social Enterprise code of Conduct" that employees would be forced to implicitly adhere to, the disgruntled will find each other and share the information via countless other channels outside the Enterprise. This time, the joke will be on the Enterprise, in stead of its employees.
Social will introduce a new kind of Unions into the Enterprise: a multi-headed beast that can't be corrupted. In stead of one-for-all, all-for-one, selective groups will use their added value to undo their exploitation.
Next to that, the usual crown princes will combine forces and demand an even bigger share

And as current Enterprise reward systems are, handing out fixed bags of money to business unit managers half-way through the year based on expected turnover, the cut for the non-aggressive will be even less than it always used to be, and they'll start to become really seriously undercut this time, maybe even having to turn in money while the economy and company profit is doing swell.
When those find out and organise, via the same ubiquitous Social information sharing system, they might find out they've been cash cows for years on a 0-1% annual pay rise

7. Extending Social outside the Enterprise

All this might be (serious) collateral damage, as long as employees compare their own performance and rewards within the Enterprise. But Social is contageous, and if you learn to like or love it during your work, chances are high that you'll be Social on some other network(s) as well, and meet similar people from other companies - need I say more?

8. Undoing global differences really quickly

We've witnessed outsourcing and offshoring, largely enabled by differences in living standards between countries. We've also seen many companies having a good part of their workforce in India or other countries, to profit from that.
What if - what if?! - those Indian colleagues learn that their Western counterparts make 10-15 times the amount of money, just because they are doing the same work in another continent or timezone? Of course they couldn't exploit that situation within their current company, but they can get a job at a competitor in "the West".
Triple damage there: low-cost Indian lost, competitor achieved a skilled and relatively cheap resource, and you probably paid for all the training to lead to that as well - not to mention the fractionary cost of providing him with Social Tools when he was on your side...

9. Simply ignoring the command & control

Check only the drawing of Hugh MacLeod in my benefits of Social Enterprise post, and you'll get the point: the Gervais principle:

A sociopath-entrepreneur with an idea recruits just enough losers to kick off the cycle. As it grows it requires a clueless layer to turn it into a controlled reaction rather than a runaway explosion

The clueless layer is there to absorb the bottom-up information flow, while freely letting the top-down flow through. It functions like a veil; the puppeteers (Board of Directors) can see through it, but no one on the outside can see what they're doing. The clueless layer is in fact made up of many thin clueless layers, hiding one from another.
And as long as it's intact, the Enterprise will function as usual

Social will bring transparency to the Enterprise, all across the board. And like any old-boys network the average Enterprise is, they thrive on secrecy and anonymity. I honestly don't see a bigger threat to the existence of Enterprises than the side-effects that Social Enterprise will bring

The concerns of Social Business

2012-02-29T22:57:00.000+01:00

[Image by Diego Cupolo]

This post is the fourth in a series of six that deals with Social Business and Social Enterprise. The goal of the series: to explore the pros and cons of Social Business and Social Enterprise, given the current odds, and fast-forwarding to business opportunities now and in the near future

This post is about the concerns of Social Business. While yesterday's was all about the benefits of Social Enterprise, this one will take concerns and apply them to Social Business

The day before yesterday, I wrote about the benefits of Social Business. It was largely about closing the gap between buyers and sellers in order to re-establish intimacy, and automagically bring back the trust that we're so used to in our more close circles: friends and families

1. Where is Social Business used most or best?

I'm pointing to point no. 5 in that post:

Social is strongest where it's closest to people: either reaching out to consumers in order to try to convert them into (paying!) customers, or reaching out to existing customers whose image of the product has been "damaged" - in plain English, those with customer complaints.
That pinpoints the best usage for Social at this very moment: in aftersales (customer service, providing that via communities and help forums) and presales (marketing and sales, providing that via communities and product reviews).

Call that Social Marketing or Social Sales on the one hand, and Social Customer Service on the other. How could this hurt our current business?
I once again go back to sing my song:

2. The mismatch between Social Business and regular Business

We're settling into the infrastructural machine layer all the things that we take for granted: the simple, static stuff that doesn't change, is highly structured, rigid even. The data, the smallest building blocks, bits and bytes. Order reigns here, where everything is subjected to business rules, and automation can thrive. It's boring and it should be: it's the foundation to our "homes"
Facing the very end, humans, the opposite takes place: we encounter complex, dynamic stuff that changes all the time, unstructured, flexible itself and requiring the greatest flexibility at the same time. It's where knowledge and information flows freely, uncapturable. Chaos thrives here, exceptions are the rule, and automation usually is impossible. It's where Social sees the light

3. The crucial task: turning unstructured data into structured (information)

Machines enable us to scale our businesses - without automation, no one can run a business these days. Well you might walk it, or stroll it even - unable to keep up with the competition.
So we need to take that unstructured Social data, turn it into structured data, information, and feed that to the machines - and only humans can do that

You have sat in a circle of 5-10 and listened to the story the person on your left told, and repeated in whispers that to the person to your right, no? And at the end, you'd hear the story from the first person, and the very last in the circle?
And laughed so hard that it hurt? There, that's a danger of Social: previously Social and now structured data will be a reflection of the perception of the person who hand-fed it in

Then again, that's nothing new: data entry is a profession, and the biggest PITA of a Business, Purchase Order to Invoice matching, is all about turning unstructured data into structured ones. An average help desk does the same: listen to the people, enter data into the machines

While Social will cover the entire pie in stead of only a part, I'm confident we'll get the hang of this. So no real threat here

4. The biggest threat: people acting like their current selves

We're not used to Social 24/7. We're used to being confined to small departments, and if you're unlucky, to 1.5 square metre cubicles in the US. Interaction? Reading or sending one email at the time, taking one telephone call. Yes we do meetings and conference calls and sometimes even video calls, but the vast majority of people "just does one on one".
We are strongly affected by our environment, and we change slowly. No need to mention examples of how a direct reaction of a single employee got amplified into a company's take on the situation

No need to get upset over that, we learn by failing. Although failure is not a goal, it is the means to success.
The great thing about Social? Only one of us needs to fail, and most every one else will learn the lesson

5. Social is only proving your current services wrong

An old one by me, being highly successful in Social pre- or aftersales "just proves your current approach to that is highly flawed".
Can't argue with that, and it's inevitable: if you offer the same services in a very new way, you're basically cannibalising your own business - and brand. You'll need new people to do the new thing, and prove the old people don't do their job well; hiring the new costs money, firing the old does as well - oh my that will be a long way to actually get some profit out of the new New, won't it?

A bit of black and white, I'll admit it, and lots of greyscale in between. Yet, look at advertising: we've accepted this (de)feat(ure) for decades in the ever-so-boring liquid detergents commercials, and also e.g. every new car out there is better than the old one. Can't innovate and become worse, can you? Well you can, but that's not the goal...

6. Social Business will only add a new or thicker management layer

The Social Customer Crush, is what I called it.
It is basically the same argument as the 1-on-1 one, but different: imagine an airport with not one control tower, but a few dozen? Or none? Plane A will be told to land on runway X by tower 1, then hear he has to wait from tower 3, then ... etcetera. The customer is also not used to anything else than one-on-one

In my FedEx case I had contact with two different persons, who were equally unhelpful but sent me slightly different information, though not at the same time. But helping the same customer more than once at the same time can have nasty side-effects of course.
What does bite here is the fact that you have to keep track of both identities: the Social Consumer, and your Customer. They only become one once you've identifed them, and upon doing so data quality comes into play at the old records' store that your company systems are...

Still, again, it might take a little bit of practice but I don't see any real issues here either. You might get conned on purpose by the odd customer but then again I love to hang up and redial the number to a help desk if my gut feeling tells me to do so. So...

That sums it up for me. As much as I tried to wear the benefit hat, I now wore the concern hat. Maybe I was too practical, too precise, too mellow, too nuanced? I'm not in this for being right or wrong or winning a debate, I'm in this and out here for dialogues, and will put my money on whatever makes most sense.

Today, I'll (and I'd) put a fair amount of money on Social Business. It won't cure diseases, yet nor will it inflict mortal wounds. Focus on pre- and aftersales, train your people, monitor closely, evaluate frequently, adjust and adapt quickly - it's just another business opportunity