Adapting to SOA

Computerworld - As part of its 2-year-old effort to move legacy mainframe systems to a service-oriented architecture (SOA), Sabre Holdings Corp. in May began dispatching "reuse advocates" to work closely with all of its development groups. The goal was to encourage developers to tap the travel company's growing registry of services for new projects.

These advocates are typically senior quality assurance or other technical leads identified by their managers as people most likely to influence developers to adapt to changes inherent in building an SOA.

"The biggest chore has been getting people to have a reuse mind-set," says Mike Missler, program manager of the reuse initiative at the Southlake, Texas-based company. "Most developers would rather develop from scratch. There is a lot of resistance."

However, he adds, Sabre's efforts are gaining traction, bolstered by advocates who provide developers with examples of reusable business logic and encourage them to add their own work to the registry.

Missler meets biweekly with the reuse advocates to gain feedback on their work with developers; he also presents awards to developers who have contributed reusable business logic and other assets to the registry.

Sabre has also engaged its development project managers to tout the reuse of application components tied together as services, Missler adds. In addition, the requirements phase of development projects now includes an assessment of opportunities to reuse components of the project.

Over 70% of companies with more than 20,000 employees are adopting SOAs, according to an April report by Forrester Research Inc. As SOAs take hold in many large enterprises, developers are faced with a paradigm shift away from traditional programming. No longer can they develop one-off applications from scratch to be abandoned after they successfully make their way through testing and quality assurance.

Instead, developers must adapt to more closely aligning IT with the business. Instead of writing new code for an isolated application, developers now often must link -- and sometimes make daily changes to -- existing business processes that may live in applications from disparate lines of business. SOAs, by default, require developers to work with the business as they develop these new composite applications -- loosely coupled applications that can be tied together, then uncoupled as needed and reused across the enterprise.