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 [email protected], "htshozawa" <htshoz...@...> 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 [email protected], "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 [email protected], "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/organisational/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? > > > > > > > > > > > > > >
