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:
Sent: Friday, March 24, 2006 12:42
AM
To:
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
<<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
<*> 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.
