As part of its two-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 mindset,” says Mike Missler, program manager of the reuse initiative at the Southlake, Tex.-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 per cent 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. These are loosely coupled apps 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.”
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, such as 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.
Danske Bank AB in Copenhagen has been operating a homegrown SOA since 2000. Today, it has about 2,000 reusable functions available for developers and 100 to 150 composite applications in production, says Claus Torp Jensen, the bank’s vice-president of architecture and development strategy.
Technology aside, Torp Jensen says that one of the bank’s biggest challenges has been to help developers find the best reusable functions for business requirements. The bank devised a development model that includes business process management modeling to identify the best solution for the business and a parallel process to analyze possible future applications of the services built for a particular project.
The result is a services map, a layout of the building blocks the company expects to be able to leverage in future projects. For example, architects and developers could refer back to the map containing a service for verifying the identity of customers and then add the ability to check the identity of a partner to that service, instead of developing a new one, Torp Jensen says.
“I can give a programming team a set of descriptive models and tell them, ‘This is what you are going to create,’ “ he explains. “They have to code the pieces and not invent the structure.”
QuickLink 052923
