davidjf

SOA story is a nice one! It was at the top of CIO challenges for 2007, and reemphasised in recent CeBit, ...

To consider the best way to develop, maintain application is to design them as independant LEGO buiding blocks, exchanging services is a nice creative dream.

But...

picture, in large companies, of application portfolio shows the real mess:

heterogeneous applications, different programming language, weight of history, big amount of usable application, only a small part being used and a smaller part really useful (using Renault CIO typology)

In that kind of case, SOA is more a modern (desperate?) programming way to try to make these old (and new) applications communicate, creating a layer of web services (communication layer using web xml protocols...).

OK, let's imagine it will work (in some years...)

Will that solve the "data base" problem, that created this heterogeneity? Every silo in the company has his own view (about what is client, what is a map, what is a piece of material) and therefore about the meaning, the way it must be coded, the information that must be inside....

Sure, a way to avoid all that is to move progressively to an ERP, insuring communication between silos but nobody can suddenly stop the past and move to a new way. And ERPs have got their own "philosophy of life"...

On that:

- is SOA DOA ? (Dead on arrival!)

- Good SOA synthesis by IBM (clear enough)

- SOA governance is a must, teams are key...

- Even if you are not necessarily a military fan, it is evident that DoD (US Department of Defense, may be the bigger worldwide purchaser ) plays an important role in definition of standards, in rationalization of IT.

(Cals, Step, CMMI, ...). This Dod article about processes gives interesting views about defining roles, within an ERP implementation challenge, for Business Process Owners, separating clearly management responsibilities and technical responsibilities....

- About the remanent strategic alignment question: " must we change organization first, an then implement IT solution , or must we facilitate/force changes with IT first" , P,P,P,I, thinks strategy, processes and people issues must be treated before IT solution choice... More complex in real life.

- IT governance and application portfolio techniques not so easy to sell internally in companies...

- Clever way for vendors to (story)tell BPM importance...

Dans cet article très simple du journal du net, on peut lire entre les lignes un débat central toujours renouvellé.

L'adoption de progiciels implique d'adapter son entreprise aux règles implicites contenues dans le logiciel.

C'est un changement majeur, modification des philosophies des processus, des cultures des acteurs, ...etc... C'est une problématique clé de "change management".

L'autre scénario est d'adapter son progiciel (et il ne suffit pas de paramétrer!), ce qui est plus ou moins faisable, et qui fait perdre une partie des avantages.

L'adaptation au secteur, au métiers, aux "verticalités" est cruciale dans ce cadre...

Par ailleurs, les pressions des clients donneurs d'ordres rendent dans certains secteurs les décisions urgentes...

On retrouve là à nouveau le débat entre la nécessaire adoption de standards (pour des raisons d'intercommunication, économiques, ...) et le besoin d'adaptation dynamique au génie propre des organisations et aux technologies changeantes.