fullsizeoutput_1bc.jpeg

Jamming out Web services? Maybe you need a conductor

Anyone who's ever watched a jazz ensemble jam knows it's a fluid process. Players have to listen to each other, yield the stage sometimes, take the spotlight every now and then and always stay in sync with the group. The same could be said for the shift to application development that revolves around web services. With service-oriented applications, functionality comes together in "content mash-ups" that unite multiple web services to give users a comprehensive application. Considering that application developers used to look at their task as a start-to-finish process, service-based software development presents managerial challenges, say Haluk Demirkan and Michael Goul, professors of information systems at the W. P. Carey School of Business. They believe the new development model demands new IT positions, and they call one such role "the conductor."

Anyone who's ever watched a jazz ensemble jam knows it's a fluid process. Players have to listen to each other, yield the stage sometimes, take the spotlight every now and then and always stay in sync with the group. The same could be said for the shift to application development that revolves around web services — computerized functionality that can be accessed and used over a network like the Internet.

With service-oriented applications, functionality comes together in "content mash-ups" that unite multiple web services — and maybe even multiple service providers — to give users a comprehensive application. It's a process akin to soloists playing one-by-one in a well-orchestrated performance.

Considering that application developers used to look at their task as a start-to-finish process, service-based software development presents managerial challenges, say Haluk Demirkan and Michael Goul, professors of information systems at the W. P. Carey School of Business. They believe the new development model demands new IT positions, and they call one such role "the conductor." Does your organization need a conductor to make the company's service-based applications swing?

Outsourcing's tiny cousin

If you're new to the world of web services, don't fret. Demirkan and Goul say the process of procuring and using web services is a lot like something you might recognize: outsourcing. But, generally, it's on a smaller scale. Reasons to outsource include obtaining access to best-of-class applications or expertise, cutting costs, increasing flexibility, reducing time-to-market on product development and improving quality, according to the professors.

The same reasons may motivate a move to web services, they maintain. Outsourcing is just a service agreement on a higher level, notes Demirkan. When Best Buy handed off its entire IT function to Accenture last year, the company was outsourcing. Accenture took on all of the responsibility and employees associated with Best Buy's IT provision.

With web services, you hand off some small responsibility — the creation of a bit of computer code, for instance. According to Demirkan, some call this "out-tasking." The work product may be smaller in out-tasking, but that doesn't necessarily simplify its management. In fact, Goul says, "The complexity of managing goes up. You probably have a lot more providers, more relationships to monitor and evaluate, as well as more service-level agreements you need to negotiate."

Big opportunities in small tasks

As Goul points out, "The more relationships you have, the more you have to manage." But, he adds, "The more opportunity you have to minimize transaction costs." When contracting for web services, you may be buying code from producers who focus all their energy on creating one type of application and, therefore, do it very well. "There's a potential for negotiation on each module of code," says Goul.

"You could wind up with the best price from a producer who has best-of-breed code you can grab and use." Contracting for web services makes your company more nimble, too, Demirkan notes. "If I outsource a project to a single service provider for a year, I'm dependent on that company's success," he says. "If that company is behind schedule, I could be out of business."

Working with multiple service providers for smaller pieces of application development frees you up to continue seeking top-tier talent, he continues. "If I'm not happy with one provider, I can move to another." Plus, multiple service providers offer the chance for some redundancy, thereby cutting risks of falling off schedule.

Thoughtful changes

When a company hands off work in an outsourcing or out-tasking agreement, they're not buying a widget. They're buying service, and that's a very different thing. As Demirkan and Goul point out, services are intangible, but perishable. Like a jazz concert, they're consumed in the same instant they're produced, so performance is everything.

And, services are customized. In fact, they're often "co-produced" or "co-created" with the consumer. According to Mary Jo Bitner, professor of marketing at the W. P. Carey School, co-production involves getting customers involved in the delivery of a service. Ordering a specialized coffee drink at Starbuck's might be co-production, because the customer provides precise instructions to get the drink just right.

Co-creation is a bigger term, Bitner says. It can apply from the conceptualization and design of a service to the final delivery and consumption of it — and, each step of the way, the customer may be involved in the process. "Co-creation is clearly evident in education," she says. "Students won't get any value out of education unless they get involved and co-create their learning."

When it comes to the IT world, Bitner sees co-creation coming into play as application developers tap customers and business strategists to determine what's really needed in technology services, ways the services will be accessed, as well as who will use them and how. So, IT professionals will increasingly need to understand end users or buyers of their services, plus strategic ways to give those customers what they want.

Until now, these were functions generally handled by other departments, such as marketing or business intelligence. And, along the way, IT pros will be playing the role of customers themselves. That's because they'll be out-tasking application development and co-creation of solutions with code providers, who supply the web services that actually get the job done.

Big-picture thinking

In both outsourcing and out-tasking, companies need someone from the home organization supervising the activity. According to Demirkan and Goul, this involves at least two roles: contract administrator to monitor work in progress; and service integrator to ensure that the services provided merge smoothly with in-house components and processes.

They see these responsibilities fusing under one job title: Conductor. According to a paper the two recently authored along with colleague Karen Corral, the conductor will "be a person or team of people who manage web-service relationships and contracts." Among the skills conductors need, Demirkan and Goul name:

  • Communication: Conductors will interact with IT personnel, employees of other organizations, as well as members of other departments throughout their own companies. In addition, they'll need to work closely with senior management in their organizations to provide strategic solutions and support process change throughout the organization.
  • Negotiation: Due to their highly technical nature, procurement of web services will be an IT responsibility, not a task for the purchasing department, which generally handles such negotiations. And, as Demirkan points out, procurement of services means negotiating service-level agreements. Performance becomes an issue; speed and quality may trump cost; and the focus may shift from placing a transaction with a vendor to building a relationship with that other company.
  • Technical Skill: Since conductors will be evaluating web-service capabilities, Demirkan and Goul see this person as being highly skilled in information technology.
  • Business-process knowledge: According to Demirkan and Goul, conductors will need to understand enough about business processes to determine which ones might be automated to support the mission of the organization. Bitner inserts a term used at IBM. She says managers there talk about "T-shaped people" — people who have depth of knowledge in their own work area, which is represented by the leg of the "T."

    But, these people also have a breadth of understanding of the business, its customers and what it takes to deliver value to those customers. Like the arms of a "T," that awareness stretches beyond the confines of one department or job title. "Just knowing technology won't be enough anymore," Demirkan says.

    Conductors will need to know the basics of corporate culture, policies, procedures and competitive forces, as well as the strategic value of deliverables, he maintains. And, Goul notes: "We think of financial people as knowing how to do research, monitor markets, evaluate stocks, and develop a portfolio. Those are the kinds of skills that need to be mapped to this whole area of using web services."

Raising the baton

Are IT professionals ready to take on this challenge? Some are, according to the W. P. Carey School professors. Some still need to make the transition. But, the professors offer ideas to bring workers along. "Have a conversation about who is playing the conductor role and maybe doesn't know it," Goul says. "Look at the people who are watching markets for services, evaluate whether they're working with those they should to develop strategies and, if they're not, get them together to share information."

Cross-functional teams certainly have a place in web-service acquisition and development, Bitner notes. "Co-creation of IT services will require more cross-functional communication," she says. Putting people through "rotations," in which they cycle through different jobs — even for a month or two — could be a good eye-opener for corporate workers, Bitner adds.

Demirkan sees companies building in processes to look for web services as a primary way to address business problems such as alignment of business strategies with information technology processes and resources. "Move away from the mentality that you have to build it in-house," he says.

He might even consider changing incentives to reward smart development, identification, implementation and procurement of service-based solutions. All the professors also say formal business education can help round workers out, but not all programs will do the job. "To be honest, the curriculum is changing, and there will be a major shift," Goul says.

Still, Bitner adds, faculty members at many business schools do see the need for people who have both depth of skill and breadth of business knowledge. And, schools are working on ways to develop those skills. It looks like would-be conductors may have to plunk out their own tunes for a while yet. But, with a little management support, they won't need to be playing the solo for long.

Bottom Line:

  • Application development has shifted from end-to-end code writing to acquisition and use of web services, or bits of functionality that, combined, do the job required.
  • IT workers are moving from solution design to service acquisition, and they may not have the skills for it.
  • Skills that now come into play include communication, coordination, negotiation and a broad-brush view of the business.
  • Several corporate exercises can help IT developers navigate the world of web services. These include cross-functional teams, job rotations and changes in incentives.

Latest news