--- In [email protected], Sasan <sasanp...@...> wrote:
At CBDI, we recommend using Architecture to model SOA at several levels (of abstraction). A quick overview is... - Business. A business view of the services it provides and consumes (irrespective of whether they are implemented in software - Specification. A logical specification architecture of the services and their relationships, independent of their implementation. This specifies what a service should do, irrespective of how it does it (to enable loose coupling) - Implementation. The logical specifications are now mapped to their implementations. This could include new or existing software (via wrappers), packages or external services. - Deployment. The services and software are now mapped to the physical network This is a 'top down' approach, but at each level we have to recognise the constrains of existing architecture - existing systems, network. Hence we need to construct both AS-IS and TO-BE models. There is a more detailed explanation here http://www.cbdiforum.com/secure/interact/2007-03/the_architecture_component.php We believe that the critical activities in delivering an SOA that is designed to support business agility, not just IT agility, is to get the service specification architecture right as this forms the key link between business and implementation. Regards Lawrence > This is an interesting point you made. We are actually in the process of > integrating a set of existing products into new a platform but this involves > rearchitecture to some degree. Discussions that we have apart from > architectural decisions have got some technical taste as well. Probably > because some people are technical leads and usually get to technical details > maybe sooner than they should be. > > Therefore I would like to ask you to expand your comment "But my primary > recommendation is to > focus on architecture rather than technology." a bit more.
