"There are going to be complexities in any SOA initiative because SOA, if being a simple basic idea, is complex to realize. As with anything, you have to choose where you want to hide complexity and where you want to show simplicity.
If you want simplicity at design and development time or run time, you will probably have complexity at modification time or use (or reuse) time. You can play with any of these axis, you always end up with one that has to give.
You have to make the choice of where you want to show simplicity and deal with the other parameters. So, here are the choices of what a simple SOA architecture should be:
a) derived from business architecture with a strict functional normalization of services (separation of concerns) to eliminate logic gaps and duplication;
b) based on standardized service contracts and a solid common data architecture, all of which promotes intrinsic interoperability and lower integration requirements;
Of course, this is not simple to design, build, run and evolve and this is where governance is critical: design time governance, development time governance, deployment time governance, change time governance, etc. The organisational structure and retribution should ultimately be designed to weave these concepts in the very culture of the SOA team (but that is another subject).
The reward is a set of stable services positionned as real enterprise assets, that are simple to use and readily available for reuse, composition and swift recomposition whithin many different processes, as business changes dictate."
Jacques Ledoux
Senior Consultant at CGI
No comments:
Post a Comment