Gregg, While I agree with your recommendation to focus on "why", I recommend focusing on "what" way before you start thinking about "how". And you've totally lost me when you talk about moving end-to-end services "into the SOA". That terminology makes it sound like a SOA is a piece of infrastructure. (e.g., an ESB).
Anne On 1/13/09, Gregg Wonderly <[email protected]> wrote: > 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 >
