Monday, 28 September 2009

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

Friday, 18 September 2009

A palace revolution. In IT?

I do apologise for the fact that in this particular blog abbreviations will be flying around like grilled geese in the land of Cockaigne

As described, a palace revolution is about changes in culture, economy, and socio-political institutions

The cultural revolution has been ongoing for decades now, with entire countries wondering about (the state and future of) their culture due to disappearing frontiers on the currency, economical and national border level

We're right in the middle of the economical one with the current crisis

Social media is now invading the earth: 300 million people on Facebook, 50 million on Twitter - and let's not

Thursday, 17 September 2009

The perfect business application

Cost is becoming an ever increasing player on the market. Total cost, not just project cost. Time-to-market is good, but time-in-market is better, so to say

In the end, there are questions that need to be answered. 70% of those questions are asked after the go-live of a project, not during
A project might be successful but maintenance might turn out to be a disaster (or anything in that grey area in between). Fill in the blanks for a project and run, a build and test, a design and build
For the 30% of the questions that get asked during the project, the same principle applies: the farther down the chain these get asked, the more costly they are

So, how can costs be minimized? Well, just by making an existing application perfect, or by creating a perfect application