Business as a Service. Business as usual?

On the theme of Integration (EDI), the past decade we've witnessed various impulses that made great waves: they were discussed, hardly criticised, embraced by most if not all, and implemented on a large scale. Tried and tested indeed

OO, XML, then ESB, then SOA are on the list. Technology-driven they all were, and even if most people agreed that SOA was business-driven, that didn't withhold "architects" from pushing SOA by waving with their WSDL's and XSD's and boasting about Web Services having the future because of their "open standards"

Without detailing why each of these lacked the necessary added value to make a true contribution to Integration, it is evident that they did. Integration solutions today are more apart and diverse than they were 10 years ago

Why do we not understand each other? We all speak the same language, or at least most of us can. Well then it must be the fact that we have different views and perceptions of the same topic; in a word, we all have our own truths. And that difference can't be solved by speaking another language: it is a functional difference, not a technical one
That's why all technical try-outs in the last decade failed to achieve their (highly ambitious) goal. They failed, because they didn't address the issue at hand: misunderstanding and mismatches on the business level, only to be exacerbated by differences on the technical level. If you have an argument with your wife, it won't do you much good switching to another language

So, let's focus on Business as a Service, and forget about the tools. Focus on the business, and how automated parts of that can be extended outside the company - by Integration. Not as a goal, but as a means
Together with the business, break down the process model: what are the business processes, and their various steps, and which business entities are required for each step? What is the offered and required Quality of Service for each of them?
Those will be the business services of the company, internally as well as externally. They're ready-made interfaces on the functional level, well-documented, legible and understandable to all
These services and interfaces will need to be able to travel: they must be able to remember a destination, a departure, be aware of time and date, and they must be able to store what I call names and numbers: other parties' systematic definition of objects along the way

Then, match those business services to IT. Match the business QoS to the QoS offered by IT, and there will be a gap - in the IT's favour, or not. If there's capacity left, there's room for reusing those business services with others. Other applications, other businesses, or other consumers. And that is where more functional differences will be encountered: fix those first. If they can't be fixed, you can't do business. It is as simple as that

Finally, when all the proper preparations and checks have been made, start thinking about the form those interfaces should have: the language(s) itself
If you want to do business with China SMB, you might want to consider speaking Mandarin
If you want to do business with Latin-America, Spanish would help a lot
North-America? English, definitely, but not UK English or Australian, they'll find that hard to understand
Now you see, there is not one language that is the right choice. It all depends, as usual. You might also see, that when you start bottom-up, there's at least some work that is done in vain. And, at last, that IT is just a small component when it comes to doing business. As usual