News Stay informed about the latest enterprise technology news and product updates.

Burton: SOA developers beware of 'waterfall'

SOA recommendations coming out of the Burton Catalyst Conference include not trying to throw software tools at the problem and that it's time to take modeling and governance seriously.

San Francisco, Calif. – SOA development is difficult enough, but if it is done with the haphazard "waterfall" methodology it is unlikely to work very well or meet end users needs, said Anne Thomas Manes, vice president and research director for the Burton Group, at today's Burton Catalyst Conference.

If Boeing didn't do modeling, would you fly in their airplanes?"
Chris Howard
AnalystBurton Group

The waterfall methodology is basically no methodology at all, said Manes, in the opening keynote Wednesday morning, "Application Architecture and Development: Building Better Software." It is the old way of writing code without much attention to requirements and then "throwing it over the wall" to testing with little or no follow up as to what happens to that service in the large SOA project.

She said working iteratively with attention to requirements, modeling and especially well defined policies for governance is the way to begin moving away from the waterfall.

"Establish governance for SOA," Manes told the developers and architects in the audience. "SOA is really different, it's really hard. It requires changes in the way you think. You need to start with strong governance and a development culture that supports good programming methodologies, including requirements, modeling and following policy rules."

Following strong rules for application development is especially important as SOA architects and developers look at open source for software, she said.

"Open source software is really cool, it's free," she said. "But there are a lot of bad open source projects out there. You need to establish strong policies for whether or not you use open source."

She said using the waterfall approach also limits reuse in SOA because individual programmers will tend to look at existing services and say: "I know I can do it better." Without methodology and rules for developing and using services, the promise of reuse will be lost in what she termed "the not-invented-here syndrome."

She did not say that this is easy or that there is a magic bullet or single solution that an analyst can recommend and architects can follow.

"We have cultural and technical issues to grapple with," she said, noting that these include application silos, backlog and cost constraints.

"There is no perfect solution that I can recommend," she said. "You have to design them to fit them into the culture of your organization."

For more information

Beware rogue services

Check out our newly updated SOA Learning Guide

Speaking in the session on modeling immediately following the keynote, Chris Howard, analyst with Burton Group, said it is not solved by management coming in and dropping IBM Rational tools on a development team. He suggested that the developers are likely to be overwhelmed by suddenly having a suite of tools thrown at them.

Manes said the move from waterfall to a more iterative methodology needs to be iterative itself and take into consideration the culture of the development and IT organization.

Answering the question: "How to get out of waterfall?" She suggested to start looking at iterative development and begin looking at how do you do modeling.

Howard suggested that while it is often an afterthought in software development, the importance of modeling is crucial in engineering in many other industries. "If Boeing didn't do modeling, would you fly in their airplanes?"

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.