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.
Just to clarify--I think Pilots and Proof-of-concept projects areimportant for some. And I also believe that some projects are justplain inappropriate for enterprise scale SOA. So I'm certainly notadvocating a leap without thinking approach.It's *after* you do the pilot and when you get into deploying servicesthat impact the business and livelihood of your company where I thinkyou need to deal with architecture (hmm loaded word, sorry).The concern I have isnt neccesarily with people doing small SOAthings, it's more the idea that a small mentality can govern a bigarchitecture...--- In [email protected], "GervasDouglas" <[EMAIL PROTECTED]> wrote:<<Start Small. Start small. Start Small. Start Small. Oh wait, Iforgot 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 tothe market! Platform vendors have long been hoping that SOA could bedefined as "all the stuff I have been selling for years, with a newbrand". Customers are too smart to fall for that and are steaming ahead…I think the only folks who have gotten "Start Small" correct have beenZapthink.The piece that they get right is that the things you do in a pilot arethe exact opposite of what you need to do to get to enterprise scale.The shortcuts that seemed so expedient in the small picture areimpossible to avoid when you take a serious corporate asset and put itup as a live service.If you dont have some reasonable architectureal guidance in place asyou 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>GervasYahoo! Groups Links<*> To visit your group on the web, go to:<*> To unsubscribe from this group, send an email to:<*> Your use of Yahoo! Groups is subject to:
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.
