Software smarts

SOA Community of Practice

To hear Bob Brown tell it, the story of the U.S. Patent and Trademark Office’s move toward service-oriented architecture is more about culture than technology. Brown, senior staff member of USPTO’s software development and maintenance organization, has been guiding the agency toward SOA. Like many other organizations, USPTO is adopting a software development method that calls for the creation of software as a collection of services.

The SOA approach aims to create shareable services that organizations can rapidly deploy to address their needs. Benefits include greater adaptability to change, easier integration with older systems and savings through software reuse.

“We were trying to break up our stovepipes like everyone else and create shared services and get into a more amorphous environment,” Brown said. “And hopefully, with that, break down the walls and reduce the lines of code you have to manage.”

An alphabet soup of software development and data management standards points toward the most common SOA path: Extensible Markup Language, Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP) and Universal Description, Discovery and Integration (UDDI). The human dimension to SOA has fewer guideposts, however.

“The biggest problem is not technological — it’s political and territorial,” Brown said.

The political considerations stem from SOA’s nature. The approach aims to eliminate barriers between isolated applications, creating services that organizations can share across boundaries. Such far-reaching efforts may face resistance, mostly about budgeting and control, industry analysts say.

“The challenges are always cultural,” said Anne Thomas Manes, a vice president and research director at the Burton Group and Web services expert. “One of the most challenging aspects to putting together a SOA adoption plan is figuring out how to resolve these cultural issues.”

Accordingly, industry and government groups are looking into the organizational impact of SOA, developing recommendations and defining best practices.

SOA spells better coordination
USPTO develops about 20 software services per year, Brown said, and commercial products add to the services population.

USPTO’s pursuit of SOA began in 2003. Agency developers had started to create services, and technology managers decided that a more formal process was necessary to coordinate their efforts, Brown said. He said the agency has adopted an incremental approach to SOA rather than an enterprisewide deployment.

A sizable portion of the organization’s service foray focuses on a single system.

Almost half of the services target USPTO’s Patent Application Location and Monitoring system. Patent examiners use the system to track patent applications. PALM originated 20 years ago as a mainframe application but has been recast as a client/server application.

USPTO’s PALM-focused services include a bibliographic data service that supplies information on patent applications. Such services streamline the interfaces users must navigate to access data. A number of patent examiner applications that once connected to PALM via multiple interfaces now link through a common service-based approach.

“Services make life a lot simpler,” Brown said.

USPTO’s services are defined in WSDL and use SOAP as the interface. A UDDI repository, built around an Oracle database, houses the metadata describing the services.

USPTO’s SOA developers include contractors in addition to agency employees. USPTO works with Computer Sciences Corp. and Raytheon, for example. In early 2005, CSC and Raytheon won contracts under the agency’s systems development and integration program.

As USPTO’s services thrust continues, Brown said, he has found that the groups most receptive to SOA are those who are experiencing the most pain — users compelled to navigate multiple systems, for example. Conversely, groups that are not facing many difficulties may be less inclined to embrace SOA.

In general, the business side of an organization may have a “hard time understanding how [SOA] benefits them, so they aren’t as behind it as they could be,” Brown said.

The onus is on the information technology shop to sell SOA, said Brown, who emphasized the importance of recognizing an organization’s different interests. Difficulties arise when IT specialists “just want to write services” and overlook SOA’s political and business ramifications, he added.

Cultural sensitivities
Organizations that ignore the broader context of a SOA adoption do so at their own risk, said industry analysts who emphasized the importance of cultural and organizational issues.

“Those are the real issues with SOA,” said Ronald Schmelzer, senior analyst at ZapThink, a market research firm that specializes in SOA and Web services research.

“The whole idea of SOA is to build these reusable, composable services that allow you to create and change applications as the organizations changes,” he said. But a group building reusable services must persuade other parts of the organization to reuse them.

“That’s not a technical problem; that’s an organizational problem,” Schmelzer said.

The SOA challenge, however, involves more than getting people to use a service. Creating services requires coordination and a consistent approach. Otherwise, the final product may be incompatible or offer redundant services.

Schmelzer said SOA adherents need to plan an architecture that is consistent throughout an organization “so you don’t have different organizations creating their own services and doing their own things.”

Brown said USPTO’s SOA Working Group, created about a year and a half ago, provides one way to educate developers on services and get everyone on the same page. The group hosts brown-bag events for developers and brings in vendors for technology updates.

The agency’s development teams operate under the chief information officer but also exist in USPTO’s finance group. A group representing users also participates in development.

USPTO’s change control board also contributes to the coordination picture. As new requirements arise, users — or developers representing users — submit a request form. That form includes a couple of lines that ask whether the new function could be a service, and if so, whether developers would create it using standards such as XML and SOAP.

The idea is to “get people to think about creating a service if they are going to write some new code,” Brown said.

Such efforts, he said, represent a start toward harnessing SOA’s potential.

“It’s a great goal, and we’ll keep trying to move in that direction,” he said.