Anne Thomas Manes wrote: > > > On Mon, Jan 12, 2009 at 3:35 AM, Steve Jones <[email protected] > <mailto:jones.steveg%40gmail.com>> wrote: > > 2009/1/11 Anne Thomas Manes <[email protected] > <mailto:atmanes%40gmail.com>>: > > > >> Michael/Steve, > >> > >> If the definition of SOA is so simple and obvious, why is it that we > >> get into heated permathreads whenever someone says something like "SOA > >> = integration"? > > > > Because that is the detail, which is where we are saying the issue is > > but also because its part of the subversion that some analysts and > > most vendors have done deliberately. SOA = Technology. > > But that's just my point: The industry has not agreed on the meaning of SOA.
I'm not sure that there needs to a "meaning" as much as there needs to be conveyed the "purpose" and the "results". Those two words, together, describe the "ideas" that provide the "meaning". > >> > >> What are people talking about when they refer to "their SOA"? > > > > Their Service Oriented Architecture? Well most of the time its the > > pictures and architectural artefacts that define how their IT is going > > to be delivered, sometimes its the physical realisation of that > > architecture and sometimes its just because they've bought a product > > with an SOA sticker. > > When people talk about SOA as a thing, they are talking about their > ESB. They might also include the applications that they've deployed > that communicate using the ESB. They are not talking about pictures > and architectural artifacts. When you make a statement like this, it feels loaded with personal perspective and generalizations that won't always be true. This is why I keep saying that the "why" (purpose of SOA) and "how" (technologies that produce the results needed for YOUR SOA) need to be what is discussed, not the "what" (technologies that are often put in place as a solution looking for a problem). To put this in other words, we shouldn't say an SOA has web services, ESBs and browsers. Instead we should say "why" as in, you should develop an SOA to help you abstract points of extension into services that can be reused by layers that will develop around your core services. This provides a clean separation of responsibilities and provides points of integration that can be used throughout the life cycle of your systems to augment, replace and extend them. Then we would say let's look at what your business has for end to end services now, and decide how we can compartmentalize and manage the movement of those services into an SOA that will ease your business to make the changes that it is planning for the future. Gregg Wonderly Gregg Wonderly Gregg Wonderly
