This Group is replete with technical geniuses with deep experience of designing, implemeting and maintaining complex enterprise systems - which is marvelous! However to an outside non-technical observer many of the arguments and opinions are bafflingly arcane as an inevitable result. Looking to explain it the non-techy senior executive wielding purchasing power, do you think the following proposition would be a resonable if slightly over-simplistic explanation of SOA and integration:
"If a greenfield enterprise system is designed and implemented according to SOA principles it will naturally have intrinsic seamless integration capabilities now and in the future." Gervas --- In [email protected], "Steve Jones" <jones.ste...@...> wrote: > > 2008/12/22 Michael Poulin <m3pou...@...>: > > Dear Jeff, > > could you, please, be so kind to tell what this means: "Stop the bullsh!t. > > If I see another presentation on governance, I'm going to drive to Boston > > and start uninstalling PowerPoint on analysts hard drives." with regard to > > our discussion? > > From the Yefim's message to me: > > "SOA is a very close cousin of three-tier architecture. ... SOA is not > > integration, but it differentiates from 3T that preceded it by being > > designed for heterogeneity." And this is what I praise the Lord for! > > BTW, does anybody know how the service-oriented integration differs from the > > NON-service-oriented integration? > > Most old style EAI was (IME) about shifting documents from A to B with > some mediation around it. These were either brokers (like MQSI) which > had some form of queue to queue pipeline or something a bit more > process oriented but fundamentally it was about linking endpoint A to > endpoint B without any real consideration about exposing a service > interface or making that interface discoverable. > > In a sense (a loose sense) the Technical SO world is the combination > of this mindset with the CORBA/RMI/Jini world of having a published > and discoverable interface but providing the fabric via which > integration and mediation can happen. > > Somewhat entertainingly however the analysts have pretty much all not > spotted the number of old style EAI products that have had an SOA > veneer lobbed on top. You can put lipstick on the pig... but its > still a pig. > > Steve > > > Cheers, > > - Michael > > ________________________________ > > From: jeffrschneider <jeffrschnei...@...> > > To: [email protected] > > Sent: Monday, December 22, 2008 1:17:50 PM > > Subject: [service-orientated-architecture] Re: Yefim Natis is sure that "SOA > > is integration" > > > > Yefim wants 'service oriented integration' ? Praise the lord. We can > > slap some basic policies around that and make it practical. > > > > Stop the bullsh!t. If I see another presentation on governance, I'm > > going to drive to Boston and start uninstalling PowerPoint on > > analysts hard drives. > > > > Merry Christmas, > > Jeff > > > > --- In service-orientated- architecture@ yahoogroups. com, "htshozawa" > > <htshozawa@ ..> wrote: > >> > >> IMHO, isn't integration just one objective of SOA. Isn't SOA an > >> architecture which will make integration easier. > >> > >> I'm afraid that the best way to just eliminate redundency may > > result > >> to just using products all from one vendor. I think there is a need > >> to distinguish between migration to a single vendor and SOA. > >> > >> I personally favor, create an architecture and a "suggested" > >> implementation plan, but to start the actual implementation with a > >> single project. > >> > >> H.Ozawa > >> > >> --- In service-orientated- architecture@ yahoogroups. com, "Gervas > >> Douglas" <gervas.douglas@ > wrote: > >> > > >> > Here is what Anne's blog has to say on this: > >> > > >> > <<According to this report by Jack Vaughn at SearchSOA | > > TechTarget, > >> > Yefim Natis asserted "SOA is integration" at last week's Gartner > >> AADI > >> > Summit. The assertion produced the usual firestorm of commentary > > on > >> > the Yahoo! SOA discussion list. Michael Poulin started the > >> discussion > >> > with this comment: > >> > > >> > "What can we do to slow down spreading such Integration SOA > >> madness?" > >> > > >> > My response followed suit: > >> > > >> > "While I agree with the last line ["SOA is less a technology > >> than > >> > a way to dependably extract business value from technology." ], I > >> > disagree with the leading one: "SOA is integration" . Many > >> > organizations mistakenly perceive SOA as an integration strategy. > >> But > >> > it is not. SOA is about architecture. To achieve SOA, you must > >> > rearchitect your systems. You must remove the deadwood. Every > >> > organization has too much stuff -- too many redundant > > applications > >> and > >> > data sources. SOA is about cleaning house. You will not simplify > >> your > >> > environment, reduce costs, and gain agility until you reduce that > >> > redundancy." > >> > > >> > We have 17 messages in the thread so far, and our debate was > > picked > >> up > >> > yesterday by Loraine Lawson at ITBusinessEdge. Loraine admonished > > us > >> > for our "boil the ocean" perspective of SOA. As many SOA case > >> studies > >> > indicate, "SOA" works well for integration. I put "SOA" into > > quotes, > >> > though, because I assert that these integration case studies are > > not > >> > examples of service oriented architecture (SOA). The are examples > > of > >> > service oriented integration (SOI). i.e., they are examples of > >> > projects that used service oriented protocols (e.g., WS-*) and > >> > middleware (e.g., ESB) to integrate two or more application > > systems. > >> > But from an architectural perspective, you still have monolithic > >> > systems bridged by integration middleware. > >> > > >> > Maybe I'm just being pedantic, but I think it's important to > >> > distinguish between integration and architectural activities. It's > >> > fine to use service oriented middleware to implement integration > >> > projects, but then you need to readjust your expectations. Most > >> > organizations that I speak with say that the goals of their SOA > >> > initiative are to reduce costs and increase agility. > > Unfortunately, > >> > these organizations aren't likely to achieve these goals if their > >> > projects only focus on integration. (Also see Chris Haddad's > >> > perspective on these success stories.) > >> > > >> > In the research that Chris and I conducted last year, we found > > only > >> > four companies that had achieved real success in their SOA > >> initiatives > >> > -- i.e., they met their goals to reduce costs and increase > > agility. > >> > Their successes were astounding, and they delivered positive > > returns > >> > on investment in less than 12 months. In all cases these companies > >> > focused on architecture -- not integration. > >> > > >> > Service oriented architecture is hard work. It's disruptive. It's > > a > >> > political minefield. It involves going through the application > >> > portfolio and identifying redundant applications that can be > >> > decommissioned and replaced by a single service. But no one ever > >> wants > >> > to open that can of worms. Many folks live by the adage, "If it > >> ain't > >> > broke, don't fix it." There's way too much other stuff to do. But > >> each > >> > additional application increases the annual maintenance and > >> operations > >> > budget. And for many of those applications, the cost of > > maintaining > >> > the application exceeds the value it brings to the business. It's > >> just > >> > good business sense to eliminant some of that redundancy. And by > > the > >> > way, the CFO is going to be looking to reduce the IT M&O budget > > this > >> > year. There is no better time to start an application > >> rationalization > >> > effort.>> > >> > > >> > You can find it at: > >> > > >> > http://apsblog. burtongroup. com/ > >> > > >> > together with a photo of Anne looking very canny!! > >> > > >> > Gervas > >> > > >> > --- In service-orientated- architecture@ yahoogroups. com, "Steve > >> Jones" > >> > <jones.steveg@ > wrote: > >> > > > >> > > Not really, the argument appears to be more about what is > >> integration, > >> > > for instance whether process and choreography count as > >> integration > >> > > and whether more dynamic interaction models count as > > integration. > >> > > > >> > > I think that most people on this list agree that SOA is > >> > > _predominately_ a governance/organisa tional/business/ thinking > >> thing, > >> > > but that there are SOA _technologies_ which are related > > directly > >> to > >> > > implementation. One of the on going challenges in this group > > is > >> the > >> > > two different worlds of SOA. > >> > > > >> > > Far from being vacuous that is in fact the biggest and oldest > >> > > challenge of IT and the point of SOA is that it can have the > >> > > discussion on both sides but its failing is that it still > > hasn't > >> made > >> > > the difference clear. > >> > > > >> > > Define integration in a tight and specific way. > >> > > > >> > > Steve > >> > > > >> > > > >> > > > >> > > 2008/12/20 Nick Gall <nick.gall@> : > >> > > > Doesn't the suspicion that SOA is vacuous grow stronger when > >> you see > >> > > > that we can't even agree about the relationship of SOA and > >> > > > integration? > >> > > > > >> > > > > >> > > > >> > > >> > > > > > > >
