SOA and agility go together like Google and search |
 |
By Rich Seeley, News Writer
20 Jun 2006 | SearchWebServices.com |
|
|
San Francisco - 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.
|
|
|
|
|
There's extra ignorance in SOA because we haven't done it before.
Gregor Hohpe
Software Architect, Google Inc.
|
|
|
|
|
|
|
|
|
|
"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.
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."
|
|
|
|
