Interesting article. And surprising at least to me. I would never tie particular development methodology with SOA. Why? Customers are using methodologies they can implement or they like. I always understood (and I'm using) the word agility in the context of SOA as agility of business not development.


Best,

Radovan



On 6/27/06, Gervas Douglas <[EMAIL PROTECTED]> wrote:

<<Talking about SOA and agile development in the same breath may seem
like comparing apples and oranges, says Gregor Hohpe, software
architect at Google Inc., but from his point of view the terms go
together like Google and search.

"Agile and SOA pair up to improve the alignment between business and
IT," Hohpe told attendees at the Burton Group Catalyst Conference in
San Francisco this past week. He was not being theoretical. He was
talking about how Web services and applications are being developed by
his employer, "one of the largest civilian computing infrastructures
in the world."

The apples and oranges view comes from looking at SOA as being "an
architectural style" that emphasizes how systems interact, while
"agile" encompasses "a development approach" that emphasizes how
people interact, Hohpe said. But in his view agile practices can help
developers move SOA beyond theory.

The agile emphasis on evolution rather than complex upfront design is
a perfect match for SOA because linking Web services into an
application is so complex that architects and developers will not
really know what they have until the project is complete, Hohpe said.
He quoted Eric Evans, author of "Domain-Driven Design,"
(Addison-Wesley 2004), saying: "Big up-front design is a great way to
lock in your ignorance."

He warned his audience to watch out for SOA models that look simple,
but contain artifacts that may not be easy to understand. Stressing
the need to try things that work in practice rather than things that
work in theory, the Google architect also poked fun at the very
standards Web services gurus hold dear.

"Who has ever looked at a WSDL document?" he asked his audience and a
couple hands went up. "Who found it enlightening?" he added and the
hands went down to much laughter.

Unlike the theories that have proliferated around SOA, Hohpe said the
techniques of agile development -- including frequent and on-going
testing, keeping releases small and iterative, and working together
with end users to make sure the application meets their needs -- grew
out of experience with actual application development.

He urged anyone planning to start their first SOA project to not only
start small but accept that they really won't know what they are
doing. He urged them to accept that Agile principle "that you will
know more at the end than you did at the start."

"There's extra ignorance in SOA because we haven't done it before," he
said.

He also warned against making assumptions at the start of a project,
especially the assumption that a complex system can "be built in one
go." This is where the iterative approach is important and he
suggested setting modest goals with shorter iterations.
For more information

Based on his experience as a consultant and now as an architect at
Google, he suggested that in building Web services or beginning an SOA
project it is important to make sure it provides business value for
the end users. This is where the agile principle of "close customer
collaboration" helps, he said.

When a member of the audience asked "How do you make a good service?"
Hohpe replied, "It's rare that people put out a service with no idea
who is going to use it. Start with high value service, with high level
of reuse. With services that get a lot of use, you get a lot of feedback."

For the managers in the audience, he also stressed that both SOA and
agile development take time for programmers to learn. He warned
against the sink or swim approach where coders unfamiliar with SOA or
agile practices are asked to start doing both at the same time.

Asked at the end of his presentation about how to build an agile SOA
development team, Hohpe said: "Minimize the number of new things you
do at the same time. I would try to get people used to the agile
process on a small scope of a single application. Then move to SOA.">>

You can find this at:

<http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1195063,00.html >

Gervas




--
Radovan Janecek
http://radovanjanecek.net/blog __._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to