This site uses cookies to provide you with a more responsive and personalized service. By using this site you agree to our use of cookies. Please read our cookie notice for more information on the cookies we use and how to delete or block them.

Bookmark Email Print this page

Web Services 2.0

Center for the Edge


Web service-oriented architectures do not just happen. Their development is intentional, and can be accomplished by transforming existing architectures over time, or as greenfield efforts. "Web Services 2.0,"  discusses architectural principles and guidelines for developing service-oriented architectures (SOA) from an outside-in point of view to identify characteristics of a service architecture that will deliver the potential of global web service-based platforms for tomorrow’s enterprise.

The Next Generation
Web Services entered the technology scene somewhere between 1998 and 2000, not long after a subset of Standard Generalized Markup Language (SGML) called EXtensible Markup Language (XML) did the same. Perception of Web Services began as “the next generation of Remote Procedure Call (RPC)” to, now, “the basis of standardizing interoperability between heterogeneous application platforms, and on which tenets of modern web architectures rest.”

Talking with technologists today about machine to machine software interoperability invariably becomes a conversation about

  • Web Services
  • Simple Object Access Protocol (SOAP)
  • Web Service Dictionary Language (WSDL)
  • Web Services (WS) -Security
  • WS-ReliableMessaging
  • Semantic Web
  • Web 2.0 

Conversations with software vendors are similar: they apply the term SOA to their product platforms to imply technology freshness, future proofing, and ease of standards-based interoperability with prospective client and third party application systems. However, when we consider how highly Web Services are touted as the basis of next generation integration and application architectures, we wonder why we don’t see more successful and widespread implementations of service-oriented architectures that enable us to do more than the application architectures that are hosted in enterprise contexts today, with which we’ve become quite familiar.

We would expect to see easier enterprise application interoperability (not just enterprise application integration), increased reuse of business functionality, greater numbers of distributed applications, a more usable web service registry than Universal Description Discovery and Integration (UDDI) has unfortunately proven to be, and hosted software exposing software as a service that becomes governable, reliable, and robust such that it can be embedded in enterprise applications. While we know that significant investments in Web Services and SOAs are being made, we see neither the kind of revolutionary breakthroughs vis-à-vis Web Services that indicate we’re able to more easily develop enterprise application functionality using them, nor the ability to deploy them more easily than applications provisioned on traditional application architectures.

Talk Versus Action
We believe one reason that we don’t see the success we’d expect is that service orientation more commonly than not is viewed as an add-on to existing architectures rather than a fundamental strategy on which an architecture is based … a kind of wrapper put around existing functionality solely to simplify systems integration. While Web Services technology could be used in this way, doing so stops short of the potential of a well-formed service-oriented platform.

A second reason is that even where we take Web Service-oriented architectures seriously, we have neither a means to find web services (which arguably could be some form of Lightweight Data Access Protocol (LDAP) database that could be used both to meet design time registry and runtime directory needs), nor a means to govern and manage their use.

The cost of not capitalizing on the potential of Web Services is so high that it warrants a closer look at how Web Services should be architecturally viewed. Without having a proper point of view regarding architecture, we will find ourselves using Web Services only as a commoditized enterprise application integration platform. The travesty of such would be trading the nominal gains and optimizations of implementing integrations between enterprise systems for those of implementing loosely coupled services, possibly arranged in service grid ecologies, that provision globally-scoped business process networks.

Learn more by downloading the thought leadership piece below.

Connect with the Center

We invite you to sign up to receive publications from the Center for the Edge which are generally available every 1-2 months. The Center issues working papers, reports and articles on a wide range of topics, from market strategy to cloud computing.

Deloitte Center for the Edge e-mail subscription  E-mail subscription

As used in this document, ‘Deloitte’ means Deloitte LLP (and its subsidiaries). Please see for a detailed description of the legal structure of Deloitte LLP and its subsidiaries.

Last updated

Share this page

Email this Send to LinkedIn Send to Facebook Tweet this More sharing options

Stay connected