CBDI Web Services Roadmap - Guiding the Transition to Web Service and SOA

Sponsored by

Sponsored Papers

Vendor Web Services Roadmap Report - IBM. IBM's strategy today is centered around "Business On Deman...
more

Many Organizations are now undertaking development of service oriented architectures, but the probab...
more

Whilst investment in Application Integration initiatives over the last decade has undoubtedly improv...
more

A Web Services Maturity Model cont'd...

Four Phases

It seems probable that most organizations will go through four major phases in the service oriented environment.

• Phase 1 - Early Learning

In this phase it's a technical service world. Early activity is exploratory and mostly about better application integration. Activity is mostly internal and an extension to current activity, and managed under existing processes.

The WSnn protocol efforts in the W3C and more recently in OASIS have now been running for some 3 years, and the all important trio - SOAP, WSDL and UDDI, together with the important WS-I profiles allow a basic level of description and interoperability of messages that establish a first base. We might regard this as completion of a major phase of work, that will permit certain types of application, which might be more easily defined by what they do not permit - for example reliability, transactionality, security etc.

In this phase the predominant service deployments will be:

• mostly internal
• low-risk external
• using existing security mechanisms
• not mission critical
• focused on better application integration

CBDI has reported on numerous case studies that have shown how Web Services can be used to good effect with the basic protocols. For example we might instance Amazon that is very clearly set on reengineering their business and enabling their affiliates to do the same. But these are in a minority. Whilst there will undoubtedly be some new and innovative uses of Web Services, this phase will be best characterized as a period in which many enterprises do their early learning, and some existing applications are wrapped in order to establish some elementary level of service oriented architecture.

It's clear there's a big difference between adopting Web Services and becoming a service oriented organization. Web Services in the end are simply a better form of middleware. Moving beyond that level requires a change in business practices not just technology.

• Phase 2 - Integration

In the second phase business drivers will start to become important. This was clear from our survey carried out in February 2003 (CBDI Web Services Usage Survey), which showed business appreciation of the benefits from better, loose coupled architecture. In this second phase SOA is a critical objective, which is justified by greater business flexibility, and creating an application environment where "business" capabilities are exposed as services which can be easily reused and upgraded.

The focus in this phase remains very much on internal activity and external services continue to use current practices and technical architectures for inter company interoperability.

The adoption of SOA does introduce some important delivery process change, as organizations introduce service delivery and management tools and techniques, but in the main this phase is managed by an extension of current practices.

It has become something of a "cause celebre" that the absence of Web Services security has been a significant inhibitor to adoption. However this bears re-examination. Those that have wanted to secure Web Services using what we have defined as first phase protocols, have used pre-existing security mechanisms (SSL, CORBA etc) without difficulty. What the WS-Security protocols bring is heterogeneous message level security, which we suggest is relevant to more sophisticated architectures that also need enhanced guarantees of reliability and availability.

And it seems most likely that the combination of security and reliability will form the basis for a second phase of Web Services adoption that will be characterized by the ability to offer some guarantees around service levels. It also seems likely that this phase will be characterized by some level of business process integration. From a timing perspective it seems highly likely that the BPEL specification will prevail and will, by the early 2004 timeframe, provide a reasonable basis for business process integration. This is corroborated by the primary vendors supporting BPEL that plan to have tools available in this period.

In this phase the predominant service deployments will be:

• business process oriented
• project level implementation
• mostly internal usage
• based on a more mature understanding of SOA with better separation of layers as BPEL scripting is implemented


• Phase 3 - Reengineering

  The third phase represents the point in time when the man waving the red flag in front of the automobile is no longer required. When the automobile and the mobile phone are designed for purpose, rather than to replicate prior practices simply because they are de facto conventions.

  The term reengineering is perhaps not popular because it has been subject to misuse, but it is highly relevant in this phase where the very purpose of services will undergo change, as well as the delivery technologies and practices.

  The primary discontinuity or driver will be the transition to "business product" thinking, where the service becomes the business product. The notion of information technology and systems requirements goes away, because the requirements are fully synonymous with the business product design.

  A key pre-condition and driver to this phase is mature measurement and management functionality, as well as ubiquitous external interoperability enabled by mature security and usage profile standards. As we have indicated earlier, it is likely that this phase will coincide with the mature availability of massively simpler (and presumably cheaper) implementation technology which will act as a significant stimulus to action.

  For some time now there has been evident something of a disconnect between the ambitions of the major platform vendors and the standards processes. The issue here is management, the protocols which are being worked under the OASIS WSDM committee.

  The issue is that enterprise level services will only become acceptable to enterprises when the provider can provide rock solid guarantees of availability, reliability and performance, AND can dynamically manage the environment to deliver that, AND prove in retrospect that the commitments have been met. This will be the major inhibitor to more widespread use and reuse of services. Although there are an extraordinary number of ISV's that have entered this Web Service Management marketplace, the typical enterprise is going to a) see a standards based platform as a prerequisite for implementation and b) prefer to wait and see what the major platform vendors provide. Early adopters will always move with early adopting tools vendors, but the mainstream market will wait.

  The current emphasis placed upon on-demand or demand based environments is going to be a critical enabler of the end point service vision. What's interesting is to compare the efforts of the major vendors. In our previous reports on this area, we have characterized the efforts of HP and Sun as primarily about utility computing - creating a flexible technical environment, whereas IBM is increasingly focused on the business opportunities that are enabled by on-demand environments. This increased visibility is going to be essential in our Third Phase, as we have pointed out in a recent CBDI Newswire - Groundhog Day. As one correspondent accurately commented, it's going to be essential to "Convince the main board to address enterprise IS architecture seriously, not as a modeling exercise and not as a means of controlling IT but as an integrated part of business strategy planning."

  Our Third Phase is therefore the point in time when service oriented applications are fully integrated with the business from organizational, funding, and product development perspectives, to name just a few.

  In this phase the predominant service deployments will be:

  • enterprise level, with common services used right across organizations
  • services implemented as an integral part of business products
  • supported by guarantees and standards based measurement and monitoring systems
  • enabled by a wider selection of available services both inside and external to organizations
  
  
• Phase 4 - Maturity

One hesitates to write and comment about maturity because it is high probability that by the time we ever reached a mature state that new concepts will have superseded what we are working with today. However in our fourth phase and mature state, services are ubiquitous. Federated services collaborate and create complex products with individual services provided from potentially many providers. Services are designed to support the consumer in their ecosystem, not in a company specific system or service. Many business services such as perhaps the BT authentication service discussed earlier may have become pervasive standards. This process will take considerably longer than the relatively trivial matter of setting protocol standards, which can be carried out by a small group of technologists sitting in isolation on top of a mountain. In contrast business service standards will require huge investment in marketing and process reengineering that may take years to come to maturity.

Timing

Summary

So don't be surprised when you hear the major vendors de-emphasizing Web Services. They know they have over reached themselves on this issue, and that they need to redirect attention for a time. On demand, demand computing, efficiency and cost reduction are all good themes that play to today's economic circumstances. This is where the vendors will address their efforts, and not unreasonably establish the necessary operating environment for a world where use of services is pervasive.

For the same reasons the vendors are characterizing Web Services as "just another form of middleware". They realize they have to adjust their messages for a while, and play down the strategic importance of Web Services, until they are ready for mainstream deployment. So focusing on just another form of middleware is resetting expectations to be relevant to applications that can reasonably be implemented during our Phase One and Two.

It's important to understand that this is a longer term game we are playing. Web Services is merely a phase in a longer running process which will eventually deliver a comprehensive service oriented environment. It's going to take time, but there's much that can be cost justified today, which equally contributes building blocks to the overall project.

The primary message in this report is the criticality of managing the process of evolution. Those businesses that sit back and allow technology matters to drive their use of services will almost certainly fail to survive what looks like a profound change in business practices, which will occur in the second half of this decade.

What's needed is a balanced approach to building the technology with today's tools, recognizing that these will certainly be superseded in due course. The most important issues are establishing the loose coupled SOA architecture that hides the implementation and allows transparent technology upgrade, while the reengineered product planning and process management practices deliver on innovative new business services that provide real competitive edge in the right timeframe.

Roadmap Actions