SOA is not an architecture. It is a style. It specifies a set of principles to follow when defining a BA, EA, AA, etc. Those are the architectures of interest and they will include principles beyond just SO principles. There is more to an architecture than just service providers and consumers.
Architecture as a term refers to both the process and to the end product. It originally meant only the end product (e.g. the building or the ship) but has come to also include the "what you do" to create that product. Many have stated here and elsewhere that SOA is something you do, not something you buy--which places emphasis on the "doing" not the "done." IMO, Linthicum is right that data is important and must be addressed. But it is not the first thing you do, IMO. I also am of the opinion that data concerns are a general architecture concern, not a concern of SO principles. For example, an EA will address data, services, infrastructure, processes, applications, events, et al. SO principles primarily address services. IMO, we need to stop thinking of SOA as *the* thing. Service orientation is but part of a bigger picture. -Rob --- In [email protected], "Kirstan Vandersluis" <[EMAIL PROTECTED]> wrote: > > Rob & Steve, I personally question whether too much emphasis is > placed on the SOA approach. Rob, your opinions express "SOA" as a > verb... its how you design and partition services. I feel that SOA > is a noun... it is an architecture and organization that you have > (or end up with), and one that will bring business agility plus IT > cost savings if it has the right service oriented qualities.
