Prepare for Job Changes

 
 
By Bob Violino  |  Posted 2007-03-08
 
 
 

There is no doubt about it: service-oriented architecture, or SOA, has gained acceptance as a way to exchange data previously trapped in legacy systems and isolated databases. The I.T. architecture supports the integration of business processes as linked services or repeatable business tasks that can be accessed to make those applications and databases available as "services," leveraging mechanisms such as eXtensible Markup Language to facilitate the sharing of information.

According to a study released in November 2006 by Boston-based AMR Research, 35% of executives said their companies had implemented one or more projects using SOA. A survey of 179 technology executives, published last month by CIO Insight, found that 79% expect their company's technology architecture will be based on service-oriented software, Web services and related technologies in the next five years.

Now that SOA has gained acceptance, what lessons have been learned from past deployments that can be used during future projects? Here are five suggestions, based on interviews with information-technology professionals and industry analysts.

Next page: Spread the Word

1) Spread the Word

Technology executives must make it clear that an SOA implementation isn't a one-shot deal. "SOA is not something you deploy and then you're finished. It's a new approach toward software engineering," says Yefim Natis, a vice president at research firm Gartner in Stamford, Conn. He anticipates that all applications will be modernized or replaced by SOA, and that new purchased and in-house-developed apps will be based on the architecture. "The SOA discipline and practices are the permanent replacement for the now-prevailing monolithic [even if technically distributed] systems."

After SOA has been successfully deployed in one or two projects, information-technology managers must articulate the value of a service-based architecture to business executives and employees. By doing this, they can show senior executives, including people in finance, that a move to SOA is worth the money and effort—including demonstrating how SOA can help departments function more successfully and workers perform more productively.

Even within the I.T. department, proponents of SOA need to promote SOA. "Initial projects tend to be pretty informal and isolated, so part of the next step needs to be scaling up the effort, bringing more of the I.T. organization into the loop and educating them," says Ian Finley, research director at AMR Research. "This is an internal sales job about what the capabilities are, what the project was and why it worked well."

Next page: Prepare for Job Changes

2) Prepare for Job Changes

Adoption of SOA requires technology organizations to understand that the role of some workers must change—and, possibly, their skills.

AMR's Finley sees three new types of workers for organizations using SOA. First is the "service creator," a combination of programmer, enterprise architect, product designer and product manager who creates services from existing applications and data sources as well as from scratch.

The "service consumer" is less of a developer and more of a business process expert, using business process modeling tools rather than programming languages to create solutions for business users.

And the "service librarian" is responsible for ensuring that solutions use existing services instead of creating new ones.

The services need to be managed like products, Finley says, with releases, product requirement lists, migrations and so on, because they have multiple customers. "For many, this will represent an evolution in their role, rather than a brand-new role," he says.

3) Develop Best Practices

Organizations that have gained traction with SOA should begin to develop best practices to help successfully deploy the architecture in other areas. Gartner's Natis says SOA is at a point in its evolution where there's lots of learning needed and many obstacles to overcome—such as lack of experience, lack of dedicated tools and, as a result, increasing complexity. All this, even as some companies begin to see benefits such as greater agility, faster times to market and faster turnaround of business requests for I.T. services.

Gartner, for example, recommends that companies establish an integration/SOA competency center.

TD Banknorth, a financial services firm in Portland, Maine, developed recommendations for implementing SOA after its initial deployment, which began in 2004. The company used webMethods' SOA platform for several projects, including a Web service to make it easier to complete customer address changes. The service, built within the webMethods Fabric suite of products, enables call-center agents or branch employees to make address changes and automatically have those changes reflected in all of the customer's accounts. Other SOA projects involve a small-business loan origination service and the company's online banking system.

The recommendations established for SOA address the software tools, people and processes involved in an implementation, and include basic Web services such as messaging, common service models, service descriptions, contracts and meta-data, says Joe Castinado, enterprise architect at TD Banknorth. "By creating these guidelines, we have the benefit of providing boundaries around what is considered a service and at what level the service can be utilized by the enterprise," Castinado says.

With these suggestions, I.T. can show others in the company what's been accomplished with SOA and how they can use the best practices to create new services.

The software industry is still working on standards for SOA, "so the established guidelines, policies and governance around SOA should be technology-independent, iterative in adoption and flexible to some degree," advises Bob Jones, vice president and head of the enterprise architecture group at TD Banknorth.

Next page: Manage Reuse

4) Manage Reuse

Because the goal of many SOA projects is to build reusable components or software modules, there needs to be a new governance structure in place to manage those new services, says AMR's Finley.

For example, a company that AMR had discussions with needed to re-deploy new services three or four times before they got to something they could reuse, Finley says. While there are tools for capturing the new services, he emphasizes that process and politics are the most important part of governance.

Just as I.T. governance ensures that technology investments are optimized to serve the business, SOA governance ensures that investments in services are optimized to serve I.T., Finley says.

An SOA governance committee should be responsible for directing and controlling activities such as service design—the definition, identity and creation of service domains; service reuse—designing a common repository of services; service ownership—assigning the creation of a shared service to a group for maintenance and upgrades; service management, reliability and availability—the ongoing management of and responsibility for the service; and service consolidation—the regular review of services and their need to be consolidated as the technologies and applications evolve.

USinternetworking, a subsidiary of AT&T that provides hosting and management services for corporate portals, enterprise applications and Internet retail sites, is looking to adopt a governance structure. It first deployed SOA in 2006 to integrate disparate applications and automate application provisioning throughout its enterprise.

Using several components of Oracle's Fusion Middleware, which provides an SOA architecture and identity management platform, USi developed SOA to integrate and simplify provisioning for internal business applications, including an Ariba procurement application and Oracle's PeopleSoft Enterprise programs. Prior to deploying SOA, provisioning employees for each of the business applications was a manual process requiring several steps to manage.

With the Oracle software, USi wrapped critical components, such as PeopleSoft's customer relationship management application programming interface and some proprietary applications, to expose them as Web services, then created processes linking the Web services to automate the company's provisioning and authentication process and streamline user name log-ons. The result was a reduction in costs to manage provisioning, though the exact amount was not available.

Going forward with its SOA deployment, USi is creating a standardized way to name and manage new services, says Michael Rulf, vice president of advanced engineering. "That allows us to create services a lot more quickly than we expected," he says.

This approach also enables USi to handle security consistently. "Each time a new function was created, it was automatically secured by the wrapper's built-in security function. Error handling was processed in a standardized way as well," Rulf says.

Next page: Measure Results

5) Measure Results

Is the move to SOA paying off, and if so, how? Some benefits, such as improved customer service, might be difficult to quantify. But others, like increased productivity and cost savings, can and should be measured.

Organizations need to develop metrics that will help them determine the long-term value of SOA, Finley says. For example, when building a return on investment model for an SOA project, companies must determine how to justify the cost of a technology initiative that might not begin paying back until years after the implementation.

"How do you put a value on that and, down the road, measure it?" Finley points out. "If you build a bunch of services, are people actually using them? There's a whole set of metrics that go along with this idea of reusable services; are you really delivering on those benefits you promised for SOA, like increased quality and flexibility? I don't think anyone out there has the answers on how to measure these things."

TD Banknorth is trying to build "general" SOA metrics such as the number of times a new service was executed in a day, week or month, and who is using the service, Castinado says. Based on its measures, the company determined that 80% of its SOA services were being used by more than one entity for development projects, and that it had reduced development costs by 50% over a nine-month period because of this reuse.