SIDEBAR: Adapting to SOA

An emphasis on reuse is changing the way developers work by Heather Havenstein

As part of its two-year-old effort to move legacy mainframe systems to a service-oriented architecture (SOA), Sabre Holdings last year 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 Sabre. "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.

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. Indeed, SOAs are the catalyst for true alignment between business and IT, says Forrester analyst Randy Heffner, as IT moves out of the realm of "order takers" to a more collaborative relationship with the business.

"IT has typically measured itself from 'Did we deliver on time and on spec and on budget?' You can do all those things and not deliver business value," Heffner says. "With services, we have finally brought the design paradigm up to a level where IT and the business can talk the same language. The business-IT dialogue starts with the business problem and not with the requirements document."

Changing the Mind-set The move toward SOAs requires a "reorientation of the thought process" as opposed to new skills for developers, says Matt Miszewski, CIO for the state of Wisconsin. The state is now overhauling its main portal, with a mandate not to deploy any objects that can't be reused within other services, he says.

"Instead of developing a line-of-business application for the Department of Revenue, I am developing a system, but it will be made up of these components that can be reused," explains Miszewski. "They are coding objects instead of whole systems."

The state has eased this shift with top executive buy-in, he says. All the deputy secretaries meet regularly to identify where they can create services - like a service to process credit cards - to be used across the state's 50-plus agencies. Miszewski also has regular briefings with the development staffers, which has helped them embrace the SOA philosophy. "Developers are excited by this. They can concentrate on adding pure value, not just building another shopping cart," he says.