Take the example of General Electric, which had too many software development approaches across GE Energy. When Agile was introduced, detractors complained it would be a “willy-nilly” approach, versus a familiar structured approach, such as waterfall, explained Paul Rogers, executive manager of GE Energy’s Software Solutions Group (SSG).

However, as Rogers explained at the recent Forrester Research event in Boston, Agile practices brought order to GE’s SSG by getting teams across the organization on the same development page, following one documented and governed methodology.

“In waterfall, it appears that you’re going from step to step. The product requirements document is created and sent to the technical requirements folks. They decompose it and send it to the coders. The coders send to it QA/QC, and you get the perfect product at the end,” Rogers said. “The problem with that is that with each handoff there is a different interpretation of the specs down the line.”

That’s a pretty unpredictable development process, he said, and the main reason SSG opted to make Agile the official methodology. All SSG employees were required to learn the GE-branded curriculum and become certified in the same Agile methodologies. The GE-branded part is a key point, since a lot of people have a different opinion of what Agile is and is not, he said.

The BPM approach

Taking the guesswork and, yes, chaos out of project management can also be achieved by using business process management (BPM) software to introduce Agile methodologies.

When a new product or service is being considered at a company, BPM identifies which processes will be affected. If changes need to be made to a process to accommodate a new product or service, it can be done quickly. Also, if a business process can not be changed — for example, a given process may protect the organization from violating a regulation — then the decision can be made on the fly not to change it.

“Being able to identify how business processes may need to change and who in particular needs to make that change, versus getting 100 people involved to see if a change might violate a standard or regulations, allows [project] teams to be Agile and flexible, and recognize where Agile is not possible,” said Mathias Kirchmer, executive director of Accenture’s BPM practice.

Yet another example provided at the Forrester event of Agile methodologies reining in a major project was Dan Simpson’s business transformation effort while CIO of Physicians Mutual (he joined Trustmark as CIO this month).

As Simpson told the audience, he was brought in to get rid of legacy systems and create a new set of modern services focused on customer needs and buying habits. His go-to solution was SOA. In the end he created services that could be reused time and again when a new application or service was called for by the business or customers. The main benefit? He delivered on his promise to create a single information view for the customer … and introduced Agile methodologies in the process.

“We decided to implement close to 40 new projects as part of the business transformation effort over a period of years,” Simpson said in an interview with SearchCIO.com. “Iterative development using Agile methods was our ’Agile version‘ for those projects. [That iterative method] was how we determined if user requirements were actually being understood during the development process, rather than us implementing something and finding out users aren’t satisfied.”

Agile saved them a lot of grief in terms of having to correct mistakes and redirect projects.

One takeaway from both Rogers and Simpson? Agile methodologies are going to vary from company to company, but you need to come to an agreement as to what Agile means in your particular situation — then document it, educate everyone and stick to it.

What I’ve found is that when doing a SOA implementation, wrapping an existing application exposes an interface in order to increase access. In addition, refacing an application provides a new interface to not only increase access but also to allow reuse. Deconstructing an application into components (“componentizing”), so that it can be reassembled exposes new services. And that feat, it seems, is the province of enterprise artists, tapping into the collective business and digital imagination of the company.

Reading up in preparation for some interviews with companies using service-oriented architecture, I kept coming across variations on the statement that doing a SOA implementation is more an art than a science. Knowing which services to expose for the maximum value requires judgment and taste, sensibilities rarely afforded much value in the world of IT. The notion that judgment and taste can make a huge difference made more sense after talking yesterday to Fred Falten, the chief architect at Amtrak. Here is Falten on designing for future generations with SOA:

“When you’re building a service, you need to plan ahead. Always think about how the service can be reused. Make the extra investment to not just have the project at hand be the mechanism that says, ‘Here is what the interface definition should be,’ but take the extra time to think about what would the entire company, or at least the next reasonable set of potential users, want.

“That pays dividends in so many ways, in terms of future savings. Don’t build services point to point, where you’re really defeating the purpose of SOA.

“The other thing I would say is granularity of the service. It’s extra work, but if you have existing environment it is all too easy of fall into the trap of taking the existing transactional environment and just exposing each transaction as a service. That makes it so fine grained that it is usually meaningless to other applications and other potential service users. It is exposing things at a level that no one knows what to do with, or if they did, it is a lot of extra hassle for them to figure out how to move all the little transactional pieces together. So, what you want to do, if you have a legacy environment that is highly transactional and has relatively small transactions in it, is take the extra time to think about how an external business unit would want this information to be presented, not the way the original team built it, but how it really means something to be business now.”

Check in with us next week to read details on how Falten dealt with the art and science of using SOA to make the Amtrak environment more fleet of foot, er … track.