Web services have been touted as a really "big thing" in the software industry the last couple of years, and that is for good reason: they promise technical interoperability between platforms from different vendors, an hitherto unheard-of thing in an industry plagued by proprietary non-compatible solutions.

IBut does anybody really care about platform interoperability? Isn't it something else we are after? In this article, we'll explain what Web services are and what they are not, and take a look at what we need beyond Web services to get to where we want to be.

The first time I heard of Web services I was excited. Imagine being able to link your application to any other application out there. You could build really nice, lightweight "apps-on-apps" - i.e., applications that do exactly what they are supposed to do and reuse data and functionality from existing applications. And there could be specialized service providers for certain services that are hard to implement or manage. And, and, and... Endless possibilities! Brave new world! I envisioned service-oriented system landscapes, where our customers would choose the optimal deployment models for each application, where they could choose the right technology for each task, and so on - without sacrificing integration!

Where Are We Now?
So where are we now, four years later? Well, we have achieved a lot, but we are far from done. Web ser-vices are here to stay, but they have not taken us to where we want to be. Those who look to Web services as a solution to any problem we have ever had will be disappointed; those who understand the big picture and see that we have taken important first steps will see the possibilities. With the standards for platform interoperability we have created an alphabet, to make it a language for communication we now have to add words and grammar. We have passed one major inflection point, the creation of the alphabet, and now have to prepare for the next one, adding words and grammar.

Web services are standards for technical interoperability between software platforms. This means that one application built on one platform can send a message to another application built on another platform, and that the receiving platform will be able to process that message. We have high ambitions for the Web services standards stack, in that we do not only cover simple messaging, but also advanced messaging features such as security and reliability. We also want to make it easier for application developers to use services offered by other applications through sophisticated machine-readable ways of describing services and how they work, enabling us to create development environments that actually do a lot of the more technical work for us. This has already had an effect on the system landscapes of our customers, where Web ser-vices now is the technology of choice for integration projects.

But did you notice the catch in the previous paragraph? "...the receiving platform will be able to process that message." This is precisely what Web services ensure, not that the receiving application actually understands the message and knows what to do with it. Of course the latter is what most people would expect from application interoperability, and of course it was this vision that got me excited four years ago. To get there, we have to add the words and grammar to our alphabet. The words are business objects and the grammar is a set of patterns describing interactions. And we have to teach everybody who wants to communicate this new language. As business applications are the ones who should communicate, they are the ones who need to learn the language. This will be the second inflection point: Adoption of business applications that are based on Web services technology and use and expose business objects and interaction patterns.

The Next Inflection Point
The previous and current generations of business applications, such as SAP R/3 and the mySAP Business Suite, have been successful because of their integration based on a common database or tightly coupled databases, i.e. they have internally spoken one language, with one set of business objects and interaction patterns. Interfaces for integration with other applications exist. However, the proprietary object models and pattern catalogs have not been explicit and could not be shared with applications from other vendors. SAP and others are now rapidly "Web services enabling" their applications by making existing and new interfaces available as Web ser-vices, eliminating the need for adaptors when integrating applications from different vendors and thus lowering the cost of ownership. This means that these applications learn to use the alphabet when communicating with others.

We can teach our current applications some words and grammar by adding new interfaces and metadata repositories, but this is tedious work and hard to get right. The next generation of business applications will be designed to speak the language from the ground up. They will make their object models and pattern catalogs explicit and shareable with other applications, and we will see integration platforms emerge that can use objects and patterns to enable communication between independently designed applications. Why do we need this? How will it work?

Let's first look at the business objects. If one application wants to tell another one to do something or wants to ask it for information about something, they have to talk about the same things. These "things" are the business objects. Both applications need to have the same understanding of the structure of the object they are communicating about and in most cases they need to have the same understanding of how this object is related to other objects. Not all applications will be built on the same object model; that is neither practical nor makes much sense. Instead, the applications need to make their object models explicit, so that an enterprise architect can implement an enterprise object model in an integration platform and map the various application object models to it. The integration platform then can provide runtime translation between the application models. In addition to this information about an object type, the applications will have to share information about specific object instances. Again, it is not practical to have all applications use the same object IDs, so we need a mapping between the IDs of the various applications in an integration platform.

Now that we have an alphabet and words, let's look at the grammar. In our case this is the patterns catalog. A pattern tells us what kind of communication around one or more objects is allowed. It tells us what services exist and in what sequence they can be called, and what the result of such a sequence of calls is. As with the objects, we cannot expect all applications to be based on the same set of patterns, so they need to make them explicit. These patterns are then used by the integration platform to orchestrate a business process across applications.

If the next generation of business applications are built on services internally, and therefore use an explicit object model and pattern catalog, it will be easy to fit them into a service-oriented system landscape. Once these applications become prevalent, and once the corresponding integration platforms become available, we will experience the next major shift in how our customers architect their system landscapes. Business processes spanning multiple applications and enterprises can be configured and reconfigured as necessary. Innovative business practices can be implemented and supported by new applications that are integrated into the overall system landscape through services.

For example, high-tech OEMs of all sizes are rapidly shedding their manufacturing capabilities and many of them are outsourcing their logistics. If they do not own the warehouses, the transportation, or the manufacturing how are they going to manufacture the right product and manage to get it at the right time to the customer? The answer is to integrate their suppliers and partners into their business processes. This is a perfect opportunity for Web services.

By giving their contract manufacturer, strategic suppliers, and third-party logistics providers visibility into their demand and coordinating the manufacture and delivery of goods through Web services they are becoming more agile and flexible. These manufacturers are narrowing their focus on design, marketing, and sales. They are outsourcing practically everything else. However, they still have to integrate all these partners into their demand and supply chain processes, and these partners change, depending on the product, the geography, or even the customer. How can they possibly be so flexible and still deliver to their customer? Many of them are turning to Web service infrastructures.

They use a set of customer-facing services for their sales channel to configure, place, and track orders, and they use a set of supplier- and partner-facing services to communicate demand and order information. They also have services facing their third-party logistics provider so that when the order is picked up, they can give the customer information about where the shipment is and when it is going to be delivered.

This allows them to be very flexible. They can rapidly switch suppliers if the current one doesn't meet standards. Alternatively, if they want to expand into a new geography through a new channel partner, they can connect to the partner through Web services and get them up and running quickly. Furthermore, they can attain this level of agility at a very reasonable cost. Web services infrastructures have already proven to lower integration costs.

What Can You Do Today?
Although we have a way to go in designing and developing the next generation of business applications, there is a lot a customer can do today in order to be well positioned to take advantage of the opportunities that lie ahead. To wait for the next release is not necessarily an option! So given your current applications, what can you do?

First of all, every enterprise should formulate their vision for an enterprise architecture. Industry consortia can be important discussion forums for this, as can contacts with vendors. Select one or two of your strategic vendors, invite them to discuss vision and strategy with you, and work with those whose vision is closely aligned with yours. Develop a strategy for how to approach new projects so that the vision will become real.

Make sure to exploit existing Web services technology as far as possible. Use a service-oriented approach for your next application development or integration project. If your applications don't offer the services you need, consider building them as part of your project.

Align all new projects with your strategy. A combination of platform work, such as developing an enterprise object model, and tactical projects, such as building a custom application for a new business practice, can get you closer to where you want to be, step by step.

The evolution of Web services can be viewed on three levels: the standards themselves, the software products built around these standards, and the way enterprises deploy these products to support their business. Of course it is the last aspect that is driving the evolution. The ultimate goal is to create adaptive business networks that allow enterprise to drive business innovation and rapidly adapt to changes in the environment. To support this, software products will ultimately be service oriented business platforms built on a complete set of interoperability standards.

Behind us we have the first inflection point in this evolution: the first set of interoperability standards triggered activity both within software companies and their enterprise customers. Enterprises are today using Web services for various integration scenarios, but not yet in a coordinated way. Software companies are designing and building products based on the standards and architected in a new, service oriented way.

When these new products are adopted, we will have reached the second inflection point: Enterprises will now have enough application services available out-of-the-box and the platform tools at hand to base their whole IT landscapes on services. This is what will get us to the adaptive business networks we envision.