Are you implying SOA initiative should be funded by business side rather 
than
IT?

H.Ozawa

Anne Thomas Manes wrote:
> I'm sorry to say that I can't find a report I've written that makes this
> point very very very clear. I think I need to fix that. Most of my
> presentations on SOA make this point clear, but looking through my 
> reports,
> I see that I have not been quite so clear. The point is made -- but it's
> much more subtle.
>
> Sorry about that.
>
> On 7/8/07, Steve Jones <[EMAIL PROTECTED]> wrote:
>>
>>   +1
>>
>> Out of interest Anne, is there a report I can quote that makes this 
>> point
>> very very very clear to clients?
>>
>> Steve
>>
>>
>>
>> On 07/07/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
>> >
>> >   I would add another: Treating SOA like a technology initiative 
>> rather
>> > than a business initiative.
>> >
>> > Anne
>> >
>> >
>> > On 7/6/07, Gervas Douglas < [EMAIL PROTECTED]> wrote:
>> > >
>> > >   <<Sandra Gittlen, writing in Datamation, explored "three ways to
>> > > avoid
>> > > SOA snafus.* Here are the three biggest snafus and how to address
>> > > them:
>> > >
>> > > 1. Operating in a vacuum. SOA is an enterprise project, and 
>> should be
>> > > managed as such. "You have to really get everyone on board -- 
>> from the
>> > > programmers to the shareholders to the end users -- to be successful
>> > > with SOA."
>> > >
>> > > 2. Not creating a governance framework. Governance is a large 
>> part of
>> > > developing an SOA strategy, and organizations must decide ahead of
>> > > time what their reuse and publication policies will be for the
>> > > services within their architecture."
>> > >
>> > > 3. Treating security as an afterthought. "Security can be one of the
>> > > trickiest areas of SOA because organizations are reusing services 
>> that
>> > > might have been created externally. "Most services, to be made as
>> > > reusable as possible, have security stripped out of them. This isn't
>> > > good." IT groups should add service interfaces that address 
>> compliance
>> > > mandates and cater to the highest level of security each application
>> > > requires. "n addition, IT groups should carefully plot out their
>> > > authorization and authentication strategies."
>> > >
>> > > I would like to add a fourth bit of advice, which Sandra 
>> mentioned in
>> > > the article but did not elevate to a "Big Mistake:"
>> > >
>> > > 4. Pushing SOA through as a massive enterprise initiative. That's 
>> sort
>> > > of like, as they say, trying to "boil the ocean." SOA should be
>> > > introduced incrementally, starting out with quick wins to 
>> demonstrate
>> > > its value to the rest of the organization. If SOA is launched as 
>> this
>> > > galactic transformative mega-project, constituents will be quickly
>> > > disappointed when they don't see mega-results to their areas of the
>> > > business.>>
>> > >
>> > > You can read this at:
>> > >
>> > > 
>> http://www.soainaction.com/blog/2007/06/the_three_biggest_soa_mistakes.php 
>>
>> > >
>> > >
>> > > Gervas
>> > >
>> > >
>> >
>>  
>>
>

Reply via email to