The
Internet has helped revolutionize some industries and has
redefined the way we do business. But for many in the
technology industry, the full potential for the Internet has
yet to be tapped. Web services is one of the concepts being
touted by industry insiders as the next evolution for the
Internet. In
fact, Microsoft’s Bill Gates has called it the “Holy
Grail.”
Ideally,
web services will allow companies to tie information, data
sources and applications together over the Internet. For example, take the
current set-up for Amazon.com whereby a consumer orders an
item and the order is seamlessly sent to a separate vendor for
shipping. Web services would multiply this out 1000-fold,
allowing computers to talk to each other regardless of
software or system thus giving an employee, customer, or
vendor access to the specific information needed to complete a
transaction.
More
specifically, “Web
services are business and consumer applications delivered via
the Internet to users who can access and combine these
services from anywhere on the Internet using any device, “
explains Anandhi
Bharadwaj, a professor of decision and information
analysis at Emory University’s Goizueta Business
School.
The
allure of web services is the promise that such a system would
save time and money. In the past, its taken specially designed
computer programs aimed at completing a specific task to
enable a company to gather and process data from its
employees, customers, and business partners. Since each computer
program was developed as the need arose, this piecemeal
approach was often cumbersome, expensive, and difficult to
maintain.
While
the use of a web browser-based format facilitates
computer-to-computer interaction now, the future of web
services would streamline the system even more. “The
promise of web services is that integration will be much
easier because everyone’s system will operate on a set of
common standards and will all be accessible via the Internet,”
said Bharadwaj. “If it’s an information-based service, it’s
highly driven by the software a company has. If that company can
write software that can be accessed from anywhere and link
with someone else’s software and information, the exchange of
information will happen much more easily. It makes good business
sense.”
Once these common standards- or agreed upon
ground rules- are in place, the need for a multitude of
providers will diminish.
This means a potential financial windfall for the
players whose technology is ultimately adopted, and likely
demise for players who don’t make the cut.
With
the potential stakes so high, its not surprising that industry
rivals are walking a tightrope — working together to develop
the foundation and standards for web services while seeking to
beat their competitors to the ultimate prize. For example, rivals
IBM, Microsoft and Sun joined forces long enough to adopt XML
(or Extensible Markup Language, a common data format) as the
underlying web services standard. Like
HTML, which makes surfing the web possible, an employee or
consumer using a web service won’t necessarily know what XML
is, yet XML provides the groundwork for web services by
allowing one company’s applications to communicate with
another company’s applications over the
Internet.
But
there are several obstacles looming along the path to
industry-wide adoption of a web services architecture. Sticking points
include the adoption of several layers of key operation
standards and the more subtle battle of changing the way
companies—their employees, partners and consumers—currently do
business.
First,
but perhaps the least pressing, is defining the term web
services. “How
people interpret the term is a key issue – it is based on a
number of open standards,” notes Benn
Konsynski.
People are familiar with both the “web” and “services.”
But to define web services as “services on the web” is, at
best, vague and at worst is misleading. Even industry insiders
have varying definitions for the term web
services.
Second,
getting to the type of global linkage that web services
promises won’t be easy.
To illustrate, take the current state of systems and
software. Imagine
each U.S. state having its own singularly sized railroad
tracks. Each time a train crossed a state line, the train
would need to be fitted with a new wheelbase to allow it to
run on that state’s rails. If the train only
travels between two states (in other words, has only a few
business partners), changing the wheelbase may not be so
bad. But if that
train travels through dozens of states (has numerous business
partners), changing the wheelbase would be expensive and time
consuming.
For
good measure, throw in that each of the “train manufactures”
produces a train with a different wheelbase—each claiming
their wheelbase to be the best. Agreeing on a standard
rail size would be a huge step.
To
aid in this effort, the Web
Services Interoperability Organization (WS-I) is currently
hammering out the intricacies of these standards with input
from WS-I members IBM, Microsoft, BEA, Sun Microsystems,
Oracle, SAP, and others.
Founded in February 2002, the WS-I is an open industry
effort to promote Web Services interoperability. However, XML aside,
there is a great deal of work to be
done.
In
a web services architecture, at any given time, companies
either publish or consume a web service; in other words, they
either create software applications to be used by others, or
they use software applications created by others.
The
standard computer language used to “publish” these services is
the already agreed upon XML. There are three key
standards currently being scrutinized, clarified and
standardarized:
▪UDDI
(or Universal Description, Discovery and Integration), a web
services directory or “yellow pages.”
▪WSDL
(Web Services Description Language), which describes a
company’s web services to other businesses so other companies
will know what the web service is, how to find it and how to
run it.
▪SOAP
(or Simple Access Protocol), the standard used to exchange the
XML-structured data between company applications.
“Is
it messy? We’re
already seeing that,” admits Bharadwaj. “It’s true any time
you’re dealing with standards. It takes a while.
There are layers and layers of standards—including security
standards within web services.”
Third,
securing and protecting information is another major
obstacle.
Understandably, companies are cautious about allowing
their data and software applications to be shared across a
network. When
dealing with a limited number of business partners, security
is less of an issue.
However, if web services are to have any significant
impact—especially for those companies with hundreds or
thousands of business partners— security standards are
essential. At the
current time, there are no accepted industry-wide security
standards for XML, although IBM did co-author the WS-Security
specification, a key industry standard for web services
security. This
year alone, Microsoft is spending $100 million to improve
software security via its “Trustworthy Computing”
initiative. But
until security standards are ironed out, many companies will
limit web services use to within the firewall.
“I
don’t think CIO’s are going to be shifting their resources on
something that relates to an outside activity when they’re
more concerned about their own internal security and operation
practices,” warns Konsynski. “A company can’t put
its operating business at risk by an alternative service
provider without responsible control. Establishment of
controls and managing those environments will be an
interesting issue.”
On
the consumer side, the creation of a Universal User Profile
(UUP) for web services brings up further concerns about
security and control.
A UUP—a consumer’s password and critical
information—would be stored with a particular service provider
(such as AOL’s Magic Carpet or Microsoft.Net’s Passport). Although this might
make life on the Internet easier for consumers (they’d only
have to enter their critical information once and then anyone
given permission to access that information would be able to
do so), Bharadwaj believes there will be resistance from
businesses anxious to control their customers’
information.
“Would I want Microsoft or some other company to have
that information so that any user communication I had with
that customer is now through Microsoft?” she asks. “Essentially, the
company that controls that consumer’s information controls the
consumer.”
Fourth,
even when standards, security, and control issues are
resolved, CIO’s and IT managers will need to change the way
they’ve been doing business for years if they’re to reap the
rewards of web services. No easy task. “Yes, all the big
players are innovating and they’re creating a tool which will
make it easier to exchange and have information real-time, but
ultimate innovation depends of people’s behavior changing,”
said Ed
Hess, an executive in residence and director of the Center
for Entrepreneurship and Corporate Growth at Goizueta.
With
web services, change has to occur on many levels. First of all, most
corporations currently write monolithic code, or code that
runs on a single system and that has a single
application. The
web services architecture is “modular.” In simple terms,
rather than being like one solid steel structure, web services
promise to be more like Lego building blocks. Companies would have
the ability to assemble components from different sources via
the Internet in order to create applications. Rather than build a
single system from the ground up, companies could search the
Internet for web services that could then be “plugged
in.”
Asking
developers to change the way they’ve always done things may
take some convincing. “Company
employees are going to need to be reeducated,” says
Bharadwaj. “If
they’re used to building one huge structure, it’s going to
take a while to think about how to build it in layers, how to
build it in modules….
It will entail a change in thinking and a change in how
companies approach development.”
Changes
in the development process aside, some companies won’t be able
to benefit from web services without making additional
technical improvements in their current systems. According to Elliot
Bendoly, a professor of decision and information analysis
at Goizueta, “Some firms still have 'rough' interfaces between
on-line and existing back-office applications that can
significantly limit the efficiencies possible via on-line
transaction automation. Efficiencies will
ultimately be limited to the weakest link in the overall
process--most often the interfaces between these disparate
systems.”
Yet
even if these elements can be worked out, IT managers and
CIO’s are still stinging from the under-delivering technology
purchased during the dotcom heyday, and thus are hesitant to
make sweeping changes and major investments in
technology.
Because
so many pieces need to come together for web services to have
a significant impact, it’s no surprise that professors
Bharadwaj and Konsynski predict that industry-wide utilization
of web services is at least five years
away.
“Different
players need to come together and create a set of services and
create a network before everything starts becoming useful,”
Bharadwaj explains. “It will take quite a lot of time until
there’s a critical mass.”
In
the meantime, Konsynski suggests that today’s CIO’s determine
where web services are most suitable for their company’s
use. Two “likely
candidates” he points to are “things that require
inter-organizational interchange” and supply-chain
issues.
“New
products and services are needed in the marketplace,” Hess
adds, “but the ultimate commercialization and acceptance comes
when somebody actually sees what they can do in terms of
dollars and cents, time and efficiency.”