As an aside: Good presentation at the EAC...
--- JP Morgenthal <[EMAIL PROTECTED]> wrote: > Todd, > > > > I like the way you stated your point. I > tell people that no one > gets it right the first time out and that, through > implementation, you will > refactor your service architecture to optimize. > This is no different than > database design or OO design. You "think" that it > should be one way, but > then as you start to put it into action, you > "realize" that it would work > better a different way. Hence, the design is > ultimately modified by the > usage. However, I disagree with the point that what > you do in a pilot is > not what you would do on an enterprise scale in SOA. > The goal is to > abstract out the business service, period. It may > need to be refactored as > you begin to realize the design in implementation, > but the process is the > same regardless. > > > > JP > > > > _____ > > From: > [email protected] > [mailto:[EMAIL PROTECTED] > On Behalf Of Todd > Biske > Sent: Friday, March 24, 2006 12:42 AM > To: [email protected] > Subject: Re: [service-orientated-architecture] Re: > Miko Does Not Believe in > Starting Small > > > > Here are my thoughts, copied from my blog: > > > > <http://www.soacenter.com/> Miko Matsumura recently > posted about the > <http://www.soacenter.com/?p=43> myth of starting > small which was followed > up by a > <http://blogs.zdnet.com/service-oriented/?p=577> > response from Joe > McKendrick of ZDNet. > > Miko stated that the only ones getting it right were > <http://www.zapthink.com/> ZapThink, who state that > "the things you do in a > pilot are the exact opposite of what you need to do > to get to enterprise > scale." For the record, I agree. This all comes down > to defining the pilot > properly. In their book, " > <http://www.amazon.com/exec/obidos/ASIN/0471768588/toddbiskespeking/> > Service Orient or Be Doomed!" Jason and Ron call out > three SOA Pilot > essentials: an architectural plan (the pilot will > cover some portion of it), > a specific scope, and clear acceptance criteria. > > There shouldn't be much controversy over these, but > yet, the case studies > and whitepapers that I see presented don't have > these elements, and it's > usually because the study is equating web services > usage with SOA. Taking a > user-facing customer portal and extending it by > allowing customers to > integrate their systems directly can be a good > thing, but is it really an > SOA pilot? > > One of the key things, in my opinion, in a proper > SOA pilot is to pick a > problem that will require the organization to see > the cultural changes that > are necessary to become a service provider. In the > portal case, the group > maintaining the portal is already a service > provider, so there's no big > stretch there. Instead, we need to find a service > that has potential for > reuse, and has no clear owner in the current > organization structure. This > scenario will give a good dose of what SOA is all > about from an IT > perspective. If you're using the pilot to sell SOA > to the business, you've > got to be even more careful in your selection, > especially in picking the > right service consumers. Agility is a particularly > difficult thing to pilot, > because it only becomes evident when something needs > to change. If a pilot > is putting it in place for the first time, there's > no change involved. What > can help pick the right pilot? The architectural > plan. If the architectural > plan isn't already service-oriented, however, what > do you do? > > My advice is to first focus on why you're doing the > pilot, and what you hope > to achieve/prove. If IT begins to understand what > being a service-provider > means (you need to have a pilot that have distinct > service consumers and > providers to do this), it is progress, even if the > service isn't as > coarse-grained as it should be or can be used as a > good case for business > justification. It may not be SOA yet, but it is a > step in right direction. > Once you understand how the IT organization needs to > change, now you can > pick a service with a bit more impact that really > can show the business that > IT has its act together and can make a difference. > > -tb > > > > On Mar 23, 2006, at 3:47 PM, miko_68 wrote: > > > > > > Just to clarify--I think Pilots and Proof-of-concept > projects are > > important for some. And I also believe that some > projects are just > > plain inappropriate for enterprise scale SOA. So I'm > certainly not > > advocating a leap without thinking approach. > > > > It's *after* you do the pilot and when you get into > deploying services > > that impact the business and livelihood of your > company where I think > > you need to deal with architecture (hmm loaded word, > sorry). > > > > The concern I have isnt neccesarily with people > doing small SOA > > things, it's more the idea that a small mentality > can govern a big > > architecture... > > > > --- In > [email protected], > "Gervas > > Douglas" <[EMAIL PROTECTED]> wrote: > > > > <<Start Small. Start small. Start Small. Start > Small. Oh wait, I > > forgot to mention that you should probably Start > Small. > > > > The superplatform vendors want you to do things > "iteratively". > > Iteratively is code word for dont build too fast so > we can catch up to > > the market! Platform vendors have long been hoping > that === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
