--- In [email protected], "Steve Jones" <jones.ste...@...> wrote: > > 2008/12/22 Gervas Douglas <gervas.doug...@...>: > > 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." > > That sounds exactly like a vendor would pitch it yes ;)
I guess I had subconsciously gone back about 3 decades and applied gel to my (now, what colour was it?) hair. Thanks, Steve, for the constructive, management-friendly transformation :) Gervas > > What I'd say is that a _standards_ based integration approach will > have a reduced _cost_ of integration and an approach that focuses on > integration as part of the _infrastructure_ will be better able to > industrialise (further reduce the costs) integration. The key is to > treat integration as purely an enabler, and thus as a commodity and > manage and procure it in that way. > > SOA helps you make integration a commodity by providing standardised > ways of looking at services and enabling the relegation of integration > to the infrastructure and enabling the business to concentrate on the > value. > > SOA makes integration cheap, if you think of Services as important and > integration as a commodity. > > > > > Gervas > > Steve > > > > > --- In [email protected], "Steve Jones" > > <jones.steveg@> wrote: > >> > >> 2008/12/22 Michael Poulin <m3poulin@>: > >> > 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 <jeffrschneider@> > >> > 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? > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > > >> > > >> > > >> > > > > >
