Software smarts

Bob Brown’s efforts to move the U.S. Patent and Trademark Office to SOA will mean better software for less money, but getting there will take some savvy salesmanship

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.

How to build a better service-oriented architecture

Need help jump-starting your service-oriented architecture project? A number of government-related groups might be able to help.

The Industry Advisory Council’s SOA/Web Services Committee, for example, is working on a SOA readiness assessment survey that targets government agencies. The project aims to identify “the obstacles and challenges to adopting [SOA] in federal organizations,” said Siddhartha Chowdhary, who co-chairs IAC’s SOA/Web Services Committee. That committee is part of the Emerging Technology Shared Interest group.

The survey will emphasize organizational and cultural issues, which Chowdhary described as the hardest aspects of SOA deployment. He said IAC plans to release the survey to as many government workers as possible, enlisting the help of the SOA Community of Practice. The SOA group is a project of the governance subcommittee of the CIO Council’s Architecture and Infrastructure Committee. The group’s objective is to help organizations obtain SOA’s benefits.

The survey is expected to look at areas in which government agencies need to follow best practices.

Meanwhile, the National Association of State Chief Information Officers (NASCIO) has published a research brief containing many SOA recommendations. It calls for CIOs to take the lead in promoting SOA among colleagues on the technical and business sides of the organization. The report also recommends “clearly articulated service-level agreements” as a means for managing expectations and organizational impact.

As for deployment, NASCIO suggests taking on small projects with limited scope, while maintaining a road map for a long-term implementation.

Individual federal agencies are also considering SOA guidelines. Chris Gunderson, executive director of the World Wide Consortium for the Grid, said he is working on a Defense Department project that involves developing SOA implementation and validation/verification guidance.

That guidance seeks to encourage Global Information Grid (GIG) software developers to reuse software code and follow best practices. The Defense Information Systems Agency’s Joint Interoperability Test Command sponsors the project.

DOD’s worldwide GIG network, which DISA operates, serves as the centerpiece of the Pentagon’s vision of network-centric operations.

It’s all about the governance

The term governance frequently arises in discussions of service-oriented architecture, and for good reason. As organizations move from test projects to more ambitious software services deployment, the need for orchestration increases. The coordination requirement may cut across a number of organizational lines, depending on the scope of adoption.

Governance can mean policies that define a common approach for building services, including the standards and tools used in the process. Siddhartha Chowdhary, co-chairman of the Industry Advisory Council’s SOA/Web Services Committee, also places services ownership under the governance rubric.

The ownership issue arises when multiple business groups intend to use a particular service. Who will take responsibility for maintaining the service? Who should pay for it? “It’s something all organizations have to address,” Chowdhary said.

Agencies can organize to deal with SOA’s challenges, Chowdhary said. Organizations have established SOA steering committees with representatives from business and information technology units. Such committees set, communicate and enforce corporate SOA policies enterprisewide, he said. An agency’s top executive should support SOA groups, he added.

Similarly, Thomas Gronbach, senior product marketing manager at Fujitsu Software, said cross-functional teams that represent different areas within an organization can facilitate an SOA culture.

“This core group, or competency center, can be instrumental in establishing and adopting best practices and corporate standards,” he said.

Agencies can avail themselves of many SOA governance software tools. Anne Thomas Manes, a vice president and research director at the Burton Group, said governance tools help capture information about projects and provide workflow and process automation capabilities.

Tools won’t change the human dynamic, but they can make SOA governance less painful, Manes said.

The 2014 Federal 100

Get to know the 100 women and men honored this year for going above and beyond in federal IT.

Reader comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above