Hi It seems to me that its possible to categorize 'pilots' in one of 3 ways: (a) as a small training excerise working round business issues; (b) as a a way of testing one approach against another for a defined task; or (c) setting goals to assess the value of an approach to 'solving' an business issue for real.
In my view (a) is very questionable as it may not confront real architecy=ure and business issues and thus its value in preparing people for the 'real task' is smal at best and misleading at worst. (b) is often used to compare products and/or SI companies - it is thus contrived and unless performed in the guise of (c) will have the inherent faults of (a). In (c) it should be expected that, if the pilot does meet its success criteria, it will be an enterprise class and useable service. So the key issues here are to do with selecting the right "service" and being clear on success factors that define the scope of the pilot . Thus there is implicit in the pilot full discovery and analysis as with a full implementation. The only difference really being that the size is ring fenced and there is a backout plan in the evnt of disaster! Chapters 15 through 17 and especially 17 of "Understanding Enterprise SOA" by Pulier & Taylor (http://www.soa.com/book/) offer insight into best practise on this subject. Tx so much --- In [email protected], Todd Biske <[EMAIL PROTECTED]> wrote: > > Bear in mind that the point about enterprise scale is actually from > ZapThink, quoted by Miko, quoted by me, so it's missing a lot of > context. The context of the quote was speaking about pilots in > general, not necessarily an SOA pilot. The way companies go about > selecting pilots and implementing them is somewhat contrary to > everything SOA. There's a big risk that in selecting an SOA pilot, a > company may go about it like every other pilot, and miss all of the > non-technical things so critical to an enterprise SOA. > See chapter 9, pages 169-173 in the Doomed book. :) > > A correctly defined SOA pilot should have the right elements to be > applicable when a full scale enterprise adoption is embraced. > > -tb > > > On Mar 24, 2006, at 6:31 AM, JP Morgenthal 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: > > > > > > > > Miko Matsumura recently posted about the myth of starting small > > which was followed up by a response from Joe McKendrick of ZDNet. > > > > Miko stated that the only ones getting it right were 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, "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" <gervas.douglas@> 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 SOA could be > >> > >> defined as "all the stuff I have been selling for years, with a new > >> > >> brand". Customers are too smart to fall for that and are steaming > >> aheadÂ… > >> > >> > >> > >> I think the only folks who have gotten "Start Small" correct have > >> been > >> > >> Zapthink. > >> > >> > >> > >> The piece that they get right is that the things you do in a pilot > >> are > >> > >> the exact opposite of what you need to do to get to enterprise scale. > >> > >> The shortcuts that seemed so expedient in the small picture are > >> > >> impossible to avoid when you take a serious corporate asset and > >> put it > >> > >> up as a live service. > >> > >> > >> > >> If you dont have some reasonable architectureal guidance in place as > >> > >> you go to enterprise scale, even starting small wont get you there. > >> > >> > >> > >> One Response to "The myth of start small" >> > >> > >> > >> > >> You can read this at: <http://www.soacenter.com/?p=43> > >> > >> > >> > >> Gervas > >> > >> > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > http://groups.yahoo.com/group/service-orientated- architecture/ > > > > > > > > [EMAIL PROTECTED] > > > > > > > > http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > > > > > > > > > > > > > YAHOO! GROUPS LINKS > > > > Visit your group "service-orientated-architecture" on the web. > > > > To unsubscribe from this group, send an email to: > > [EMAIL PROTECTED] > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > > > 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/
